“왜 같은 화면인데 어떤 웹은 빠르고, 어떤 웹은 느리게 느껴질까?”
프론트엔드 개발자가 성능 최적화를 고민할 때 가장 먼저 이해해야 할 것은 브라우저가 화면을 그리는 구조(렌더링)와 이를 측정하는 웹 성능 지표들이다.
이번 글에서는 렌더링 흐름, CRP(Critical Rendering Path), 그리고 FCP, LCP, CLS 같은 Web Vitals를 정리해보도록 하자.
🧱 브라우저 렌더링 기본 흐름
브라우저는 HTML 파일을 받아 다음 과정을 거쳐 화면에 내용을 그린다:
1. HTML 파싱 → DOM 트리 생성
2. CSS 파싱 → CSSOM 트리 생성
3. DOM + CSSOM → Render Tree 생성
4. Layout (각 요소의 위치 계산)
5. Paint (픽셀로 그리기)
6. Composite (레이어 합성 후 최종 출력)이 모든 과정을 거쳐야 비로소 사용자가 화면을 볼 수 있다.
⚡ Critical Rendering Path(CRP)란?
CRP는 브라우저가 최초 화면을 그릴 때까지 필요한 자원 로딩과 처리 경로를 의미한다.
대표적인 CRP 지연 요소:
<link>로 불러오는 CSS → CSSOM 생성 전까지 렌더링 중단<script>가 DOM 파싱을 막음 (unlessasyncordefer)- 폰트, 이미지, JS 등이 렌더링 블로킹 자원이 되기 쉬움
개선 전략
| 방법 | 설명 |
|---|---|
defer, async | JS 파싱/실행 지연 |
preload, prefetch | 중요 리소스 우선 로딩 |
| CSS 분리 & 최소화 | CRP를 빠르게 만들기 위한 핵심 |
📊 주요 성능 지표 – Web Vitals
Google은 웹 사용자 경험을 측정하기 위해 Web Vitals를 정의했다.
이 지표들은 Lighthouse, PageSpeed Insights 등에서 확인할 수 있다.
1. 🟡 FCP (First Contentful Paint)
처음으로 텍스트, 이미지, SVG 등이 화면에 그려지는 시점
- 사용자가 “화면이 뜨기 시작했다”는 느낌을 받는 순간
- 1초 이내면 좋은 사용자 경험
2. 🟢 LCP (Largest Contentful Paint)
화면에서 가장 큰 콘텐츠가 로딩되는 시점
- 메인 이미지나 큰 텍스트 등 실질적인 로딩 완료 시점
- 2.5초 이내가 이상적
3. 🔵 CLS (Cumulative Layout Shift)
페이지 로딩 중 레이아웃이 튀는 현상(shift)의 누적 점수
- 버튼 클릭하려는데 레이아웃이 밀려서 다른 버튼 눌리는 현상 👎
- 점수 0.1 미만이 이상적
4. 🟠 TTI (Time to Interactive)
페이지가 완전히 반응 가능한 시점
- JS 실행 중 페이지가 멈춰 있는 경우 TTI가 지연됨
- 프레임 드랍, 긴 JS 태스크, 메인 스레드 블로킹 등이 원인
🔍 Lighthouse & Web Vitals 분석 기초
- Chrome DevTools → Lighthouse 탭
- PageSpeed Insights
- Core Web Vitals 확장 프로그램 (실시간 측정)
주요 개선 팁 요약
| 문제 | 해결 방안 |
|---|---|
| FCP 지연 | 폰트 지연 로딩, 이미지 지연 로딩 |
| LCP 느림 | 메인 이미지 지연 → preload |
| CLS 높음 | width/height 명시, 광고 영역 고정 |
| TTI 늦음 | JS 최적화, 코드 스플리팅, lazy load |
✅ 프론트엔드 개발자를 위한 실전 팁
- 렌더링 차단 요소(스크립트, 폰트, CSS)를 최대한 줄여야 FCP/LCP가 빨라진다
- CLS는 디자인 문제로 많이 생기므로 레이아웃 안정성을 신경 써야 한다
- Chrome DevTools → Performance 탭에서 실제 렌더링 흐름을 시각화해보자
- 개발/배포 후에는 Lighthouse 점검을 습관처럼 돌리는 게 좋다
✍️ 마무리 요약
성능 개선은 감이 아니라 데이터로 해야 한다. 브라우저의 렌더링 구조와 Web Vitals 지표를 이해하면 무엇이 병목인지 정확히 파악할 수 있고, 사용자 경험을 개선할 수 있다.
Tech Blog