웹 성능 지표 Core Web Vitals편집자 확인

구글은 웹 성능을 평가하는 핵심 기준으로 Core Web Vitals를 제시한다. 이는 웹사이트의 사용자 경험 품질을 측정하기 위한 실질적이고 통일된 지표 체계를 제공하는 것을 목표로 한다. 구글은 이러한 지표를 검색 엔진 최적화(SEO)의 랭킹 신호 중 하나로 공식적으로 사용하며, 이는 웹 생태계 전반의 성능과 사용자 만족도를 개선하려는 의도를 반영한다.

평가 기준은 LCP, FID, CLS라는 세 가지 핵심 지표에 집중한다. 각 지표는 로딩 성능, 상호작용 반응성, 시각적 안정성이라는 사용자 경험의 핵심 측면을 각각 측정한다. 구글은 이러한 지표에 대해 '양호', '개선 필요', '나쁨'의 세 가지 임계값을 정의하여 웹사이트의 성능 상태를 명확하게 분류한다.

이 기준은 페이지 경험(Page Experience)이라는 더 넓은 평가 체계의 일부로 통합된다. 페이지 경험 평가에는 Core Web Vitals 외에도 모바일 친화성, HTTPS 보안, 방해성 간섭 콘텐츠 부재 등의 요소가 포함된다. 구글은 이러한 기준을 구글 서치 콘솔의 'Core Web Vitals' 보고서와 PageSpeed Insights, Lighthouse와 같은 무료 도구를 통해 개발자와 사이트 소유자가 쉽게 측정하고 개선할 수 있도록 지원한다.

Core Web Vitals는 사용자가 웹사이트를 방문할 때 느끼는 실제 경험을 정량적으로 측정하기 위해 설계되었다. 이 지표들은 단순한 기술적 수치가 아니라, 페이지 로딩의 인지된 속도, 상호작용의 반응성, 시각적 안정성과 같이 사용자 인식에 직접적으로 영향을 미치는 요소들을 포착한다. 예를 들어, 느린 LCP는 사용자에게 콘텐츠가 준비되지 않았다는 인상을 주고, 높은 FID는 버튼이나 링크 클릭에 대한 응답이 없다는 느낌을 준다. 이러한 지연과 불안정성은 사용자의 좌절감을 높여 이탈률을 증가시키는 주요 원인이 된다.

사용자 경험과의 연관성은 비즈니스 성과와도 직결된다. 연구에 따르면, LCP가 2.5초에서 4.0초로 늘어나면 사용자 이탈 가능성이 32% 증가한다[2]. 마찬가지로, 시각적으로 불안정한 페이지(CLS 점수 낮음)는 사용자가 의도하지 않은 요소를 클릭하게 하거나, 읽고 있던 콘텐츠를 놓치게 만들어 전환율을 저하시킨다. 따라서 Core Web Vitals를 최적화하는 것은 기술적 개선을 넘어, 사용자의 만족도와 참여도를 높이고 궁극적으로 비즈니스 목표를 달성하기 위한 핵심 전략이 된다.

결론적으로, Core Web Vitals는 개발자와 사이트 소유자에게 객관적인 데이터를 제공하여, 주관적일 수 있는 '사용자 경험'을 측정하고 개선할 수 있는 실질적인 프레임워크를 마련해준다. 이 지표들을 통해 사용자가 실제로 느끼는 불편함의 원인을 파악하고, 그 해결에 우선적으로 자원을 투입할 수 있게 된다.

구글은 2021년부터 Core Web Vitals를 검색 엔진 최적화의 공식적인 랭킹 요소로 포함시켰다. 이는 웹사이트의 사용자 경험을 정량적으로 평가하여 검색 결과의 순위에 반영한다는 것을 의미한다. 구체적으로 LCP, FID, CLS 세 가지 지표가 '양호'한 기준을 충족하는 페이지는 검색 순위에서 유리한 신호를 받을 수 있다. 반대로, 이러한 지표가 '나쁨' 상태인 페이지는 사용자 경험을 저해하는 것으로 간주되어 검색 순위에서 불리해질 가능성이 있다.

