전자상거래를 위한 Core Web Vitals: 구매 의도가 높은 방문자가 최악의 성능을 경험하는 이유

전자상거래의 보이지 않는 성능 문제

제 고객 중 다수는 Core Web Vitals 통과에 깊은 관심을 가지고 있습니다. 통과한다는 것은 전체 트래픽의 75%가 좋은 경험을 해야 함을 의미합니다. 훌륭한 목표입니다. 하지만 이 75%를 최적화하는 과정에서 작지만 중요한 약 5%의 그룹, 즉 고객으로 전환될 방문자가 간과되고 있습니다.

아이러니하게도, 구매 의도가 높은 방문자들은 종종 사이트에서 최악의 성능을 경험하게 됩니다. 여러분이 최적화를 잊었기 때문이 아닙니다. 캐싱 시스템이 이들을 적극적으로 배제하기 때문입니다.

마지막 검토: 2026년 3월 Arjen Karel

CrUX 데이터가 문제를 숨기는 이유

Core Web Vitals 최적화는 주로 Google 순위 보너스로 인해 평균보다 약간 못 미치는 방문자를 최적화하는 데 초점을 맞추는 경향이 있습니다. 전자상거래에서는 이를 넘어 구매 의도가 높은 방문자에게 추가적인 초점을 맞추는 것이 매우 타당합니다. 이들이 바로 고객으로 전환되는 방문자이기 때문입니다.

Deloitte와 Google의 연구에 따르면, 페이지 속도가 0.1초 개선되면 소매 사이트의 장바구니 담기 액션이 9.1% 증가합니다. 그리고 이 순간이 바로 그들에게 캐싱이 작동을 멈추는 시점입니다.

일반적으로 장바구니에 담긴 항목 수로 이러한 사용자를 식별할 수 있습니다.

또 다른 맹점이 있습니다. CrUX(Chrome User Experience Report)는 동기화가 활성화된 Chrome 사용자만 추적합니다. 많은 전자상거래 쇼핑객이 모바일에서 Safari를 사용하거나 동기화되지 않는 브라우저를 사용합니다. CrUX 대시보드에는 녹색 점수가 표시될 수 있지만 실제 구매자는 전혀 다른 경험을 할 수 있습니다. 이것이 통과된 CrUX 점수가 전체 이야기를 말해주지 않는 이유입니다.

캐싱 절벽: 사용자가 장바구니에 항목을 추가할 때 발생하는 일

문제는 다음과 같습니다. 장바구니에 항목을 추가하면 캐싱이 파괴됩니다. 그리고 캐싱은 사이트를 빠르게 만드는 요소입니다.

캐싱 플러그인은 동적 콘텐츠가 있는 사용자에 대해 전체 페이지 캐싱을 비활성화합니다. "장바구니의 항목"처럼 단순한 것도 서버가 모든 요청마다 전체 페이지를 다시 빌드하도록 강제합니다. 이는 Time to First Byte를 크게 증가시키며, 이는 Largest Contentful Paint와 First Contentful Paint를 직접적으로 느려지게 만듭니다.

수치는 극적입니다. 일반적인 WooCommerce 사이트에서 TTFB는 약 100ms(캐시됨)에서 1,600ms 이상(캐시되지 않음)으로 증가합니다. 누군가 장바구니에 제품을 추가하는 순간 서버 응답 시간이 16배 증가하는 것입니다. 익명 방문자에게는 1초도 안 되어 로드되는 페이지를 로그인한 WooCommerce 사용자가 5~9초 동안 기다리는 경우도 보았습니다.

각 플랫폼의 처리 방식

WooCommerce는 사용자가 장바구니에 항목을 추가할 때 woocommerce_cart_hash, woocommerce_items_in_cart, wp_woocommerce_session 등의 여러 쿠키를 설정합니다. 캐싱 플러그인(WP Rocket, LiteSpeed Cache, WP Super Cache)이 이 쿠키를 감지하는 순간, 모든 페이지에 대한 캐시를 우회합니다. 장바구니 페이지뿐만이 아닙니다. 홈페이지, 제품 페이지, 카테고리 페이지가 모두 캐시되지 않습니다. 게다가 WooCommerce는 미니 카트 위젯을 업데이트 상태로 유지하기 위해 모든 페이지 로드 시 /?wc-ajax=get_refreshed_fragments로 AJAX 요청을 보냅니다. 공유 호스팅에서는 이 요청 하나만으로도 2~3초가 걸릴 수 있습니다.

