Core Web Vitals란? LCP·INP·CLS 기준과 개선 방법 총정리

페이지가 빠르게 열리는 것처럼 보이는데도 PageSpeed Insights 결과가 좋지 않거나, Google Search Console에서 개선이 필요한 URL로 표시되는 경우가 있습니다.

이럴 때는 단순한 서버 속도보다 Core Web Vitals를 먼저 확인할 필요가 있습니다.

Core Web Vitals는 사용자가 페이지의 주요 콘텐츠를 얼마나 빨리 확인할 수 있는지, 버튼이나 메뉴를 눌렀을 때 얼마나 빠르게 반응하는지, 페이지를 읽는 동안 화면이 안정적으로 유지되는지를 측정하는 웹 성능 지표입니다.

현재 핵심 지표는 다음 세 가지입니다.

• LCP: 주요 콘텐츠가 표시되는 속도
• INP: 클릭이나 입력에 대한 반응 속도
• CLS: 화면 배치가 갑자기 움직이는 정도

이번 글에서는 Core Web Vitals의 의미와 권장 기준을 살펴보고, 워드프레스 사이트를 운영하면서 실제로 적용할 수 있는 개선 방법까지 알아보겠습니다.

Core Web Vitals 30초 요약

Core Web Vitals는 실제 사용자가 체감하는 웹페이지 품질을 평가하기 위한 지표입니다.

지표	측정 대상	좋은 상태
LCP	주요 콘텐츠가 표시되는 속도	2.5초 이하
INP	사용자 입력에 반응하는 속도	200ms 이하
CLS	화면 레이아웃의 안정성	0.1 이하

세 지표 중 하나만 좋아서는 충분하지 않습니다. 로딩 속도가 빠르더라도 버튼 반응이 늦거나 화면이 계속 움직이면 사용자는 사이트를 불편하게 느낄 수 있습니다.

사이트를 점검할 때는 PageSpeed Insights의 점수만 보는 것이 아니라 LCP, INP, CLS가 각각 어떤 원인으로 나빠졌는지 확인해야 합니다.

Core Web Vitals란?

Core Web Vitals는 Google이 웹페이지의 실제 사용자 경험을 측정하기 위해 정의한 핵심 성능 지표입니다.

일반적인 속도 측정은 페이지가 열리는 데 걸리는 전체 시간을 중심으로 판단합니다. 반면 Core Web Vitals는 사용자가 페이지를 이용하면서 실제로 마주치는 경험을 구체적으로 나누어 측정합니다.

예를 들어 다음과 같은 페이지를 생각해 볼 수 있습니다.

• 상단 배너 이미지가 늦게 나타난다.
• 메뉴를 눌러도 화면이 바로 바뀌지 않는다.
• 글을 읽는 중 광고가 나타나면서 본문이 아래로 밀린다.
• 버튼을 누르려는 순간 위치가 바뀐다.
• 첫 화면이 오랫동안 빈 상태로 남아 있다.

서버 응답 자체가 빠르더라도 이런 현상이 반복되면 좋은 사용자 경험이라고 보기 어렵습니다.

Core Web Vitals는 이러한 문제를 LCP, INP, CLS라는 수치로 구분해 보여줍니다.

Core Web Vitals가 SEO에서 중요한 이유

Core Web Vitals는 Google 검색의 페이지 경험 평가에 사용되는 신호 중 하나입니다.

다만 Core Web Vitals 점수가 좋다고 해서 검색 결과 상위 노출이 자동으로 보장되는 것은 아닙니다. 검색 의도를 충족하는 콘텐츠, 사이트의 신뢰성, 내부 링크, 모바일 사용성 등 여러 요소가 함께 작용합니다.

따라서 Core Web Vitals는 검색 순위를 올리는 단독 기술이라기보다, 좋은 콘텐츠를 사용자가 불편 없이 소비할 수 있도록 만드는 기본 조건으로 이해하는 것이 적절합니다.