Core Web Vitals가 SEO에 미치는 영향은 직접적이면서도 간접적이다. 직접적인 영향은 앞서 언급한 대로 구글의 공식 랭킹 알고리즘에 포함된다는 점이다. 간접적인 영향은 성능이 사용자의 행동에 미치는 효과를 통해 발생한다. 빠르고 반응적이며 시각적으로 안정적인 페이지는 이탈률을 낮추고 체류 시간을 늘리며 전환율을 높이는 데 기여한다. 이러한 사용자 참여 지표는 검색 엔진이 페이지의 가치를 판단하는 데 중요한 참고 자료가 된다.

SEO 측면에서 Core Web Vitals를 관리할 때는 몇 가지 주의점이 있다. 첫째, 이 지표들은 수많은 랭킹 요소 중 하나일 뿐이며, 여전히 콘텐츠의 관련성과 질이 가장 중요한 요소로 남아 있다. 둘째, 지표는 실시간으로 변동하며, 사용자 환경(기기, 네트워크 등)에 따라 측정값이 달라질 수 있다. 따라서 단일 실험실 데이터보다는 실제 사용자 데이터를 기반으로 한 장기적인 추세를 모니터링하는 것이 바람직하다. 마지막으로, 모바일과 데스크톱 환경은 별도로 평가되므로, 두 플랫폼 모두에 대한 최적화가 필요하다.

LCP는 페이지 로드 타임라인에서 가장 큰 콘텐츠 요소가 화면에 렌더링되는 시점을 측정하는 지표이다. 여기서 '가장 큰 콘텐츠 요소'는 일반적으로 이미지나 비디오 요소, 혹은 큰 텍스트 블록(예: 제목 또는 문단)을 의미한다. 이 지표는 사용자가 페이지의 주요 콘텐츠를 인지하는 데 걸리는 시간을 측정하여, 실제로 느끼는 페이지 로딩 속도를 반영한다. 좋은 사용자 경험을 제공하기 위해서는 LCP가 페이지가 처음 시작된 후 2.5초 이내에 발생해야 한다.

LCP의 측정 대상이 되는 주요 요소는 다음과 같다.

* <img> 요소

* <image> 요소 내부의 <svg> 요소

* <video> 요소 (포스터 이미지 사용 시)

* CSS background-image 속성을 통해 로드된 요소

* 텍스트 노드를 포함하는 블록 수준 요소 (예: <p>, <h1>)

LCP 값은 페이지 로드 과정에서 지속적으로 평가된다. 브라우저는 새로운 콘텐츠가 화면에 그려질 때마다 현재 '가장 큰 요소'를 식별하고, 그 요소의 렌더링 시간을 기록한다. 최종 LCP 값은 사용자와의 첫 상호작용(예: 클릭, 탭, 키 누름)이 발생하기 전까지 기록된 가장 큰 요소의 렌더링 시간으로 결정된다.

LCP 성능에 영향을 주는 일반적인 원인은 서버 응답 시간이 느리거나, 렌더링을 차단하는 자바스크립트와 CSS, 그리고 리소스 로드 시간이 길다는 점이다. 따라서 LCP를 개선하기 위해서는 서버 최적화, 중요 리소스의 우선적 로드(예: preload 사용), 렌더링 차단 리소스 제거 또는 지연, 이미지 최적화 등의 기법이 적용된다.

