Core Web Vitals 설명: LCP, INP, CLS를 쉬운 말로 이해하기

Core Web Vitals는 웹사이트의 성격 검사가 아닙니다

Core Web Vitals는 종종 알 수 없는 점수표처럼 다뤄집니다. 어떤 페이지에 빨간 숫자가 뜨고, 누군가 Slack에 스크린샷을 올리면, 팀은 JavaScript 프레임워크를 두고 논쟁을 시작합니다.

그다지 유용한 방식은 아닙니다.

Core Web Vitals를 이해하는 더 나은 방법은 더 단순합니다. 실제 사람이 실제 기기에서 페이지를 사용할 만하다고 느끼는지를 나타내는 세 가지 측정값입니다. 성능, 접근성, 품질의 모든 측면을 포착하지는 못합니다. 하지만 흔히 사용자를 짜증 나게 하는 세 가지 문제는 잘 잡아냅니다.

• 주요 콘텐츠가 나타나는 데 너무 오래 걸립니다.
• 사용자가 무언가를 하려고 할 때 페이지가 느리게 반응합니다.
• 사용자가 읽거나 탭하는 동안 레이아웃이 이리저리 움직입니다.

이 세 가지가 바로 Core Web Vitals인 LCP, INP, CLS입니다.

Google은 이를 페이지 경험 신호의 일부로 사용하지만, SEO 관점이 이것을 신경 써야 하는 가장 좋은 이유는 아닙니다. 더 좋은 이유는 느리고, 흔들리고, 반응이 둔한 페이지가 사용자의 시간을 낭비하기 때문입니다. 그런 페이지는 전환율도 낮고, 지원 부담도 커지며, 시간이 지날수록 더 나빠지는 경향이 있습니다.

세 가지 지표를 한 문장씩 정리하면

자세히 들어가기 전에, 쉬운 말로 정리하면 다음과 같습니다.

• LCP, 또는 Largest Contentful Paint는 주요 시각 콘텐츠가 로드되는 데 걸리는 시간을 측정합니다.
• INP, 또는 Interaction to Next Paint는 방문 전반에 걸쳐 사용자 상호작용에 페이지가 얼마나 빠르게 반응하는지 측정합니다.
• CLS, 또는 Cumulative Layout Shift는 페이지가 예기치 않게 얼마나 많이 움직이는지 측정합니다.

일반적인 기준값은 다음과 같습니다.

| Metric | Good | Needs improvement | Poor | |---|---:|---:|---:| | LCP | 2.5s 이하 | 2.5s–4.0s | 4.0s 초과 | | INP | 200ms 이하 | 200ms–500ms | 500ms 초과 | | CLS | 0.1 이하 | 0.1–0.25 | 0.25 초과 |

이 숫자들은 보통 실제 사용자 방문의 75번째 백분위수를 기준으로 평가됩니다. 이 점이 중요합니다. 완벽한 실험실 테스트 한 번을 만드는 것이 목표가 아닙니다. 더 느린 휴대폰과 더 불안정한 네트워크를 사용하는 사람들을 포함해, 대부분의 사용자에게 좋은 경험을 제공하는 것이 목표입니다.

자동화된 보고서를 보고 어디서 시작해야 할지 모르겠다면, 진단과 공포를 분리하는 것이 도움이 됩니다. 이 작업 흐름은 Lighthouse 보고서를 당황하지 않고 읽는 방법에 대한 별도 가이드에서 더 자세히 다룹니다.

LCP: 페이지가 언제 로드된 것처럼 느껴지는가?

Largest Contentful Paint는 뷰포트 안에서 가장 큰 시각 콘텐츠 요소가 렌더링되는 시간을 측정합니다. 실제로는 보통 다음과 같은 요소입니다.

• 히어로 이미지,
• 큰 제목,
• 대표 기사 이미지,
• 제품 이미지,
• 큰 텍스트 블록.

LCP는 모든 스크립트, 추적 픽셀, 화면 아래 이미지가 언제 로딩을 끝냈는지를 묻는 지표가 아닙니다. 이 지표가 묻는 것은 이것입니다. 사용자가 보러 온 핵심 요소가 언제 보이기 시작했는가?

그래서 LCP는 예전의 “페이지 로드 시간”보다 더 사람 중심적인 지표입니다. 페이지가 기술적으로는 늦게 로딩을 끝내더라도 주요 콘텐츠가 빠르게 나타나면 빠르게 느껴질 수 있습니다. 반대도 마찬가지입니다. 히어로 영역이 여전히 비어 있거나, 흐릿하거나, 렌더링 지연으로 막혀 있는 동안에도 load 이벤트는 발생할 수 있습니다.