성능을 개선하면 다음과 같은 효과도 기대할 수 있습니다.

개선 영역	기대할 수 있는 변화
주요 콘텐츠 로딩	방문자가 내용을 더 빨리 확인할 수 있음
클릭 반응	메뉴·버튼·검색 기능의 체감 품질 향상
화면 안정성	잘못된 클릭과 사용자 불편 감소
모바일 사용성	느린 네트워크와 저사양 기기에서 체감 개선
전환 과정	회원가입·문의·구매 중 이탈 가능성 감소

콘텐츠의 품질이 비슷한 페이지가 경쟁하고 있다면, 사용하기 편한 페이지가 장기적으로 더 안정적인 성과를 낼 가능성이 있습니다.

Core Web Vitals 평가 기준

Core Web Vitals는 일반적으로 다음 기준으로 구분합니다.

지표	좋음	개선 필요	나쁨
LCP	2.5초 이하	2.5초 초과~4초 이하	4초 초과
INP	200ms 이하	200ms 초과~500ms 이하	500ms 초과
CLS	0.1 이하	0.1 초과~0.25 이하	0.25 초과

평가할 때는 한 번 측정한 가장 좋은 결과가 아니라 실제 방문 데이터의 분포가 중요합니다.

PageSpeed Insights에서 실험실 데이터는 양호하지만 실제 사용자 데이터는 좋지 않게 나타날 수도 있습니다. 반대로 테스트 환경에서는 점수가 낮아도 실제 사용자 데이터가 상대적으로 양호할 수 있습니다.

따라서 한 번의 점수보다 일정 기간 동안 수집된 실제 사용자 데이터를 함께 확인하는 것이 좋습니다.

LCP란?

LCP는 Largest Contentful Paint의 약자로, 첫 화면에서 가장 큰 콘텐츠 요소가 표시되기까지 걸리는 시간을 측정합니다.

대부분의 사이트에서는 다음 요소가 LCP 대상이 됩니다.

• 대표 이미지
• 상단 배너
• 큰 배경 이미지
• 게시물 제목
• Hero 영역의 텍스트 또는 이미지
• 첫 화면에 배치된 콘텐츠 썸네일

방문자가 페이지에 접속했는데 본문이나 대표 이미지가 오랫동안 나타나지 않는다면 페이지가 느리다고 느끼게 됩니다. LCP는 이러한 체감 로딩 속도를 수치로 나타냅니다.

LCP가 느려지는 주요 원인

서버 응답이 느린 경우

브라우저가 서버에서 첫 번째 HTML을 늦게 받으면 이후의 이미지, CSS, JavaScript 로딩도 함께 늦어집니다.

공유 호스팅의 자원이 부족하거나 데이터베이스 요청이 오래 걸리는 사이트, 캐시가 설정되지 않은 워드프레스 사이트에서 자주 발생합니다.

대표 이미지 용량이 큰 경우

화면에 1,200픽셀 크기로 표시되는 이미지를 4,000픽셀 이상의 원본 파일로 올리면 불필요한 데이터 전송이 발생합니다.

특히 PNG 형식의 대형 배너나 품질을 지나치게 높인 JPEG 이미지는 LCP를 늦추는 대표적인 원인입니다.

CSS와 JavaScript가 렌더링을 막는 경우

브라우저는 화면을 그리기 전에 필요한 CSS와 JavaScript를 처리합니다. 첫 화면에 필요하지 않은 코드까지 한꺼번에 불러오면 주요 콘텐츠 표시가 늦어질 수 있습니다.

LCP 이미지에 Lazy Loading을 적용한 경우

Lazy Loading은 화면 아래쪽 이미지의 불필요한 로딩을 줄이는 데 유용합니다.