FID는 사용자가 페이지와 처음으로 상호작용(예: 링크 클릭, 버튼 탭, 사용자 정의 자바스크립트 컨트롤 사용)을 시도한 순간부터 브라우저가 실제로 그 상호작용에 대한 응답을 시작할 수 있을 때까지의 시간을 측정합니다. 이 지표는 사용자가 느끼는 페이지의 반응성을 직접적으로 반영합니다. 낮은 FID 값은 페이지가 사용자의 입력에 빠르게 응답한다는 것을 의미하며, 이는 긍정적인 사용자 경험으로 이어집니다.

FID의 지연은 주로 메인 스레드의 바쁨에서 비롯됩니다. 브라우저의 메인 스레드는 자바스크립트 실행, 레이아웃 계산, 페인팅 등 여러 작업을 처리합니다. 페이지 로드 초기에 많은 자바스크립트가 실행되면 메인 스레드가 차단되어 사용자의 입력 처리가 지연될 수 있습니다. FID는 이러한 '입력 지연'의 첫 번째 인스턴스를 측정하는 데 초점을 맞춥니다.

FID는 실제 사용자 모니터링 데이터를 통해 측정해야 하는 지표입니다. 이는 실험실 환경에서 재현하기 어려운 실제 사용자의 다양한 디바이스 성능과 네트워크 조건에서의 경험을 포착하기 때문입니다. FID를 개선하기 위한 주요 방법은 메인 스레드 작업을 최적화하고 분산시키는 것입니다. 여기에는 불필요한 자바스크립트 실행을 지연 또는 제거하고, 긴 작업을 작은 단위로 나누며, 웹 워커를 활용하는 것이 포함됩니다. 또한, 타사 스크립트의 영향을 최소화하고 효율적인 이벤트 핸들러를 작성하는 것도 중요합니다.

CLS는 페이지 수명 주기 동안 발생하는 모든 예상치 못한 레이아웃 이동의 누적 점수를 측정하는 지표이다. 시각적 안정성을 정량화하며, 사용자가 예측하지 못한 요소의 움직임으로 인해 방해받는 정도를 나타낸다. 점수는 이동 거리와 영향을 받는 영역의 비율을 곱한 '이동 점수'의 합으로 계산된다. 낮은 CLS 점수는 페이지의 시각적 요소가 안정적임을 의미하며, 좋은 사용자 경험의 핵심 요소로 간주된다.

CLS 문제는 주로 DOM 요소가 비동기적으로 로드되거나 동적 콘텐츠가 삽입될 때 발생한다. 대표적인 원인으로는 크기가 지정되지 않은 이미지나 동영상, 동적으로 삽입되는 광고나 위젯, 웹 폰트 로딩으로 인한 FOUT 또는 FOIT 현상 등이 있다. 이러한 요소들은 초기 렌더링 후에 로드되거나 크기가 변경되면서 주변 콘텐츠를 밀어내게 되어 사용자가 읽거나 클릭하려는 순간에 요소가 이동하는 불쾌한 경험을 초래한다.

CLS를 개선하기 위한 주요 기법은 다음과 같다.

• 미리 공간 확보: 이미지와 동영상 요소에 width와 height 속성을 명시적으로 설정한다. 또는 CSS의 aspect-ratio 속성을 사용하여 종횡비를 미리 정의한다.

• 동적 콘텐츠의 안정적인 삽입: 광고나 위젯과 같은 동적 콘텐츠를 위한 공간을 미리 확보하거나, 사용자 상호작용이 없는 영역(예: 페이지 하단)에 삽입한다.

• 폰트 로딩 최적화: font-display: optional이나 swap을 사용하거나, FOUT를 제어하기 위해 CSS Font Loading API를 활용한다.

• 레이아웃을 유발하는 속성 주의: 상단에 요소를 추가할 때는 transform 속성을 고려하며, 애니메이션은 transform과 opacity 속성을 우선 사용하여 레이아웃 이동을 최소화한다.

CLS는 사용자의 인지적 안정성과 직접적으로 연결된다. 예측 가능한 레이아웃은 사용자의 집중력을 유지하고, 실수로 잘못된 요소를 클릭하는 오류를 줄여 전반적인 사용자 경험을 향상시킨다. 따라서 LCP나 FID와 함께 웹 페이지의 핵심 품질을 평가하는 중요한 척도가 된다.