LCP가 나빠지는 흔한 원인

대부분의 나쁜 LCP 문제는 몇 가지 예측 가능한 곳에서 발생합니다.

1. 느린 서버 응답

HTML 문서가 늦게 도착하면, 그 뒤의 모든 작업도 늦게 시작됩니다.

1. 렌더링을 차단하는 CSS 또는 JavaScript

브라우저가 콘텐츠를 가지고 있지만 아직 그릴 수 없는 상태입니다.

1. 최적화되지 않은 히어로 이미지

가장 큰 요소가 너무 크거나, 형식이 맞지 않거나, 우선순위가 낮거나, 실수로 lazy-load되고 있습니다.

1. 텍스트 렌더링을 지연시키는 웹 폰트

큰 제목이 LCP 요소일 수 있으며, 폰트 로딩이 이를 지연시키거나 시각적으로 바꿀 수 있습니다.

1. 클라이언트 사이드 렌더링 지연

의미 있는 콘텐츠를 보여주기 전에 큰 JavaScript 번들이 필요하다면 LCP가 악화됩니다.

LCP를 개선하는 방법

실제 LCP 요소부터 시작하세요. 브라우저가 무엇을 측정하는지 알기 전에는 임의의 자산을 최적화하지 마세요.

실용적인 해결책은 다음과 같습니다.

• HTML을 빠르게 제공하세요. 적절한 곳에 캐시를 사용하고, 백엔드 작업을 줄이며, 느린 리디렉션을 피하세요.
• LCP 이미지를 최적화하세요. 올바른 크기, 압축, 형식을 사용하세요.
• 화면 상단 히어로 이미지는 lazy-load하지 마세요.
• 실제로 우선순위가 가장 높은 주 이미지에만 fetchpriority="high"를 신중하게 사용하세요.
• 렌더링 지연을 의미 있게 줄일 때에만 critical CSS를 inline하세요.
• 첫 번째 의미 있는 렌더링 전에 필요한 JavaScript를 줄이세요.
• font-display: swap 또는 의도적인 다른 폰트 전략을 사용하세요.

이미지와 폰트는 자주 문제가 되는 원인입니다. 이미지의 경우, 절충점은 단순히 “파일이 작으면 좋다”가 아닙니다. 형식 선택, 인코딩 노력, 브라우저 지원이 모두 중요합니다. 그래서 우리는 AVIF가 WebP보다 나은 경우와 그렇지 않은 경우에 대한 실용적인 의사결정 트리를 따로 정리해 두었습니다. 글자가 많은 페이지에서는 많은 사이트가 실제로 쓰는 것보다 더 많은 폰트 파일을 제공하기 때문에 웹 폰트는 여전히 가장 쉬운 성능 개선 기회 중 하나입니다.

INP: 페이지가 터치에 반응하는가?

Interaction to Next Paint는 반응성을 측정합니다. 더 구체적으로는 사용자의 상호작용과, 브라우저가 그 상호작용을 처리한 뒤 다음 시각적 업데이트가 일어나기까지의 지연을 봅니다.

상호작용에는 다음과 같은 것들이 포함됩니다.

• 버튼 클릭,
• 메뉴 탭,
• 체크박스 선택,
• 폼 필드에 입력,
• 아코디언 열기.

INP는 2024년에 First Input Delay를 대체해 Core Web Vital이 되었습니다. 좋은 변화였습니다. First Input Delay는 첫 번째 상호작용만 봤습니다. INP는 더 넓습니다. 페이지 방문 전체의 상호작용을 고려하고, 지연이 큰 상호작용을 페이지의 반응성 점수로 보고합니다.

쉬운 말로 하면, INP는 로드된 것처럼 보이지만 실제로는 멈춘 듯한 페이지를 잡아냅니다.

아마 이런 페이지를 사용해 본 적이 있을 것입니다. 준비된 것처럼 보입니다. 메뉴를 탭합니다. 0.5초 동안 아무 일도 일어나지 않습니다. 다시 탭합니다. 그러면 두 가지 일이 한꺼번에 일어납니다. 이것이 INP 문제입니다.

INP가 나빠지는 흔한 원인

INP는 보통 메인 스레드 문제입니다. 브라우저는 반응하고 싶지만 JavaScript, 렌더링 작업, 레이아웃 계산이 길을 막고 있습니다.

