Speculation Rules: 이커머스를 위한 prefetch와 prerender

이커머스 사이트에서 상품 상세 링크를 클릭하고 첫 화면이 보이기까지 평균 800ms에서 2초가 걸립니다. Speculation Rules는 사용자가 클릭하기도 전에 페이지를 미리 불러와, 이 시간을 사실상 0에 가깝게 줄여줍니다.

원리: 다음 클릭을 미리 예상하기

Speculation Rules는 Chrome 121부터 내장된 선언형 API입니다. 기존의 <link rel="prefetch">를 더 강력하고 제어 가능한 메커니즘으로 대체합니다. 예측에는 두 가지 수준이 있습니다:

• Prefetch – 대상 페이지의 HTML과 핵심 서브리소스를 내려받습니다. 렌더링은 클릭 시에 수행됩니다.
• Prerender – 더 나아가, 브라우저가 백그라운드에서 전체 DOM을 구성합니다. 클릭하면 즉시 페이지가 표시됩니다.

구현은 <script type="speculationrules"> 태그 안의 하나의 JSON 블록으로 충분합니다:

<script type="speculationrules">
{
  "prerender": [
    { "where": { "selector_matches": ".product-card a" }, "eagerness": "moderate" }
  ]
}
</script>

eagerness 파라미터가 트리거 시점을 제어합니다: conservative는 hover를 기다리고, moderate는 그보다 적극적으로, eager는 즉시 미리 로드합니다.

Rayban: 프로덕션에 가장 먼저 도입한 사례 중 하나

Rayban은 PLP에 Speculation Rules를 가장 먼저 도입한 브랜드 중 하나입니다. 그들의 접근은 뷰포트 내에 보이는 상품 카드 링크를 대상으로 하고 eagerness: moderate를 사용하는 것이었습니다. 그 결과, PLP → PDP 전환에서 체감 LCP가 1.2초에서 200ms 이하로 감소했습니다.

💡 moderate 선택은 전략적입니다. 48개 상품이 있는 PLP에서 eager를 쓰면 48개의 prerender가 동시에 발생해 모바일 대역폭에 치명적입니다. moderate에서는 Chrome이 hover되었거나 뷰포트에 가까운 링크만 미리 로드합니다.

CHANEL에서 구현한 방식

CHANEL에서는 상황이 달랐습니다. 사이트가 매우 비주얼 중심이고 고해상도 이미지, 동영상 등 무거운 에셋이 많았습니다. 전체 prerender는 대역폭 소모가 너무 컸죠. 그래서 하이브리드 접근을 택했습니다:

• PLP에서 처음 보이는 상위 6개 상품 카드에 대해 Prefetch
• Prerender는 메가 메뉴에만 적용 — 특정 축에서 대부분의 탐색이 몰리는 항목들

⚠️ 사용자 의존 데이터가 있는 페이지 (account, cart, checkout)에는 절대 스페큘레이션을 적용하지 마십시오

필드 측정 결과: 해당 페이지들의 중앙값 LCP가 380ms 감소했고, 전환에도 유의미한 개선이 관측되었습니다

Speculation Rules가 특히 효과적인 경우

모든 사이트가 동일한 이득을 얻는 것은 아닙니다. 특히 효과가 두드러지는 경우는 다음과 같습니다:

• PLP → PDP에서 예측 가능한 상품 상세 — 상위 3~6개 결과가 대부분의 클릭을 차지
• 메가 메뉴에서 주요 카테고리로 — 이동 경로가 매우 예측 가능
• 에디토리얼 페이지에서 고정된 랜딩 페이지로 연결되는 CTA
• 내부 검색 엔진 — 첫 번째 결과 prefetch

반대로, 다단계 checkout이나 제품 구성기처럼 다음 페이지가 서버 측 폼에 좌우되는 흐름에서는 효과가 없습니다. 경로가 선형적이기 때문입니다.

피해야 할 함정

Prerender는 메모리와 CPU를 소모합니다. Chrome은 moderate에서 동시 prerender를 2개, eager에서 10개로 제한합니다. 이 한도를 넘어도 오류는 발생하지 않으며, 기존의 추측 작업이 조용히 폐기됩니다.

• 부작용이 있는 페이지(장바구니 추가, 전환 트래킹)는 절대 prerender하지 말 것
• PerformanceObserver의 speculation-rules 엔트리 타입으로 대역폭 영향을 모니터링
• 느린 3G 연결에서 테스트 — 제한된 네트워크에서 500KB prefetch가 현재 페이지를 느리게 할 수 있음
• 호환성 확인: Chrome 121+만 지원. Safari와 Firefox는 해당 태그를 조용히 무시함.

Speculation Rules는 어떻게 테스트하나요?

구성한 규칙이 제대로 동작하는지 확인하려면 Chrome DevTools가 상세한 정보를 제공합니다. Application 탭에서 현재 페이지에 정의된 모든 규칙을 확인할 수 있습니다. prefetch나 preload가 발생하면 Speculative loads 전용 탭에 기록됩니다. 경로는 Application > Background services > Speculative loads입니다.

실제 영향 측정하기

CrUX는 스페큘레이션의 이득을 직접적으로 포착하지 못합니다(사전 로드된 페이지 뷰 비율만 확인 가능) – LCP/FCP 지표는 초기 로드에서만 측정되고, 소프트 내비게이션은 제외되기 때문입니다. 효과를 측정하려면 RUM 측에서 계측해야 합니다:

performance.getEntriesByType("navigation").forEach(entry => { if (entry.activationStart > 0) { console.log("Page prerendered, activation delay:", entry.activationStart); } });

activationStart 속성이 0이 아니면 해당 페이지가 prerender된 것입니다. prerender 혜택을 받은 내비게이션의 규모와 대상을 정량화하는 유일하게 신뢰할 수 있는 방법입니다.

Speculation Rules는 기존 최적화를 대체하지 않습니다 — 나쁜 TTFB는 prerender 여부와 상관없이 여전히 나쁩니다. 하지만 이미 잘 최적화된 사이트에서는 페이지 간 전환 시간이라는 마지막 마찰을 제거해 줍니다.