페이지의 최대 콘텐츠 페인트 (LCP)는 개선하기가 복잡할 수 있으며, 종종 여러 움직이는 부분과 절충점이 수반됩니다. 이 게시물에서는 개발자가 최적화 노력을 기울여야 할 부분을 결정하기 위해 웹 전반의 실제 페이지 로드에서 발생하는 필드 데이터를 살펴봅니다.
기본적인 LCP 조언: 이미지 크기를 줄이세요.
대부분의 웹 페이지에서 LCP 요소는 이미지입니다. 따라서 LCP를 개선하는 가장 좋은 방법은 LCP 이미지를 최적화하는 것이라고 생각하는 것이 당연합니다.
LCP가 도입된 이후 5년 가량 이러한 사항이 헤드라인을 장식하는 조언이 되었습니다. 이미지의 크기와 압축이 적절해야 하며 이때 21세기 이미지 형식을 사용하세요. Lighthouse는 이러한 추천을 제공하기 위해 3가지 다른 감사도 제공합니다.
<ph type="x-smartling-placeholder">
<ph type="x-smartling-placeholder">이것이 일반적인 조언인 이유 중 하나는 과도한 바이트는 측정하기 쉽고 이미지 압축 도구를 제안하기 쉽기 때문입니다. 빌드 및 배포 파이프라인에 따라 구현하기도 쉬울 수 있습니다.
그렇다면 그렇게 하세요! 사용자에게 전송하는 바이트 수가 줄어들어 대부분이 이득입니다. 웹에 불필요하게 큰 이미지를 제공하는 사이트가 많지만 기본적인 압축만으로도 해결할 수 있습니다.
하지만 LCP에 소요되는 시간을 일반적으로 어디에서 확인하는지 알아보기 위해 Chrome에서 사용자의 현장 성능 데이터를 살펴보기 시작하면서 이미지 다운로드 시간이 병목 현상으로 거의 발생하지 않는다는 것을 알게 되었습니다.
대신 LCP의 다른 부분이 훨씬 더 큰 문제입니다.
LCP 하위 부분 분류
LCP를 개선할 수 있는 가장 큰 기회가 무엇인지 파악하기 위해 LCP 최적화에 설명된 대로 LCP 하위 부분의 데이터를 살펴보았습니다.
페이지와 프레임워크마다 페이지의 LCP 요소가 되는 요소를 로드하고 표시하는 데 서로 다른 접근 방식을 취할 수 있지만 각 요소는 다음과 같은 하위 부분으로 나눌 수 있습니다.
이 도움말에서 인용하는 내용은 다음과 같습니다.
- 첫 바이트까지의 시간 (TTFB)
- 사용자가 페이지 로드를 시작한 시점부터 브라우저가 실행될 때까지의 시간입니다. HTML 문서 응답의 첫 바이트를 수신합니다.
- 리소스 로드 지연
- TTFB와 브라우저가 LCP 리소스 로드를 시작하는 시점 사이의 시간입니다. 만약
LCP 요소는 렌더링하는 데 리소스 로드가 필요하지 않습니다. 이번에는
0입니다. - 리소스 로드 시간
- LCP 리소스 자체를 로드하는 데 걸리는 시간입니다. LCP가
요소를 렌더링하는 데 리소스 로드가 필요하지 않습니다. 이번에는
0입니다. - 요소 렌더링 지연
- LCP 리소스 로드가 완료된 시점과 LCP 요소 사이의 시간입니다. 있습니다.
실제 내비게이션 성능 데이터
| LCP 등급 | TTFB (ms) | 이미지 로드 지연 (밀리초) | 이미지 로드 시간 (밀리초) | 렌더링 지연 (밀리초) |
|---|---|---|---|---|
| 좋음 | 600 | 350 | 160 | 230 |
| 개선 필요 | 1,360 | 720 | 270 | 310 |
| 나쁨 | 2,270명 | 1,290 | 350 | 360 |
이 게시물에서는 Chrome의 하위 리소스 이미지 LCP와 함께 페이지 탐색의 데이터를 사용하여 LCP 하위 부분을 살펴보았습니다. 이전에 이러한 종류의 데이터를 살펴본 적이 있지만 실제 사용자가 페이지의 LCP를 기다리는 동안 어디에서 시간을 보내는지 확인하기 위해 필드 데이터에서 수집한 데이터는 없었습니다.
Core Web Vitals와 마찬가지로, Google은 CrUX 데이터 세트에서 각 출처의 각 LCP 하위 부분의 75번째 백분위수 (p75)를 취하여 p75 값의 분포 4개 (하위 부분마다 하나씩)를 도출했습니다. 이러한 분포를 요약하기 위해 4개의 LCP 하위 부분 각각에 대해 모든 출처에서 해당 값의 중앙값을 취했습니다.
마지막으로 출처를 '좋음', '개선 필요', '나쁨'에 따라 버킷으로 분할합니다. 75번째 백분위수의 LCP 이를 통해 LCP가 우수한 출처와 LCP가 낮은 출처를 어떻게 구분하는지 보여줍니다.
LCP 이미지의 크기를 줄이시겠어요? 이번에는 데이터를 사용해 보겠습니다.
로드 시간은 LCP 리소스(이 경우 이미지)를 가져오는 데 걸리는 시간을 측정합니다. 이 시간은 일반적으로 이미지의 바이트 수에 비례하므로 해당 바이트 수를 줄이기 위한 모든 성능 권장 사항이 있습니다.
이전 그래프에서 시간의 흐름을 볼 때 한 가지 눈에 띄는 것은 이미지 로드 시간에 많은 시간이 소요되지 않는다는 것입니다. 실제로 모든 LCP 버킷에서 가장 짧은 LCP 하위 부분입니다. 로드 시간이 양호한 LCP 출처에 비해 불량한 LCP 출처의 경우 더 길지만 여전히 시간이 많이 소비되지는 않습니다.
LCP가 낮은 대다수의 출처는 LCP 이미지를 다운로드하는 데 p75 LCP 시간의 10% 미만을 소비합니다.
예. 이미지를 최적화해야 하지만 이는 LCP 개선의 일부일 뿐입니다. 이 데이터를 보면 일반적인 웹 출처의 경우 압축 방식이 아무리 정교한 데도 LCP 전체의 잠재적 밀리초 이득이 작다는 것을 알 수 있습니다.
<ph type="x-smartling-placeholder">마지막으로 한 가지 놀라운 사실은 느린 로드 시간이 모바일 장치와 모바일 네트워크의 품질로 인한 것이었습니다. 한때 일반적인 전화기에서 유선으로 연결된 데스크톱 컴퓨터와 동일한 이미지를 다운로드하는 데 몇 배 더 오래 걸릴 것으로 예상했을 수도 있습니다. 데이터에 따르면 더 이상 그렇지 않습니다. LCP가 낮은 출처의 경우 p75 이미지 로드 시간 중앙값이 데스크톱보다 모바일에서 20% 느립니다.
첫 바이트까지의 시간 (TTFB)
네트워크를 요청하는 탐색의 경우 TTFB는 항상 다소 시간이 걸립니다. DNS 조회를 수행하고 연결을 시작하는 데 시간이 걸립니다. 물리학을 능가할 수 없습니다. 요청이 서버에 도달하기 위해 유선과 광학 케이블을 통해 현실 세계를 통과해야 하며, 그러면 응답이 다시 돌아가야 합니다. LCP가 양호한 출처의 중앙값도 75번째 백분위수에서 TTFB에 0.5초 이상을 소비합니다.
그러나 LCP 원본의 TTFB 불일치는 개선의 여지가 있음을 보여줍니다. LCP가 낮은 출처의 최소 절반 이상에서 2,270밀리초의 p75 TTFB는 단독으로 p75 LCP가 2.5초의 '양호'한 속도보다 더 빠르지 않음을 거의 보장합니다. 있습니다. 이 시간을 적당히 줄이면 LCP가 상당히 개선될 것입니다.
물리학을 이길 수는 없지만, 해낼 수 있는 일이 있습니다. 예를 들어 사용자가 서버와 매우 다른 위치에 있는 경우가 많다면 CDN을 통해 콘텐츠를 서버에 가깝게 제공할 수 있습니다.
자세한 내용은 TTFB 최적화 가이드를 참조하세요.
간과된 느린 LCP의 원인인 리소스 로드 지연
TTFB는 개선할 수 있지만 모든 개선사항이 물리학적으로 제약을 받는다면, 리소스 로드 지연을 잠재적으로 제거할 수 있으며, 실제로는 제공 아키텍처에 의해서만 제한됩니다.
이 하위 부분은 HTML 응답 (TTFB)의 첫 번째 바이트가 도착한 시점부터 브라우저가 LCP 이미지 요청을 시작하는 시점까지의 시간을 측정합니다. Google은 수년 동안 LCP 이미지를 다운로드하는 데 걸리는 시간에 초점을 맞춰 왔지만, 브라우저에 다운로드 시작을 알리기도 전에 시간을 낭비하는 경우가 종종 있었습니다.
LCP가 낮은 사이트 중앙값은 LCP 이미지 다운로드를 실제로 다운로드하는 시간의 거의 4배에 달하며, TTFB와 이미지 요청 사이에는 1.3초가 소요됩니다. 이는 단일 하위 부분에서 소진된 2.5초 LCP 예산의 절반이 넘는 것입니다.
종속 항목 체인은 긴 로드 지연의 일반적인 원인입니다. 더 간단한 쪽은 스타일 시트를 로드하는 페이지로, 브라우저에서 레이아웃을 수행한 후에 LCP가 되는 배경 이미지를 설정합니다. 이러한 모든 단계는 브라우저가 LCP 이미지 다운로드를 시작하기도 전에 진행되어야 합니다.
'시작자'를 기록하는 HTTP 보관 공개 크롤링 데이터 사용 LCP 이미지 간 네트워크 요청 체인을 살펴보면 요청 체인 길이와 느린 LCP 간의 명확한 상관관계를 확인할 수 있습니다.
<ph type="x-smartling-placeholder">
<ph type="x-smartling-placeholder">핵심은 LCP가 페이지 레이아웃에 배치되기 전에 로드를 시작할 수 있도록 가능한 한 빨리 LCP를 브라우저에 알리는 것입니다. 이를 위해 사용할 수 있는 몇 가지 도구가 있습니다. 예를 들어 HTML의 기존 <img> 태그를 사용하면 미리 로드 스캐너가 태그를 빠르게 찾아 다운로드를 시작할 수 있고, <img>가 아닌 이미지를 위한 <link rel="preload"> 태그 (또는 HTTP 헤더)를 사용할 수 있습니다.
브라우저가 우선순위를 지정할 리소스를 결정하도록 돕는 것도 중요합니다. 페이지가 로드되는 동안 페이지에서 많은 요청을 하는 경우 특히 그렇습니다. 브라우저에서 많은 리소스가 로드되고 레이아웃이 발생한 후에야 LCP 요소가 무엇인지 알 수 없기 때문입니다. 잠재적 LCP 요소에 fetchpriority="high" 속성 주석을 달고 loading="lazy"를 피해야 합니다. 그러면 브라우저에서 리소스 로드를 즉시 시작하도록 지정할 수 있습니다.
로드 지연 최적화에 대한 추가 조언을 읽어보세요.
렌더링 지연
렌더링 지연은 브라우저에서 LCP 이미지가 로드되고 준비된 시점부터의 시간을 측정하지만, 어떤 이유로 인해 화면에 표시되기까지 지연이 발생합니다. 이미지가 준비되면 기본 스레드를 차단하는 긴 작업일 때도 있고, 숨겨진 요소를 표시하기 위한 UI 선택일 수도 있습니다.
일반적인 웹 출처의 경우 렌더링이 크게 지연될 것으로 보이지는 않지만 최적화 중에는 이전에 다른 하위 부분에서 소요했던 시간 때문에 렌더링 지연을 생성할 수 있습니다. 예를 들어 페이지가 LCP 이미지를 미리 로드하여 빠르게 사용할 수 있게 되면 더 이상 긴 로드 지연이 발생하지 않지만, 렌더링 차단 스타일 시트 또는 페이지가 표시되기 전에 모든 JavaScript 로드를 완료해야 하는 클라이언트 측 렌더링 앱에서 페이지 자체가 이미지를 표시할 준비가 되지 않은 경우 LCP는 여전히 느리게 로드되며 대기에 소요된 시간이 렌더링 지연으로 표시됩니다. 이러한 이유로 LCP와 관련하여 서버 측 렌더링이나 정적 HTML이 유리한 경우가 많습니다.
자체 콘텐츠가 영향을 받는 경우 렌더링 지연 최적화에 관한 추가 도움말을 참고하세요.
모든 하위 부분 확인
LCP를 효과적으로 최적화하려면 개발자가 이미지 최적화에만 집중하는 것이 아니라 페이지 로드를 전체적으로 살펴봐야 합니다. 개선의 여지가 더 크므로 LCP에 항상 확인해야 합니다.
현장에서 이 데이터를 수집하기 위해 web-vitals 라이브러리의 기여 분석 빌드에는 LCP 하위 부분의 타이밍이 포함됩니다. Chrome 사용자 환경 보고서 (CrUX)에 아직 이 모든 데이터가 포함되어 있지는 않지만, TTFB 및 LCP에 관한 항목은 있으므로 시작에 불과합니다. 향후 이 게시물에 사용된 데이터를 CrUX에 포함할 수 있기를 바라며, 이와 관련된 더 많은 소식을 기대해 주시기 바랍니다.
LCP 하위 부분을 로컬에서 테스트하려면 웹 바이탈 확장 프로그램 또는 이 도움말의 JavaScript 스니펫을 사용해 보세요. Lighthouse는 '최대 콘텐츠 페인트 요소'에 분류를 포함합니다. 감사를 참조하세요. DevTools Performance(출시 예정) 패널에서 LCP 하위 부분에 대한 자세한 조언을 확인하세요.