대표적인 원인은 다음과 같습니다.

• 큰 JavaScript 번들,
• 비용이 큰 이벤트 핸들러,
• 클라이언트 렌더링 앱의 hydration 작업,
• 메인 스레드를 두고 경쟁하는 서드파티 스크립트,
• 페이지 로드 이후의 오래 걸리는 작업,
• 작은 상호작용으로 촉발되는 복잡한 DOM 업데이트,
• 코드가 레이아웃 값을 반복해서 읽고 쓰는 layout thrashing.

마케팅 태그, 분석 도구, 채팅 위젯, 동의 배너가 모두 영향을 줄 수 있습니다. 이것이 “모든 것을 제거하라”는 뜻은 아닙니다. 페이지의 모든 스크립트에는 비용이 있고, 상호작용 지연은 그 비용이 자주 드러나는 지점이라는 뜻입니다.

INP를 개선하는 방법

INP 개선은 하나의 마법 같은 속성보다, 메인 스레드 경쟁을 줄이는 일에 가깝습니다.

유용한 접근법은 다음과 같습니다.

• 긴 JavaScript 작업을 더 작은 조각으로 나누세요.
• 필수적이지 않은 작업은 페이지를 사용할 수 있게 된 뒤로 미루세요.
• 사용하지 않는 JavaScript는 단순히 minify하는 데 그치지 말고 제거하세요.
• 이벤트 핸들러를 작고 예측 가능하게 유지하세요.
• 작은 상태 변화 때문에 인터페이스의 큰 부분을 다시 렌더링하지 마세요.
• 가능한 경우 단순한 시각 상태에는 CSS를 사용하세요.
• 서드파티 스크립트를 감사하고 필요한 곳에서만 로드하세요.

상호작용 디자인도 살펴보세요. 버튼이 즉각적인 시각 피드백을 제공하면, 후속 작업이 더 오래 걸리더라도 더 반응성이 좋게 느껴질 수 있습니다. 이것이 성능의 대체물은 아니지만, 좋은 인터페이스 엔지니어링의 일부입니다. 접근성 있는 웹 버튼에 대한 체크리스트도 이 부분과 겹칩니다. 명확한 상태, 올바른 의미 구조, 예측 가능한 동작은 사용자와 브라우저 모두에게 도움이 됩니다.

CLS: 페이지가 사용자가 예상한 위치에 머무르는가?

Cumulative Layout Shift는 보이는 요소의 예기치 않은 움직임을 측정합니다. 사용자가 문단을 읽기 시작했는데 그 위에 광고, 이미지, 배너가 로드되어 텍스트를 아래로 밀어내면 CLS에 반영됩니다.

CLS는 초 단위로 측정되지 않습니다. 얼마나 많은 콘텐츠가, 얼마나 멀리 움직였는지를 기반으로 한 점수입니다. 낮을수록 좋습니다.

핵심 단어는 예기치 않은입니다. 사용자 동작으로 인해 발생한 레이아웃 변화는 보통 같은 방식으로 계산되지 않습니다. 누군가 “더 보기”를 탭해서 콘텐츠가 확장된다면 예상 가능한 일입니다. 뉴스레터 배너가 3초 뒤 상단에 나타나 모든 것을 아래로 밀어낸다면 그렇지 않습니다.

CLS가 나빠지는 흔한 원인

CLS 실패는 대개 평범한 원인에서 나옵니다.

• width와 height 속성이 없는 이미지,
• 예약 공간이 없는 광고 또는 임베드,
• 콘텐츠 위에 삽입되는 쿠키 배너,
• 서로 다른 메트릭으로 교체되는 웹 폰트,
• 늦게 로드되는 프로모션 바,
• 페이지 상단 근처에 동적으로 삽입되는 콘텐츠.

해결책은 보통 콘텐츠가 도착하기 전에 공간을 예약하는 것입니다. 브라우저는 가능한 한 일찍 페이지의 형태를 알아야 합니다.

CLS를 개선하는 방법

눈에 보이는 이동부터 시작하세요. 녹화를 보거나 브라우저 도구를 사용해 어떤 요소가 움직이는지 확인하세요.

그다음 지루하지만 효과적인 해결책을 적용하세요.