실제 사용자 데이터(RUM, Real User Monitoring) 측정은 실제 웹사이트 방문자의 브라우저에서 성능 데이터를 수집하는 방식이다. 이 방법은 실험실 환경이 아닌, 다양한 기기, 네트워크 조건, 지리적 위치에 있는 실제 사용자들의 경험을 포착한다. 따라서 Core Web Vitals를 포함한 성능 지표를 평가하는 가장 현실적이고 대표성 있는 방법으로 간주된다.

RUM 데이터는 일반적으로 웹페이지에 삽입된 작은 자바스크립트 코드 스니펫을 통해 수집된다. 이 코드는 사용자의 브라우저가 페이지를 로드하고 상호작용하는 과정에서 성능 타이밍 API(예: Navigation Timing API, Paint Timing API)를 호출하여 LCP, FID, CLS와 같은 메트릭을 측정한다. 측정된 데이터는 분석을 위해 원격 서버로 전송된다. 주요 RUM 제공업체로는 Google Analytics(GA4), CrUX(Chrome User Experience Report) 데이터를 활용하는 서비스, 그리고 상용 모니터링 도구들이 있다.

RUM 측정의 핵심 장점은 실제 사용 환경의 복잡성을 반영한다는 점이다. 다음 표는 실험실 데이터와의 주요 차이점을 보여준다.

RUM 데이터를 해석할 때는 백분위수(예: 75번째 백분위수)에 주목하는 것이 일반적이다. 이는 가장 나쁜 경험을 제외한 대부분의 사용자 경험이 이 수준 이상임을 보장하기 위한 것이다. 예를 들어, LCP의 '좋음' 기준인 2.5초 이하는 75번째 백분위수 값으로 평가받는다[4]. 따라서 성능 최적화 작업은 이 백분위수 값을 개선하는 데 초점을 맞춘다.

실험실 데이터 측정은 통제된 환경에서 웹 페이지를 로드하고 Core Web Vitals를 비롯한 성능 지표를 분석하는 방법이다. 주로 개발 단계나 로컬 환경에서 사전에 성능 문제를 진단하고 최적화하는 데 사용된다. 이 방법은 네트워크 속도, CPU 성능, 기기 사양 등 테스트 조건을 일정하게 유지할 수 있어, 코드 변경이나 리소스 최적화의 효과를 정량적으로 비교하기에 적합하다.

대표적인 실험실 측정 도구로는 Google Lighthouse와 PageSpeed Insights가 있다. Lighthouse는 Chrome DevTools에 내장되거나 커맨드 라인 도구로 실행할 수 있으며, 페이지 로드 시뮬레이션을 통해 LCP, CLS 등의 점수를 제공한다. PageSpeed Insights는 Lighthouse를 기반으로 하며, 간편한 웹 인터페이스를 통해 URL을 입력하면 실험실 데이터와 함께 현장 데이터도 함께 리포트한다. 이 외에도 WebPageTest는 전 세계 다양한 위치와 네트워크 조건에서의 테스트를 설정할 수 있어 더 포괄적인 실험실 분석이 가능하다.

실험실 데이터는 실제 사용자 환경의 다양성을 완벽히 반영하지는 못한다는 한계가 있다. 사용자의 다양한 기기, 불안정한 네트워크, 백그라운드 프로세스 등의 변수를 통제된 환경에서 모의하기 어렵기 때문이다. 따라서 실험실 데이터는 주로 성능 병목 현상을 발견하고 최적화 방향을 설정하는 데 초점을 맞추며, 최종적인 성능 평가는 RUM 데이터와 함께 종합적으로 고려해야 한다.

