쇼핑몰 Core Web Vitals 가이드: LCP·INP·CLS

LCP·INP·CLS의 의미와 75번째 백분위수 기준 임계값, 실험실 데이터와 필드 데이터의 차이, Shopify·WooCommerce 쇼핑몰의 개선 방법을 정리합니다.

FixReports 편집팀10분 분량

Core Web Vitals는 실제 방문자가 페이지를 어떻게 경험하는지 나타내는 Google의 세 가지 지표로, 로딩을 나타내는 LCP(Largest Contentful Paint), 반응성을 나타내는 INP(Interaction to Next Paint), 시각적 안정성을 나타내는 CLS(Cumulative Layout Shift)로 이루어집니다. 방문의 75% 이상이 “좋음” 범위에 들면 페이지가 기준을 통과합니다. 즉 LCP 2.5초 이내, INP 200밀리초 이내, CLS 0.1 이하여야 하며, 모바일과 데스크톱은 따로 측정합니다. 온라인 쇼핑몰에서 점수가 미달하는 원인은 대개 크거나 지연 로딩되는 히어로 이미지와 상품 이미지, 앱과 추적 스크립트, 웹 폰트, 그리고 페이지가 표시된 뒤 콘텐츠를 아래로 밀어내는 배너나 리뷰 위젯입니다.

핵심 요약

  • 좋음, 개선 필요, 나쁨은 페이지 로드의 75번째 백분위수로 판정하며, LCP는 4초 초과, INP는 500 ms 초과, CLS는 0.25 초과일 때 나쁨입니다 (web.dev (새 탭에서 열림)).
  • 2024년 3월 12일 INP가 FID(First Input Delay)를 대신해 Core Web Vitals 지표가 되었습니다 (web.dev (새 탭에서 열림)).
  • Chrome UX Report의 필드 데이터는 최근 28일의 이동 평균이며, iOS용 Chrome은 포함되지 않습니다 (Chrome for Developers (새 탭에서 열림)).
  • Shopify의 image_tag 필터는 따로 지정하지 않으면 템플릿의 처음 세 섹션에서는 이미지를 즉시 로드하고, 네 번째 섹션부터는 지연 로드합니다 (Shopify (새 탭에서 열림)).
  • WordPress 6.3부터 코어는 LCP 요소일 가능성이 가장 높다고 판단한 이미지에 fetchpriority="high"를 추가합니다 (Make WordPress Core (새 탭에서 열림)).

Core Web Vitals의 기준값은 얼마인가요?

페이지 로드의 75번째 백분위수가 세 지표 모두에서 좋음 범위에 들면 페이지가 Core Web Vitals를 충족합니다.

지표측정 대상좋음개선 필요나쁨
LCP뷰포트에서 가장 큰 이미지, 동영상 또는 텍스트 블록이 렌더링될 때까지의 시간2.5초 이하2.5초 초과 4.0초 이하4.0초 초과
INP클릭, 탭, 키 입력부터 다음 프레임이 그려질 때까지의 시간200 ms 이하200 ms 초과 500 ms 이하500 ms 초과
CLS보이는 콘텐츠가 예기치 않게 움직이는 정도0.1 이하0.1 초과 0.25 이하0.25 초과

기준값은 2026년 10월 기준 web.dev의 LCP (새 탭에서 열림), INP (새 탭에서 열림), CLS (새 탭에서 열림) 가이드를 따른 것입니다.

75번째 백분위수를 쓴다는 것은 결과가 가장 빠른 방문자만이 아니라 대부분의 방문자를 반영한다는 뜻이며, Google은 모바일과 데스크톱을 구분해 (새 탭에서 열림) 평가합니다. PageSpeed Insights는 세 지표가 모두 좋음일 때 페이지를 통과로 판정하며, INP 데이터가 충분하지 않으면 LCP와 CLS만으로 판단합니다 (PageSpeed Insights 문서 (새 탭에서 열림)). Google은 안정화된 Core Web Vitals 지표를 1년에 한 번보다 자주 바꾸지 않겠다고 밝혔습니다.

쇼핑몰에서는 LCP 요소가 히어로 배너나 대표 상품 이미지인 경우가 많기 때문에 이미지 처리가 특히 중요합니다.

2024년 3월 INP가 FID를 대체한 이유는 무엇인가요?

FID는 첫 번째 상호작용만, 그것도 지연의 일부만 측정한 반면 INP는 방문 전체의 상호작용을 살펴보기 때문에 INP가 FID를 대체했습니다.