하지만 첫 화면의 대표 이미지까지 지연 로딩하면 브라우저가 중요한 이미지를 늦게 요청하게 됩니다. 결과적으로 데이터 사용량은 줄어도 LCP는 오히려 나빠질 수 있습니다.

LCP 개선 방법

이미지 크기와 형식을 최적화한다

업로드 전에 실제 표시 크기에 맞게 이미지 해상도를 줄이고 WebP 또는 AVIF 형식을 사용하는 것이 좋습니다.

예를 들어 본문 너비가 800픽셀이라면 3,000픽셀 이상의 이미지를 그대로 제공할 이유가 많지 않습니다. 고해상도 화면을 고려하더라도 적절한 크기의 반응형 이미지를 제공하는 편이 효율적입니다.

워드프레스는 업로드된 이미지를 여러 크기로 생성할 수 있으므로 테마에서 srcset과 sizes 속성이 정상적으로 적용되는지도 확인해야 합니다.

첫 화면 이미지를 우선적으로 불러온다

첫 화면의 핵심 이미지는 Lazy Loading 대상에서 제외하고, 필요하다면 높은 우선순위로 요청하도록 설정합니다.

<img
  src="hero-image.webp"
  width="1200"
  height="675"
  alt="Core Web Vitals의 LCP, INP, CLS 설명"
  fetchpriority="high"
>

모든 이미지에 fetchpriority="high"를 적용하면 요청 우선순위가 무너질 수 있습니다. LCP 대상이 될 가능성이 높은 핵심 이미지에만 제한적으로 사용하는 것이 좋습니다.

서버 캐시를 적용한다

워드프레스는 사용자가 페이지를 요청할 때 PHP 실행과 데이터베이스 조회가 발생할 수 있습니다.

페이지 캐시를 적용하면 미리 생성된 HTML을 제공할 수 있어 서버 응답 시간을 단축하는 데 도움이 됩니다.

운영 환경에 따라 다음 방식을 사용할 수 있습니다.

• 워드프레스 캐시 플러그인
• Nginx FastCGI Cache
• 서버 측 페이지 캐시
• Cloudflare 캐시
• 호스팅 업체가 제공하는 캐시 기능

캐시를 여러 단계에 중복 적용하면 로그인 상태나 장바구니 데이터가 잘못 표시될 수 있으므로 동적 페이지의 제외 규칙도 함께 설정해야 합니다.

불필요한 리디렉션을 줄인다

http에서 https, www에서 비-www 주소 등 여러 단계의 리디렉션이 발생하면 실제 HTML 요청이 늦어집니다.

대표 주소를 하나로 정하고 가능한 한 한 번의 리디렉션으로 최종 URL에 도달하도록 구성하는 것이 좋습니다.

SJSBIZ TIP

LCP가 나쁠 때 이미지 압축부터 시작하는 경우가 많습니다. 그러나 서버 응답 시간이 이미 2초에 가깝다면 이미지만 줄여서는 2.5초 기준을 맞추기 어렵습니다. 먼저 TTFB, LCP 리소스 요청 시점, 이미지 다운로드 시간을 나누어 확인해야 합니다.

INP란?

INP는 Interaction to Next Paint의 약자로, 사용자가 페이지와 상호작용한 뒤 다음 화면 변화가 표시되기까지 걸리는 시간을 측정합니다.

대표적인 상호작용은 다음과 같습니다.

• 메뉴 클릭
• 버튼 클릭
• 모바일 화면 터치
• 검색어 입력
• 아코디언 메뉴 열기
• 상품 옵션 선택
• 댓글 작성
• 장바구니 추가

사용자가 버튼을 눌렀는데 화면이 멈춘 것처럼 느껴지거나, 메뉴가 한참 뒤에 열리는 경우 INP가 좋지 않을 가능성이 있습니다.

INP가 느려지는 주요 원인

긴 JavaScript 작업

브라우저의 메인 스레드에서 긴 JavaScript 작업이 실행되는 동안에는 클릭이나 키보드 입력 처리가 늦어질 수 있습니다.