Core Web Vitals를 측정하고 분석하기 위해 구글은 여러 공식 도구를 제공하며, 서드파티 도구들도 이를 지원한다. 측정 환경은 크게 실험실 환경(Lab Data)과 실제 사용자 환경(RUM)으로 나뉘며, 각 도구는 서로 다른 측정 방식을 활용한다.

주요 측정 도구는 다음과 같다.

이들 도구를 조합하여 사용하는 것이 일반적이다. 예를 들어, 개발 단계에서는 Lighthouse나 Chrome DevTools를 사용하여 실험실 환경에서 성능을 진단하고 최적화한다. 이후 웹사이트가 운영되면 PageSpeed Insights나 Search Console의 Core Web Vitals 보고서를 통해 실제 사용자가 경험하는 성능을 모니터링한다. 최종적으로 web-vitals 라이브러리를 통해 자체 분석 시스템에 성능 데이터를 수집하여 장기적인 추세를 관찰할 수 있다.

LCP는 페이지의 주요 콘텐츠가 사용자 화면에 표시되는 데 걸리는 시간을 측정한다. 이 지표를 개선하려면 리소스 로딩을 최적화하고 렌더링 경로를 단축하는 데 집중해야 한다.

가장 효과적인 방법은 LCP 후보 요소(일반적으로 큰 이미지, 비디오, 배경 이미지가 있는 블록 요소, 텍스트 블록 등)의 로딩을 우선시하는 것이다. 주요 이미지는 적절한 크기로 압축하고, 최신 이미지 포맷(WebP 또는 AVIF)을 사용하며, loading="lazy" 속성을 적용하지 말아야 한다. 웹 폰트는 font-display: swap;을 사용하여 렌더링 차단을 방지하고, 가능하면 시스템 폰트를 우선 사용하는 것이 좋다. JavaScript와 CSS는 최소화, 압축, 비동기 로딩을 적용하고, 크리티컬 CSS는 인라인으로 처리하여 렌더링 차단을 줄인다.

서버 측 응답 속도는 LCP에 직접적인 영향을 미친다. TTFB를 개선하기 위해 CDN을 활용하고, 서버 인프라를 최적화하며, 캐싱 정책(Cache-Control, ETag 등)을 적극적으로 설정해야 한다. 정적 자원은 장기간 캐싱하고, HTTP/2 또는 HTTP/3 프로토콜을 사용하여 연결 효율을 높일 수 있다. 클라이언트 측에서는 리소스 힌트(preconnect, preload, dns-prefetch 등)를 사용하여 초기 연결을 미리 설정하는 것이 도움이 된다.

이러한 기법들을 적용한 후에는 PageSpeed Insights나 Lighthouse와 같은 도구를 사용하여 개선 효과를 측정하고, 실제 사용자 환경에서의 LCP 값을 Chrome User Experience Report 등을 통해 지속적으로 모니터링해야 한다.

FID 개선의 핵심은 메인 스레드의 과도한 작업을 줄여 사용자의 첫 상호작용에 빠르게 응답할 수 있도록 하는 것이다. 이를 위해 자바스크립트 실행을 최적화하는 것이 가장 중요하다. 긴 작업을 분할하거나 지연 실행하고, 불필요한 타사 스크립트를 제거하거나 지연 로드해야 한다. 또한 코드 분할과 트리 쉐이킹을 통해 초기 번들 크기를 줄여 파싱과 실행 시간을 단축할 수 있다.

메인 스레드의 응답성을 높이는 구체적인 방법은 다음과 같다.

웹 워커를 활용하는 것도 효과적인 전략이다. 메인 스레드를 차지하는 복잡한 계산 작업을 웹 워커로 옮기면 메인 스레드가 사용자 입력에 즉시 반응할 수 있다. 또한, 서버 사이드 렌더링을 통해 초기 페이지를 빠르게 보여준 후 클라이언트에서 상호작용을 처리하는 방식도 FID에 긍정적인 영향을 미칠 수 있다.

