Core Web Vitals에서 블로그가 걸리는 건 대개 LCP 요소 하나입니다

PageSpeed Insights를 처음 열어봤을 때 받는 충격이 있다. 글도 열심히 썼고, 주제도 괜찮은 것 같은데 점수가 40점대라면? '어디를 고쳐야 하는지'가 영어 설명으로 잔뜩 나와 있는데 뭐부터 봐야 할지 막막한 그 느낌.

Core Web Vitals(CWV)는 구글이 2021년 5월 롤아웃을 시작해 6월에 완료한 페이지 경험 지표다. 그리고 2024년 3월에는 FID(First Input Delay)가 INP(Interaction to Next Paint)로 교체되면서 지표가 한 번 더 정교해졌다. 한국어 자료들은 대부분 '세 가지 지표가 있다'는 데서 끝난다. 정작 필요한 건 공식 기준값이 정확히 얼마인지, 내가 쓰는 플랫폼에서 실제로 뭘 고칠 수 있는지인데.

LCP·INP·CLS 공식 기준값과 숫자 뒤의 맥락

구글이 web.dev 공식 문서에 명시한 임계값이다. 75번째 백분위수 기준 — 방문자 100명 중 75명 이상이 이 수치를 달성해야 'Good'으로 인정받는다. 중앙값(50th)이 아니라 75th를 기준으로 쓰는 건, 느린 환경의 방문자까지 실제 경험을 반영하기 위해서다. 다시 말해 상위 25%만 빠르다고 통과되지 않는다.

LCP는 페이지에서 가장 큰 이미지나 텍스트 블록이 화면에 그려지는 시간이다. 대표 이미지를 늦게 불러오면 여기서 발목 잡힌다.

INP는 클릭·탭·키보드 입력 후 브라우저가 다음 화면을 그리기까지 걸리는 응답 지연을 전체 세션에 걸쳐 추적한다. 첫 번째 인터랙션만 봤던 FID보다 훨씬 엄격한 이유가 거기 있다.

CLS는 글을 읽는 중 광고·이미지·폰트가 뒤늦게 로딩되면서 텍스트 위치가 밀리는 현상을 수치화한 것이다. 이미지 태그에 width·height가 없거나 외부 폰트가 늦게 적용될 때 주로 발생한다.

실제로 세 지표를 모두 Good으로 통과하는 사이트는 절반을 조금 넘는 수준이고, 가장 많이 발목을 잡는 건 LCP다. 세 지표를 주기적으로 확인하는 가장 빠른 방법은 Google Search Console의 'Core Web Vitals' 보고서다. 문제 URL이 묶음으로 뜨므로 어디서 주로 실패하는지 한눈에 파악할 수 있다.

PSI 점수를 올렸는데 왜 Search Console은 그대로인가 🔍

CWV를 처음 다루는 블로거들이 공통으로 빠지는 함정이 있다. Lighthouse 점수(PSI 하단의 초록 숫자)를 올리면 구글 검색 순위에 바로 영향을 준다는 믿음이다. 실제로는 그렇지 않다.

구글이 랭킹 신호로 쓰는 건 CrUX(Chrome User Experience Report) 필드 데이터다. 크롬 브라우저를 실제로 쓰는 방문자들의 지난 28일치 롤링 통계가 기준이다. Lighthouse는 구글 서버가 통제된 환경에서 시뮬레이션한 랩(Lab) 데이터이고, CrUX는 진짜 사람들이 실제로 겪은 경험치다. PSI 상단의 'Field Data' 섹션과 하단의 'Lab Data' 섹션이 다른 이유가 여기 있다.

여기서 소규모 블로그에만 해당하는 중요한 사실 하나가 있다. 월 방문자가 적으면 CrUX 데이터 자체가 쌓이지 않는다. 구글은 충분한 실제 방문자 데이터가 없는 URL에 대해 'Field Data 없음'을 표시하거나, 유사 URL을 묶어 Origin(도메인 전체) 수준에서 집계한다. PSI를 열었을 때 상단 Field Data 섹션이 회색이거나 '데이터가 충분하지 않습니다'라고 나오는 블로그는 이 상태다.

그 말은, 지금 당장 CWV 개선 작업이 구글 SEO에 직접 영향을 주지 않는다는 뜻이다. 필드 데이터가 없으면 CWV가 랭킹 신호로 작동하지 않는다.

그렇다면 최적화를 미뤄도 되느냐? 아니다. 이유가 두 가지다. 첫째, 방문자가 늘어 CrUX 데이터가 쌓이기 시작하는 순간 현재 성능 수준이 그대로 필드 데이터로 기록된다. 처음부터 빠른 블로그가 유리한 출발선을 갖는다. 둘째, LCP가 4.0초를 넘는 블로그는 방문자가 스크롤도 하기 전에 이탈한다. 이건 SEO 신호 이전에 독자 경험 문제다.