통계 스크립트, 광고 코드, 채팅 위젯, 팝업, 슬라이더, 애니메이션 플러그인이 많을수록 메인 스레드의 작업량이 증가합니다.

너무 많은 워드프레스 플러그인

플러그인의 개수 자체가 성능을 결정하는 것은 아닙니다. 가벼운 플러그인 20개보다 무거운 페이지 빌더 하나가 더 큰 영향을 줄 수도 있습니다.

중요한 것은 각 플러그인이 프런트엔드에 얼마나 많은 JavaScript와 CSS를 추가하는지 확인하는 것입니다.

한 번에 많은 DOM 요소를 변경하는 경우

버튼 클릭 후 수백 개의 요소를 동시에 변경하거나 복잡한 레이아웃을 다시 계산하면 화면 반응이 느려질 수 있습니다.

INP 개선 방법

사용하지 않는 JavaScript를 제거한다

실제로 사용하지 않는 슬라이더, 팝업, SNS 공유, 채팅, 분석 도구가 모든 페이지에서 로드되고 있지 않은지 확인합니다.

특정 페이지에서만 사용하는 스크립트는 필요한 페이지에서만 불러오는 것이 좋습니다.

긴 작업을 나눈다

한 번에 처리하던 작업을 여러 개의 작은 작업으로 나누면 브라우저가 사용자 입력에 반응할 기회를 확보할 수 있습니다.

개발자가 직접 코드를 관리하는 사이트라면 긴 반복문, 대규모 DOM 변경, 동기식 처리부터 점검하는 것이 좋습니다.

입력 직후 시각적인 반응을 제공한다

서버 처리가 필요한 버튼이라도 클릭 직후 로딩 표시나 버튼 상태 변경을 보여주면 사용자가 입력이 정상적으로 처리되었다는 사실을 알 수 있습니다.

다만 시각적인 표시만 빠르게 보여주고 실제 작업을 계속 지연시키는 방식은 근본적인 해결책이 아닙니다. 서버 요청과 화면 렌더링 과정도 함께 최적화해야 합니다.

서드파티 스크립트를 점검한다

광고, 방문자 분석, 외부 폰트, 실시간 상담, 동영상 삽입 코드 등은 사이트 외부에서 불러오는 경우가 많습니다.

운영에 반드시 필요한 도구인지 확인하고, 불필요한 스크립트는 제거하거나 사용자 상호작용 이후에 불러오는 방식을 검토할 수 있습니다.

SJSBIZ TIP

INP 문제는 첫 화면 로딩 테스트만으로 발견하기 어렵습니다. 페이지가 모두 열린 뒤 메뉴, 검색, 댓글, 필터, 장바구니 같은 실제 기능을 직접 조작하면서 Chrome DevTools의 Performance 패널로 확인하는 것이 좋습니다.

CLS란?

CLS는 Cumulative Layout Shift의 약자로, 사용자가 예상하지 못한 상태에서 화면 요소가 이동한 정도를 측정합니다.

페이지를 읽는 도중 이미지가 나타나면서 문장이 아래로 밀리거나, 광고가 삽입되면서 누르려던 버튼의 위치가 바뀌는 현상이 대표적인 예입니다.

화면 이동은 단순한 불편을 넘어 잘못된 클릭을 유발할 수 있습니다.

CLS가 높아지는 주요 원인

• 이미지의 가로·세로 크기를 지정하지 않음
• 광고 영역의 공간을 미리 확보하지 않음
• iframe이나 동영상 크기가 로딩 후 결정됨
• 웹폰트 적용 후 글자 폭이 달라짐
• 페이지 상단에 알림창이나 배너를 뒤늦게 삽입함
• JavaScript가 기존 콘텐츠 위에 새 요소를 추가함

CLS 개선 방법

이미지 크기를 명시한다