이것이 주요 전자상거래 플랫폼 중 WooCommerce의 Core Web Vitals 통과율이 가장 낮은 이유 중 하나입니다. 2025 Web Almanac에 따르면 데스크톱에서 세 가지 Core Web Vitals를 모두 통과한 Shopify 사이트는 76%인 반면, WooCommerce 사이트는 33%에 불과합니다.

Shopify는 관리형 CDN 인프라 덕분에 이를 더 잘 처리하지만, Shopify조차도 customer 또는 cart 객체가 포함된 페이지는 캐시할 수 없습니다. 차이점은 Shopify의 기본 TTFB(약 0.51초)가 이미 충분히 빨라서 캐시되지 않음에 따른 패널티가 더 적다는 것입니다.

Magento 2는 기발한 해결책을 찾았습니다. 장바구니 사용자에게도 전체 페이지가 항상 캐시됩니다. 동적 콘텐츠(미니 카트, 사용자 인사말, 재고 상태)는 /customer/section/load/에 대한 AJAX를 통해 클라이언트 측에서 가져오며 브라우저의 localStorage에 저장됩니다. 페이지 자체는 전체 페이지 캐시에 유지됩니다. 이는 아키텍처 수준에서 해결된 "설계에 의한 지연(slow by design)" 문제입니다.

최고의 고객이 최악의 페이지를 보게 됩니다

수치를 보면 더욱 고통스럽습니다. Farfetch의 측정에 따르면 LCP가 100ms 증가할 때마다 전환율이 1.3% 떨어졌습니다. Blue Triangle은 LCP가 2초에서 4~5초로 느려질 때 전환율이 40~50% 감소한다는 것을 발견했습니다.

방문자가 빠르고 캐시된 사이트를 둘러봅니다. 마음에 드는 제품을 찾습니다. "장바구니에 담기"를 클릭합니다. 그 정확한 순간에 캐싱이 멈추고 TTFB는 100ms에서 1,600ms로 급증합니다. 이제부터 그들이 방문하는 모든 페이지(제품 비교, 배송 확인, 결제 진행)는 캐시되지 않습니다. 구매 가능성이 가장 높은 사람들이 현재 가장 느린 버전의 사이트를 둘러보고 있는 것입니다.

CoreDash가 모니터링하는 사이트 전반에서 자체 호스팅 전자상거래 플랫폼의 경우 장바구니 사용자가 익명 방문자보다 3~5배 더 나쁜 TTFB를 경험하는 것을 확인했습니다. Shopify와 같은 관리형 플랫폼의 경우 그 격차가 작지만(1.5~2배) 여전히 측정 가능합니다.

RUM 데이터에서 이를 감지하는 방법

Lighthouse나 PageSpeed Insights에서는 이 문제를 볼 수 없습니다. 이러한 도구는 쿠키가 없는 익명 방문자로 테스트합니다. 실제 구매자가 어려움을 겪는 동안 실험실 점수는 훌륭하게 보일 것입니다.

이 문제를 찾으려면 Real User Monitoring이 필요합니다. 사용자의 장바구니 쿠키 설정 여부에 따라 RUM 데이터를 분류하세요. 이 두 세그먼트 간의 TTFB, FCP, LCP를 비교해 보십시오. 2배 이상의 차이가 보인다면 캐싱 우회가 문제입니다.

대부분의 분석 플랫폼에서는 페이지 유형별로 분류할 수도 있습니다. (일반적으로 캐시되는) 제품 목록 페이지와 (절대 캐시되지 않는) 장바구니 및 결제 페이지를 비교하세요. 이 두 페이지 유형 간에 TTFB 차이가 500ms 이상이면 서버 대기 시간에 주의가 필요하다는 적신호입니다.

