Web Vitals 이름을 외웠는지가 아니라, 체감 지표에서 원인 도구로 내려가는 분석 흐름과 측정 환경 설계 감각이 있는지를 가른다.
Chrome DevTools 성능 분석은 Core Web Vitals(LCP·INP·CLS) 같은 사용자 체감 지표를 먼저 잡고, Performance 패널 타임라인에서 그 지표를 악화시킨 작업이 무엇인지 거꾸로 추적한다. LCP는 렌더링 경로와 리소스 로드, INP는 메인 스레드 Long Task, CLS는 레이아웃 점프가 원인 후보다. Network의 waterfall과 TTFB로 전송 비용을, Memory의 Heap Snapshot으로 누수를, Coverage로 안 쓰는 JS/CSS를 본다. 결론은 단일 점수가 아니라 "어떤 작업이 어떤 지표를 깎고 있는가"를 연결해 고칠 순서를 정하는 것이다.
LCP가 느려서 원인을 추적했더니 이미지가 아니라 렌더 차단 CSS였던 경험이 있다면 "지표만으로는 원인을 못 가린다"는 이야기로 엮을 수 있다
Long Task로 INP를 깎고 있는 무거운 핸들러를 쪼개거나 디퍼한 경험이 있다면 메인 스레드 점유를 어떻게 분해했는지 풀 수 있다
Heap Snapshot으로 Detached DOM을 찾아 SPA 누수를 잡은 경험이 있다면 라우팅 시나리오를 어떻게 설계했는지 연결할 수 있다
Coverage로 안 쓰는 JS를 찾아 코드 스플리팅 기준을 잡은 경험이 있다면 번들 크기와 LCP의 인과를 어떻게 끊어 봤는지 말할 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.