이미지가 다운로드되기 전에 브라우저가 필요한 공간을 확보할 수 있도록 width와 height를 지정합니다.

<img
  src="core-web-vitals.webp"
  width="1200"
  height="675"
  alt="Core Web Vitals 핵심 지표 비교"
>

CSS로 반응형 이미지를 사용하더라도 HTML의 가로·세로 속성을 함께 제공하는 것이 좋습니다.

img {
  max-width: 100%;
  height: auto;
}

광고와 외부 콘텐츠의 공간을 확보한다

광고가 실제로 로드된 뒤에야 영역 높이가 결정되면 본문이 밀릴 수 있습니다.

광고 크기를 미리 예상할 수 있다면 최소 높이를 지정해 공간을 확보합니다. 광고가 표시되지 않을 때 빈 공간을 어떻게 처리할지도 함께 고려해야 합니다.

상단 배너를 기존 콘텐츠 위에 삽입하지 않는다

쿠키 안내, 이벤트 배너, 앱 설치 안내 등을 페이지 로딩 후 상단에 삽입하면 전체 콘텐츠가 아래로 밀릴 수 있습니다.

화면 위에 겹쳐 표시하거나 처음부터 필요한 공간을 확보하는 방식이 안정적입니다.

웹폰트 로딩을 최적화한다

웹폰트가 늦게 로드되면 기본 글꼴에서 웹폰트로 바뀌는 과정에서 글자 폭과 줄바꿈 위치가 달라질 수 있습니다.

가능하면 필요한 글꼴과 굵기만 사용하고, 시스템 폰트와 크기가 비슷한 대체 글꼴을 지정합니다.

SJSBIZ TIP

CLS는 데스크톱보다 모바일에서 더 크게 체감될 수 있습니다. 화면 너비가 좁아 작은 글자 폭 변화도 여러 줄의 재배치를 일으킬 수 있기 때문입니다. 데스크톱 결과만 확인하지 말고 모바일 환경을 별도로 점검해야 합니다.

Core Web Vitals 측정 도구

성능 문제를 정확히 찾으려면 실제 사용자 데이터와 테스트 데이터를 구분해야 합니다.

PageSpeed Insights

PageSpeed Insights는 URL을 입력하면 모바일과 데스크톱 성능을 분석해 줍니다.

조건이 충족되는 사이트는 실제 Chrome 사용자의 데이터와 현재 환경에서 실행한 Lighthouse 테스트 결과를 함께 보여줍니다.

확인할 항목은 다음과 같습니다.

• 실제 사용자 데이터가 존재하는지
• 모바일과 데스크톱 결과가 다른지
• LCP 대상 요소가 무엇인지
• 사용하지 않는 JavaScript가 많은지
• 이미지 크기와 형식이 적절한지
• 렌더링을 차단하는 리소스가 있는지

Google Search Console

Search Console의 Core Web Vitals 보고서는 실제 사용 데이터를 바탕으로 URL을 좋음, 개선 필요, 나쁨 상태로 구분합니다.

개별 URL이 아니라 비슷한 페이지 그룹으로 표시될 수 있으므로 같은 템플릿을 사용하는 게시물이나 상품 페이지를 함께 점검하는 것이 좋습니다.

방문 데이터가 충분하지 않은 신규 사이트나 소규모 사이트는 보고서에 URL이 나타나지 않을 수도 있습니다. 데이터가 없다고 해서 성능이 좋거나 나쁘다고 단정할 수는 없습니다.

Chrome Lighthouse

Lighthouse는 현재 브라우저 환경에서 페이지 성능을 테스트합니다.

개발 중인 페이지나 실제 사용자 데이터가 부족한 사이트를 점검할 때 유용합니다. 다만 테스트 당시의 컴퓨터 성능, 네트워크 상태, 브라우저 확장 프로그램 등에 따라 결과가 달라질 수 있습니다.

