[2026 최신] 핵심 웹 비탈스 CORE Web Vitals 최적화 방법 완벽 가이드 | 테라그로스

구글 광고 운영하면서 랜딩페이지 성능 때문에 전환율 깨지는 케이스를 정말 많이 봤다. 광고비는 잘 쓰는데 정작 페이지가 느려서 사람들이 떠나버리면 그 돈 다 날리는 거다. 그래서 우리가 클라이언트한테 항상 강조하는 게 핵심 웹 비탈스, Core Web Vitals다. 근데 이게 2024년 이후로 꽤 바뀌었다. 옛날에 알던 지식으로 접근하면 헛다리 짚기 딱 좋다.

솔직히 말하면 Core Web Vitals를 그냥 “구글이 시키니까 맞춰야 하는 숙제” 정도로 보는 분들이 많은데, 우리 입장에서는 광고 품질평가점수랑도 엮이고 자연검색 순위에도 영향 주는 실전 지표다. 오늘은 2026년 현재 기준으로 뭐가 진짜 중요하고, 어떻게 손대야 점수가 올라가는지 현장에서 굴린 경험 위주로 풀어보겠다.

핵심 웹 비탈스가 지금 어떻게 구성돼 있나

가장 먼저 짚을 게, 지표 구성이 바뀌었다는 점이다. 과거에는 LCP, FID, CLS 이 세 개가 삼총사였다. 근데 FID(First Input Delay)는 2024년 3월에 공식적으로 퇴출됐고 그 자리를 INP(Interaction to Next Paint)가 차지했다. 지금 2026년 기준으로 보면 INP가 자리 잡은 지 2년이 넘었으니, 아직도 FID 얘기하는 자료가 있으면 그건 낡은 거라고 보면 된다.

현재 3대 지표를 정리하면 이렇다.

• LCP (Largest Contentful Paint) – 화면에서 제일 큰 콘텐츠 요소가 그려지는 데 걸리는 시간. 보통 히어로 이미지나 큰 텍스트 블록이 대상이 된다. 2.5초 이내가 양호 기준.
• INP (Interaction to Next Paint) – 사용자가 클릭이나 탭을 했을 때 화면이 반응하기까지의 지연. 페이지 전체 생애 동안의 상호작용을 측정한다는 게 FID랑 결정적으로 다른 부분이다. 200밀리초 이내가 양호.
• CLS (Cumulative Layout Shift) – 페이지 로딩 중에 요소들이 갑자기 움직여서 레이아웃이 흔들리는 정도. 0.1 이하가 양호.

FID는 첫 입력 “지연”만 봤다. 그러니까 첫 클릭이 얼마나 빨리 받아들여지나만 측정했는데, 솔직히 이건 너무 관대한 지표였다. 첫 반응은 빠른데 그 뒤로 페이지가 버벅대도 점수는 멀쩡하게 나왔으니까. INP는 그 허점을 메운다. 전체 상호작용 중 가장 느린 축에 속하는 반응 시간을 잡아내기 때문에 실제 체감 성능을 훨씬 정직하게 반영한다.

측정부터 제대로 해야 한다 – 필드 데이터와 랩 데이터

최적화 들어가기 전에 측정 얘기를 먼저 해야겠다. 이거 헷갈리는 분들이 정말 많다. 데이터에는 두 종류가 있다.

랩 데이터(Lab Data)는 통제된 환경에서 시뮬레이션으로 뽑는다. Lighthouse나 PageSpeed Insights의 상단 점수가 여기 해당한다. 개발 단계에서 디버깅할 때 유용하지만, 실제 사용자 경험이랑은 차이가 날 수 있다. 내 노트북에선 빠른데 사용자 구형 안드로이드에선 느린 경우, 랩 데이터만 보면 못 잡는다.

필드 데이터(Field Data)는 진짜 사용자들의 실제 측정값이다. CrUX(Chrome User Experience Report)라고, 크롬에서 실제 방문자들 데이터를 익명으로 모은 거다. 구글이 검색 순위에 실제로 반영하는 건 바로 이 필드 데이터다. 그래서 우리는 클라이언트 사이트 진단할 때 PageSpeed Insights 상단의 “실제 사용자 환경에서 수집된 데이터” 섹션을 가장 먼저 본다. 랩 점수 90점 나와도 필드 데이터가 빨간색이면 그건 실패한 거다.

