코어 웹 바이탈(Core Web Vitals)

세 가지 지표와 좋은 기준

• Largest Contentful Paint(LCP) — 화면에 보이는 영역에서 가장 큰 요소, 보통 히어로 이미지나 제목이 그려질 때까지 걸리는 시간. 2.5초 이하가 좋음이고 4초를 넘으면 나쁨입니다. "페이지가 도착한 것처럼 느껴진 시점"에 가장 가까운 측정값입니다.
• Interaction to Next Paint(INP) — 탭, 클릭, 키 입력에서 브라우저가 다음 프레임을 그릴 때까지의 지연을 첫 상호작용만이 아니라 방문 전체에 걸쳐 측정한 값. 200밀리초 이하가 좋음이고 500을 넘으면 나쁨입니다. 거의 모든 페이지가 손쉽게 통과하던 First Input Delay를 2024년 3월에 대체했습니다.
• Cumulative Layout Shift(CLS) — 페이지가 로드되는 동안 보이는 콘텐츠가 얼마나 튀는지를 단위 없는 숫자로 나타낸 값. 0.1 이하가 좋음이고 0.25를 넘으면 나쁨입니다. 단골 원인은 크기를 지정하지 않은 이미지, 늦게 로드되는 폰트, 콘텐츠 위에 끼어드는 배너입니다.

구글이 쓰는 점수는 필드 데이터입니다. 실제 크롬 사용자의 실제 세션이며, Chrome User Experience Report에 28일 이동 구간으로 모입니다. 라이트하우스나 PageSpeed Insights의 실험실 항목은 합성된 기기 하나에서 한 번의 방문을 흉내 냅니다. 원인을 찾는 데는 더없이 유용하지만, 평가 대상이 되는 숫자는 아닙니다. 트래픽이 적은 사이트는 필드 데이터가 아예 없을 수 있고, 그런 경우에는 평가 자체가 이뤄지지 않습니다.

순위에는 얼마나 영향을 줄까

여기에 쏟는 노력이 전제하는 것보다는 적게 영향을 줍니다. 코어 웹 바이탈은 페이지 경험의 한 입력값이고, 구글은 이를 약한 페이지를 끌어올리기보다 비슷한 결과들을 가르는 완만한 신호라고 일관되게 설명해 왔습니다. 빠른 페이지가 더 나은 답을 이기지는 않습니다. 어떤 페이지에 유입이 없다면 성능이 원인인 경우는 드물고, 진단은 대개 더 위쪽에 있습니다. 색인, 검색 의도의 일치, 혹은 순위에 오를 만한 것이 애초에 없다는 사실 쪽입니다.

확실하게 값을 하는 지점은 클릭 이후입니다. 페이지가 그려지기 전에 떠난 사람은 애초에 순위 문제가 아니었고, 엄지 밑에서 흔들리는 레이아웃은 가장 아쉬운 기기에서 전환을 깎아먹습니다. 코어 웹 바이탈을 검색의 동점 처리 요소를 겸한 전환 개선 작업으로 다루면 우선순위가 제자리를 찾습니다. 정말 느린 페이지를 고치고, 이미 통과한 점수를 더 다듬는 일은 그만두면 됩니다.

우리 사이트의 LCP를 재다가 빠진 함정

LCP는 사람이 본 것이 아니라 브라우저가 기록한 것을 측정합니다. 지표가 오해를 부르는 자리는 정확히 그 간극입니다. 우리가 만드는 AgentCeres — agentceres.com의 AI 그로스 오피서 — 의 첫 화면에서는 제목이 하이드레이션 이후에만 실행되는 스크롤 등장 애니메이션 뒤에 있었습니다. PageSpeed Insights가 보고한 모바일 LCP는 6.6초였고 그중 약 98%가 요소 렌더 지연이었습니다. 페이지는 이미 한참 전에 로드돼 있었고, 제목은 자바스크립트가 따라잡을 때까지 그냥 보이지 않았을 뿐입니다. 자바스크립트가 차단된 방문자에게는 끝까지 보이지 않았습니다.

그걸 고치자 더 이상한 문제가 드러났습니다. 자바스크립트 등장 효과를 순수 CSS 페이드로 바꿨더니 측정된 LCP가 좋아지기는커녕 나빠졌습니다. 2026년 7월 12일에 실측한 값은 8.1초였고, 기준점은 내비게이션 바의 작은 로고로 옮겨 가 있었습니다. 투명도 0에서 시작하는 페이드는 컴포지터에서 처리되어 요소를 다시 그리지 않기 때문에, 크롬은 그 요소에 대한 LCP 후보를 아예 내보내지 않고 지표는 조용히 실제로 그려진 다른 것으로 옮겨 갑니다. 해결책은 제목에 등장 애니메이션을 전혀 주지 않는 것이었습니다. 여기서 얻는 교훈은 일반적입니다. 나타날 때 움직이게 만든 요소는 더 이상 LCP 요소가 아닐 수 있고, 그때 읽는 점수는 페이지의 다른 부분을 설명합니다.