코드 땜장이

큰 이미지가 느릴 때 렌더링 속도를 높이는 법: 포맷, 크기, 로딩 전략 한 번에 정리 빠른 답 원본 이미지를 그대로 내려보내지 말고 실제 표시 크기와 DPR에 맞춘 파일을 서버나 CDN에서 변환해 제공합니다. AVIF와 WebP를 우선하되 로 JPEG 또는 PNG fallback을 함께 두어 브라우저 호환성을 확보합니다. 첫 화면 핵심 이미지는 무조건 lazy 처리하지 말고 fetchpriority="high" 또는 preload를 검토하고, 나머지 이미지만 지연 로딩합니다. Network와 Performance 패널에서 전송 크기, 선택된 소스, 디코드 시간, LCP 후보 이미지를 함께 봐야 병목을 정확히 찾을 수 있습니다. 브라우저 렌더링 흐름을 중심으로 초안을 다시 정리하고, 현재 기준의 포맷 지원과 우선순위 관련 공식 문서 포인트를 짧게 확인하겠습니다. 오래된 설명과 지금 설명이 갈리는 부분도 함께 정리해서 발행용 본문으로 맞추겠습니다.# 큰 이미지가 느릴 때 렌더링 속도를 높이는 법: 포맷, 크기, 로딩 전략 한 번에 정리 목차 시간 흐름으로 이해하기 흐름으로 보기 브라우저 안에서 실제로 무슨 순서로 일어날까 큰 이미지가 느린 이유는 다운로드만이 아니다 현재 기준 포맷 선택과 오래된 설명의 차이 요청 시점과 우선순위 다루기 표시 크기와 레이아웃 안정성 맞추기 CDN, 캐시, 변환 파이프라인에서 줄일 수 있는 비용 DevTools로 병목 확인하기 무엇부터 바꾸면 좋을까 공식 문서와 레퍼런스 시간 흐름으로 이해하기 HTML 파싱 시점 img 는 비교적 빨리 발견되지만 CSS 배경 이미지는 CSS를 읽은 뒤에야 요청 후보가 되는 경우가 많습니다. → 전송 시점 파일 크기, 캐시 적중 여부, CDN 거리 차이가 첫 바이트와 다운로드 시간을 바꿉니다. → 디코드 시점 압축된 파일을 화면용 비트맵으로 풀어내는 과정에서 CPU와 메모리를 사용합니다. → 레이아웃 시점 이미지 비율이 늦게 확정되면 자리 계산이 다시 일어나고 CL...

웹 애플리케이션 성능 최적화, 로딩 경로별로 정리하는 핵심 방법 빠른 답 첫 화면에 필요 없는 JavaScript는 분리하고 늦게 불러와야 초기 로딩이 빨라집니다. 이미지와 비디오는 화면에 보일 때 로드하고, 크기와 포맷을 먼저 줄여야 체감 성능이 좋아집니다. 캐시는 단순 저장이 아니라 정적 자산과 HTML의 정책을 다르게 가져가야 효과가 큽니다. 최적화는 감으로 하지 말고 Network, Performance, Lighthouse 같은 측정 결과로 우선순위를 잡아야 합니다. 목차 왜 웹 성능은 로딩 경로로 봐야 할까 흐름으로 보기 요청 시작과 리소스 다운로드에서 생기는 병목 파싱과 실행: DOM, CSSOM, JavaScript가 서로 만나는 지점 렌더링: 렌더 트리, 레이아웃, 페인트, 컴포지팅의 비용 초기 로딩을 줄이는 설정 무거운 자산을 늦게 가져오는 방법 재방문 속도를 높이는 캐시 전략 DevTools로 병목을 반복 측정하는 방법 흔한 오해와 함께 보는 정리 포인트 왜 웹 성능은 로딩 경로로 봐야 할까 같은 300KB라도 언제 내려오고 무엇을 막느냐에 따라 체감은 크게 달라집니다. 첫 화면에 바로 필요한 CSS 300KB와, 아직 열지 않은 설정 페이지의 JavaScript 300KB는 사용자 경험에 미치는 영향이 다릅니다. 그래서 성능 최적화는 파일 크기를 줄이는 일에만 머물지 않고, 어떤 자원이 어떤 단계의 병목이 되는지 파악하는 작업에 가깝습니다. 브라우저 관점에서 병목은 보통 세 갈래로 나타납니다. 네트워크에서 늦게 내려오는 경우, JavaScript 파싱과 실행 때문에 메인 스레드가 오래 묶이는 경우, 렌더링 단계에서 레이아웃과 페인트가 반복되는 경우입니다. 이 세 지점을 로딩 경로 하나로 묶어 보면 코드 스플리팅, 레이지 로딩, 캐시, CSS 최적화가 각각 어디에 영향을 주는지 자연스럽게 연결됩니다. 흐름으로 보기 이 순서를 먼저 잡아두면 최적화 기법의 위치가 정리됩니다. 코드 스플리팅과 defer 는 초기 다운로드와...