• 이미지에 명시적인 width와 height 속성을 추가하세요.
• 반응형 미디어 컨테이너에는 CSS aspect-ratio를 사용하세요.
• 광고, 임베드, iframe을 위해 고정 또는 최소 공간을 예약하세요.
• 로드 후 기존 콘텐츠 위에 배너를 삽입하지 마세요.
• 최종 폰트와 비슷한 메트릭을 가진 폰트 대체값을 선택하세요.
• top, left, width, height처럼 레이아웃 속성을 바꾸는 애니메이션은 피하고, transform을 선호하세요.

CLS는 영리함보다 규율이 더 중요한 몇 안 되는 성능 지표 중 하나입니다. 페이지에 안정적인 박스가 있으면 대체로 좋은 점수를 받습니다.

필드 데이터와 랩 데이터는 모두 유용하지만, 답하는 질문이 다릅니다

서로 다른 도구가 서로 다른 숫자를 보여주는 것은 흔한 혼란의 원인입니다. 정상입니다.

필드 데이터는 실제 사용자에게서 나옵니다. 실제 기기, 네트워크, 위치, 브라우저 조건을 반영합니다. Google의 Chrome User Experience Report가 필드 데이터의 한 예입니다.

랩 데이터는 통제된 테스트 환경에서 나옵니다. 익숙한 예가 Lighthouse입니다. 반복 가능하고 디버깅에 유용하지만, 사용자가 실제로 겪는 경험과 같지는 않습니다.

사용자에게 실제 문제가 있는지 판단할 때는 필드 데이터를 사용하세요. 그 문제를 재현하고 디버깅할 때는 랩 데이터를 사용하세요.

또한 Core Web Vitals는 보통 브랜드의 단일한 추상적 속성이 아니라 URL 또는 URL 그룹 단위로 평가된다는 점도 기억하세요. 홈페이지, 블로그 글, 가격 페이지, 체크아웃은 매우 다른 병목을 가질 수 있습니다.

합리적인 작업 순서

세 지표가 모두 나쁘다면 모든 곳에서 시작하고 싶은 유혹이 생깁니다. 참으세요.

실용적인 순서는 다음과 같습니다.

1. 명백한 CLS부터 고치세요

누락된 이미지 크기와 불안정한 배너는 빠른 성과로 이어지는 경우가 많습니다.

1. 중요한 템플릿의 LCP를 개선하세요

제품 페이지, 랜딩 페이지, 기사, 가입 흐름처럼 중요한 페이지에 집중하세요.

1. 실제 상호작용으로 INP를 조사하세요

사용자가 실제로 클릭하는 것을 클릭해 보세요. 메뉴, 필터, 폼, 체크아웃 컨트롤은 초기 로드 추적보다 더 많은 것을 드러내는 경우가 많습니다.

1. 서드파티 스크립트를 감사하세요

비용을 정당화하는 것은 유지하세요. 그렇지 않은 것은 제거하거나 지연시키세요.

1. 성능 예산을 설정하세요

예산이 없으면 성능 개선은 퇴색합니다. 새로운 스크립트, 이미지, 디자인 컴포넌트가 조용히 작업을 되돌릴 것입니다.

중요한 점은 배지를 얻기 위해 최적화하지 말라는 것입니다. 사용자 여정을 위해 최적화하세요. 트래픽이 적은 페이지에서의 미미한 점수 개선보다, 조금 완벽하지 않더라도 훨씬 빠른 체크아웃 상호작용이 더 중요할 수 있습니다.

<!-- tool-cta:start -->

💡 이렇게 해보세요: LCP는 보통 이미지 문제이므로, 첫 번째 쉬운 성과로 Image Compressor를 사용해 히어로 이미지의 크기를 줄이세요.

<!-- tool-cta:end -->

Core Web Vitals가 말해주지 않는 것

Core Web Vitals는 유용하지만 완전하지는 않습니다.

콘텐츠가 좋은지 알려주지 않습니다. 내비게이션이 타당한지 알려주지 않습니다. 접근성을 보장하지 않습니다. 개인정보 보호, 보안, 신뢰, 가독성, 또는 페이지가 사용자의 질문에 답하는지를 측정하지 않습니다.

판단을 대신하지도 않습니다. 어떤 페이지는 Core Web Vitals를 통과하고도 불쾌할 수 있습니다. 복잡한 애플리케이션은 제약 조건 안에서 책임감 있게 설계되었더라도 기준값을 놓칠 수 있습니다.

LCP, INP, CLS를 화재경보기처럼 다루세요. 울리면 조사하세요. 조용할 때도 건물 관리는 계속하세요.