Google은 2023년 5월 INP를 Core Web Vitals 지표로 채택한다고 발표했고, 이 전환은 2024년 3월 12일 (새 탭에서 열림)부터 적용되었습니다. FID는 첫 번째 상호작용의 입력 지연만 보고했을 뿐, 이벤트 핸들러를 실행하거나 결과를 화면에 그리는 데 걸린 시간은 포함하지 않았습니다. INP는 방문 전체에서 클릭, 탭, 키 입력을 관찰해 이상값을 제외한 가장 긴 상호작용을 보고하며, 스크롤과 마우스 오버는 포함하지 않습니다. CrUX API와 PageSpeed Insights API 사용자는 2024년 9월 9일까지 전환해야 했습니다 (web.dev (새 탭에서 열림)).

각 상호작용은 세 부분으로 나뉩니다. 입력 지연(바쁜 스크립트를 기다리는 시간), 처리 시간(핸들러 실행), 표시 지연(다음 프레임을 그리는 시간)입니다 (web.dev (새 탭에서 열림)).

쇼핑몰에서 이런 상호작용은 옵션 선택기, 수량 버튼, 장바구니 담기, 장바구니 드로어, 필터, 메뉴입니다. 첫 탭이 빨라 FID는 통과하더라도, 나중에 필터를 열 때는 느리게 느껴지는 페이지가 있을 수 있었습니다.

실험실 데이터와 필드 데이터는 어떻게 다른가요?

실험실 데이터(랩 데이터)는 고정된 조건에서 한 번 실행한 테스트 결과이고, 필드 데이터는 실제 방문자에게서 일정 기간 수집한 데이터입니다. Google은 무엇부터 고칠지 정할 때 필드 데이터를 활용하라고 권장합니다 (web.dev (새 탭에서 열림)).

실험실 데이터필드 데이터
출처시뮬레이션한 페이지 로드 1회(Lighthouse, Chrome DevTools, PageSpeed Insights의 실험실 데이터 영역)실제 Chrome 방문자(Chrome UX Report) 또는 자체 실사용자 모니터링(RUM)
조건고정된 기기와 네트워크. Lighthouse의 기본 모바일 테스트 (새 탭에서 열림)는 “Slow 4G”(왕복 150 ms, 다운로드 1.6 Mbps)와 4배 CPU 감속을 사용합니다방문자가 실제로 사용하는 기기, 네트워크, 위치
INP단순한 페이지 로드에서는 측정되지 않음. TBT(Total Blocking Time)가 대략적인 대용 지표실제 상호작용에서 측정
적합한 용도디버깅, 배포 전 변경 사항 확인방문자가 실제로 경험하는 수준 파악

TBT는 메인 스레드의 각 작업에서 50 ms를 넘는 부분을 합산한 값입니다. web.dev는 평균적인 모바일 하드웨어에서 200 ms 미만을 권장하지만, TBT가 INP를 대신할 수는 없다고 말합니다 (web.dev (새 탭에서 열림)).

쇼핑몰에 중요한 Chrome UX Report(CrUX)의 세부 사항은 세 가지입니다.

  • 매일 업데이트되는 28일 이동 평균 (새 탭에서 열림)입니다.
  • Chrome의 보고 조건을 충족하는 사용자의 데스크톱 및 Android용 Chrome을 대상으로 합니다. iOS용 Chrome은 제외되므로, 쇼핑객 대부분이 iPhone 사용자인 쇼핑몰은 일부 방문자의 필드 데이터만 보게 됩니다 (방법론 (새 탭에서 열림)).
  • 페이지와 출처(origin)는 공개적으로 발견 가능하고 방문자가 충분할 때만 포함되므로, 트래픽이 적은 쇼핑몰은 출처 수준의 데이터만 있거나 데이터가 아예 없을 수 있습니다.

Shopify의 웹 성능 대시보드 (새 탭에서 열림)도 실사용자 LCP, INP, CLS를 75번째 백분위수로 보고하지만 기간이 28일이 아닌 30일이므로, CrUX와 어느 정도 차이가 날 수 있습니다.

쇼핑몰 페이지에서 LCP를 느리게 만드는 원인은 무엇인가요?