브라우저 주소창에 URL을 입력하면 화면이 뜨기까지: DNS부터 렌더링까지 빠른 답 주소 입력 뒤 바로 화면이 뜨는 것이 아니라 DNS 조회, 연결 수립, TLS 협상, HTTP 요청, 렌더링이 순서대로 진행됩니다. 첫 화면 속도는 서버 응답 시간만이 아니라 CSS 다운로드, JavaScript 실행, 레이아웃·페인트 비용에도 크게 영향을 받습니다. HTTPS 사이트는 요청 전에 인증서 검증과 키 협상이 들어가므로 TLS 단계가 별도 병목이 될 수 있습니다. 병목은 Chrome DevTools의 Network와 Performance 탭으로 네트워크 지연과 렌더링 비용을 나눠 확인하는 것이 가장 빠릅니다. 목차 흐름으로 보기 왜 이 과정을 같이 봐야 하나 연결이 열리기 전: DNS, TCP, TLS, HTTP 응답이 화면이 되는 핵심: DOM, CSSOM, 렌더 트리 레이아웃, 페인트, 컴포지팅은 각각 무엇을 하나 첫 화면을 늦추는 흔한 비용 DevTools로 병목을 어떻게 찾나 구성과 설정으로 줄일 수 있는 비용 면접과 실무에서 자주 틀리는 설명 흐름으로 보기 1 DNS 조회 ↓ 2 TCP 연결 ↓ 3 TLS 협상 ↓ 4 HTTP 요청/응답 ↓ 5 DOM·CSSOM 생성 ↓ 6 레이아웃·페인트·컴포지팅 이 여섯 단계는 웹 페이지 로딩의 가장 큰 뼈대입니다. 앞쪽은 리소스를 받아오는 네트워크 흐름이고, 뒤쪽은 받은 데이터를 실제 화면으로 바꾸는 브라우저 렌더링 흐름입니다. 페이지가 느릴 때 원인을 정확히 찾으려면 이 둘을 섞지 말고 끊어서 봐야 합니다. 왜 이 과정을 같이 봐야 하나 브라우저 주소창에 https://www.google.com 을 입력하는 행동은 단순히 “서버에 요청한다”로 끝나지 않습니다. 브라우저는 먼저 어디로 연결할지 찾아야 하고, 안전한 연결을 만들어야 하며, HTML과 정적 자원을 받아온 뒤 그것을 다시 화면용 구조로 바꿔야 합니다. 사용자가 보는 첫 화면은 서버 응답 그 자체가 아니라, 브라우저가 수행한 렌더링 파이...

브라우저는 HTML을 어떻게 화면으로 바꿀까: 렌더링 파이프라인과 성능 포인트 빠른 답 브라우저는 DOM -> CSSOM -> 렌더 트리 -> 레이아웃 -> 페인트 -> 컴포지팅 순서로 화면을 만든다. 크기와 위치를 바꾸면 레이아웃 비용이 커지고, 색상·그림자·배경 변경은 주로 페인트 비용을 만든다. transform과 opacity 중심 애니메이션은 컴포지팅 단계에서 처리돼 더 부드럽게 동작하는 경우가 많다. 성능 문제는 감으로 추측하지 말고 Chrome DevTools의 Performance, Layers, Paint flashing으로 먼저 확인한다. 목차 데이터 흐름과 상태 소유권부터 봐야 하는 이유 브라우저 렌더링 파이프라인을 왜 알아야 할까: 화면은 느린데 API는 빠른 이유 HTML이 픽셀이 되기까지: DOM, CSSOM, 렌더 트리, 레이아웃, 페인트, 컴포지팅 어떤 변경이 어디까지 전파될까: 스타일 계산, 레이아웃, 페인트, 컴포지팅 프런트엔드에서 자주 만드는 안티패턴 성능에 유리한 렌더링 구성 예시: CSS 속성 선택과 숨김 전략 렌더링 타이밍: React 리렌더링과 브라우저 페인트는 다르다 Chrome DevTools로 병목 확인하기 자주 하는 오해와 실무 체크리스트 데이터 흐름과 상태 소유권부터 봐야 하는 이유 브라우저 렌더링 파이프라인은 브라우저가 화면을 그리는 방법을 설명합니다. 하지만 실무에서 성능 문제가 시작되는 지점은 대개 그보다 앞입니다. 어떤 상태가 바뀌었고, 그 상태 변화가 어떤 컴포넌트 재계산과 DOM 변경으로 이어졌는지가 먼저입니다. 브라우저는 갑자기 화면을 느리게 만드는 주체라기보다, 애플리케이션이 만든 결과를 계산하고 그리는 쪽에 가깝습니다. 그래서 프런트엔드 성능은 브라우저 지식만으로는 잘 풀리지 않습니다. 상태를 누가 소유하는지, 변경이 어떤 방향으로 흐르는지, 작은 상호작용이 왜 큰 트리의 리렌더링으로 번지는지를 같이 봐야 합니다. 상태는 한 곳이 소유하고, 아래로 전...