구매 의도가 높은 방문자를 위한 성능 수정 방법

캐싱에 의존하기 전에 백엔드를 수정하세요. 캐싱 플러그인에만 의존하지 마십시오. 백엔드 코드를 분석하고, 데이터베이스 쿼리를 최적화하며, 서버를 미세 조정하여 캐싱 없이도 빠른 TTFB를 보장하세요. 캐시 없이 느린 사이트는 장바구니 사용자에게 치명적으로 느릴 것입니다. TTFB의 캐시 기간 하위 부분이 모든 힘든 작업을 수행해서는 안 됩니다.

부분 캐싱(프래그먼트 캐싱)을 사용하세요. 페이지에서 비용이 많이 드는 부분을 별도로 캐시하십시오. 제품 설명, 내비게이션 메뉴 및 푸터 콘텐츠는 거의 변경되지 않으며 전체 페이지 캐시가 비활성화된 경우에도 Memcached나 Redis에 캐시할 수 있습니다. 장바구니 사용자가 페이지를 요청하면 CMS는 처음부터 모든 것을 다시 생성하는 대신 캐시된 조각으로 페이지를 조립합니다. 이는 캐시되지 않은 TTFB를 60~80%까지 줄일 수 있습니다.

동적 컴포넌트를 클라이언트 측에서 렌더링하세요. 이것이 Magento 2의 접근 방식이며 효과가 있습니다. 페이지의 대부분을 캐시된 HTML(서버 측 렌더링)로 제공하세요. 그런 다음 페이지가 로드된 후 JavaScript와 작은 API 호출을 사용하여 동적 부분(장바구니 수, 사용자 인사말, 개인화된 추천)을 가져옵니다. 브라우저는 즉시 빠르고 캐시된 HTML을 얻습니다. 동적인 부분은 잠시 후 채워집니다. LCP와 FCP는 동적 콘텐츠가 아닌 캐시된 셸에 의해 구동되므로 빠른 상태를 유지합니다.

Shopify의 헤드리스 프레임워크(Hydrogen)는 정확히 이 작업을 수행합니다. 제품 데이터는 긴 TTL로 적극적으로 캐시되는 반면, 장바구니 및 고객 데이터는 CacheNone()을 사용하고 로드 후 클라이언트 측에서 가져옵니다. 이 패턴은 또한 동적 가져오기가 사용자 상호 작용을 차단하지 않고 비동기적으로 발생하기 때문에 INP 문제를 방지합니다.

효과적인 캐시 키 관리를 구현하세요. 정적 요소(대부분 URL만으로도 충분한 캐시 키가 됨)에는 단순한 키를 사용하고, 사용자 ID, 제품 ID, 타임스탬프가 포함된 동적 콘텐츠에는 복잡한 키를 사용하세요. 이렇게 하면 "완전 캐시됨"과 "전혀 캐시되지 않음" 중에서 선택하는 대신 사용자 단위로 캐시할 수 있습니다.

장바구니가 아닌 페이지에서 장바구니 조각을 비활성화하세요. WooCommerce를 운영하는 경우 미니 카트가 표시되지 않는 페이지에서는 wc-ajax=get_refreshed_fragments 호출을 비활성화하세요. 여러 성능 플러그인(Perfmatters, FlyingPress)이 이를 위한 토글을 제공합니다. 이는 장바구니 사용자를 위한 모든 페이지 로드에서 2~3초의 AJAX 호출을 제거합니다.

에지 사이드 구성을 고려하세요. Cloudflare를 사용하는 경우 Workers는 에지에서 페이지를 조립할 수 있습니다. CDN에서 캐시된 페이지 본문을 제공하고 별도의 하위 요청을 통해 동적 조각(장바구니, 사용자 정보)을 주입합니다. Cloudflare는 정확히 이 작업을 수행하여 TTFB를 빠르게 유지하면서도 개인화된 콘텐츠를 제공하는 Workers를 위한 Edge Side Includes 구현을 게시했습니다.