쇼핑몰에서 LCP가 느린 이유는 대개 대표 이미지가 너무 무겁거나, 늦게 발견되거나, 지연 로딩이나 애니메이션 때문에 일부러 늦춰지기 때문입니다.

  • LCP 이미지의 지연 로딩. web.dev는 절대 이렇게 하지 말라고 말합니다 (web.dev (새 탭에서 열림)). web.dev가 WordPress 페이지를 분석한 결과, 네이티브 지연 로딩을 사용하는 사이트의 75번째 백분위수 LCP가 더 느렸고, 첫 화면(스크롤 없이 보이는 영역) 이미지에 지연 로딩을 적용하지 않자 성능 저하가 사라졌습니다 (web.dev (새 탭에서 열림)).
  • 늦게 발견되는 이미지. CSS background-image로 지정했거나 슬라이더 스크립트가 삽입하는 히어로 이미지는 브라우저가 처음 훑어보는 HTML에 없습니다. Shopify는 히어로 콘텐츠에 CSS 배경을 쓰거나 LCP 이미지에 페이드인 효과를 주지 말라고 권고합니다 (Shopify (새 탭에서 열림)).
  • 낮은 우선순위. 이미지는 레이아웃이 완료될 때까지 낮은 우선순위로 로드되므로, Shopify는 LCP 이미지에 fetchpriority="high"를 지정하라고 권장합니다 (Shopify (새 탭에서 열림)). web.dev는 이 속성을 한두 개보다 많은 이미지에 지정하면 효과가 줄어든다고 설명합니다 (web.dev (새 탭에서 열림)).
  • 렌더링을 차단하는 CSS와 스크립트. <head>에 있는 큰 스타일시트와 동기 스크립트는 이미지가 도착한 뒤에도 렌더링을 지연시킵니다 (web.dev (새 탭에서 열림)).
  • 파일 크기와 폰트. 최신 이미지 형식, srcset과 sizes, CDN을 사용합니다. 웹 폰트에는 auto나 block이 아닌 font-display 값을 지정합니다.
<!-- Main product image: real src in the HTML, eager, high priority -->
<img src="/images/linen-shirt-1200.webp"
     srcset="/images/linen-shirt-600.webp 600w, /images/linen-shirt-1200.webp 1200w"
     sizes="(min-width: 990px) 50vw, 100vw"
     width="1200" height="1500"
     fetchpriority="high"
     alt="Natural linen shirt, front view">

<!-- Gallery images below the first screen: lazy -->
<img src="/images/linen-shirt-back-600.webp" loading="lazy"
     width="600" height="750" alt="Natural linen shirt, back view">

쇼핑몰 페이지에서 INP가 느린 이유는 무엇인가요?

쇼핑몰의 INP가 느리다는 것은 대개 메인 스레드에서 실행되는 JavaScript가 너무 많아 탭이 기다려야 한다는 뜻이며, 그중 상당수는 앱, 추적 태그, 테마 기능에서 나옵니다.

리뷰, 채팅, 분석 스크립트가 아직 실행 중일 때 쇼핑객이 “장바구니에 담기”를 탭하면 그 탭은 대기하게 됩니다. 상품 폼 전체를 다시 렌더링하는 옵션 선택기는 처리 시간을 늘립니다. 거대한 메가 메뉴와 스와치가 많은 컬렉션 그리드는 표시 지연을 늘립니다.

web.dev는 긴 작업을 쪼개 메인 스레드에 양보하고, 화면을 먼저 업데이트한 뒤 나머지 작업을 미루며, DOM을 작게 유지하라고 권장합니다 (web.dev (새 탭에서 열림)). Shopify는 쇼핑몰에 맞는 단계를 덧붙입니다. 모든 앱, 픽셀, 테마 스크립트를 점검하고, 중요하지 않은 것은 지연시키고, 기능은 사용자가 상호작용할 때 로드하고, 진행 중인 테스트가 없을 때는 A/B 테스트의 깜빡임 방지(anti-flicker) 스니펫을 끄는 것입니다 (Shopify (새 탭에서 열림)).

상품 페이지와 컬렉션 페이지에서 레이아웃 이동은 왜 생기나요?

쇼핑몰의 레이아웃 이동은 대부분 첫 렌더링 뒤에 나타나거나 크기가 바뀌는 콘텐츠에서 생깁니다. 크기가 지정되지 않은 이미지, 공지 바와 쿠키 바, 리뷰 위젯, 앱 블록, 폰트 교체가 그 예입니다.

