Speculation Rules로 페이지 즉시 로드하기
Speculation Rules API를 통해 페이지를 즉시 로드하여 Core Web Vitals를 개선하는 방법을 알아보세요.
Speculation Rules API로 Core Web Vitals 즉시 개선하기
왜 어떤 페이지는 즉시 로드되는 것처럼 보이는지 궁금하신가요? 아마도 그 페이지에 Speculation Rules가 구현되어 있기 때문일 것입니다!
Speculation Rules API는 다중 페이지 애플리케이션(MPA)에서 향후 페이지 로드 속도를 prefetch하거나 심지어 prerender하여 향상시킵니다. 개발자는 브라우저가 더 빠르고(또는 즉각적인) 페이지 로드를 위해 문서를 prefetch 또는 prerender하도록 제안하는 speculation rules를 구성할 수 있습니다. Speculation rules는 리소스를 prefetch하기 위한 <link rel="prefetch">와 같은 이전 기술이나 더 이상 사용되지 않는 Chrome 전용 <link rel="prerender">를 대체합니다.
Speculation rules는 문서 수준에서 작동하므로 전체 페이지 탐색이 수반되는 MPA에 적합합니다. 주로 API 호출이나 부분적인 콘텐츠 업데이트를 사용하는 단일 페이지 애플리케이션(SPA)은 내부 라우트 변경에 대해 이 API의 이점을 크게 누리지 못할 것입니다. 그러나 Speculation Rules는 랜딩 페이지에서 애플리케이션의 초기 상태를 prerender하여 초기 로드 시간을 잠재적으로 상쇄함으로써 여전히 SPA에 이점을 줄 수 있습니다.
최종 검토: 2026년 2월, Arjen Karel
Speculation Rules 퀵스타트
이미 speculation rules가 무엇인지 알고 계신가요? 잘됐네요! 즉시 시작할 수 있도록 준비된 스니펫이 여기 있습니다. 자신에게 맞는 스니펫을 골라 페이지의 <head>에 배치하기만 하면 됩니다(prerender를 prefetch로 변경하거나 eagerness를 자유롭게 변경하세요)!
<!--
corewebvitals.io에서 제공하는 WordPress speculation rules
모든 내부 링크를 prefetch합니다
wp-login, wp-admin, wp content와 일치하는 링크는 건너뜁니다
nofollow 속성이 있는 링크는 건너뜁니다
쿼리 문자열이 있는 링크(예: /search?q=welcome)는 건너뜁니다
-->
<script type="speculationrules">
{
"prefetch": [{
"source": "document",
"where": {
"and": [
{ "href_matches": "\\/*" },
{ "not": {
"href_matches": [
"\\/wp-login.php",
"\\/wp-admin\\/*",
"\\/*\\\\?*",
"\\/wp-content\\/*"
]
}},
{ "not": {
"selector_matches": "a[rel~=\\"nofollow\\"]"
}}
]
},
"eagerness": "moderate"
}]
}
</script>
<!-- corewebvitals.io에서 제공하는 Data-preload 트리거 speculation rules -->
<script type="speculationrules">
{
"prefetch": [{
"source": "document",
"where": {
"selector_matches": "a[data-preload]"
},
"eagerness": "moderate"
}]
}
</script>
팁: 나만의 speculation rules를 빠르게 만들어야 한다면 <b>speculation rules 생성기</b>를 사용해 보는 것은 어떨까요?
실제 도입 효과
Speculation rules는 이론적인 것에 그치지 않습니다. 웹에서 가장 유명한 기업들이 이미 이를 사용하며 측정 가능한 결과를 얻고 있습니다.
Ray-Ban은 moderate eagerness를 사용하여 제품 목록 페이지에 prerender 규칙을 구현했습니다. 모바일에서 LCP가 4.69초에서 2.66초로 단축되었습니다(43% 향상). 모바일 전환율은 101%, 데스크톱 전환율은 156% 증가했습니다.
Shopify는 2025년 6월 전체 플랫폼에 conservative prefetch를 도입했습니다. A/B 테스트 결과, 모든 페인트 지표에 걸쳐 데스크톱에서는 평균 130ms, 모바일에서는 180ms의 향상을 보였습니다.
2024년 9월에 출시된 Cloudflare Speed Brain은 기본적으로 모든 Cloudflare 요금제에 speculation rules를 추가합니다. prefetch에 성공한 사이트는 LCP가 45% 감소했습니다.
심지어 Google Search도 speculation rules를 사용합니다. 검색 결과는 eager eagerness로 prefetch되어 클릭당 Android LCP를 67ms 절약합니다.
CoreDash에서 모니터링하는 사이트 전반에서 prerender된 탐색의 p75 LCP는 320ms로, 동일한 사이트의 표준 탐색 1,800ms와 비교됩니다. 단일 API만으로 82%가 개선된 것입니다. moderate eagerness로 speculation rules를 사용하는 사이트는 전체 탐색의 약 28%가 성공적으로 prefetch되거나 prerender됩니다. prefetch된 탐색은 HTML이 이미 브라우저의 인메모리 캐시에 있기 때문에 p75 TTFB가 45ms에 불과합니다.
Speculation Rules의 이점
향상된 UX (User Experience): 콘텐츠를 예측하고 미리 로드함으로써 Speculation Rules는 거의 즉각적인 페이지 로드를 보장하여 사용자가 매끄럽게 탐색할 수 있도록 합니다. 이는 복잡성이나 JavaScript 의존성 없이 전통적인 다중 페이지 웹사이트에서도 단일 페이지 애플리케이션의 성능에 필적합니다. 더 빠른 로드 시간은 더 나은 브라우징 경험을 의미하며, 사용자 참여도를 높이고 이탈률을 줄일 가능성이 높습니다.
SEO 이점: 향상된 페이지 속도는 직접적인 랭킹 요소이며 더 나은 Time to First Byte는 더 나은 Largest Contentful Paint로 이어지므로, speculation rules를 구현하면 당연히 Core Web Vitals가 개선되고 PageSpeed 보너스를 얻을 수 있습니다.
복잡성 감소: 이전에는 SPA를 사용하거나 MPA를 위한 사용자 지정 prefetch 로직을 작성해야만 거의 즉각적인 페이지 로드가 가능했습니다. 많은 사용 사례에서 SPA의 단점은 초기 부팅 시간인데, JavaScript에 크게 의존하기 때문에 상당한 시간이 소요될 수 있으며 MPA에 비해 복잡성이 증가합니다. Speculation rules에는 이러한 문제가 없습니다. 이를 통해 특히 콘텐츠 중심의 더 넓은 범위의 웹사이트에서 빠른 로드를 실현할 수 있습니다.
또한 이 API는 로직의 상당 부분을 브라우저에 위임하여 어떤 페이지를 prerender할지 결정하는 프로세스를 단순화합니다. 이는 JavaScript에 의존하여 이러한 확인을 수행하고 미리 로드할 페이지를 주입했던 이전 방법에 비해 엄청난 개선입니다. 브라우저는 prerender 여부를 결정할 때 모바일 기기의 부족한 메모리나 배터리 절약 모드와 같은 사용자 컨텍스트를 기본적으로 고려할 수 있습니다. 이러한 동적 적응은 사용자 리소스를 절약하고 제약이 있는 환경에서도 더 부드러운 경험을 보장합니다.
기타 이점: Speculation-Rules HTTP 헤더를 사용하면 문서 콘텐츠를 직접 수정할 필요 없이 콘텐츠 전송 네트워크(CDN)를 통해 더 쉽게 배포할 수 있습니다. document rules를 통한 세밀한 제어를 통해 개발자는 URL 패턴이나 CSS 선택자를 기반으로 prefetch 또는 prerender에 대한 정확한 조건을 정의할 수 있습니다. 이를 통해 수동으로 URL을 지정하는 일을 줄이고 사이트 전체에 적용되는 speculation ruleset을 만들 수 있습니다. "eagerness" 설정은 speculation이 발생하는 시점에 대한 세밀한 제어를 제공하여 미리 로드하는 속도와 리소스 소비 간의 균형을 유지합니다. 이는 불필요한 미리 로드를 줄이고 리소스 낭비를 방지하는 데 도움이 됩니다.
브라우저 지원
Speculation rules는 Chrome 109+, Edge 109+ 및 모든 Chromium 기반 브라우저에서 지원됩니다. Can I Use에 따르면 이는 전 세계 브라우저 트래픽의 약 79%를 차지합니다. Firefox는 prefetch 부분에 대해 긍정적인 표준 입장을 표명했지만 아직 지원을 출시하지는 않았습니다. Safari 26.2에는 플래그 뒤에 작동하는 구현이 있지만 기본적으로 활성화되어 있지는 않습니다.
speculation rules를 지원하지 않는 브라우저의 경우, 기능 감지를 사용하여 <link rel="prefetch">로 fallback할 수 있습니다.
if (HTMLScriptElement.supports &&
HTMLScriptElement.supports('speculationrules')) {
// 브라우저가 speculation rules를 지원합니다
} else {
// fallback: <link rel="prefetch"> 주입
const link = document.createElement('link');
link.rel = 'prefetch';
link.href = '/next-page.html';
document.head.append(link);
}
Speculation Rules 메커니즘
Speculation rules는 JSON 구조를 사용하여 정의되며 다음 두 가지 방법으로 구현할 수 있습니다.
- 인라인 스크립트: 메인 HTML 문서의
<head>또는<body>내의<script type="speculationrules">태그 안에 JSON을 포함합니다. - HTTP 헤더: 문서의 응답에서
Speculation-RulesHTTP 헤더를 사용하여 규칙을 전달합니다. 이 헤더는 규칙이 포함된 JSON 파일을 가리키므로 HTML 콘텐츠를 직접 수정하지 않고도 더 쉬운 CDN 배포가 가능합니다.
JSON 구조는 "prefetch" 및 "prerender" 배열을 사용하여 각 투기적 로드 유형에 대한 규칙을 포함합니다. 각 규칙은 URL 목록 또는 document rules와 같은 다른 소스를 사용할 수 있습니다.
- urls (URL 목록): prefetch 또는 prerender할 URL의 배열입니다.
- where (document rules): 페이지의 어떤 링크를 prefetch하거나 prerender해야 하는지 결정하는 조건을 사용하는 객체입니다.
각 규칙은 다음과 같은 속성을 포함하는 객체로 정의됩니다.
- requires: speculation에 대한 제한을 설정하는 문자열 배열입니다. 현재 유효한 유일한 문자열은 "anonymous-client-ip-when-cross-origin"이며, 이는 cross-origin prefetch가 클라이언트의 IP 주소를 익명화해야 함을 나타냅니다.
- target_hint: 탐색 가능한 타겟 이름("_self" 또는 "_blank")에 대한 힌트를 제공하는 문자열로, user agent가 로딩 프로세스를 최적화할 수 있도록 합니다.
- referrer_policy: prefetch되거나 prerender된 URL에 적용할 referrer policy입니다.
- relative_to ("list" 소스에만 해당): "urls" 배열에 제공된 URL이 문서의 기본 URL("document")에 상대적인지 또는 speculation rules JSON 파일의 위치("ruleset")에 상대적인지 지정합니다.
- eagerness: 브라우저가 얼마나 적극적으로 prefetch 또는 prerender해야 하는지 제어합니다. 사용 가능한 설정은 "immediate", "eager", "moderate" 및 "conservative"이며 각각 다른 트리거를 갖습니다.
- expects_no_vary_search: speculation된 URL이 검색 매개변수에 따라 다른 응답을 가질 것으로 예상되는지 여부를 브라우저에 알려주는 힌트입니다. 콘텐츠를 변경하지 않는 UTM 매개변수나 기타 트래킹 쿼리 문자열이 있는 페이지에 유용합니다.
마지막으로 각 규칙에는 eagerness 설정이 있어 speculation을 실행할 시점을 정의할 수 있으며, 언제 speculation할 것인지와 어떤 URL에 대해 speculation을 수행할 것인지를 분리합니다. eagerness 설정은 list 및 document 소스 규칙 모두에 사용할 수 있으며 immediate, eager, moderate, conservative의 네 가지 설정이 있습니다.
- immediate: speculation rules가 관찰되자마자 가능한 한 빨리 speculation하는 데 사용됩니다.
- eager: 데스크톱에서는 링크 위로 10밀리초 동안 마우스를 가져가면 트리거됩니다. 모바일에서는(2026년 1월부터) 링크가 뷰포트에 들어온 지 50ms 후에 트리거됩니다.
- moderate: 링크 위로 200밀리초 동안 마우스를 가져가면(또는 그보다 먼저 발생하는 pointerdown 이벤트에서, 그리고 hover 이벤트가 없는 모바일에서) speculation을 수행합니다.
- conservative: 포인터나 터치 다운 시 speculation합니다.
Chrome 한도
Chrome은 남용을 방지하고 기기 리소스를 보호하기 위해 동시 speculation에 대한 한도를 시행합니다.
- immediate / eager: 최대 50개의 prefetch와 10개의 prerender.
- moderate / conservative: 최대 2개의 prefetch와 2개의 prerender (FIFO: 새로운 speculation이 가장 오래된 것을 대체합니다).
또한 데이터 절약 모드가 활성화되어 있거나, 기기가 배터리가 부족한 상태에서 배터리 절약 모드에 있거나, 사용자가 "페이지 미리 로드" 설정을 비활성화한 경우 Chrome은 speculation을 완전히 비활성화합니다.
Prefetch 또는 Prerender
Speculation Rules API는 prefetch와 prerender라는 두 가지 주요 형태의 투기적 로딩을 지원합니다. 두 기술 모두 페이지 로드 속도를 높일 수 있지만, 복잡성과 리소스 소비 측면에서 차이가 있습니다.
- Prefetching은 더 가벼운 형태의 투기적 로딩입니다. 페이지나 해당 하위 리소스를 렌더링하지 않고 대상 URL의 HTML을 다운로드하고 캐시합니다. 이 접근 방식은 주로 Time to First Byte를 개선합니다. 개선된 Time to First Byte는 Largest Contentful Paint 및 First Contentful Paint와 같은 더 나은 페인트 지표로 이어집니다.
- Prerendering은 HTML만 다운로드하는 것보다 훨씬 더 많은 일을 합니다. HTML과 모든 하위 리소스를 다운로드하고 보이지 않는 숨겨진 탭에서 전체 페이지를 렌더링합니다. 이 페이지로 탐색하면 거의 즉각적인 디스플레이가 표시됩니다. 이 기술은 Time to First Byte를 개선하는 것 이상의 방법으로 Largest Contentful Paint를 향상시킵니다. 또한 LCP 요소도 다운로드하고 렌더링합니다. Prerendering 후에는 리소스 크기가 이미 알려져 있으므로 Prerendering은 Cumulative Layout Shift를 제거할 수도 있습니다.
세 번째 옵션인 스크립트 전까지 prerender(prerender until script)도 있습니다. 이 새로운 기능(Chrome 144, 2026년 1월)은 HTML을 가져와서 렌더링 및 하위 리소스 로딩을 시작하지만, 첫 번째 차단 스크립트 태그에서 JavaScript 실행을 일시 중지합니다. 이는 CSS, 이미지, 글꼴을 미리 로드하면서 스크립트 부작용(예: 분석 실행)을 제거합니다.
그렇다면 무엇이 더 나을까요? Prerendering일까요, Prefetching일까요? 이는 페이지와 평균적인 방문자에 따라 다릅니다. Prerendering이 설계상 더 빠를 수는 있지만, 클라이언트와 서버 모두에서 훨씬 더 많은 리소스를 사용합니다. Prerendering 또는 Prefetching에 대한 선택은 다음에 따라 달라집니다.
- 사용자의 기기 기능: 제한된 메모리를 가진 기기로 방문하는 비율이 높다면 Prerendering이 최선의 선택이 아닐 수 있습니다.
- Prerender 또는 prefetch 규칙의 특수성: 어떤 링크는 클릭될 가능성이 더 높고 어떤 페이지는 전환될 가능성이 더 높습니다. 이러한 페이지는 prerender 규칙을 위한 완벽한 후보입니다. 다른 페이지는 prefetch에 더 적합할 수 있습니다.
리소스 요구량이 많기 때문에 특히 모바일 기기나 느린 연결에서는 과도한 prerendering을 주의해야 합니다. prerendering의 잠재적인 이점은 성능 저하 및 리소스 낭비의 위험과 비교하여 저울질해야 합니다.
올바른 eagerness 설정
어떤 eagerness 설정을 사용할지는 사이트에 따라 다릅니다. 매우 단순한 정적 사이트의 경우, 더 적극적으로 speculation하는 것은 비용이 거의 들지 않으면서 사용자에게는 유익할 수 있습니다. 더 복잡한 아키텍처와 무거운 페이지 payload를 가진 사이트는 사용자로부터 긍정적인 의도 신호를 얻어 낭비를 제한할 때까지 덜 자주 speculation함으로써 낭비를 줄이는 것을 선호할 수 있습니다.
Speculation Rules API의 eagerness 설정은 브라우저가 예측된 사용자 탐색을 기반으로 콘텐츠를 언제 prefetch 또는 prerender할지에 영향을 미칩니다. 이 설정은 미리 로드의 이점을 극대화하는 것과 리소스 낭비를 최소화하는 것 사이의 절충안을 제공합니다.
list 규칙의 기본 eagerness는 immediate입니다. moderate 및 conservative 옵션은 사용자가 상호 작용하는 URL을 특정 목록으로 제한하도록 list 규칙에 사용될 수 있습니다. 많은 경우 적절한 where 조건이 있는 document rules가 더 적절할 수 있습니다.
document rules의 기본 eagerness는 conservative입니다. 문서가 많은 URL로 구성될 수 있다는 점을 감안할 때, document rules에 immediate 또는 eager를 사용할 때는 주의해야 합니다.
eagerness를 구성할 때 개발자는 UX, 리소스 비용 및 브라우저 제한 사항을 고려해야 합니다. 과도한 speculation은 사용자의 대역폭, 메모리 및 CPU에 부담을 주어 특히 제약이 있는 네트워크나 기기에서 성능을 저하시킬 수 있습니다. 또한 사용자가 구성한 데이터 절약 모드, 배터리 부족 상태 또는 브라우저 확장 프로그램과 같은 요인이 리소스 절약을 우선시하여 speculation rules를 재정의할 수 있습니다.
Speculation rules 확인 및 디버깅
페이지에 speculation rules가 있는지 확인하려면 Chrome DevTools를 열고 Application 패널로 이동한 다음 Background Services > Speculative Loads > Speculations로 이동하세요. (디버깅할 페이지를 로드하기 전에 Speculations 창을 여세요.) 이 패널은 다음 정보를 제공합니다.
- 성공한 speculation 횟수.
- prerender되거나 prefetch되는 개별 URL.
- 각 speculation의 상태.
Performance 패널의 Network 트랙은 DevTools 컨텍스트를 전환할 필요 없이 prerender된 리소스와 관련된 네트워크 활동을 표시합니다. 또한 DevTools 컨텍스트를 prerender된 페이지로 전환하여 일반 페이지처럼 검사할 수도 있습니다.
Speculation Rules 모니터링 및 분석
- Real User Monitoring (RUM): RUM 도구를 사용하여 실제 UX를 측정하세요. Largest Contentful Paint (LCP)와 같은 지표를 관찰하여 speculation rules가 페이지 로드 시간에 미치는 영향을 평가합니다. prerender되지 않은 페이지와 비교하여 prerender된 페이지에서 LCP의 개선 사항을 찾아보세요.
- A/B 테스트: A/B 테스트를 수행하여 다양한 speculation rule 구성을 비교하고 특정 웹사이트 및 사용자 기반에 가장 적합한 설정을 식별하세요.
고려 사항
리소스 소비: speculation을 남용하면 대역폭, 메모리 및 CPU 사용량에 부정적인 영향을 미칠 수 있습니다. conservative 또는 moderate eagerness로 시작하여 결과를 모니터링한 후 값을 늘리세요.
브라우저 호환성: 모든 브라우저가 Speculation Rules API를 완벽하게 지원하는 것은 아닙니다. 위의 기능 감지 코드를 사용하여 Chromium이 아닌 브라우저에 대한 fallback을 제공하세요.
개인 정보 보호: 개발자는 speculation rules가 사용자 브라우징 패턴을 노출할 수 있는 방식에 주의를 기울이고 적절한 개인 정보 보호 조치를 구현해야 합니다. cross-origin prefetch의 경우 "anonymous-client-ip-when-cross-origin" 요구 사항을 사용하여 Chrome의 비공개 prefetch 프록시를 통해 클라이언트 IP를 마스킹하세요.
분석: Prerender된 페이지는 JavaScript를 실행하므로 사용자가 실제로 탐색하기 전에 분석 스크립트가 실행됩니다. Google Analytics 및 Google Publisher Tag는 이를 자동으로 처리합니다. 다른 분석 도구의 경우 페이지가 활성화될 때까지 초기화를 지연하세요.
if (document.prerendering) {
document.addEventListener('prerenderingchange', function() {
initAnalytics();
}, { once: true });
} else {
initAnalytics();
}
Speculation Rules API는 웹 애플리케이션의 성능과 UX를 향상시키는 강력한 접근 방식을 제공합니다. 메커니즘, 이점 및 고려 사항을 이해함으로써 개발자는 이 API를 사용하여 더 빠르고 매력적인 웹사이트를 구축할 수 있습니다.
Speculation Rules 및 WordPress
WordPress 6.8(2025년 4월)부터 speculation rules가 WordPress Core에 내장되었습니다. 기본 구성은 conservative eagerness와 함께 prefetch를 사용하며, 방문자가 로그인하지 않고 고유 주소(permalinks)가 활성화되어 있을 때 모든 프런트엔드 페이지에 적용됩니다.
WordPress Core Performance 팀은 더 많은 제어 기능을 제공하는 독립 실행형 Speculative Loading 플러그인(활성 설치 40,000회 이상)도 유지 관리합니다. 플러그인은 두 가지 설정 그룹을 제공합니다.
- Speculation 모드: prefetch와 prerender 중에서 선택합니다. Prerendering은 prefetching보다 로드 시간이 더 빠릅니다. 그러나 상호 작용이 필요한 콘텐츠의 경우 prefetching이 더 안전한 선택일 수 있습니다.
- Eagerness: conservative(일반적으로 클릭 시), moderate(일반적으로 마우스 오버 시) 또는 eager(아주 작은 신호 시) 중에서 선택합니다. eagerness 설정은 투기적 로드(speculative loads)가 얼마나 빨리 트리거되는지 결정합니다.
PHP 필터를 사용하여 speculation에서 특정 경로를 제외할 수 있습니다.
add_filter(
'plsr_speculation_rules_href_exclude_paths',
function($paths) {
$paths[] = '/cart/*';
$paths[] = '/checkout/*';
return $paths;
}
);
스크립트를 연기하고 로딩을 최적화하는 더 많은 방법은 전체 가이드를 참조하세요.