비교 테스트를 할 때는 같은 환경과 조건을 유지해야 합니다.

Chrome DevTools Performance 패널

Performance 패널은 페이지 로딩과 사용자 상호작용 과정에서 어떤 작업이 오래 걸리는지 자세히 확인할 때 사용합니다.

JavaScript 긴 작업, 레이아웃 이동, 렌더링 지연, 네트워크 요청 순서 등을 분석할 수 있어 원인을 찾는 단계에서 유용합니다.

실제 사용자 데이터와 실험실 데이터의 차이

Core Web Vitals를 점검할 때 가장 혼란스러운 부분은 도구마다 결과가 다르게 나타나는 것입니다.

이는 오류라기보다 측정 방식의 차이일 가능성이 큽니다.

구분	실제 사용자 데이터	실험실 데이터
측정 대상	실제 방문자	설정된 테스트 환경
반영 환경	다양한 기기와 네트워크	일정한 기기·네트워크 조건
주요 용도	현재 사용자 경험 평가	문제 원인 분석과 개선 테스트
대표 도구	Search Console, PageSpeed Insights 필드 데이터	Lighthouse, DevTools
데이터 변화	일정 기간 누적 후 반영	테스트 즉시 확인

실험실 테스트에서 성능이 개선되었더라도 Search Console의 실제 사용자 데이터에는 바로 반영되지 않을 수 있습니다.

따라서 개선 직후에는 Lighthouse로 기술적 변화를 확인하고, 이후 실제 사용자 데이터의 추세를 관찰하는 방식이 적절합니다.

워드프레스 Core Web Vitals 개선 순서

워드프레스에서는 무작정 최적화 플러그인을 추가하기보다 문제의 우선순위를 정하는 것이 중요합니다.

1단계: 백업과 기준값 기록

설정을 변경하기 전에 전체 백업을 진행합니다.

그다음 주요 페이지의 모바일·데스크톱 결과를 기록합니다.

• 홈페이지
• 방문자가 많은 게시물
• 카테고리 페이지
• 문의 또는 전환 페이지
• 이미지가 많은 페이지

기준값이 없으면 변경 후 실제로 개선되었는지 판단하기 어렵습니다.

2단계: 이미지 최적화

큰 이미지부터 크기를 줄이고 WebP 또는 AVIF 형식을 적용합니다.

첫 화면 대표 이미지는 Lazy Loading에서 제외하고, 본문 아래쪽 이미지는 지연 로딩을 유지합니다.

이미지에 가로·세로 크기가 지정되어 있는지도 확인합니다.

3단계: 캐시와 압축 설정

페이지 캐시와 브라우저 캐시를 적용하고, 서버에서 Brotli 또는 Gzip 압축이 정상적으로 동작하는지 확인합니다.

캐시 플러그인을 여러 개 동시에 활성화하면 기능이 충돌할 수 있습니다. 핵심 기능이 겹치는 플러그인은 한 개만 사용하는 것이 안전합니다.

4단계: 불필요한 CSS와 JavaScript 정리

모든 페이지에 로드되는 플러그인 파일을 확인합니다.

사용하지 않는 페이지 빌더 기능, 슬라이더, 아이콘 라이브러리, 팝업, 애니메이션을 줄이면 LCP와 INP를 함께 개선할 수 있습니다.

5단계: 폰트 최적화

사용하는 글꼴 종류와 굵기를 줄이고, 외부 폰트 요청이 지나치게 많지 않은지 확인합니다.

한글 웹폰트는 파일 용량이 커질 수 있으므로 사이트 디자인에 꼭 필요한지 검토해야 합니다.

6단계: CDN 적용 검토

방문자와 서버의 물리적 거리가 멀거나 이미지와 정적 파일이 많은 사이트는 CDN으로 전송 시간을 줄일 수 있습니다.

다만 CDN을 적용했다고 서버 처리 시간이 자동으로 해결되는 것은 아닙니다. 느린 데이터베이스 요청이나 PHP 처리 문제는 별도로 점검해야 합니다.