CLS (Cumulative Layout Shift)는 예기치 않은 레이아웃 이동을 측정하는 지표로, 사용자가 페이지를 읽거나 상호작용하려 할 때 요소가 갑자기 이동하는 현상을 의미한다. 이는 사용자 경험을 크게 해치며, 실수로 잘못된 버튼을 클릭하게 만들 수 있다. CLS를 개선하기 위해서는 페이지의 모든 리소스가 로드되는 동안 레이아웃이 안정적으로 유지되도록 설계해야 한다.

가장 효과적인 개선 방법은 이미지 및 비디오 요소에 명시적인 width와 height 속성을 지정하는 것이다. 이렇게 하면 브라우저가 로딩 전부터 해당 요소가 차지할 공간을 미리 확보할 수 있다. 동적으로 삽입되는 콘텐츠(예: 광고, 위젯, 동영상 플레이어)는 항상 미리 공간을 확보한 컨테이너 안에 배치해야 한다. CSS의 aspect-ratio 속성을 활용하면 반응형 디자인에서도 고정된 비율의 공간을 쉽게 확보할 수 있다.

폰트 로딩 전략도 CLS에 큰 영향을 미친다. 웹 폰트는 일반적으로 지연 로딩되며, 폰트가 적용될 때 텍스트의 레이아웃이 변할 수 있다. font-display: optional이나 swap을 사용할 때는 font-display: swap과 함께 size-adjust, descent-override 등의 속성을 사용하여 대체 폰트와의 크기 차이를 최소화해야 한다. 또는 font-display: block을 사용하여 폰트가 완전히 로드될 때까지 텍스트를 보이지 않게 처리할 수도 있다.

다음은 주요 원인과 해결 방법을 정리한 표다.

애니메이션과 전환 효과는 transform 속성을 활용하는 것이 좋다. transform은 레이아웃을 재계산하지 않고 요소를 이동하거나 변형할 수 있어 CLS를 유발하지 않는다. 마지막으로, Google Search Console의 Core Web Vitals 리포트나 Lighthouse 도구를 사용하여 문제가 발생하는 특정 페이지와 요소를 정확히 식별한 후, 위 전략을 우선순위에 따라 적용해야 한다.

성능 데이터를 수집한 후, 이를 올바르게 해석하고 개선 작업의 우선순위를 결정하는 것이 중요하다. 단순히 LCP, FID, CLS 수치만 확인하는 것을 넘어, 데이터의 분포(예: 75번째 백분위수), 사용자 세그먼트별 차이(예: 모바일/데스크톱, 지역별), 그리고 다른 웹 성능 지표와의 상관관계를 종합적으로 분석해야 한다. 예를 들어, LCP가 나쁜 페이지의 대부분에서 특정 타사 스크립트나 큰 크기의 이미지가 공통적으로 나타난다면, 그 원인을 집중적으로 해결하는 것이 효율적이다.

우선순위 결정은 비즈니스 영향도와 개선 난이도를 기준으로 이루어진다. 사용자 이탈률이나 전환율에 직접적인 영향을 미치는 지표(예: 결제 페이지의 FID)를 최우선으로 고려한다. 다음 표는 우선순위 결정을 위한 간단한 프레임워크를 보여준다.

분석 과정에서는 실제 사용자 데이터(RUM)가 실험실 데이터보다 더 높은 가치를 지닌다. RUM 데이터는 실제 다양한 사용자 환경과 네트워크 조건에서의 성능을 반영하기 때문이다. 또한, 성능 개선은 일회성 작업이 아니라 지속적인 모니터링과 반복을 통해 이루어지므로, 주요 지표에 대한 추이를 관찰하고 개선 효과를 측정하는 체계가 필요하다.

