프런트엔드 웹 성능 컨설턴트

프런트엔드, 사용자가 체감하는 모든 것이 결정되는 곳

브라우저는 가차 없다. HTML을 파싱하고, CSS를 발견하며, JavaScript를 실행한다. 그리고 크리티컬 리소스가 도착하기 전까지는 아무것도 렌더링할 수 없다. 미니파이되지 않은 200KB의 CSS 파일, 렌더 블로킹으로 로드되는 폰트, head에 주입된 analytics 스크립트 — 이런 요소 하나하나가 사용자가 화면에 무언가를 보기까지의 순간을 늦춘다.

제가 수행하는 감사에서 마주치는 Core Web Vitals 문제의 대부분은 프런트엔드 문제다. preload 없이 PNG 형식 2MB의 hero 이미지로 악화된 LCP. DOM 전체 리렌더링을 트리거하는 이벤트 리스너 때문에 무거워진 INP. 로딩 후 페이지에 삽입되는 광고나 임베드로 인해 발생하는 CLS.

서드파티 스크립트, 방 안의 코끼리

제가 감사하는 대부분의 이커머스 사이트에서 서드파티 스크립트는 실행되는 JavaScript의 50%~80%를 차지한다. Tag managers, 트래킹 픽셀, A/B testing, 챗봇, 추천 위젯 — 하나하나가 용량과 네트워크 요청을 더한다.

문제는 누구도 누적 영향을 보지 않는다는 것이다. 80KB짜리 tag manager 하나쯤은 괜찮아 보인다. 하지만 그것이 각자 고유 로직을 실행하는 태그 15개를 불러오면 Long Tasks가 연달아 발생하고 INP가 폭증한다. 해법이 항상 전면 삭제는 아니다 — 각 스크립트의 실제 영향을 감사(audit)하고, 더 이상 쓰지 않는 것은 제거하며, 나머지는 비차단 방식으로 로드하는 것이다.

실무에서의 Critical Rendering Path

개념은 단순하다: 사용자가 보이는 콘텐츠를 표시하기 전에 브라우저가 다운로드하고 실행해야 하는 것을 최소화하는 것이다. 실제로는 모든 것에 걸쳐 있다 — head의 태그 순서, 폰트 로딩 전략, JavaScript 코드 스플리팅, 크리티컬 CSS 추출.

이 주제가 흥미로운 이유는 스택마다 함정이 다르기 때문이다. SSR을 사용하는 React 사이트는 TTFB는 매우 좋을 수 있지만, hydration 때문에 INP가 처참할 수 있다. 플러그인 12개가 달린 WordPress는 종종 400KB의 CSS를 로드하는데, 그중 90%는 현재 페이지에 적용되지 않는다. SFCC 사이트는 흠잡을 데 없는 HTML을 제공하면서도 개인화 레이어 때문에 3MB의 JavaScript를 주입하기도 한다.

중요한 것을 측정하기

Lighthouse 점수는 출발점으로 유용하지만 실제 경험을 반영하지는 않는다. 어떤 사이트는 랩 환경에서는 점수 95를 받지만, 실제 필드에서는 LCP가 4초일 수 있다. 그 차이는 네트워크, 디바이스, headless 모드에서는 로드되지 않는 서드파티들에서 비롯된다.

CrUX — Chrome User Experience Report — 데이터는 최근 28일 동안 실제 사용자가 겪은 경험을 측정한다. Google이 랭킹에서 Core Web Vitals을 평가할 때 사용하는 유일한 데이터 소스다. 그리고 각 최적화의 효과를 측정하기 위해 제가 사용하는 소스이기도 하다.