7단계: 하나씩 변경하고 다시 측정

여러 설정을 한 번에 변경하면 어떤 설정이 개선 또는 오류를 만들었는지 알기 어렵습니다.

한 가지 항목을 변경한 뒤 캐시를 비우고 주요 기능을 확인한 다음 같은 조건에서 다시 측정하는 방식이 안전합니다.

자주 하는 실수

PageSpeed 점수 100점만 목표로 한다

Lighthouse 성능 점수는 유용한 참고 자료이지만 점수 자체가 검색 순위를 결정하는 것은 아닙니다.

점수를 높이기 위해 필요한 기능까지 제거하면 실제 사용성은 오히려 떨어질 수 있습니다.

모든 이미지를 지연 로딩한다

첫 화면의 LCP 이미지까지 지연 로딩하면 주요 콘텐츠 표시가 늦어질 수 있습니다.

지연 로딩은 화면 아래쪽 이미지에 우선 적용하는 것이 좋습니다.

최적화 플러그인을 여러 개 설치한다

캐시, CSS 축소, JavaScript 지연 기능이 중복되면 화면이 깨지거나 관리자 로그인, 결제, 댓글 기능에 문제가 생길 수 있습니다.

플러그인을 추가하기 전에 기존 플러그인이 같은 기능을 제공하는지 확인해야 합니다.

모바일 결과를 확인하지 않는다

실제 검색 방문자의 상당수가 모바일 환경을 이용할 수 있습니다.

데스크톱에서 빠른 사이트도 모바일 기기의 처리 성능과 네트워크 환경에서는 느리게 동작할 수 있으므로 모바일 결과를 우선 점검하는 것이 좋습니다.

테스트 결과 한 번만 보고 결론을 내린다

실험실 데이터는 측정할 때마다 달라질 수 있습니다.

같은 조건에서 여러 번 측정하고 중앙값이나 전반적인 추세를 비교하는 것이 더 정확합니다.

Core Web Vitals 운영 체크리스트

• □ 모바일과 데스크톱을 각각 측정했다.
• □ LCP가 2.5초 이하인지 확인했다.
• □ INP가 200ms 이하인지 확인했다.
• □ CLS가 0.1 이하인지 확인했다.
• □ 첫 화면의 LCP 요소를 확인했다.
• □ LCP 이미지에서 불필요한 Lazy Loading을 제거했다.
• □ 이미지에 width와 height를 지정했다.
• □ WebP 또는 AVIF 이미지를 사용했다.
• □ 페이지 캐시를 적용했다.
• □ 브라우저 캐시를 설정했다.
• □ Brotli 또는 Gzip 압축을 적용했다.
• □ 사용하지 않는 JavaScript를 줄였다.
• □ 서드파티 스크립트를 점검했다.
• □ 웹폰트 종류와 굵기를 줄였다.
• □ 광고와 iframe 영역의 공간을 확보했다.
• □ 모바일 메뉴와 버튼의 반응 속도를 확인했다.
• □ 변경 전후 결과를 같은 조건에서 비교했다.
• □ 주요 기능과 화면이 정상적으로 작동하는지 확인했다.

Core Web Vitals FAQ

Core Web Vitals가 좋으면 검색 순위가 바로 올라가나요?

Core Web Vitals가 좋다는 이유만으로 검색 순위가 바로 오르는 것은 아닙니다.

Google 검색은 콘텐츠의 관련성, 유용성, 신뢰성, 페이지 경험 등 다양한 요소를 함께 고려합니다. 다만 성능 개선은 사용자가 콘텐츠를 편하게 이용할 수 있도록 만들고, 사이트의 전반적인 페이지 경험을 개선하는 데 도움이 됩니다.

LCP는 무조건 2.5초 이하여야 하나요?