web.dev는 흔한 원인으로 크기를 알 수 없는 미디어, 기존 콘텐츠 위에 추가되는 콘텐츠, 스스로 크기를 바꾸는 서드파티 위젯, 대체 폰트와 크기가 다른 웹 폰트를 꼽습니다 (web.dev (새 탭에서 열림)). 쇼핑몰에서는 상단에 삽입되는 무료 배송 바, 상품명보다 늦게 로드되는 별점, 가격 아래의 할부 안내 문구, 추천 상품 캐러셀이 여기에 해당합니다. Shopify는 팝업 콘텐츠도 레이아웃 이동을 일으킬 수 있다고 지적합니다 (Shopify (새 탭에서 열림)).

사용자 입력 후 500 ms 이내에 일어난 이동은 집계되지 않지만, 스크롤 중의 이동은 집계되며 실험실 도구는 이를 놓치는 경우가 많습니다 (web.dev (새 탭에서 열림)). 이미지에는 width와 height 또는 CSS aspect-ratio를 지정하고, 위젯이 들어갈 자리를 미리 확보하고, 배너는 오버레이로 표시하고, size-adjust로 폰트 교체에 따른 이동을 줄이고, 애니메이션은 top이나 left 대신 transform으로 처리합니다.

/* Reserve space for a reviews summary that loads after the page */
.product-reviews-summary { min-height: 24px; }

/* Keep product cards from jumping while images load */
.product-card img { width: 100%; height: auto; aspect-ratio: 4 / 5; }

Shopify에서 Core Web Vitals는 어떻게 개선하나요?

Shopify에서는 첫 이미지를 높은 우선순위로 즉시 로드하고, 앱 스크립트를 줄이고, 관리자 화면의 웹 성능 보고서로 결과를 확인하는 것만으로 대부분의 개선 효과를 얻을 수 있습니다.

관리자 화면에서 데이터 확인

요약은 온라인 스토어 > 테마(Online Store > Themes) 페이지에 표시되고, LCP, INP, CLS 전체 보고서는 분석 > 보고서(Analytics > Reports)에 있습니다. 데이터는 최대 36시간까지 지연될 수 있으며, 비공개 모드는 꺼져 있어야 합니다 (Shopify 도움말 센터 (새 탭에서 열림)).

Liquid에서 이미지 로딩 제어

image_tag 필터는 preload를 지정하지 않으면 페이지 아래쪽 섹션의 이미지를 지연 로드합니다 (image_tag 레퍼런스 (새 탭에서 열림)). 첫 번째부터 세 번째 섹션까지는 즉시 로드하고, 네 번째 섹션부터는 지연 로드합니다. 테마 편집기에서는 section.index가 nil이므로 <= 3 대신 > 3으로 조건을 검사합니다.

{%- if section.index == 1 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'eager', fetchpriority: 'high', widths: '600, 900, 1200, 1600', sizes: '100vw' }}
{%- elsif section.index > 3 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'lazy', sizes: '100vw' }}
{%- else -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: sizes: '100vw' }}
{%- endif -%}

상품 그리드에서는 처음 몇 개의 카드만 즉시 로드하라고 Shopify는 제안합니다(예: forloop.index <= 4) (Shopify (새 탭에서 열림)). preload: true는 꼭 필요한 곳에만 사용합니다. Shopify는 늦게 발견되는 리소스 한두 개만 미리 로드하라고 권장합니다.

앱이 남긴 코드 제거

사용하지 않는 앱 임베드는 온라인 스토어 > 테마 편집 > 앱 임베드(Online Store > Edit theme > App embeds)에서 끕니다 (Shopify 도움말 센터 (새 탭에서 열림)). 앱을 삭제하면 앱 블록은 제거되지만, 테마 파일을 직접 수정한 앱은 “유령 코드(ghost code)”를 남길 수 있으며, Shopify는 이것이 품질과 성능 문제를 일으킬 수 있다고 말합니다 (Shopify (새 탭에서 열림)). Shopify는 또한 스크립트 태그가 2027년 3월 1일부터 실행되지 않는다고 밝혔습니다. 폰트의 경우 Shopify는 외부 폰트 서비스보다 자체 CDN이나 시스템 폰트를 권장합니다 (Shopify (새 탭에서 열림)).

WooCommerce에서 Core Web Vitals는 어떻게 개선하나요?