여기서 중요한 함정 하나. INP는 사용자 상호작용이 있어야 측정된다. 그래서 신규 페이지나 트래픽 적은 페이지는 필드 데이터가 안 잡힌다. 이럴 땐 PageSpeed Insights 말고도 Chrome DevTools의 Performance 패널에서 직접 인터랙션을 걸어보면서 진단해야 한다. 구글이 제공하는 web-vitals 자바스크립트 라이브러리를 심어서 자체 수집하는 방법도 우리가 큰 사이트에 자주 쓴다.

LCP 잡는 법 – 제일 큰 요소를 빨리 그려라

LCP가 안 나오는 사이트 열어보면 원인이 거의 정해져 있다. 대표적인 게 히어로 이미지가 너무 무거운 경우다. 메인 비주얼 한 장이 3MB씩 되는 사이트가 아직도 흔하다.

우리가 실제로 손대는 순서는 이렇다. 먼저 이미지 포맷을 WebP나 AVIF로 바꾼다. 같은 화질에 용량이 JPEG 대비 30에서 50퍼센트까지 줄어든다. 어떤 클라이언트는 메인 이미지만 WebP로 교체했는데 LCP가 4.1초에서 2.3초로 떨어졌다. 그것만으로 양호 기준에 들어왔다.

그다음이 우선순위 힌트다. LCP 대상이 되는 이미지에 fetchpriority="high" 속성을 붙이면 브라우저가 그 이미지를 먼저 받아온다. 반대로 화면 아래쪽 이미지는 loading="lazy"로 미뤄야 한다. 근데 여기서 실수하는 게, LCP 이미지에까지 lazy loading을 걸어버리는 경우다. 그러면 오히려 첫 화면 그리기가 늦어진다. 이거 정말 자주 보는 실수다.

서버 응답 속도, 그러니까 TTFB(Time To First Byte)도 LCP에 직접 영향을 준다. 아무리 이미지를 최적화해도 서버가 첫 바이트 뱉는 데 1초 넘게 걸리면 LCP는 절대 안 나온다. CDN 붙이고, 캐싱 제대로 걸고, 호스팅이 너무 저렴한 공유 호스팅이면 업그레이드를 권한다. 한국 사이트인데 해외 서버 쓰는 경우도 의외로 많은데, 이건 거의 무조건 갈아타라고 한다.

마지막으로 렌더링을 막는 리소스. 페이지 상단에서 무거운 CSS나 자바스크립트가 로딩을 붙잡고 있으면 그동안 화면이 비어 있다. 핵심 CSS는 인라인으로 박고 나머지는 비동기로 불러오는 식으로 정리한다.

INP 개선 – 반응성을 살리는 게 진짜 어렵다

3대 지표 중에 가장 까다로운 게 INP다. LCP나 CLS는 비교적 정형화된 처방이 있는데, INP는 자바스크립트 실행 구조랑 직접 엮여서 까다롭다.

핵심 원인은 거의 항상 메인 스레드가 막혀 있다는 거다. 사용자가 버튼을 눌렀는데 그 순간 자바스크립트가 무거운 작업을 처리하느라 화면을 못 그리면 INP가 치솟는다. 광고 태그, 분석 스크립트, 채팅 위젯 이런 서드파티 스크립트가 주범인 경우가 많다. GTM에 태그를 30개씩 욱여넣은 사이트 보면 INP가 안 좋을 수밖에 없다.

우리가 쓰는 처방을 몇 가지 풀면 이렇다.

• 긴 작업 쪼개기 – 50밀리초 넘게 메인 스레드를 잡는 작업을 Long Task라고 부른다. 이걸 잘게 나눠서 중간중간 브라우저가 사용자 입력을 처리할 틈을 준다. setTimeout이나 최신 scheduler.yield() API를 쓴다.
• 서드파티 스크립트 다이어트 – 안 쓰는 마케팅 태그, 중복된 분석 도구 정리만 해도 INP가 눈에 띄게 좋아진다. 진짜 필요한지 하나씩 따져봐야 한다.
• 입력 지연 줄이기 – 클릭 핸들러 안에서 무거운 계산을 즉시 다 처리하지 말고, 화면 갱신에 필요한 최소한만 먼저 그리고 나머지는 뒤로 미룬다.

경험상 INP는 한 방에 안 잡힌다. DevTools Performance 패널 켜놓고 실제로 클릭해보면서 어느 인터랙션에서 막히는지 하나씩 추적해야 한다. 시간이 좀 걸리는 작업이라 솔직히 인내심이 필요하다.