2.5초 이하는 좋은 상태를 판단하는 권장 기준입니다.

일부 페이지가 일시적으로 기준을 초과했다고 해서 즉시 문제가 발생하는 것은 아니지만, 실제 사용자 데이터에서 지속적으로 기준을 넘는다면 원인을 점검하는 것이 좋습니다.

INP와 예전에 사용하던 FID는 어떤 차이가 있나요?

FID는 사용자의 첫 번째 상호작용에서 입력 지연 시간을 중심으로 측정했습니다.

INP는 페이지를 이용하는 동안 발생하는 여러 상호작용의 반응성을 더 폭넓게 평가합니다. 따라서 페이지가 열린 뒤 메뉴, 버튼, 입력 기능이 실제로 얼마나 원활하게 동작하는지 파악하는 데 더 적합합니다.

PageSpeed Insights 점수와 Search Console 결과가 다른 이유는 무엇인가요?

PageSpeed Insights의 Lighthouse 결과는 특정 테스트 환경에서 측정한 실험실 데이터입니다.

Search Console은 실제 Chrome 사용자의 누적 데이터를 기반으로 합니다. 사용자 기기, 네트워크, 지역, 페이지 상태가 서로 다르기 때문에 두 결과가 일치하지 않을 수 있습니다.

Search Console에 Core Web Vitals 데이터가 없는 이유는 무엇인가요?

신규 사이트이거나 방문량이 적으면 평가에 필요한 실제 사용자 데이터가 충분하지 않을 수 있습니다.

이 경우 Lighthouse와 Chrome DevTools로 페이지를 점검하면서 실제 사용자 데이터가 쌓이는 과정을 기다려야 합니다. 보고서에 데이터가 없다는 사실만으로 성능이 양호하다고 판단해서는 안 됩니다.

캐시 플러그인을 설치하면 모든 문제가 해결되나요?

캐시는 서버 응답과 반복 요청을 줄이는 데 도움이 되지만 모든 문제를 해결하지는 못합니다.

큰 대표 이미지, 과도한 JavaScript, 잘못된 광고 영역, 폰트로 인한 레이아웃 이동 등은 별도로 수정해야 합니다.

마무리

Core Web Vitals는 단순한 속도 점수가 아니라 실제 방문자가 페이지를 얼마나 빠르고 안정적으로 이용할 수 있는지를 보여주는 지표입니다.

LCP는 주요 콘텐츠의 표시 속도, INP는 클릭과 입력에 대한 반응 속도, CLS는 화면의 안정성을 측정합니다.

성능을 개선할 때는 한꺼번에 모든 설정을 바꾸기보다 다음 순서로 진행하는 것이 좋습니다.

1. 실제 사용자 데이터와 테스트 데이터를 구분한다.
2. 가장 문제가 큰 지표를 찾는다.
3. 해당 지표에 영향을 주는 원인을 확인한다.
4. 한 가지 설정씩 변경한다.
5. 같은 환경에서 변경 전후를 비교한다.
6. 실제 사용자 데이터의 장기적인 변화를 확인한다.

콘텐츠 품질이 우수해도 페이지가 늦게 표시되거나 버튼이 반응하지 않고 화면이 계속 움직인다면 방문자는 오래 머물기 어렵습니다.

Core Web Vitals 개선은 검색엔진을 위한 작업에만 그치지 않습니다. 사이트를 방문한 사람이 원하는 정보를 더 빠르고 편안하게 확인할 수 있도록 만드는 웹사이트 운영의 기본 과정입니다.

같이 보면 좋은 글

• HTTP/1.1과 HTTP/2, HTTP/3의 차이와 실제 성능 영향
• WebP와 AVIF 이미지 포맷 비교
• Brotli 압축의 원리와 웹서버 적용 방법
• Lighthouse로 웹사이트 성능을 분석하는 방법
• 브라우저 캐시 설정과 웹사이트 속도 개선 방법