게시일: 2025년 3월 7일
Speculation Rules API를 사용하면 사용자가 향후 페이지 탐색을 미리 가져오거나 미리 렌더링하여 페이지 탐색을 더 빠르게 또는 즉시 실행할 수 있으므로 성능이 향상됩니다.
이 API는 구현의 용이성을 염두에 두고 설계되었지만 특히 복잡한 사이트에서는 사용하기 전에 몇 가지 고려사항을 고려해야 합니다. 이 가이드는 사이트 소유자가 이러한 고려사항을 이해하는 데 도움이 됩니다.
계획
추측 규칙을 구현하기 전에 API를 구현하는 방법 (몇 가지 옵션이 있음)과 추측의 비용 (추측할 페이지를 결정하는 데 도움이 됨)을 고려하는 것이 좋습니다.
추측 규칙을 구현하는 방법 결정
사용할 수 있는 다양한 방법이 있으므로 먼저 사이트에 투기 규칙을 구현하는 방법을 결정해야 합니다.
- 페이지의 HTML에 직접
- JavaScript 사용
- HTTP 헤더 사용
궁극적으로 모든 메서드는 동일한 효과를 주지만 구현의 용이성 및 유연성 측면에서 이점이 있을 수 있습니다.
사이트는 가장 적합한 옵션을 선택해야 하며 필요한 경우 이러한 옵션을 조합하여 사용할 수도 있습니다. 또는 플러그인 (예: WordPress용 예상 로드 플러그인)이나 라이브러리 또는 플랫폼을 사용하여 구현할 수 있으며, 이러한 플러그인이나 라이브러리 또는 플랫폼은 개발자가 선택할 수 있습니다. 하지만 사용 가능한 옵션을 알고 있는 것이 좋습니다.
페이지의 HTML에 추측 규칙 직접 포함
추측 규칙은 HTML에 <script type="speculationrules"> 요소를 포함하여 페이지에서 직접 구현할 수 있습니다. 이는 템플릿을 사용하는 정적 사이트의 빌드 시간에 추가되거나 페이지가 요청될 때 서버의 런타임에 추가될 수 있습니다. 에지 워커가 HTML에 삽입할 수도 있습니다 (이 가이드의 뒷부분에서 설명하는 HTTP 헤더 메서드가 더 쉬울 수 있음).
이렇게 하면 전체 사이트에 정적 규칙을 포함할 수 있지만, CSS 클래스에 의해 트리거되는 규칙을 사용하여 페이지에서 렌더링할 URL을 선택할 수 있으므로 문서 규칙은 여전히 동적일 수 있습니다.
<script type="speculationrules">
{
"prerender": [{
"where": { "selector_matches": ".prerender" }
}],
"prefetch": [{
"where": { "selector_matches": ".prefetch" }
}]
}
</script>
이전 스크립트는 prerender 클래스가 있는 링크를 미리 렌더링하고 링크에 prefetch 클래스가 있는 경우에도 마찬가지로 미리 가져옵니다. 이를 통해 개발자는 이러한 클래스를 HTML에 포함하여 추측을 트리거할 수 있습니다.
이러한 클래스의 링크가 페이지의 초기 HTML에 포함되는 것 외에도, 이러한 클래스가 앱에 의해 동적으로 추가되는 경우에도 링크가 추측되므로 앱에서 필요에 따라 추측을 트리거하고 삭제할 수 있습니다. 이는 더 구체적인 추측 규칙을 만들거나 삭제하는 것보다 간단할 수 있습니다. 대부분의 사이트에서 사용되는 기본 규칙과 페이지별 규칙을 모두 사용하려면 페이지당 여러 추측 규칙을 포함할 수도 있습니다.
또는 더 구체적인 추측 규칙을 사용해야 하는 경우 페이지별 또는 템플릿별 규칙을 사용하여 특정 페이지 또는 페이지 유형에 대해 다른 규칙을 허용할 수 있습니다.
마지막으로 서버 측에서 렌더링된 페이지는 서버에서 사용할 수 있는 모든 정보(예: 해당 페이지의 분석 정보 또는 특정 페이지의 일반적인 사용자 여정)를 기반으로 더 동적인 규칙을 보유할 수도 있습니다.
JavaScript를 사용하여 추측 규칙 추가
페이지 내 스크립트에 규칙을 포함하는 대신 자바스크립트를 사용하여 규칙을 삽입할 수도 있습니다. 이렇게 하면 페이지 템플릿을 덜 업데이트해야 할 수 있습니다. 예를 들어 태그 관리자가 규칙을 삽입하면 추측 규칙을 빠르게 출시할 수 있으며 필요한 경우 빠르게 사용 중지할 수도 있습니다.
또한 이 옵션을 사용하면 사용자가 페이지와 상호작용하는 방식에 따라 동적 클라이언트 측 규칙을 허용할 수 있습니다. 예를 들어 사용자가 장바구니에 상품을 추가하면 결제 페이지를 미리 렌더링할 수 있습니다. 또는 특정 조건에 따라 추측을 트리거하는 데 사용할 수 있습니다. API에는 기본적인 상호작용 기반 규칙을 허용하는 적극성 설정이 포함되어 있지만 JavaScript를 사용하면 개발자가 자체 로직을 사용하여 추측할 시점과 페이지를 결정할 수 있습니다.
앞에서 언급한 것처럼 새 규칙을 삽입하는 다른 방법은 페이지에 기본 문서 규칙을 두고 링크에 적절한 클래스를 추가하여 규칙과 일치하도록 하여 JavaScript가 문서 규칙을 트리거하도록 하는 것입니다.
HTTP 헤더를 사용하여 추측 규칙 추가
개발자를 위한 마지막 옵션은 HTTP 헤더를 사용하여 규칙을 포함하는 것입니다.
Speculation-Rules: "/speculationrules.json"
규칙 리소스 (이 예에서는 /speculationrules.json)가 전송되고 사용되는 방식에는 몇 가지 추가 요구사항이 있습니다.
이 옵션을 사용하면 문서 콘텐츠를 변경하지 않고도 CDN에서 더 쉽게 배포할 수 있습니다. 즉, JavaScript를 사용하여 추측 규칙을 동적으로 변경하는 것은 불가능합니다. 그러나 CSS 선택자 트리거가 있는 문서 규칙은 여전히 동적 변경을 허용할 수 있습니다(예: 링크에서 prerender 클래스 삭제).
JavaScript 옵션과 마찬가지로 HTTP 헤더로 추측 규칙을 구현하면 사이트 콘텐츠와 별개로 구현할 수 있으므로 전체 사이트 재빌드 없이 규칙을 더 쉽게 추가하고 삭제할 수 있습니다.
비용에 미치는 영향 고려
추측 규칙을 구현하기 전에 이 API를 사용할 때 사용자와 사이트에 미치는 비용 영향을 고려하는 데 시간을 할애하는 것이 좋습니다. 비용에는 대역폭 (사용자와 사이트 모두 비용이 발생함) 및 처리 비용 (클라이언트 측과 서버 측 모두)이 포함됩니다.
사용자 비용 고려
추측적 로드란 사용자가 새 위치로 이동할 수 있는 위치를 추측하는 것을 의미합니다. 그러나 탐색이 이루어지지 않으면 리소스가 낭비되었을 수 있습니다. 따라서 사용자에게 미치는 영향을 특히 주의해야 합니다.
- 향후 탐색을 다운로드하는 데 사용되는 추가 대역폭(특히 대역폭이 더 제한될 수 있는 모바일에서)
- 사전 렌더링을 사용할 때 이러한 페이지를 렌더링하는 데 드는 추가 처리 비용
완전히 정확한 예측을 사용하면 추가 비용이 발생하지 않습니다. 방문자가 다음에 해당 페이지를 방문할 것이기 때문입니다. 단, 비용이 선불로 지출된다는 점만 다릅니다. 그러나 미래를 완전히 정확하게 예측하는 것은 불가능하며, 투기 전략이 공격적일수록 낭비의 위험이 커집니다.
Chrome은 이 문제를 신중하게 고려했으며 API에는 생각보다 훨씬 저렴한 비용을 의미하는 여러 기능이 포함되어 있습니다. 특히 HTTP 캐시를 재사용하고 교차 출처 iframe을 로드하지 않으면 동일한 사이트에서 탐색을 미리 렌더링하는 데 드는 비용이 캐시된 리소스가 없는 전체 페이지보다 훨씬 적은 경우가 많으므로 추측적 로드의 비용이 예상보다 적습니다.
하지만 이러한 보호 조치를 취하더라도 사이트는 추측할 페이지와 이러한 추측으로 인한 사용자 비용을 신중하게 고려해야 합니다. 추측 로드에 적합한 후보는 분석 또는 일반적인 사용자 여정을 기반으로 상당히 높은 신뢰도로 합리적으로 예측할 수 있고 비용이 적은 페이지(예: 리치 페이지가 적은 페이지)입니다.
활성화될 때까지 지연되어야 하는 JavaScript도 고려해 보세요. 필요한 시점까지 콘텐츠를 지연 로드하는 것과 마찬가지로, 이렇게 하면 사전 렌더링이 더 저렴해지지만 훨씬 개선된 사용자 환경을 제공할 수 있습니다. 더 저렴한 추측을 통해 더 자주 또는 더 적극적으로 추측할 수 있습니다.
불가능한 경우 적당하거나 보수적인 에이그리니스 규칙을 사용하는 덜 공격적인 전략을 사용하는 것이 좋습니다. 또는 확신이 낮을 때는 프리렌더링보다 비용이 훨씬 적은 프리패치를 사용하고, 확신이 높아지면(예: 링크를 마우스 오버하거나 실제로 클릭할 때) 전체 프리렌더링으로 업그레이드할 수 있습니다.
추가 백엔드 부하 고려
사이트 소유자는 사용자의 추가 비용뿐만 아니라 자체 인프라 비용도 고려해야 합니다. 모든 페이지에서 2회, 3회 또는 그 이상의 페이지 로드가 발생하는 경우 이 API를 사용하면 백엔드 비용이 증가할 수 있습니다.
페이지와 리소스를 캐시할 수 있도록 하면 출처 부하량과 전반적인 위험이 크게 줄어듭니다. CDN과 결합하면 원본 서버에 추가 부하가 거의 발생하지 않습니다. 단, CDN 비용 증가는 고려해야 합니다.
서버 또는 CDN을 사용하여 sec-purpose HTTP 헤더로 식별된 추측 결과를 제어할 수도 있습니다. 예를 들어 Cloudflare의 Speed Brain 제품은 CDN의 에지 서버에 이미 캐시된 추측만 허용하며 요청을 출처로 다시 전송하지 않습니다.
그러나 추측 로드는 일반적으로 동일 출처 페이지 로드에 사용되므로 사용자는 브라우저의 캐시에서 공유 리소스를 이미 보유하고 있습니다(처음부터 캐시할 수 있다고 가정). 따라서 추측은 일반적으로 전체 페이지 로드만큼 비용이 많이 들지 않습니다.
과도한 추측과 과소한 추측 사이의 균형을 찾습니다.
Speculation Rules API를 최대한 활용하는 열쇠는 과도하게 추측(즉, 비용이 불필요하게 지출되고 추측이 사용되지 않는 경우)과 너무 보수적(즉, 너무 적게 또는 너무 늦게 추측하여 이익이 거의 실현되지 않는 경우) 사이의 균형을 찾는 것입니다.
비용이 저렴한 경우 (예: CDN 에지 노드에 캐시된 작고 정적 방식으로 생성된 페이지) 추측을 더 공격적으로 적용할 수 있습니다.
그러나 CDN 에지에서 캐시할 수 없는 더 크고 풍부한 페이지의 경우 더 많은 주의가 필요합니다. 마찬가지로 리소스 집약적인 페이지는 네트워크 대역폭이나 처리 성능을 소모하여 현재 페이지에 부정적인 영향을 미칠 수 있습니다. API의 목표는 성능을 개선하는 것이므로 성능 회귀는 바람직하지 않습니다. 이는 미리 렌더링을 최대 1~2페이지로 유지해야 하는 또 다른 이유입니다. 또한 Chrome은 적극성에 따라 한 번에 미리 렌더링을 2~10개로 제한합니다.
추측 규칙 구현 단계
추측 규칙을 구현하는 방법을 결정했다면 다음으로 추측할 내용과 이를 출시하는 방법을 계획해야 합니다. 정적 개인 블로그와 같이 간단한 사이트는 특정 페이지의 전체 사전 렌더링으로 바로 이동할 수 있지만 더 복잡한 사이트는 고려해야 할 추가적인 복잡성이 있습니다.
미리 가져오기로 시작
미리 가져오기는 일반적으로 대부분의 사이트에 비교적 안전하게 구현할 수 있으며, Cloudflare 및 WordPress와 같은 대규모 출시를 포함하여 많은 사이트에서 취하는 초기 접근 방식입니다.
주의해야 할 주요 문제는 URL을 미리 가져오면 상태 변경 및 서버 측 비용이 발생할 수 있다는 점입니다(특히 캐시할 수 없는 페이지의 경우). 상태 변경(예: /logout 페이지 미리 로드)은 GET 링크로 구현되지 않는 것이 이상적이지만 안타깝게도 웹에서는 흔히 발생합니다.
이러한 URL은 규칙에서 구체적으로 제외할 수 있습니다.
<script type="speculationrules">
{
"prefetch": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
moderate 또는 conservative eagerness 설정을 사용하여 한 페이지에서 다른 페이지로의 일반적인 탐색으로 제한하거나 마우스 오버 또는 클릭 시 모든 동일 출처 링크에 대해 미리 가져올 수 있습니다. conservative 설정은 위험이 가장 낮지만 잠재적 보상도 가장 낮습니다. 여기에서 시작하는 경우 최소한 moderate까지 진행하는 것을 목표로 하되, eager까지 진행하면 더 많은 성능 이점을 얻을 수 있습니다. 그런 다음 적절한 경우 prerender로 업그레이드하세요.
위험도가 낮은 사전 렌더링
미리 가져오기 추측은 더 쉽게 배포할 수 있지만 API에 대한 궁극적인 성능 이점은 미리 렌더링에 있습니다. 추측 후 페이지가 바로 방문되지 않는 경우 (다음 섹션에서 다룹니다) 추가 고려사항이 있을 수 있지만, moderate 또는 conservative 사전 렌더링의 경우 탐색이 바로 발생할 가능성이 높으므로 상대적으로 위험성이 낮은 다음 단계일 수 있습니다.
<script type="speculationrules">
{
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
일반적인 페이지를 미리 가져와 비긴접 미리 렌더링 개선
일반적인 방법 중 하나는 로드 시 eager 설정 (URL 목록에 지정하거나 selector_matches 사용)을 사용하여 자주 방문하는 다음 페이지 중 소수의 페이지를 미리 로드한 다음 moderate 설정으로 미리 렌더링하는 것입니다. 링크 위로 마우스를 가져갈 때까지 HTML 미리 로드가 완료될 가능성이 높으므로 미리 로드 없이 마우스 오버 시 미리 렌더링하는 것보다 성능이 향상됩니다.
<script type="speculationrules">
{
"prefetch": [{
"urls": ["next.html", "next2.html"],
"eagerness": "eager"
}],
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
이전 미리 렌더링
moderate 문서 규칙을 사용하면 상대적으로 위험이 적은 API를 구현하기 쉽지만, 전체 사전 렌더링에는 시간이 충분하지 않은 경우가 많습니다. 이 API에서 허용하는 즉시 탐색을 실행하려면 그 이상으로 나아가 페이지를 더 적극적으로 미리 렌더링해야 할 수 있습니다.
이는 정적 URL 목록 (이전의 미리 로드 예시와 같음)을 사용하거나 selector_matches를 사용하여 소수의 URL (가급적 1~2페이지)을 식별하고 다른 URL을 문서 규칙으로 처리하는 방식으로 실행됩니다.
<script type="speculationrules">
{
"prerender": [
{
"where": {
"selector_matches": : ".prerender"
},
"eagerness": "eager",
},
{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}
]
}
</script>
다음 탐색을 정확하게 예측할 수 있도록 트래픽 분석이 필요할 수 있습니다. 사이트를 통한 일반적인 고객 여정을 이해하면 추측 로드에 적합한 항목을 식별하는 데도 도움이 됩니다.
더 적극적인 사전 렌더링으로 전환하면 애널리틱스, 광고, JavaScript와 관련된 고려사항이 더 많아질 수 있으며, 사전 렌더링된 페이지를 최신 상태로 유지하거나 상태 변경에 관한 추측을 취소하거나 새로고침해야 할 수도 있습니다.
애널리틱스, 광고, JavaScript
사전 렌더링을 사용할 때는 더 복잡한 사이트의 경우 분석에 미치는 영향도 고려해야 합니다. 일반적으로 페이지가 추측될 때 페이지 (또는 광고) 조회수를 기록하지 않으며 추측이 활성화된 경우에만 기록합니다.
일부 애널리틱스 제공업체 (예: Google 애널리틱스) 및 광고 제공업체 (예: Google 게시자 태그)는 이미 추측 규칙을 지원하며 페이지가 활성화될 때까지 조회수를 기록하지 않습니다. 하지만 구현한 다른 제공업체 또는 맞춤 분석에는 추가 고려가 필요할 수 있습니다.
JavaScript에 검사를 추가하여 페이지가 활성화되거나 표시될 때까지 특정 코드가 실행되지 않도록 할 수 있으며 전체 <script> 요소를 이러한 검사로 래핑할 수도 있습니다. 페이지에서 태그 관리자를 사용하여 이러한 스크립트를 삽입하는 경우 태그 관리자 스크립트 자체를 지연시켜 한 번에 모두 해결할 수 있습니다.
마찬가지로 동의 관리자는 서드 파티 스크립트를 활성화될 때까지 지연할 수 있는 기회입니다. Google은 다양한 동의 관리자 플랫폼과 협력하여 사전 렌더링을 인식하도록 하고 있으며, 동일한 작업을 수행하려는 다른 사용자를 기꺼이 지원합니다. PubTech는 개발자가 사전 렌더링 중에 JavaScript를 실행하거나 차단할 수 있는 옵션을 제공하는 회사 중 하나입니다.
애플리케이션 코드의 경우 특히 페이지에 JavaScript 코드가 렌더링되지 않는 경우 활성화될 때까지 코드 실행을 지연하는 변경사항을 추가할 수 있습니다. 이 방법은 더 빠르고 안전하지만 활성화 시 모든 코드가 한 번에 실행된다는 의미입니다. 이렇게 하면 활성화 시 많은 작업이 발생하여 INP에 영향을 미칠 수 있습니다. 특히 페이지가 완전히 로드되어 상호작용할 준비가 된 것처럼 보일 수 있기 때문입니다.
또한 JavaScript에 종속된 콘텐츠 (예: 클라이언트 측에서 렌더링된 콘텐츠)인 경우 이를 지연하면 미리 렌더링이 LCP 및 CLS에 미칠 수 있는 긍정적인 영향이 줄어듭니다. 사전 렌더링 단계에서 더 많은 JavaScript를 실행할 수 있도록 하는 보다 타겟팅된 접근 방식을 사용하면 더 나은 환경을 제공할 수 있지만 구현하기가 쉽지 않을 수 있습니다.
처음에는 더 복잡한 사이트의 경우 많은 스크립트 태그를 완전히 지연하는 것이 좋은 전략일 수 있습니다. 하지만 API를 최대한 활용하려면 프리렌더링 중에 최대한 많은 JavaScript가 실행되도록 하는 것이 궁극적인 목표여야 합니다.
분석 또는 광고 문제가 있는 사이트의 경우 이러한 문제가 상대적으로 적은 미리 로드부터 시작하고, 미리 렌더링을 지원하기 위해 취해야 할 조치를 고려하는 것이 좋습니다.
사전 렌더링 추측 업데이트
탐색 전에 페이지를 사전 렌더링하면 사전 렌더링된 페이지가 오래될 위험이 있습니다. 예를 들어 전자상거래 사이트의 사전 렌더링된 페이지에는 결제 장바구니가 포함될 수 있습니다. 장바구니에 있는 전체 상품 또는 다른 페이지의 장바구니에 있는 상품 수를 보여주는 카운터일 수 있습니다. 장바구니에 상품을 더 추가한 후 사전 렌더링된 페이지로 이동하면 이전 결제 상태가 표시되어 사용자에게 혼란을 줄 수 있습니다.
이는 새로운 문제가 아니며 사용자가 브라우저에서 여러 탭을 열어두면 동일한 문제가 발생합니다. 그러나 사전 렌더링된 페이지의 경우 사용자가 사전 렌더링을 의도적으로 시작하지 않았기 때문에 이러한 상황이 발생할 가능성이 더 높고 예상치 못한 결과를 초래할 수 있습니다.
Broadcast Channel API는 브라우저의 한 페이지에서 이와 같은 업데이트를 다른 페이지에 브로드캐스트하도록 허용하는 한 가지 방법입니다. 이렇게 하면 여러 탭 문제도 해결됩니다. 사전 렌더링된 페이지는 브로드캐스트 메시지를 수신할 수 있지만 활성화될 때까지 자체 브로드캐스트 메시지를 전송할 수는 없습니다.
또는 사전 렌더링된 페이지는 서버 (주기적 fetch() 또는 WebSocket 연결 사용)를 사용하여 업데이트를 받을 수 있지만 업데이트가 지연될 수 있습니다.
사전 렌더링 추측 취소 또는 새로고침
사전 렌더링된 페이지를 계속 사용하면서 사용자에게 혼란을 주지 않으려면 사전 렌더링된 페이지를 업데이트하는 것이 좋습니다. 불가능한 경우 추측을 취소할 수 있습니다.
사이트에서 방문 가능성이 더 높은 다른 페이지를 미리 렌더링하려는 경우 Chrome의 한도를 초과하지 않도록 하는 데도 사용할 수 있습니다.
추측을 취소하려면 페이지에서 추측 규칙을 삭제하거나, 이 접근 방식을 사용하는 경우 클래스 또는 기타 일치 기준을 삭제해야 합니다. 또는 추측된 페이지가 더 이상 현재 페이지가 아님을 감지하면 window.close()를 호출할 수 있습니다. 페이지에서 이를 감지할 수 있다면 상태를 업데이트하여 최신 상태로 되돌리는 것이 더 좋습니다.
페이지를 다시 미리 렌더링할 수 있도록 이러한 규칙(또는 일치 기준)을 다시 삽입할 수도 있습니다. 하지만 기존 페이지를 최신 상태로 유지하는 것이 낭비가 적으므로 일반적으로 더 나은 방법입니다. 추측 규칙이 삭제된 후에는 브라우저가 삭제를 감지하고 추측을 취소할 수 있도록 새 마이크로태스크 이후에 재삽입을 완료해야 합니다. 모든 추측 규칙 스크립트를 삭제하는 한 가지 방법은 다음 예와 같습니다.
async function refreshSpeculations() {
const speculationScripts = document.querySelectorAll('script[type="speculationrules"]');
for (const speculationScript of speculationScripts) {
// Get the current rules as JSON text
const ruleSet = speculationScript.textContent;
// Remove the existing script to reset prerendering
speculationScript.remove();
// Await for a microtask before re-inserting.
await Promise.resolve();
// Reinsert rule in a new speculation rules script
const newScript = document.createElement('script');
newScript.type = 'speculationrules';
newScript.textContent = ruleSet;
console.log(newScript);
// Append the new script back to the document
document.body.appendChild(newScript);
}
}
규칙을 삭제하면 기존 프레디터 (또는 미리 로드)가 취소되지만 규칙을 다시 삽입하면 즉시 또는 조기 규칙 (기본값인 즉시를 사용하는 URL 목록 규칙 포함)만 추측됩니다. 그러나 보통 또는 보수적인 추측은 삭제되지만 링크와 다시 상호작용할 때까지 자동으로 다시 트리거되지는 않습니다.
이 새로고침 옵션은 JavaScript 삽입 규칙으로 제한되지 않습니다. HTML에 포함된 정적 규칙도 표준 DOM 변경사항이므로 동일한 방식으로 삭제하거나 변경할 수 있습니다. HTTP 추측 규칙은 삭제할 수 없지만 일치 기준 (예: prerender 클래스)은 삭제하고 JavaScript로 다시 추가할 수 있습니다.
Chrome에서는 서버 응답이 미리 렌더링을 취소할 수 있도록 Clear-Site-Header 추가 지원도 검토하고 있습니다 (예: 업데이트 장바구니 요청이 이루어진 경우).
효과 측정
추측 규칙을 구현한 후에는 속도가 자동으로 빨라진다고 가정하지 말고 성공 여부를 측정해야 합니다. 앞서 언급한 대로 과도한 추측은 클라이언트 또는 서버에 과부하가 발생하면 실제로 성능이 저하될 수 있습니다.
여러 단계 (미리 가져오기, 위험도가 낮은 사전 렌더링, 사전 렌더링 초기화)로 구현하는 경우 각 단계에서 측정해야 합니다.
성공을 측정하는 방법
추측 규칙은 LCP와 같은 핵심 실적 측정항목에 긍정적인 영향을 미치며 CLS 및 INP에도 영향을 미칠 수 있지만 전반적인 사이트 수준 측정항목에서는 명확하지 않을 수 있습니다. 이는 사이트가 다른 탐색 유형 (예: 방문 페이지)으로 주로 구성되어 있거나 동일 출처 탐색이 이미 충분히 빠르기 때문에 탐색을 대폭 개선하더라도 Chrome 사용자 환경 보고서 (CrUX)에 보고된 75번째 백분위수 측정항목에 영향을 미치지 않을 수 있기 때문입니다.
CrUX의 페이지 탐색 유형을 사용하여 탐색 중 navigate_cache 또는 prerender인 비율과 시간이 지남에 따라 이 비율이 증가하는지 확인할 수 있습니다. 그러나 자세한 분석을 위해 실시간 사용자 모니터링을 사용하여 데이터를 추측된 탐색으로 분류하여 다른 탐색보다 얼마나 더 빠른지 확인해야 할 수 있습니다.
사용량 및 낭비를 측정하는 방법
또 다른 중요한 고려사항은 올바른 페이지를 추측하고 있는지 측정하는 것입니다. 이렇게 하면 낭비를 방지하고 이 API에서 이익을 얻을 수 있는 최적의 페이지를 타겟팅할 수 있습니다.
안타깝게도 추측을 시작하는 페이지에서는 추측 시도의 상태를 직접 확인할 수 없습니다. 또한 브라우저가 특정 상황에서 추측을 보류할 수 있으므로 시도가 트리거되었다고 가정할 수 없습니다. 따라서 페이지 자체에서 측정해야 합니다. 또한 페이지에서 추측 중인지 또는 추측했는지 확인하기 위해 두 API를 확인해야 합니다.
if (document.prerendering) {
console.log("Page is prerendering");
} else if (performance.getEntriesByType("navigation")[0]?.activationStart > 0) {
console.log("Page has already prerendered");
} else {
console.log("This page load was not using prerendering");
}
그러면 이 페이지에서 백엔드 서버에 추측 시도를 기록할 수 있습니다.
애널리틱스의 한 가지 복잡성은 사전 렌더링을 인식하고 페이지가 활성화될 때까지 애널리틱스 호출을 무시하는 제공업체 (예: Google 애널리틱스)입니다. 여기에는 별도의 이벤트 호출도 포함됩니다. 따라서 Google 애널리틱스 사용자는 다른 옵션인 서버 측 로깅 옵션을 사용해야 합니다.
클라이언트 측에서 이를 실행할 수도 있습니다. 이 경우 각 사전 렌더링된 페이지가 공유 저장소에 사전 렌더링을 기록하고 호출 페이지에서 이를 읽습니다. localStorage는 페이지에서 벗어나 탐색할 때 읽을 수 있으므로 가장 효과적입니다. sessionStorage는 사전 렌더링된 페이지에 대한 특수 처리가 있으므로 사용할 수 없습니다. 그러나 localStorage는 트랜잭션 안전하지 않으며 여러 페이지가 미리 렌더링되는 경우 다른 페이지에서 동시에 이를 업데이트할 수 있습니다. 이 데모에서는 고유한 해시와 개별 항목을 사용하여 이 문제를 방지합니다.
결론
추측 규칙을 사용하면 페이지 실적을 크게 향상할 수 있습니다. 이 가이드에서는 이 API를 구현할 때 잠재적인 문제를 방지하고 API를 최대한 활용하기 위해 고려해야 할 사항을 설명합니다.
구현을 미리 계획하면 재작업을 방지할 수 있습니다. 특히 더 복잡한 사이트의 경우 prefetch로 시작하여 위험성이 낮은 prerender로 이동한 다음 조기 prerender로 이동하기 전에 여러 단계의 출시를 진행해야 합니다. 마지막으로 API를 최적으로 사용하고 있는지 확인하기 위해 개선사항, 사용량, 낭비를 측정하는 것이 중요합니다.