품질·성능·보안 · 공식 문서
LCP 개선 방법, 네 구간으로 원인 찾는 점검 순서
LCP 시간을 첫 바이트까지의 시간, 리소스 로드 지연, 리소스 로드 시간, 요소 렌더링 지연의 4구간으로 나눠 어느 구간이 긴지부터 봅니다. 구글 크롬 팀 문서는 이름에 「지연」이 든 두 구간을 0에 가깝게 줄이라고 적었고, 고치는 순서는 로드 지연, 렌더링 지연, 로드 시간, 첫 바이트 순입니다.
LCP 는 첫 화면에서 가장 큰 이미지나 글 덩어리가 다 그려질 때까지 걸린 시간입니다. 숫자 하나로 나오지만 원인은 서버, 이미지, 렌더링 차단으로 갈립니다.
그래서 숫자를 구간으로 나눠야 고칠 자리가 보입니다. 구글 크롬 팀이 공개한 구간 분석법을 원문 그대로 따라갑니다.
발견 01
LCP 시간은 4구간의 합이라, 긴 구간 하나를 찾으면 원인이 좁혀집니다
| 구간(Lighthouse 한국어 화면) | 영어 이름 | 권장 몫 | 원문 정의 |
|---|---|---|---|
| 첫 바이트까지의 시간 | Time to First Byte | 약 40% | The time from when the user initiates loading the page until the browser receives the first byte of the HTML document response.사용자가 페이지 로드를 시작한 때부터 브라우저가 HTML 문서 응답의 첫 바이트를 받을 때까지의 시간. |
| 리소스 로드 지연 | Resource load delay | 10% 미만 | The time between TTFB and when the browser starts loading the LCP resource.첫 바이트를 받은 뒤부터 브라우저가 LCP 리소스를 받기 시작할 때까지의 시간. |
| 리소스 로드 시간 | Resource load duration | 약 40% | The duration of time it takes to load the LCP resource itself.LCP 리소스 자체를 받는 데 걸리는 시간. |
| 요소 렌더링 지연 | Element render delay | 10% 미만 | The time between when the LCP resource finishes loading and the LCP element rendering fully.LCP 리소스를 다 받은 뒤부터 LCP 요소가 화면에 다 그려질 때까지의 시간. |
Collectively, they add up to the full LCP time. In some cases, an optimization applied to one part won't improve LCP, it will just shift the time saved to another part.
네 구간을 더하면 LCP 전체 시간이 된다. 한 구간을 줄여도 LCP 는 그대로이고 줄인 시간이 다른 구간으로 옮겨 갈 뿐인 경우가 있다.
이미지를 압축했는데 LCP 가 그대로인 경우가 이 문장의 예입니다. 줄인 시간은 렌더링 지연으로 옮겨 가고 합은 그대로 남습니다.
구간별 시간은 PageSpeed Insights 아래쪽 Lighthouse 진단의 「LCP 분석」 항목과 크롬 개발자 도구 성능 패널에서 봅니다.
발견 02
「지연」이 든 2구간이 길다면 이미지나 렌더링 차단이 원인입니다
| 신호 | 가리키는 원인 | 원문 |
|---|---|---|
| 첫 바이트까지의 시간이 길다 | 서버 응답, 리디렉션, 캐시 미적중 | A high TTFB can be due to multiple server redirects, visitors located far away from the nearest site server, visitors on poor network conditions, or an inability to use cached content due to query parameters.첫 바이트가 늦는 원인은 여러 번의 서버 리디렉션, 서버에서 먼 방문자, 나쁜 네트워크, URL 파라미터 때문에 캐시를 못 쓰는 경우 등이다. |
| 첫 바이트와 FCP 사이가 길다 | 렌더링 차단 CSS·스크립트 | A large delta between TTFB and FCP could indicate that the browser needs to download a lot of render-blocking assets.첫 바이트와 FCP 사이가 길면 브라우저가 렌더링 차단 리소스를 많이 받아야 한다는 뜻일 수 있다. |
| FCP 와 LCP 사이가 길다 | 대표 이미지·글을 스크립트가 늦게 넣음 | A large delta between FCP and LCP indicates that the LCP resource is either not immediately available for the browser to prioritize (for example, text or images that are managed by JavaScript rather than being available in the initial HTML), or that the browser is completing other work before it can display the LCP content.FCP 와 LCP 사이가 길면 LCP 리소스를 브라우저가 바로 찾지 못하거나(스크립트가 넣는 글·이미지 등), 그리기 전에 다른 일을 하고 있다는 뜻이다. |
| 실험실과 실제 사용자 값이 다르다 | 실제 사용자 데이터를 기준으로 판단 | If Lighthouse and CrUX disagree, then CrUX likely provides a more accurate picture of your user experience.Lighthouse 와 실제 사용자 데이터(CrUX)가 다르면 CrUX 쪽이 사용자 경험을 더 정확히 보여 줄 가능성이 높다. |
| 요소 렌더링 지연의 원인 | 원문 |
|---|---|
| head 의 CSS·동기 스크립트 | Rendering of the entire page is blocked due to stylesheets or synchronous scripts in the <head> that are still loading.아직 받는 중인 head 의 스타일시트나 동기 스크립트 때문에 페이지 전체 렌더링이 차단된다. |
| 스크립트가 요소를 늦게 넣음 | The LCP resource has finished loading, but the LCP element has not yet been added to the DOM (it's waiting for some JavaScript code to load).LCP 리소스는 다 받았지만, 스크립트를 기다리느라 LCP 요소가 아직 DOM 에 들어가지 않았다. |
| A/B 테스트 도구가 요소를 숨김 | The element is being hidden by some other code, such as an A/B testing library that's still determining what experiment the user should be in.어떤 실험을 보여 줄지 정하는 중인 A/B 테스트 라이브러리 같은 다른 코드가 요소를 숨기고 있다. |
| 긴 작업이 기본 스레드를 붙잡음 | The main thread is blocked due to long tasks, and rendering work needs to wait until those long tasks complete.긴 작업이 기본 스레드를 붙잡고 있어 렌더링이 그 작업이 끝나기를 기다린다. |
발견 03
고치는 순서는 로드 지연부터이고, 첫 바이트는 손댈 범위가 작아 마지막에 둡니다
They're presented in order, starting with the optimizations that are likely to have the biggest impact.
아래 네 단계는 효과가 클 가능성이 높은 것부터 순서대로 적었다.
| 순서 | 구간 | 고치는 일 | 원문 |
|---|---|---|---|
| 1 | 리소스 로드 지연 | 대표 이미지를 HTML 의 img 로, 지연 로딩 빼기, fetchpriority="high" | A good rule of thumb is that your LCP resource should start loading at the same time as the first resource loaded by that page.LCP 리소스는 그 페이지가 처음 받는 리소스와 같은 때에 받기 시작하는 것이 좋은 기준이다. |
| 2 | 요소 렌더링 지연 | 렌더링 차단 CSS 줄이기, head 동기 스크립트 defer, 긴 작업 쪼개기 | Rendering of the entire page is blocked due to stylesheets or synchronous scripts in the <head> that are still loading.아직 받는 중인 head 의 스타일시트나 동기 스크립트 때문에 페이지 전체 렌더링이 차단된다. |
| 3 | 리소스 로드 시간 | 표시 크기에 맞춘 이미지, 최신 형식, 같은 출처에서 내보내기, 캐시 | Our research shows that the load duration portion of LCP tends not to be a significant bottleneck for most sites.구글 조사로는 대부분 사이트에서 LCP 리소스를 내려받는 시간 자체는 큰 병목이 아니다. |
| 4 | 첫 바이트까지의 시간 | 리디렉션 줄이기, CDN·캐시, 분석용 URL 파라미터가 캐시를 깨는지 확인 | A high TTFB can be due to multiple server redirects, visitors located far away from the nearest site server, visitors on poor network conditions, or an inability to use cached content due to query parameters.첫 바이트가 늦는 원인은 여러 번의 서버 리디렉션, 서버에서 먼 방문자, 나쁜 네트워크, URL 파라미터 때문에 캐시를 못 쓰는 경우 등이다. |
| 자주 놓치는 설정 | 원문 |
|---|---|
| 대표 이미지의 지연 로딩 | Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP.LCP 이미지는 절대 지연 로딩하지 않는다. 언제나 불필요한 로드 지연이 생겨 LCP 가 나빠진다. |
| fetchpriority 를 여러 이미지에 | However, setting a high priority on more than one or two images makes priority setting unhelpful in reducing LCP.높은 우선순위를 이미지 한두 개보다 많이 주면 LCP 를 줄이는 데 도움이 되지 않는다. |
| CDN 캐시 미적중 | Another common cause is when cached content cannot be used from a CDN edge server, and all requests must be directed all the way back to the origin server.첫 바이트가 늦는 또 다른 흔한 원인은 CDN 엣지 서버의 캐시를 쓰지 못해 모든 요청이 원본 서버까지 가는 경우다. |
| 미리 만든 HTML(정적 생성) | If prerendering is possible with your architecture, it's generally a better choice for performance.구조상 미리 렌더링(정적 생성)이 가능하다면 대체로 성능에 더 나은 선택이다. |
이미지 용량은 셋째 순서입니다. 원문은 대부분 사이트에서 이 구간이 큰 병목이 아니라고 적었습니다. 크기와 형식 고르기는 「SEO 이미지 사이즈」 편에 자세히 적었습니다.
서버·이미지·스크립트·글꼴 전체의 고치는 순위는 「웹 페이지 속도 개선」 편에 정리했습니다.
발견 04
같은 LCP 2.5초 초과라도 B2B·B2C·B2G 는 긴 구간이 다릅니다
예시 ① 해외 바이어용 기업 사이트(B2B)
국내 서버 하나로 해외 방문을 받으면 첫 바이트까지의 시간이 깁니다. 구간 표에서 이 칸이 절반을 넘는다면 CDN 이 첫 손질입니다.
제품 상세 페이지의 대표 사진은 HTML 의 img 로 두어 리소스 로드 지연을 줄입니다.
예시 ② 슬라이드 배너가 첫 화면인 쇼핑몰(B2C)
배너 슬라이드를 스크립트가 그리면 FCP 와 LCP 사이가 벌어집니다. 첫 장 이미지만 HTML 에 두고 fetchpriority="high" 를 줍니다.
A/B 테스트 도구가 첫 화면을 숨겼다가 보여 준다면 요소 렌더링 지연이 길어집니다. 테스트 범위를 첫 화면 밖으로 옮깁니다.
예시 ③ 글 위주의 공공기관 누리집(B2G)
가장 큰 요소가 공지 제목 같은 글 덩어리라면 리소스 로드 시간은 0이고, 웹 글꼴과 렌더링 차단 CSS 가 남은 원인입니다.
글꼴이 늦으면 글자가 비어 보이는 시간이 LCP 에 더해집니다. font-display 설정부터 확인합니다.
그럼 느린 LCP 는 어떤 순서로 점검하나요?
- pagespeed.web.dev 위쪽 실제 사용자 데이터에서 LCP 가 2.5초를 넘는지, 이 URL 데이터인지 출처 전체 데이터인지 확인합니다.
- 아래쪽 Lighthouse 진단에서 「LCP 분석」을 펼쳐 LCP 요소가 이미지인지 글인지와 4구간의 시간을 적습니다.
- 리소스 로드 지연이 길면 대표 이미지가 HTML 에 img 로 있는지, loading="lazy" 가 붙었는지 봅니다.
- 요소 렌더링 지연이 길면 head 의 CSS·동기 스크립트와 A/B 테스트 도구를 봅니다.
- 리소스 로드 시간이 길면 이미지 크기·형식을, 첫 바이트까지의 시간이 길면 리디렉션·CDN·캐시를 봅니다.
- 고친 뒤 같은 진단으로 구간 시간이 다른 구간으로 옮겨 가지 않았는지 보고, 28일 뒤 실제 사용자 데이터로 확인합니다.
조사 방법
- web.dev (Google Chrome) 「Optimize Largest Contentful Paint」 (문서 수정일 2025-03-31) · 최종 확인일 2026-10-25 · https://web.dev/articles/optimize-lcp
- web.dev (Google Chrome) 「Largest Contentful Paint (LCP)」 (문서 수정일 2025-09-04) · 최종 확인일 2026-10-25 · https://web.dev/articles/lcp
- GoogleChrome/lighthouse (GitHub) 「ko.json (Lighthouse 13.5.0 한국어 화면 문구)」 · 최종 확인일 2026-10-25 · https://github.com/GoogleChrome/lighthouse/blob/main/shared/localization/locales/ko.json
- Google for Developers 「About PageSpeed Insights」 (문서 수정일 2024-10-21) · 최종 확인일 2026-10-18 · https://developers.google.com/speed/docs/insights/v5/about
- 구간 4개와 권장 몫, 고치는 순서는 web.dev 「Optimize Largest Contentful Paint」 원문을 옮긴 것입니다. 신호와 원인을 짝지은 표는 편집 판단입니다.
- 예시 ①②③은 이해를 돕기 위해 만든 가상 상황이며, 실제 기업·기관의 사례가 아닙니다.
- 원문은 영어판(hl=en)이고, 구간 이름(첫 바이트까지의 시간·리소스 로드 지연·리소스 로드 시간·요소 렌더링 지연·LCP 분석)은 Lighthouse 한국어 화면 문구(ko.json)를 따랐습니다.