PSI에서 자신의 블로그가 어느 상태인지 확인하는 방법은 간단하다. pagespeed.web.dev에 글 URL을 넣고 상단 Field Data 영역을 먼저 본다. 데이터가 있으면 랭킹 신호로 작동 중인 것이고, 없으면 지금은 구조 개선에 집중해 미래 트래픽을 대비하는 시점이다.

내 블로그의 LCP 요소는 정확히 무엇인가

"LCP를 개선하세요"라는 말은 넘치는데, "내 글의 LCP 요소가 정확히 뭔지"를 찾는 방법은 잘 안 나온다. LCP를 개선하려면 먼저 브라우저가 어느 요소를 LCP로 판정하는지 알아야 한다.

PSI 리포트 하단의 'Lab Data' 섹션 아래로 내려가면 '진단(Diagnostics)' 항목 중에 '가장 큰 콘텐츠가 포함된 페인트 요소(Largest Contentful Paint element)' 항목이 있다. 여기에 실제 DOM 요소가 명시된다. 예를 들어 IMG 태그와 해당 이미지 URL이 표시되거나, H1 같은 텍스트 블록이 지목될 수 있다.

블로그 포스트에서 LCP 요소가 무엇인지 확인하는 절차는 다음과 같다.

글 URL을 PSI에 입력한 뒤, 리포트가 나오면 스크롤을 내려 'Diagnostics' 영역을 찾는다. 거기서 'Largest Contentful Paint element'를 클릭하면 해당 요소의 DOM 경로와 함께 실제로 페이지에서 어디에 있는지 표시된다. 대부분 블로그에서는 두 가지 중 하나다. 포스트 상단의 대표 이미지 태그, 또는 가장 큰 텍스트 블록인 H1이다.

LCP 요소가 이미지라면 할 일이 명확하다. 해당 이미지가 WebP 포맷인지, 불필요하게 원본 해상도 그대로 올라가 있지는 않은지, fetchpriority="high" 속성이 붙어 있는지 순서대로 확인한다. LCP 요소가 H1 텍스트라면 그 위에서 렌더를 막고 있는 외부 스크립트나 CSS가 없는지 'Opportunities' 섹션의 '렌더 블로킹 리소스 제거' 항목을 본다.

같은 블로그라도 글마다 대표 이미지 크기가 다르면 LCP 요소가 달라질 수 있으므로, 점수가 특히 낮은 글을 선별해서 확인하는 게 효율적이다.

플랫폼별 CWV 개선, 할 수 있는 것과 없는 것

플랫폼마다 건드릴 수 있는 범위가 다르다. '할 수 없는 것'을 먼저 알아두면 헛수고를 줄인다.

티스토리

HTML/CSS 스킨 편집은 허용하지만 서버·호스팅 제어권은 없다. 서버는 카카오 인프라에 종속되어 있어 TTFB 자체를 줄이는 건 불가능하다. 그래서 티스토리에서 가장 효과를 낼 수 있는 건 클라이언트 사이드에서 로딩을 줄이는 작업, 특히 이미지 최적화와 외부 리소스 제거다.

워드프레스

세 플랫폼 중 제어 범위가 가장 넓다. 호스팅을 직접 선택하기 때문에 서버 응답 시간(TTFB)까지 손볼 수 있는 유일한 플랫폼이기도 하다. 다만 공유 호스팅에서 TTFB가 높으면 프론트엔드 최적화만으로 LCP Good을 달성하기 어렵고, PSI '기회' 탭에서 '서버 응답 시간 단축(TTFB)'이 권고사항으로 뜬다면 관리형 호스팅(Kinsta, WP Engine 등)으로 이전하거나 Cloudflare를 앞에 두는 게 현실적 해법이다.

네이버 블로그

플랫폼 구조 자체가 사용자 제어를 거의 허용하지 않는다. 네이버 블로그에서 할 수 있는 최적화는 콘텐츠 레벨, 즉 이미지를 올리기 전에 미리 압축해두는 정도가 전부다.

네이버 블로그는 구글 검색 인덱싱 자체에 제한이 있어 CWV가 구글 SEO에 미치는 직접 영향이 다른 플랫폼보다 훨씬 적다. CWV 최적화가 목적이라면 티스토리·워드프레스가 훨씬 유효하다.

어디서 막혔냐에 따라 시작점이 다르다