WooCommerce에서는 플러그인이 WordPress의 이미지 우선순위 처리를 덮어쓰지 않게 하고, 장바구니와 결제 페이지를 제외한 모든 페이지를 캐시하고, 필요 없이 모든 페이지에서 로드되는 스크립트를 제거합니다.

  • 코어의 이미지 처리 유지. WordPress 6.3(2023년 8월 8일 출시)부터 코어는 LCP 요소일 가능성이 높은 이미지(기본값 기준 최소 50,000제곱픽셀)에 fetchpriority="high"를 추가하고, 처음 세 개의 콘텐츠 이미지에는 지연 로딩을 적용하지 않습니다 (Make WordPress Core (새 탭에서 열림)). 최적화 플러그인이 자체 지연 로딩을 추가한다면 히어로 이미지와 대표 상품 이미지가 제외되는지 확인합니다.
  • 장바구니는 빼고 페이지 캐시. WooCommerce 가이드는 서버 또는 플러그인 페이지 캐시와 CDN을 권장하되, 장바구니와 결제 페이지는 캐시하지 말라고 안내합니다 (WooCommerce 개발자 문서 (새 탭에서 열림)).
  • 카트 프래그먼트 확인. WooCommerce 7.8부터 cart fragments 스크립트는 장바구니(Cart) 위젯이 있는 곳에서만 로드되지만, 일부 테마는 이 위젯을 하드코딩해 둡니다. 미니 카트(Mini-Cart) 블록은 cart fragments를 사용하지 않습니다 (WooCommerce 개발자 블로그 (새 탭에서 열림)).
  • 무거운 플러그인 찾기. WooCommerce는 느린 플러그인을 찾는 데 Query Monitor를 쓰고, 중요하지 않은 JavaScript는 지연 로드하라고 제안합니다.

레이아웃의 첫 화면에 이미지가 세 개보다 많이 보인다면 WordPress의 기준값을 높일 수 있습니다.

// functions.php: skip lazy loading for the first 4 content images (default is 3)
add_filter( 'wp_omit_loading_attr_threshold', function () {
    return 4;
} );

수정 효과가 나타나기까지 얼마나 걸리나요?

실험실 테스트에는 수정 효과가 바로 나타나지만, CrUX는 지난 28일을 평균하므로 필드 데이터에 완전히 반영되기까지는 최대 약 4주가 걸립니다.

한 번의 실행 결과는 편차가 있으므로 변경 전후에 실험실 테스트를 여러 번 실행한 뒤, PageSpeed Insights, Search Console의 Core Web Vitals 보고서, 또는 Shopify 보고서에서 필드 수치를 지켜봅니다. 무료 스캔을 이용하면 약 1분 만에 첫 결과를 확인할 수 있습니다. 성능 수정 리포트는 속도를 제한한 모바일 실험실 테스트(느린 4G, 4배 CPU 감속)를 실행하고 Chrome UX Report 필드 데이터를 더하며, Google에 쇼핑몰 데이터가 충분하면 INP도 포함합니다.

자주 묻는 질문

Core Web Vitals는 Google 검색 순위에 영향을 주나요?

Google은 Core Web Vitals가 순위 결정 시스템에 사용된다고 밝히면서도, 좋은 점수가 상위 순위를 보장하지는 않으며 페이지 경험이 좋지 않더라도 가장 관련성 높은 콘텐츠를 계속 보여 준다고 설명합니다 (Google 검색 센터 (새 탭에서 열림)).

PageSpeed Insights에 내 쇼핑몰의 필드 데이터가 표시되지 않는 이유는 무엇인가요?

CrUX에는 공개적으로 발견 가능하고 조건을 충족하는 Chrome 방문자가 충분한 페이지와 출처만 포함됩니다. 트래픽이 적은 쇼핑몰은 출처 수준의 데이터만 있거나 데이터가 아예 없을 수 있으므로, 실험실 테스트와 플랫폼 자체 보고서를 활용해야 합니다.

통과하려면 Lighthouse 점수가 90점 이상이어야 하나요?

아니요. Lighthouse 성능 점수는 실험실 결과이고, Core Web Vitals 평가는 75번째 백분위수의 필드 데이터를 사용합니다. 따라서 Lighthouse 점수가 그리 높지 않아도 통과할 수 있고, 점수가 높아도 통과하지 못할 수 있습니다.

상품 이미지를 모두 지연 로드해야 하나요?

아니요. 첫 화면 아래의 이미지는 지연 로드하되, 히어로 이미지와 대표 상품 이미지는 즉시 로드하고 그중 하나에 fetchpriority="high"를 지정합니다.

모바일 결과가 데스크톱보다 나쁜 이유는 무엇인가요?

Google은 모바일과 데스크톱을 따로 측정하며, 휴대전화는 프로세서와 네트워크가 더 느립니다. Lighthouse 모바일 테스트는 Slow 4G 프로필과 4배 CPU 감속으로 이런 환경을 시뮬레이션합니다.

출처

전체 가이드