Chrome DevTools 성능 패널로 LCP 진단하기
스로틀링된 트레이스를 기록하고, 4가지 LCP 하위 요소를 확인하여 가장 오래 걸리는 단계를 찾으세요.
이 가이드는 Largest Contentful Paint (LCP) 허브의 일부입니다. Chrome DevTools Performance 패널이라는 단일 도구를 다룹니다. 스로틀링이 적용된 트레이스를 기록하고, LCP의 4가지 하위 요소를 확인한 뒤, 무엇을 먼저 수정해야 할지 확실히 알 수 있습니다.
Table of Contents!
DevTools는 가장 마지막 단계입니다
Performance 패널은 lab tool입니다. 단 한 번의 페이지 로드를 하나의 기기, 하나의 네트워크(여러분의 환경)에서 측정합니다. 그렇기 때문에 시작점이 아니라 마무리 단계로 적합합니다.
field data로 시작하십시오. CrUX는 애초에 LCP가 문제인지 여부를 알려줍니다. RUM 데이터는 실제 사용자에게 어떤 페이지와 어떤 요소가 느린지 알려줍니다. 이 워크플로우는 LCP 문제 해결 및 식별에서 단계별로 다룹니다. 그 후 DevTools는 남은 단 하나의 질문, 즉 '왜'에 답합니다.
field data를 건너뛰면, 우연히 테스트한 페이지를 우연히 연결된 네트워크 환경에 맞춰 최적화하게 됩니다. 이는 제가 거의 모든 감사(audit)에서 목격하는 패턴입니다. 개발자의 기기에서는 통과하지만 CrUX p75는 실패하고 모두가 혼란스러워합니다. 여러분은 광랜에 연결된 빠른 노트북을 측정한 것입니다. 하지만 사용자는 기차 안에서 보급형 안드로이드를 사용하고 있습니다.
라이브 메트릭 뷰
DevTools(Windows와 Linux에서는 Ctrl+Shift+I, Mac에서는 Cmd+Option+I)를 열고 Performance 탭으로 이동하십시오. 이 패널은 더 이상 빈 화면으로 열리지 않습니다. 기록을 시작하기도 전에, 브라우징 중 로컬로 측정된 현재 페이지의 LCP, CLS, INP를 포함한 라이브 메트릭 뷰를 보여줍니다.
이 뷰에서 LCP 작업에 유용한 세 가지가 있습니다. 첫째, LCP 요소의 이름을 알려주며, 마우스를 올리면 페이지에서 해당 요소가 강조 표시됩니다. 따라서 브라우저가 어떤 이미지나 헤딩을 선택했는지 추측할 필요가 없습니다. 또한 이 뷰에서 field data를 활성화할 수 있습니다. 그러면 DevTools가 해당 URL과 오리진의 CrUX 수치를 가져와 로컬 값 옆에 보여줍니다. 만약 로컬 LCP가 0.8초인데 field p75가 3.1초라면, 그 격차가 첫 번째 발견입니다. 여러분의 기기는 대표성이 없으며 스로틀링은 선택이 아닌 필수입니다.
빠른 팁: DevTools를 열지 않고도 페이지에서 LCP 요소를 강조 표시하고 싶다면 무료 Core Web Vitals Visualizer Chrome 확장 프로그램을 사용하십시오.
기록하기 전 스로틀링 적용
개발자 기기에서 스로틀링 없이 측정한 트레이스는 거의 무가치합니다. 수치는 훌륭하게 나오겠지만, 실제 사용자 경험과는 전혀 일치하지 않습니다. 기록하기 전에 패널에서 CPU와 네트워크 스로틀링을 모두 설정하십시오.
- CPU 스로틀링: 모바일 테스트의 기본값으로 4x slowdown을 사용하십시오. 20x는 저사양 기기와 비슷합니다. 최신 Chrome 버전은 특정 기기에 맞춰 프리셋을 보정할 수도 있습니다. Calibrate 옵션은 현재 하드웨어의 속도를 기준으로 저사양 및 중급 모바일 프리셋을 생성합니다. 빠른 데스크톱에서의 4x는 오래된 노트북에서의 4x와 완전히 다른 기기이기 때문에 이 기능은 중요합니다.
- 네트워크 스로틀링: Slow 4G를 사용하십시오. 이는 Chrome이 이름을 바꾸기 전 Fast 3G로 불렸던 프리셋이며, Lighthouse가 모바일 환경을 시뮬레이션할 때 사용하는 값입니다. 더 나은 연결 상태를 테스트할 때는 가벼운 옵션인 Fast 4G를 사용합니다.
field data가 활성화되면, DevTools는 실제 사용자 경험과 일치하는 스로틀링 프리셋을 추천하기도 합니다. 이를 사용하십시오. 이 설정에 대한 자세한 근거는 Core Web Vitals를 위한 최적의 DevTools 네트워크 설정 가이드를 확인하십시오.
페이지 로드 기록
"Record and reload" 버튼을 클릭하십시오. Chrome은 빈 페이지로 이동하여 트레이스를 시작하고 페이지를 로드한 뒤, 로드가 끝난 몇 초 후 자동으로 기록을 중지합니다. LCP를 분석할 때는 기록 중에 아무것도 건드릴 필요가 없습니다. 페이지에 손을 대지 마십시오.
빠른 팁: 확장 프로그램이 비활성화된 시크릿 창에서 기록하십시오. 확장 프로그램은 모든 페이지에 스크립트를 주입하며, 이 스크립트들은 사이트와 아무런 관련이 없는 long task로 트레이스에 나타납니다.
LCP breakdown 인사이트 분석
트레이스가 완료되면, 왼쪽의 Insights 사이드바에 DevTools가 발견한 항목들이 나열됩니다. 여기서 필요한 것은 LCP breakdown(이전 Chrome 버전에서는 LCP by phase)입니다. 이는 LCP 시간을 4개의 하위 요소로 나눕니다.
| 하위 요소 | 측정 대상 | 해결 방법 |
|---|---|---|
| Time to First Byte | 탐색 시작부터 HTML 응답의 첫 바이트가 도착할 때까지 | TTFB 개선하기 |
| Resource load delay | TTFB부터 브라우저가 LCP 리소스 다운로드를 시작할 때까지 | Resource Load Delay 최적화하기 |
| Resource load duration | LCP 리소스를 다운로드하는 데 소요된 시간 | Resource Load Duration 최적화하기 |
| Element render delay | 리소스 다운로드가 완료된 순간부터 요소가 페인트될 때까지 | Element Render Delay 최적화하기 |
웹폰트가 없는 텍스트 LCP의 경우 다운로드할 것이 없습니다. 따라서 두 가지 리소스 하위 요소는 0이 되며, 전체 시간은 TTFB와 render delay가 전부입니다.
인사이트에서 하위 요소 위로 마우스를 올리면 DevTools가 타임라인에서 해당 구간을 정확히 강조합니다. 클릭하면 타임라인이 확대되어 그 구간에 속한 요청과 작업들을 볼 수 있습니다. field data를 활성화했다면, 인사이트는 각각의 lab 하위 요소 옆에 CrUX p75 값을 함께 보여줍니다(사이트에 대한 CrUX 이미지 LCP 데이터가 있을 경우). 이 비교는 패널에서 가장 과소평가된 기능입니다. 오후 내내 문제를 수정하는 데 시간을 쏟기 전에, 지금 보고 있는 트레이스가 실제 사용자 경험과 유사한지 알려주기 때문입니다.
건강한 breakdown은 어떤 모습이어야 할까요? Google의 가이드라인은 두 가지 delay 하위 요소가 0에 가까워야 하며(각각 LCP의 10% 미만), 거의 모든 시간이 TTFB와 실제 다운로드에 쓰여야 한다고 권장합니다. 수백만 건의 페이지 로드를 분석한 자체 Core Web Vitals 연구는 현실이 이와 얼마나 거리가 먼지 보여줍니다. TTFB가 48%, load delay가 24%, load duration이 겨우 10%, render delay가 17%를 차지합니다. 다시 한번 읽어보십시오. 중간값에 해당하는 사이트에서, 이 두 가지 대기 단계는 다운로드 자체보다 4배나 많은 시간을 낭비합니다. 이 단계에서는 아무것도 다운로드되지 않습니다. 렌더링되는 것도 없습니다. 브라우저는 더 일찍 시작할 수 있었던 작업을 기다릴 뿐이며, 이것이 바로 이 두 하위 요소를 가장 먼저 살펴봐야 하는 이유입니다.
LCP request discovery 인사이트
LCP가 이미지인 경우, 확인해볼 만한 두 번째 인사이트가 있습니다. 바로 LCP request discovery입니다. 이는 LCP 요청에 대해 세 가지를 검사합니다.
- 이미지(또는 preload)에
fetchpriority="high"가 적용되었습니까? - 초기 HTML 문서에서 이 요청을 찾을 수 있습니까?
- lazy loading이 올바르게 적용되지 않았습니까?
실패한 검사 항목은 discovery 문제의 원인을 가리킵니다. 또한 인사이트는 타임라인에 이미지 다운로드가 시작될 수 있었던 시점과 손실 중인 예상 시간을 주석으로 표시합니다. 이 세 가지 실패 원인에는 각각 구체적인 해결책이 존재하며, Resource Load Delay 가이드에서 모두 다룹니다.
직접 타임라인 분석하기
인사이트는 일반적인 상황을 다룹니다. 그 외의 모든 경우는 직접 트레이스를 읽어야 합니다. LCP에는 세 가지 트랙이 중요합니다.
Timings 트랙은 FCP, LCP, DCL, load 이벤트의 마커를 보여줍니다. LCP 마커는 요소가 페인트된 순간입니다. 여러분이 진단하는 모든 문제는 이 마커의 왼쪽에 있습니다.
Network 트랙은 모든 요청을 보여줍니다. LCP 리소스를 찾아 얼마나 오래 걸렸는지뿐만 아니라 언제 시작되었는지 확인하십시오. 3초짜리 LCP에서 2.5초에 시작되는 요청은 discovery 문제이며, 아무리 이미지 압축을 많이 해도 해결할 수 없습니다. 처음 도착한 HTML 바이트에서부터 해당 이미지를 발견할 수 있게 만들었다면, 브라우저가 head를 파싱하는 동안 다운로드가 시작되었을 것입니다.
Main 트랙은 main thread 작업을 보여줍니다. long task는 모서리에 빨간색 삼각형으로 표시됩니다. 찾아야 할 패턴은 다음과 같습니다. LCP 리소스 다운로드가 끝났지만, LCP 마커가 수백 밀리초 더 오른쪽에 위치한 경우입니다. 이 간격이 바로 element render delay이며, 빨간색 표시가 있는 작업 중 하나가 대개 그 원인입니다. 해당 작업 위에 마우스를 올려 어떤 스크립트 때문인지 확인하십시오. 제 경험상 여러분의 코드보다는 태그 관리자나 동의 스크립트(consent script)가 원인인 경우가 훨씬 많았습니다.
발견한 문제 해결하기
breakdown에서 가장 큰 비중을 차지하는 하위 요소가 다음 단계를 결정합니다. TTFB, Resource Load Delay, Resource Load Duration 또는 Element Render Delay 중 하나입니다. LCP 요소가 이미지인 경우, LCP 이미지 최적화 가이드가 이 4가지를 모두 관통합니다.
마지막으로 덧붙이자면, 사전 렌더링된 페이지는 4가지 하위 요소가 모두 거의 0으로 나타납니다. 사용자가 클릭하기 전에 브라우저가 모든 작업을 수행했기 때문입니다. LCP 문제가 랜딩 페이지가 아닌 사이트 내 탐색(navigation)에서 발생한다면, speculation rules를 통해 이 모든 진단 과정을 건너뛸 수 있습니다.