세 지표 중 어디서 막혔느냐에 따라 접근 순서가 달라진다. LCP는 체감 속도와 직결되어 독자가 이탈 여부를 결정하는 첫 번째 관문이고, CLS는 읽다가 갑자기 내용이 밀리는 불쾌한 경험을 유발하며, INP는 댓글·공유·메뉴 클릭 등 상호작용이 많은 페이지에서 문제가 된다. 이 순서대로 우선순위를 잡는 게 효율적이다.

LCP Poor(4초 초과)일 때

대표 이미지 크기·포맷 점검 → WebP 교체부터 시작한다. PSI '기회' 탭에서 TTFB가 400ms 이상이면 서버·호스팅 점검이 선행되어야 한다. LCP 대상 이미지에 fetchpriority="high" 속성을 추가하면 브라우저가 다른 리소스보다 해당 이미지를 먼저 요청해 체감 로딩 속도를 줄일 수 있다. 렌더 블로킹 CSS·JS 제거 또는 defer 처리는 그다음이다.

CLS Poor(0.25 초과)일 때

이미지·영상 태그에 width·height를 먼저 명시한다. 블로그 포스트에서 CLS가 갑자기 치솟는 가장 흔한 원인은 크기 정보 없이 삽입된 이미지와 늦게 로드되는 광고 배너다. 외부 폰트 로딩에 font-display: swap을 적용하고, 광고·동적 콘텐츠 삽입 위치에 min-height를 예약한다.

INP Poor(500ms 초과)일 때

블로그에서 INP Poor가 나오는 주된 원인이 있는데, 생각보다 많은 경우 본문 콘텐츠가 아니라 댓글·공유·위젯 스크립트다. Disqus 같은 외부 댓글 시스템은 페이지 로드 시 수십 개의 외부 스크립트를 불러오며 메인 스레드를 길게 차지한다. 카카오 공유 SDK 같은 SNS 공유 버튼도 각각 외부 스크립트를 로드한다. 실시간 방문자 카운터 위젯도 마찬가지다. 이것들이 동시에 메인 스레드를 경쟁하면 사용자가 링크를 클릭했을 때 반응이 500ms를 넘는 일이 생긴다.

PSI '진단(Diagnostics)' 탭에서 '메인 스레드 작업 최소화' 항목을 펼치면 어떤 스크립트가 얼마나 오래 스레드를 점유하는지 도메인별로 표시된다. disqus.com, t1.kakaocdn.net 같은 외부 도메인이 긴 막대로 나오면 그게 INP의 원인이다. 해결 방법은 불필요한 서드파티 스크립트 제거, 또는 클릭 후에만 로드되도록 지연 처리하는 것이다. 대용량 JavaScript 번들이 있다면 코드 분할(code splitting)이나 defer/async 처리가 다음 단계다.

지금 PSI를 열었다면, 어디서 시작할 것인가

점수 측정은 모바일 기준으로 먼저 한다. 구글 CWV 평가에서 모바일과 데스크톱은 별도로 집계되는데, 블로그 트래픽 특성상 모바일 방문자가 대부분이고 점수도 모바일이 훨씬 낮게 나온다. PSI 상단의 탭을 '모바일'로 고정하는 것이 출발점이다.

리포트가 뜨면 상단 Field Data를 먼저 본다. 데이터가 있는지 없는지를 확인하는 것이 첫 번째 판단이다. 없다면 앞서 설명한 것처럼 현재는 CWV가 랭킹에 직접 영향을 주지 않지만, 지금 하는 개선이 데이터가 쌓이기 시작할 때 기준선이 된다.

Field Data에서 어느 지표가 Poor인지 확인했으면 PSI 하단 Diagnostics 섹션으로 내려간다. 'Largest Contentful Paint element' 항목으로 내 글의 LCP 요소가 무엇인지 확인하고, 그 요소를 기준으로 'Opportunities' 섹션의 권고사항을 대조한다. 권고사항에는 절약 가능한 시간이 함께 표시된다. 가장 절약 시간이 큰 항목 하나에 집중하는 것이 전체를 동시에 건드리는 것보다 효과를 파악하기 훨씬 쉽다.

한 가지만 바꾸고 PSI를 다시 돌려 전후를 비교한다. 개선 후 Search Console 보고서 반영까지는 28일 이상이 걸린다. PSI 점수가 올랐다고 CrUX 데이터가 당장 바뀌는 게 아니라 실제 방문자 데이터가 새로 쌓여야 한다. 그래서 Search Console보다 PSI 점수 변화로 먼저 확인하고, 28일 뒤 Field Data 수치가 움직이는지 보는 순서가 현실적이다.

참고자료

• Web Vitals — web.dev
• Core Web Vitals와 구글 검색 결과 — Google Search Central
• PageSpeed Insights