CLS 안정화 – 화면이 덜컹거리지 않게

CLS는 셋 중에 가장 직관적이다. 페이지 읽다가 광고가 갑자기 떠서 본문이 아래로 밀리거나, 버튼 누르려는 순간 위치가 바뀌어서 엉뚱한 걸 누른 경험 다들 있을 거다. 그게 CLS가 나쁜 거다.

가장 흔한 원인이 이미지나 영상에 크기 지정이 안 된 경우다. 브라우저가 이미지를 다 받기 전엔 얼마나 공간을 차지할지 모르니까, 받고 나서 갑자기 자리를 밀어낸다. 해결은 단순하다. img 태그에 width와 height 속성을 명시하거나 CSS에서 aspect-ratio를 지정해두면 브라우저가 미리 공간을 확보한다.

두 번째가 동적으로 끼어드는 콘텐츠다. 광고 슬롯, 배너, 임베드 위젯 같은 것들. 이런 건 미리 자리를 비워두는 게 정석이다. 광고가 들어올 영역에 고정 높이를 잡아두면, 광고가 늦게 떠도 본문이 안 밀린다.

세 번째는 웹폰트다. 폰트가 늦게 로딩되면서 기본 폰트에서 커스텀 폰트로 바뀔 때 글자 크기가 미묘하게 달라져 레이아웃이 흔들린다. font-display: optional이나 swap 설정, 그리고 폰트 preload로 어느 정도 잡힌다. 한글 폰트는 용량이 커서 서브셋 처리까지 해주면 더 좋다.

광고 운영자 관점에서 왜 이게 돈이 되나

여기는 우리가 진짜 하고 싶은 얘기다. 개발자 입장에서 Core Web Vitals는 기술 숙제지만, 마케터 입장에서는 직접 돈이 걸린 문제다.

첫째, 자연검색 순위. 구글은 페이지 경험을 랭킹 신호로 쓴다고 공식 문서에서 밝혀왔다. 콘텐츠 품질이 비슷한 두 페이지가 경쟁하면 성능 좋은 쪽이 유리하다. 광고비 안 들이고 들어오는 트래픽을 늘리는 길이다.

둘째, 광고 랜딩페이지 경험. 구글 광고의 품질평가점수에는 방문 페이지 경험이 들어간다. 페이지가 느리면 같은 입찰가로도 노출이 덜 되고 클릭당 비용이 올라간다. 우리가 어떤 계정에서 랜딩페이지 LCP를 4초대에서 2초대로 줄였더니, 광고 세팅을 거의 안 건드렸는데도 전환율이 18퍼센트 올라간 적이 있다. 페이지가 빨라지니까 이탈이 줄고, 그게 그대로 전환으로 이어진 거다.

셋째, 그냥 사용자가 안 떠난다. 모바일 페이지 로딩이 3초를 넘으면 절반 가까이가 그냥 닫아버린다는 건 오래된 데이터지만 지금도 유효하다. 아무리 광고를 잘 돌려서 사람을 데려와도, 페이지에서 떠나면 그 클릭값은 0이다.

실전 점검 순서 – 어디부터 손대야 하나

마지막으로 우리가 현장에서 쓰는 점검 순서를 공유한다. 무작정 다 고치려고 들면 시간만 날린다. 임팩트 큰 순서로 간다.

1. PageSpeed Insights에서 필드 데이터부터 확인. 어느 지표가 빨간색인지 본다.
2. LCP가 문제면 – 히어로 이미지 용량과 포맷, fetchpriority, 서버 TTFB 순으로 점검.
3. INP가 문제면 – 서드파티 스크립트 목록 뽑고, DevTools로 막히는 인터랙션 추적.
4. CLS가 문제면 – 이미지 크기 속성, 광고 슬롯 예약 공간, 웹폰트 로딩 점검.
5. 수정 후 최소 28일은 기다려야 필드 데이터에 반영된다. 급하게 결과 확인하려 들지 말 것.

마지막 항목이 의외로 중요하다. 필드 데이터는 28일 이동 평균이라, 오늘 고쳤다고 내일 점수가 바뀌지 않는다. 이거 모르고 “고쳤는데 왜 점수가 그대로냐”고 답답해하는 분들이 많은데, 좀 기다려야 한다.