INP는 Core Web Vitals의 상호작용 반응성 지표인 FID를 대체하기 위해 2024년 3월에 공식적으로 도입되었다. FID가 페이지 로드 중 발생하는 첫 번째 입력의 지연만 측정하는 데 비해, INP는 페이지의 전체 수명 주기 동안 사용자의 모든 상호작용(클릭, 탭, 키보드 누름)에 대한 반응성을 종합적으로 평가한다. INP는 가장 지연이 긴 상호작용의 지연 시간을 기록하여, 실제 사용자가 경험하는 전반적인 반응성을 더 정확히 반영하는 지표로 설계되었다.

INP의 측정 방식은 단일 상호작용의 처리 지연을 측정하는 FID와 근본적으로 다르다. INP는 하나의 상호작용이 시작(예: 사용자 클릭)부터 다음 프레임이 화면에 그려질 때까지의 총 소요 시간을 측정한다. 이는 이벤트 처리, 메인 스레드 작업, 렌더링 파이프라인 전 과정을 포함한다. 최종 INP 값은 측정 기간(일반적으로 페이지 세션) 동안 기록된 모든 상호작용 지연의 백분위수(일반적으로 75번째 또는 98번째)를 기반으로 산출된다.

INP의 평가 기준은 좋음, 개선 필요, 나쁨의 3단계로 구분된다. 200밀리초 이하는 '좋음', 200밀리초 초과 500밀리초 미만은 '개선 필요', 500밀리초 이상은 '나쁨'으로 평가받는다. 이 기준은 사용자 인지에 기반하여, 200밀리초 미만의 응답은 즉각적으로 느껴지고, 그 이상은 지연으로 인식될 수 있음을 반영한다.

INP로의 전환은 웹 개발자에게 더 포괄적인 성능 최적화를 요구한다. 단순히 첫 입력을 빠르게 하는 것뿐만 아니라, 페이지 사용 중 발생하는 모든 상호작용, 특히 장시간 실행되는 자바스크립트 작업, 큰 레이아웃 재계산, 이벤트 핸들러의 비효율성 등을 개선해야 한다. Google Search Console의 Core Web Vitals 보고서와 Chrome User Experience Report 등 주요 모니터링 도구들은 이미 INP 데이터를 제공하고 있다.

Core Web Vitals는 Google이 제시한 웹 성능의 핵심 지표로서, 지속적으로 진화하고 있다. 초기에는 LCP, FID, CLS 세 가지 지표로 구성되었으나, 2024년 3월부터 FID는 INP(Interaction to Next Paint)로 대체되었다[7]. 이 변화는 단순한 입력 반응 속도보다는 사용자가 페이지와 상호작용하는 전체 과정의 반응성을 종합적으로 평가하는 데 초점을 맞추기 위한 것이다. INP는 페이지 수명 동안 발생하는 모든 상호작용의 지연 시간을 측정하여 가장 나쁜 값을 기록하므로, 일관된 사용자 경험을 보장하는 데 더 적합한 지표로 평가받는다.

미래에는 사용자 경험을 측정하는 지표의 범위가 더욱 확대될 가능성이 있다. 예를 들어, 스크롤 성능, 애니메이션 부드러움, 배터리 소모 효율성, 접근성과의 통합 측정 등이 새로운 핵심 평가 요소로 고려될 수 있다. 또한, 인공지능을 활용한 성능 진단과 자동 최적화 제안이 더욱 정교해질 전망이다. Google은 웹 생태계의 건강과 사용자 만족도를 지속적으로 높이기 위해 Core Web Vitals의 정의와 평가 방식을 주기적으로 검토하고 업데이트할 것으로 예상된다.

이러한 지표의 변화는 개발자와 사이트 소유자에게 지속적인 학습과 적응을 요구한다. 성능 최적화는 단순히 현재 기준을 맞추는 일회성 작업이 아니라, 변화하는 기준과 사용자 기대에 맞춰 웹 사이트를 계속 발전시키는 지속적인 과정이다.