- E-commerce
이커머스 Core Web Vitals: 매출을 갉아먹는 흔한 실수들
Paul Delcloy
저자
TL;DR
Core Web Vitals(LCP, INP, CLS)는 Google 랭킹 신호이자 전환율에 직접적인 영향을 미치는 지표입니다. 이커머스 사이트에서 반복적으로 나타나는 7가지 기술적 실수가 있습니다. 이를 바로잡으면 잃어버린 매출을 되찾을 수 있습니다 - Vodafone은 LCP를 31% 개선해 **매출 +8%**를 달성했습니다. 본 가이드는 각 실수와 구체적인 해결 방법을 자세히 다룹니다.
이커머스에 Core Web Vitals가 중요한 이유
web vitals는 단순한 Google의 변덕이 아닙니다. 실제 사용자 경험을 측정하는 지표이며, 매출에 직접적인 영향을 미칩니다.
공식 임계값(실제 방문 75 백분위수 기준):
| 지표 | 좋음 | 개선 필요 | 나쁨 |
|---|---|---|---|
| LCP (로딩) | ≤ 2.5s | ≤ 4s | > 4s |
| INP (상호작용성) | ≤ 200ms | ≤ 500ms | > 500ms |
| CLS (시각적 안정성) | ≤ 0.1 | ≤ 0.25 | > 0.25 |
수치가 모든 것을 말해줍니다:
- Vodafone: LCP 31% 개선 → 매출 +8%
- Farfetch: LCP 100ms 단축마다 → 전환율 +1.3%
- Swappie: LCP + CLS 개선 → 모바일 매출 +42%
- Cdiscount: CWV 최적화 → 블랙 프라이데이 기간 매출 +6%
이커머스 사이트 performance는 DevOps 문제가 아닙니다. 비즈니스 문제입니다.
2024년 3월부터 INP가 FID를 대체해 Core Web Vitals에 포함되었습니다. 여전히 팀이 FID를 최적화하고 있다면, 잘못된 지표를 붙잡고 있는 셈입니다.
실수 #1 - 최적화되지 않은 hero 상품 이미지 (LCP)
제가 이커머스 사이트에서 가장 자주 보는 실수입니다. 홈페이지나 상품 상세 페이지의 hero 이미지는 대부분 LCP 요소이지만, 매번 잘못 처리됩니다.
전형적인 증상:
- 압축하지 않은 2MB JPEG로 제공되는 이미지
- WebP나 AVIF 대신 PNG 포맷
- fetchpriority 속성 부재
- above-the-fold 이미지에 loading="lazy" 적용
해결책:
<img src="hero.webp" // Always use WebP or AVIF formats
fetchpriority="high" // Specify priority for the main LCP image
loading="eager" // This is optional : `eager` is default value
width="1200" // Specify image sizes
height="600"
alt="대표 상품"> // SEO and accessibility alternative description
이미지가 CSS나 JavaScript(background-image, carousel JS)를 통해 로드된다면 head에 preload를 추가하세요:
<link rel="preload" as="image" href="hero.webp" fetchpriority="high">
핵심 포인트:
- WebP(또는 최신 브라우저용 AVIF)로 변환하세요
- 품질 85-90%로 압축하세요 - 눈으로는 차이를 알 수 없습니다
- fetchpriority="high"는 페이지당 단 하나의 이미지에만 적용하세요
- Shopify에서는 테마의 hero 이미지에 loading: 'eager' 파라미터와 함께 image_tag를 사용하세요
잘 처리된 이커머스 LCP는 종종 이 이미지 하나로 결정됩니다.
실수 #2 - 페이지를 밀어내는 상품 carousel (CLS)
홈페이지의 상품 carousel은 CLS 폭탄입니다. 콘텐츠가 로드되고, carousel이 초기화되면서 페이지 전체가 아래로 튀어 오릅니다. 결과: CLS > 0.25, 사용자는 짜증나고, 클릭은 빗나갑니다.
흔한 원인:
- JS 초기화 전 carousel 높이가 예약되지 않음
- 명시적 크기(width와 height) 없는 이미지
- 표시되는 슬라이드 수의 비동기 로딩
해결책: JS가 실행되기 전에 공간을 예약하세요:
.carousel-wrapper { min-height: 420px; /* carousel의 기지 높이 */ contain: layout; }
그리고 이미지에는 항상 크기를 지정하세요:
<img src="your-image.webp" width="440" height="440" />
WooCommerce / PrestaShop에서는 서드파티 carousel 플러그인(잘못 설정된 Slick, Swiper)이 주범입니다. 스크립트가 로드되기 전에 CSS에서 컨테이너가 고정 높이를 갖는지 확인하세요.
이커머스 CLS는 80%가 명시적인 크기 지정과 공간 예약으로 해결됩니다. 전체 아키텍처를 리팩토링할 필요가 없습니다.
실수 #3 - 상호작용을 막는 서드파티 스크립트 (INP)
이커머스 INP는 가장 고치기 어려운 지표이자 가장 자주 무시되는 지표입니다. 그러나 2024년 3월부터 공식 Core Web Vital이 되었습니다.
문제는 이렇습니다: "장바구니 담기" 클릭, 메뉴 열기, 모든 상호작용은 JavaScript 코드를 실행시킵니다. 메인 스레드가 서드파티 스크립트로 점유되어 있다면, 시각적 응답은 200ms를 넘깁니다. 사용자는 사이트가 느리다고 인식합니다.
챗봇, 마케팅 픽셀, A/B testing
저는 수십 개의 이커머스 사이트에서 이 실수를 봤습니다. 흔한 범인들:
| 스크립트 | 일반적인 INP 영향 | 수정 우선순위 |
|---|---|---|
| Chatbot (Intercom, Drift, Zendesk) | +80–200ms | 높음 |
| 마케팅 픽셀 (Meta, TikTok, Pinterest) | +40–120ms | 높음 |
| A/B testing (Optimizely, AB Tasty) | +60–150ms | 높음 |
| Analytics (잘못 설정된 GA4) | +20–60ms | 중간 |
| CMP / Consent (Axeptio, Didomi) | +30–80ms | 중간 |
해결책:
-
서드파티 스크립트는
async로 로드하세요 - 절대head에 동기 방식으로 넣지 마세요.defer도 피하세요: 내부 코드(메뉴, 장바구니)가 해당 이벤트를 기다려 초기화된다면,defer로 로드된 서드파티가 기능적 SPOF를 만들 수 있습니다: 사이트는 표시되지만, 클릭에 아무것도 응답하지 않습니다. -
중요하지 않은 스크립트는 첫 사용자 상호작용 이후로 지연시키세요:
// chatbot은 첫 클릭 이후에만 로드
document.addEventListener('click', () => {
loadChatbot();
}, { once: true });
-
Chrome DevTools → Performance 탭에서 감사하세요 → 서드파티 스크립트가 유발하는 "Long Tasks"를 찾으세요
-
사용하지 않는 것은 제거하세요 - Pinterest 캠페인을 운영하지 않는 사이트에서 활성화된 Pinterest 픽셀은 순수한 낭비입니다
15-20개의 앱이 설치된 Shopify 사이트에서는 Total Blocking Time이 2초를 넘기는 경우가 흔합니다. 각 앱은 JS를 추가합니다. 정리하세요.
실수 #4 - LCP 이미지에 적용된 lazy load
흔한 역설: 팀이 모든 이미지에 loading="lazy"를 추가해 성능을 최적화하려 합니다. LCP 이미지까지 포함해서요. 결과: Largest Contentful Paint가 폭발합니다.
문제: loading="lazy"는 사용자가 해당 영역에 가까워질 때까지 브라우저가 이미지를 로드하지 못하게 합니다. 모바일에서는 hero 이미지가 above-the-fold인 경우가 많아 즉시 로드되어야 합니다. 그러나 브라우저가 페이지를 구성하기 전까지는 이미지가 viewport에 보일지 알 수 없으므로, 이미지 다운로드가 지연됩니다.
간단한 규칙:
- Above-the-fold 이미지 → loading="eager", 즉 속성의 기본값 (+ 페이지의 LCP 이미지라면 fetchpriority="high")
- Below-the-fold 이미지 → loading="lazy"
PrestaShop이나 WooCommerce 같은 플랫폼에서는 테마가 종종 전역 규칙으로 모든 이미지에 loading="lazy"를 적용합니다. hero 이미지의 템플릿을 확인하고 속성을 명시적으로 오버라이드하세요.
진단 도구: PageSpeed Insights는 LCP 요소를 직접 식별하고 loading="lazy"가 잘못 적용된 경우 알려줍니다.
실수 #5 - preload되지 않은 웹 폰트 (CLS + LCP)
웹 폰트는 이중 문제의 원천입니다: LCP를 지연시키고(폰트 로딩 중 텍스트가 보이지 않음) CLS를 발생시킵니다(폰트가 로드되면 텍스트 크기가 바뀝니다 - FOUT).
증상:
- preload 없는 font-display: swap → 로딩 시 CLS 발생
- 최적화 없이 Google Fonts에서 로드되는 폰트 → 차단성 외부 요청
- 불필요하게 로드되는 여러 굵기와 스타일
해결책:
<!-- <head> 안, 다른 모든 CSS보다 먼저 -->
<link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>
그리고 CSS에서:
@font-face {
font-family: 'Inter';
src: url('/fonts/inter-var.woff2') format('woff2');
font-display: optional; /* 느린 연결에서 FOUT 방지 */
}
font-display: optional은 swap보다 더 공격적입니다: 폰트가 캐시에서 즉시 사용할 수 없으면 브라우저는 시스템 폰트를 사용합니다. CLS 제로, LCP 지연 제로. 깨끗한 web vitals를 원하는 이커머스에게는 올바른 선택입니다.
실용적 팁: Google Fonts 대신 폰트를 로컬에 호스팅하세요. 외부 요청 하나 감소, DNS 연결 하나 감소 = LCP 개선 (그리고 GDPR 준수 강화).
실수 #6 - CLS를 유발하는 상품 필터와 정렬
동적 필터가 있는 카테고리 페이지는 전형적인 이커머스 CLS 사례입니다. 사용자가 도착하고, 필터가 JS로 로드되며, 상품 그리드 전체가 200px 아래로 내려갑니다. CLS 점수: 0.35. 실패입니다.
무슨 일이 일어나는가:
- 초기 HTML이 필터 없이 표시됨
- JS가 그리드 위에 필터 바를 삽입함
- 그리드가 아래로 밀려남 → layout shift
해결책:
초기 렌더링부터 필터 공간을 예약하세요:
.filters-container { min-height: 56px; /* 필터 바의 기지 높이 */ }
또는 더 나은 방법: 서버 사이드에서 필터를 렌더링(SSR)하여 초기 HTML에 포함되도록 하세요. 예를 들어 PrestaShop에는 이 문제를 피하는 SSR 패싯 모듈이 존재합니다.
상품 그리드의 skeleton loader에는:
.product-grid { min-height: 800px; /* 그리드의 대략적인 높이 */ }
황금 규칙: 초기 로딩 이후에 기존 콘텐츠 위로 콘텐츠를 절대 삽입하지 마세요. 만약 그래야 한다면 미리 공간을 예약하세요.
실수 #7 - 카테고리 페이지의 높은 TTFB (LCP)
TTFB(Time to First Byte)는 공식 Core Web Vital은 아니지만 LCP의 첫 번째 고리입니다. TTFB 2초는 LCP ≤ 2s를 수학적으로 불가능하게 만듭니다.
이커머스 카테고리 페이지에서 TTFB는 특정한 이유로 폭발합니다:
- 필터링된 상품을 가져오는 복잡한 SQL 쿼리
- 익명 사용자에 대한 HTML 캐시 부재
- 모든 요청마다 전체 서버 렌더링 (CDN 부재)
- 매 페이지마다 서버 측에서 실행되는 서드파티 모듈
카테고리 페이지 TTFB 목표:
- < 400ms: 훌륭함
- 400–600ms: 매우 좋음
- 600–800ms: 수용 가능
- > 800ms: 우선 수정 대상
구체적인 조치:
- 익명 사용자의 카테고리 페이지에 대해 HTML 캐시를 활성화하세요 - 이는 노력 대비 가장 큰 효과를 내는 수정입니다
- 사용자에게 가까운 edge node에서 리소스를 제공하기 위해 CDN을 사용하세요(Cloudflare, Fastly)
- SQL 쿼리를 최적화하세요: 필터(가격, 카테고리, 재고)에 사용되는 열에 인덱스를 추가하세요
- 반복되는 카탈로그 쿼리를 위해 객체 캐시(Redis, Memcached)를 활성화하세요
- PrestaShop이나 WooCommerce를 사용한다면 PHP 8.3+로 업그레이드하세요 - 성능 향상은 실재합니다
Shopify나 SFCC에서는 인프라 성능이 제공업체에 의해 관리됩니다. 그럼에도 TTFB가 높다면 사이트 코드 쪽을 살펴보세요:
- Liquid snippets나 복잡한 템플릿이 서버 응답 시간을 늦출 수 있습니다
- 맞춤형 개발이나 서버 측에서 콘텐츠를 주입하는 앱도 TTFB에 영향을 줄 수 있습니다.
정기적으로 관찰되는 또 다른 문제는 인프라 위치입니다. 글로벌 브랜드라면 유럽에만 위치한 단일 인프라는 origin과의 거리 때문에 호주나 남미 사용자에게는 더 느릴 것입니다.
이커머스의 Core Web Vitals를 어떻게 감사할 것인가
무엇이든 수정하기 전에, 측정하세요. 실제 사용자 데이터(field data)는 항상 실험실 데이터보다 우선합니다.
필수 도구:
| 도구 | 종류 | 측정 대상 |
|---|---|---|
| Google Search Console | Field | 페이지별 실제 CWV, 모바일/데스크톱 분할 |
| PageSpeed Insights | Field + Lab | LCP, INP, CLS + 권장 사항 |
| Chrome DevTools | Field + Lab | 정밀 진단, Long Tasks, waterfall |
| CrUX Vis | Field | CWV의 시계열 변화 |
| web-vitals JS | Field (RUM) | 프로덕션 측정, analytics로 전송 |
이 도구들은 무료이며 자유롭게 접근 가능합니다. 이커머스 사이트의 전반적인 성능을 파악할 수 있게 해주지만 제한된 시야만 제공합니다:
- 실험실 테스트 환경(특히 PageSpeed)은 제약이 있고 커스터마이징할 수 없습니다.
- Google이 수집하는 RUM 데이터는 Chrome Android와 데스크톱 Chrome 사용자에게만 한정됩니다.
- Field와 lab 데이터는 서버 측 문제에 대해서는 순진합니다.
이러한 도구 외에도 이커머스 web performance 전문가에게 의뢰하는 것을 고려해볼 만합니다. 서버 응답 시간을 최적화하는 profiling 등 훨씬 더 고급 도구를 사용할 수 있기 때문입니다.
| 기능 | SpeedCurve | Dynatrace | Datadog | CrUX Vis | Web Page Test |
|---|---|---|---|---|---|
| 합성 테스트 | 네, 강점입니다! | 네, 그러나 단순함 | 네, 매우 제한적 | 아니오 | 도구의 핵심 원리 |
| RUM | 비즈니스 지향 | 기술 지향 | 기술 지향 | CrUX 데이터 | Catchpoint 기능 |
| 상관관계 분석 | 네 | 아니오 | 아니오 | 아니오 | 아니오 |
| Profiling | 아니오 | 네 | 네 | 아니오 | 아니오 |
| 설치 | 온사이트 스크립트 | 스크립트 + 서버 | 스크립트 + 서버 | 없음 | 없음 |
| 가격 | 유료 (€) | 유료 (€€€) | 유료 (€€) | 무료 | Freemium |
직접 시작해 보고 싶다면, 다음과 같은 webperf 감사 프로세스를 권장합니다:
- Search Console → Core Web Vitals 보고서 → "나쁨"과 "개선 필요" 페이지를 식별하세요
- 비즈니스 영향에 따라 우선순위를 정하세요: 월 50,000 방문의 카테고리 페이지가 같은 기간 500 방문의 store locator 페이지보다 일반적으로 더 가치 있습니다.
- Chrome DevTools → Performance 탭 → 모바일에서 느린 4G 연결을 시뮬레이션하세요
사이트 성능의 근본 원인을 식별하고 싶으신가요? Shopify, PrestaShop, Sylius, 심지어 SalesForce Commerce Cloud를 사용하든, 구조화된 webperf 감사는 명확한 답을 얻는 가장 빠른 방법입니다.
각 지표의 작동 방식을 자세히 이해하려면, Core Web Vitals 공식 문서가 측정 메커니즘과 공식 임계값을 다룹니다.
이커머스 Core Web Vitals 최적화는 일회성 프로젝트가 아닙니다. 회귀가 매출에 영향을 미치기 전에 감지할 수 있도록 지속적인 monitoring을 구축하세요.
FAQ
Core Web Vitals는 이커머스의 Google 랭킹 요소인가요?
네. 2021년부터 CWV는 Google이 랭킹에 사용하는 "Page Experience" 신호의 일부입니다. 매우 경쟁이 치열한 검색어(예: "남성 러닝화")에서 콘텐츠가 동등하다면, 좋은 CWV를 가진 사이트가 우위를 차지합니다. 영향은 중간 정도이지만 실재하며, 전환율에 미치는 직접적인 영향과 합쳐집니다.
INP와 FID의 차이는 무엇인가요?
FID는 첫 번째 상호작용까지의 지연만 측정했습니다. INP는 세션 전반에 걸친 모든 상호작용의 지연 시간(클릭, 탭, 키보드 입력)을 측정합니다. 사용자가 필터를 클릭하고, 장바구니에 상품을 담고, 메뉴를 여는 이커머스 사이트의 실제 경험을 INP가 훨씬 더 잘 대표합니다. FID는 2024년 3월에 CWV에서 제외되었습니다.
Lighthouse 점수가 90 이상인데 왜 field CWV는 나쁜가요?
Lighthouse는 시뮬레이션된 연결에서 서드파티 스크립트, 쿠키, 사용자 상태 없이 실행되는 실험실 테스트입니다. Field CWV는 실제 사용자, 실제 모바일 연결, Chrome 확장 프로그램, 활성화된 마케팅 스크립트와 함께 측정됩니다. 격차는 엄청날 수 있습니다. Field 데이터(Search Console, CrUX)를 신뢰하세요.
수정 효과가 Search Console에 반영되기까지 얼마나 걸리나요?
Google은 Search Console의 CWV 데이터를 28일 롤링 윈도우의 지연으로 업데이트합니다. 수정 후 보고서에 개선이 반영되기까지 4-6주를 예상하세요. CrUX 데이터는 월간 업데이트됩니다.
Shopify에서 정말 Core Web Vitals를 최적화할 수 있나요?
네, 그러나 제약이 있습니다. TTFB와 인프라는 Shopify가 관리합니다 - 서버를 건드릴 수 없습니다. 반면 테마(이미지, 폰트, CSS, JS), 설치된 앱(각 앱은 JS를 추가합니다), Liquid 코드는 제어할 수 있습니다. 가장 큰 이득은 종종 불필요한 앱 제거와 이미지 최적화에서 나옵니다.
이커머스에 가장 영향이 큰 CWV는 무엇인가요?
LCP가 첫 번째입니다. 페이지 도착 시점부터 속도 인지를 결정하기 때문입니다. INP가 두 번째인데, 구매 경험(필터, 장바구니, checkout)에 직접 영향을 미칩니다. CLS가 세 번째입니다 - 높은 CLS는 잘못된 클릭과 사용자 좌절을 유발하지만, 전환에 대한 영향은 더 간접적입니다.
유용한 자료
- Web Vitals - Google 공식 문서 - 정의, 임계값, 지표 수명 주기
- Core Web Vitals와 비즈니스 영향 - 사례 연구 - Vodafone, Tokopedia, Redbus, Cdiscount 사례
- LCP 최적화 - web.dev - 완전한 기술 가이드
- INP 최적화 - web.dev - 완전한 기술 가이드
- CLS 최적화 - web.dev - 완전한 기술 가이드
- PageSpeed Insights - field + lab 측정 도구
- Core Web Vitals 보고서 - Google Search Console - 페이지별 실제 데이터
업데이트 03 6월 2026