Chrome팀은 향후 탐색을 미리 가져오거나 미리 렌더링하여 탐색 성능을 개선하는 데 사용되는 추측 규칙 API의 흥미로운 업데이트를 진행하고 있습니다. 이러한 추가 개선사항은 이제 Chrome 122부터 모두 사용할 수 있으며 일부 기능은 이전 버전에서도 사용할 수 있습니다.
이러한 변경사항을 통해 페이지 미리 가져오기 및 미리 렌더링을 훨씬 더 쉽게 배포하고 낭비를 줄일 수 있게 되었으며, 이를 통해 더 많은 채택을 유도할 수 있기를 바랍니다.
추가 기능
먼저 Speculation Rules API에 추가된 새로운 항목과 사용 방법을 설명합니다. 그런 다음 실제로 작동하는 모습을 확인할 수 있는 데모를 보여드리겠습니다.
문서 규칙
이전에는 Speculation Rules API가 미리 가져오거나 미리 렌더링할 URL 목록을 지정하여 작동했습니다.
<script type="speculationrules">
{
"prerender": [
{
"source": "list",
"urls": ["next.html", "next2.html"]
}
]
}
</script>
추측 규칙은 새 추측 규칙 스크립트를 추가하고 이러한 추측을 삭제하기 위해 이전 스크립트를 삭제할 수 있다는 점에서 반동적입니다 (기존 추측 규칙 스크립트의 urls 목록을 업데이트해도 추측 변경이 트리거되지 않음). 하지만 여전히 URL 선택은 페이지 요청 시 서버에서 전송하거나 클라이언트 측 JavaScript를 통해 이 목록을 동적으로 만드는 등 사이트에 맡겨졌습니다.
목록 규칙은 다음 탐색이 명확한 탐색 옵션의 소수 집합에서 이루어지는 간단한 사용 사례 또는 사이트 소유자가 사용하려는 휴리스틱을 기반으로 URL 목록이 동적으로 계산된 후 페이지에 삽입되는 고급 사용 사례에 대한 옵션으로 남아 있습니다.
대신 문서 규칙을 사용하여 자동 링크를 찾는 새로운 옵션을 제공하게 되어 기쁩니다. 이는 where 조건에 따라 문서 자체에서 URL을 가져옴으로써 작동합니다. 링크 자체를 기반으로 할 수 있습니다.
<script type="speculationrules">
{
"prerender": [{
"source": "document",
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout/*"}}
]
},
"eagerness": "moderate"
}]
}
</script>
CSS 선택자는 href 일치의 대안으로 또는 href 일치와 함께 현재 페이지에서 링크를 찾는 데 사용할 수도 있습니다.
<script type="speculationrules">
{
"prerender": [{
"source": "document",
"where": {
"and": [
{ "selector_matches": ".prerender" },
{ "not": {"selector_matches": ".do-not-prerender"}}
]
},
"eagerness": "moderate"
}]
}
</script>
이렇게 하면 페이지별로 특정 규칙을 사용하는 대신 전체 사이트에서 단일 추측 규칙을 사용할 수 있으므로 사이트에서 추측 규칙을 훨씬 더 쉽게 배포할 수 있습니다.
물론 페이지의 모든 링크를 사전 렌더링하는 것은 낭비가 될 수 있으므로 이 새로운 기능과 함께 eagerness 설정이 도입되었습니다.
열의
어떠한 추측도 정밀도와 재현율과 리드 타임 사이의 절충점을 고려해야 합니다. 페이지 로드 시 모든 링크를 미리 렌더링한다는 것은 사용자가 클릭하는 링크를 거의 확실하게 미리 렌더링한다는 의미입니다 (페이지에서 동일 사이트 링크를 클릭한다고 가정). 이때 최대한 긴 리드 타임을 사용하지만 대역폭이 엄청나게 낭비될 수 있습니다.
반면 사용자가 링크를 클릭한 후에만 미리 렌더링하면 낭비를 방지할 수 있지만 리드 타임이 크게 단축됩니다. 즉, 브라우저가 해당 페이지로 전환되기 전에 사전 렌더링이 완료되지 않았을 가능성이 큽니다.
eagerness 설정을 사용하면 추측을 실행해야 하는 시점을 정의하여 추측할 시점과 추측을 실행할 URL을 구분할 수 있습니다. eagerness 설정은 list 및 document 소스 규칙 모두에 사용할 수 있으며 4가지 설정이 있습니다. Chrome에는 다음과 같은 휴리스틱이 있습니다.
immediate: 가능한 한 빨리, 즉 추측 규칙이 관찰되는 대로 추측할 때 사용합니다.eager: 현재immediate설정과 동일하게 작동하지만, 향후에는immediate와moderate의 중간 정도로 작동할 예정입니다.moderate: 링크에 마우스를 200밀리초 동안 가져가면 (또는 그보다 빠른 경우pointerdown이벤트에서 그리고hover이벤트가 없는 모바일에서) 추측을 실행합니다.conservative: 포인터 다운 또는 터치 다운 시 추측합니다.
list 규칙의 기본 eagerness는 immediate입니다. moderate 및 conservative 옵션을 사용하여 list 규칙을 사용자가 상호작용하는 URL로 특정 목록으로 제한할 수 있습니다. 하지만 대부분의 경우 적절한 where 조건이 있는 document 규칙이 더 적합할 수 있습니다.
document 규칙의 기본 eagerness는 conservative입니다. 문서가 여러 URL로 구성될 수 있으므로 document 규칙에 immediate 또는 eager를 사용하는 것은 신중해야 합니다 (다음의 Chrome 제한사항 섹션 참고).
사용할 eagerness 설정은 사이트에 따라 다릅니다. 매우 간단한 정적 사이트의 경우 더 적극적으로 추측해도 비용이 거의 들지 않으며 사용자에게 유익할 수 있습니다. 아키텍처가 더 복잡하고 페이지 페이로드가 더 큰 사이트의 경우 사용자가 낭비를 줄이겠다는 의도를 더 긍정적으로 나타낼 때까지 추측을 덜 자주 실행하여 낭비를 줄이는 것이 좋습니다.
moderate 옵션은 중간 지점입니다. 많은 사이트에서 마우스 오버 또는 포인터 다운 시 모든 링크를 사전 렌더링하는 다음과 같은 간단한 추측 규칙을 사용하여 추측 규칙의 기본적이면서도 강력한 구현을 활용할 수 있습니다.
<script type="speculationrules">
{
"prerender": [{
"source": "document",
"where": {
"href_matches": "/*"
},
"eagerness": "moderate"
}]
}
</script>
Chrome 제한사항
eagerness를 선택하더라도 Chrome에는 이 API의 과도한 사용을 방지하기 위한 제한사항이 적용됩니다.
eagerness |
프리페치 | 사전 렌더링 |
|---|---|---|
immediate/eager |
50 | 10 |
moderate/conservative |
2 (FIFO) | 2 (FIFO) |
사용자 상호작용에 따라 달라지는 moderate 및 conservative 설정은 선입 선출 (FIFO) 방식으로 작동합니다. 한도에 도달하면 메모리를 절약하기 위해 새 추측으로 인해 가장 오래된 추측이 취소되고 최신 추측으로 대체됩니다.
moderate 및 conservative 추측이 사용자에 의해 트리거되므로 메모리를 절약하기 위해 더 적은 기준점 2를 사용할 수 있습니다. immediate 및 eager 설정은 사용자 작업에 의해 트리거되지 않으므로 브라우저에서 어느 것이 필요한지, 언제 필요한지 알 수 없으므로 한도가 더 높습니다.
FIFO 큐에서 푸시되어 취소된 추측은 다시 트리거될 수 있습니다(예: 해당 링크 위로 마우스를 가져가면 다시 트리거됨). 그러면 해당 URL이 다시 추측됩니다. 이 경우 이전 추측으로 인해 브라우저가 해당 URL의 HTTP 캐시에 일부 리소스를 캐시했을 가능성이 높으므로 추측을 반복해도 네트워크 및 시간 비용이 크게 줄어듭니다.
immediate 및 eager 한도도 동적입니다. 이러한 에이그리니스 수준을 사용하여 추측 규칙 스크립트 요소를 삭제하면 삭제된 추측이 취소되어 용량이 생성됩니다. 이러한 URL은 새 URL 스크립트에 포함되어 있고 한도에 도달하지 않은 경우 다시 추측할 수도 있습니다.
또한 Chrome은 다음을 포함하여 특정 조건에서 추측이 사용되지 않도록 방지합니다.
- Save-Data.
- 에너지 절약 모드
- 메모리 제약조건
- '페이지 미리 로드' 설정이 사용 중지된 경우 (uBlock Origin과 같은 Chrome 확장 프로그램에서도 명시적으로 사용 중지됨)
- 백그라운드 탭에서 열리는 페이지
이러한 모든 조건은 과도한 추측이 사용자에게 해가 될 때 그 영향을 줄이는 것을 목표로 합니다.
선택사항 source
Chrome 122에서는 source 키가 선택사항이 됩니다. url 또는 where 키의 존재에서 추론할 수 있기 때문입니다. 따라서 다음 두 추측 규칙은 동일합니다.
<script type="speculationrules">
{
"prerender": [{
"source": "document",
"where": { "href_matches": "/*" },
"eagerness": "moderate"
}]
}
</script>
<script type="speculationrules">
{
"prerender": [{
"where": { "href_matches": "/*" },
"eagerness": "moderate"
}]
}
</script>
Speculation-Rules HTTP 헤더
추측 규칙은 문서의 HTML에 직접 포함하는 대신 Speculation-Rules HTTP 헤더를 사용하여 전송할 수도 있습니다. 이를 통해 문서 콘텐츠 자체를 변경하지 않고도 CDN에서 더 쉽게 배포할 수 있습니다.
Speculation-Rules HTTP 헤더는 문서와 함께 반환되며 추측 규칙이 포함된 JSON 파일의 위치를 가리킵니다.
Speculation-Rules: "/speculationrules.json"
이 리소스는 올바른 MIME 유형을 사용해야 하며 교차 출처 리소스인 경우 CORS 검사를 통과해야 합니다.
Content-Type: application/speculationrules+json
Access-Control-Allow-Origin: *
상대 URL을 사용하려면 추측 규칙에 "relative_to": "document" 키를 포함하는 것이 좋습니다. 그렇지 않으면 상대 URL은 추측 규칙 JSON 파일의 URL에 상대적입니다. 이는 동일 출처 링크의 일부 또는 전체를 선택해야 하는 경우에 특히 유용합니다.
향상된 캐시 재사용
문서를 미리 가져오거나 미리 렌더링할 때 HTTP 캐시에 리소스를 저장하고 재사용할 수 있도록 Chrome의 캐싱을 여러 가지로 개선했습니다. 즉, 추측이 사용되지 않더라도 추측을 통해 향후 이익을 얻을 수 있습니다.
또한 Chrome에서 캐시 가능한 리소스에 HTTP 캐시를 사용하기 때문에 재추론 (예: moderate 조기 실행 설정이 있는 문서 규칙)이 훨씬 저렴해집니다.
또한 캐시 재사용을 더욱 개선하기 위한 새로운 No-Vary-Search 제안도 지원합니다.
No-Vary-Search 지원
페이지를 미리 가져오거나 미리 렌더링할 때 특정 URL 매개변수 (기술적으로 검색 매개변수라고 함)는 서버에서 실제로 전송하는 페이지에 중요하지 않으며 클라이언트 측 JavaScript에서만 사용될 수 있습니다.
예를 들어 UTM 매개변수는 Google 애널리틱스에서 캠페인 측정에 사용되지만 일반적으로 서버에서 다른 페이지가 전송되지는 않습니다. 즉, page1.html?utm_content=123와 page1.html?utm_content=456는 서버에서 동일한 페이지를 전송하므로 캐시에서 동일한 페이지를 재사용할 수 있습니다.
마찬가지로 애플리케이션은 클라이언트 측에서만 처리되는 다른 URL 매개변수를 사용할 수 있습니다.
No-Vary-Search 제안을 사용하면 서버가 전송된 리소스에 차이가 없는 매개변수를 지정할 수 있으므로 브라우저가 이러한 매개변수만 다른 이전에 캐시된 문서 버전을 재사용할 수 있습니다. 참고: 현재 이 기능은 Chrome (및 Chromium 기반 브라우저)에서만 탐색 미리 로드 추측에 대해 지원됩니다.
추측 규칙은 expects_no_vary_search를 사용하여 No-Vary-Search HTTP 헤더가 반환될 것으로 예상되는 위치를 나타내는 것을 지원합니다. 이렇게 하면 불필요한 다운로드를 더 이상 방지할 수 있습니다.
<script type="speculationrules">
{
"prefetch": [{
"urls": ["/products*"],
"expects_no_vary_search": "params=(\"id\")"
}]
}
</script>
<a href="/products?id=123">Product 123</a>
<a href="/products?id=124">Product 124</a>
이 예에서 /products 초기 페이지 HTML은 제품 ID 123와 124에서 모두 동일합니다. 그러나 id 검색 매개변수를 사용하여 제품 데이터를 가져오는 JavaScript를 사용하는 클라이언트 측 렌더링에 따라 페이지 콘텐츠는 달라집니다. 따라서 해당 URL을 미리 가져오고 페이지가 모든 id 검색 매개변수에 사용될 수 있음을 보여주는 No-Vary-Search HTTP 헤더를 반환해야 합니다.
그러나 미리 로드가 완료되기 전에 사용자가 링크를 클릭하면 브라우저가 /products 페이지를 수신하지 못했을 수 있습니다. 이 경우 브라우저는 No-Vary-Search HTTP 헤더가 포함될지 알 수 없습니다. 그러면 브라우저는 링크를 다시 가져올지 또는 미리 가져오기가 완료될 때까지 기다려 No-Vary-Search HTTP 헤더가 포함되어 있는지 확인할지 선택할 수 있습니다. expects_no_vary_search 설정을 사용하면 브라우저가 페이지 응답에 No-Vary-Search HTTP 헤더가 포함될 것으로 예상된다는 것을 알 수 있으며, 이 미리 로드가 완료될 때까지 기다릴 수 있습니다.
데모
moderate 성급함 설정이 적용된 문서 규칙을 확인하는 데 사용할 수 있는 데모가 https://speculative-rules.glitch.me/common-fruits.html에 있습니다.
DevTools를 열고 Application 패널을 클릭합니다. 그런 다음 백그라운드 서비스 섹션에서 예측 로드를 클릭한 다음 추측 창을 클릭하고 상태 열을 기준으로 정렬합니다.
과일 위로 마우스를 가져가면 페이지가 미리 렌더링되는 것을 볼 수 있습니다. 이를 클릭하면 사전 렌더링되지 않은 레시피 중 하나보다 훨씬 빠른 LCP 시간이 표시됩니다. 이 데모는 다음 동영상에서도 설명되어 있습니다.
DevTools를 사용하여 추측 규칙을 디버그하는 방법에 관한 자세한 내용은 이전 추측 규칙 디버깅 블로그 게시물을 참고하세요.
추측 규칙을 위한 플랫폼 지원
추측 규칙은 규칙을 <script type="speculationrules"> 요소에 삽입하여 비교적 간단하게 구현할 수 있지만 플랫폼 지원을 사용하면 클릭 한 번으로 처리할 수 있습니다. YouTube는 다양한 플랫폼 및 파트너와 협력하여 더 쉽게 투기 규칙을 적용할 수 있도록 노력하고 있습니다.
또한 다른 브라우저에서도 원하는 경우 이 흥미로운 API를 구현할 수 있도록 웹 인큐베이터 커뮤니티 그룹 (WICG)을 통해 API를 표준화하기 위해 노력하고 있습니다.
WordPress
WordPress 핵심 성능팀 (Google 개발자 포함)에서 추측 규칙 플러그인을 만들었습니다. 이 플러그인을 사용하면 WordPress 사이트에 문서 규칙 지원을 클릭 한 번으로 간편하게 추가할 수 있습니다. 이 플러그인은 WordPress Performance Lab 플러그인을 통해서도 설치할 수 있습니다. 이 플러그인을 설치하면 팀의 관련 성능 플러그인에 대한 최신 정보를 계속 확인할 수 있으므로 설치하는 것이 좋습니다.
추측 모드 및 적극성 설정이라는 두 가지 설정 그룹을 사용할 수 있습니다.
특정 URL을 미리 가져오거나 미리 렌더링하지 않도록 하는 등 더 복잡한 설정은 문서를 참고하세요.
Akamai
Akamai는 세계를 선도하는 CDN 제공업체 중 하나이며, 한동안 Speculation Rules API를 적극적으로 실험해 왔습니다. Akamai는 고객이 CDN 설정에서 이 API를 사용 설정하는 방법에 관한 문서를 발표했습니다. 또한 이전에 이 새로운 API로 얻을 수 있는 인상적인 결과도 공유했습니다.
NitroPack
NitroPack은 맞춤 탐색 AI를 사용하여 추측 규칙에 추가할 페이지를 예측하는 성능 최적화 솔루션으로, 링크 위로 마우스를 가져가는 것보다 긴 리드 타임을 제공하는 것을 목표로 하지만 관찰된 모든 링크에 대해 불필요하게 추측하는 데 낭비하지는 않습니다. 자세한 내용은 Nitropack Speculation Rules API 문서를 참고하세요. 이 혁신적인 솔루션은 기존 목록 규칙이 사이트별 통계와 함께 사용될 때 여전히 많은 이점을 제공할 수 있음을 보여줍니다.
Chrome팀은 NitroPack과 협력하여 추측 규칙 API에 관한 웹 세미나도 진행했습니다. 이 웹 세미나에서는 추측을 일찍 자주 하는 것과 늦게 자주 하는 것 사이에서 고려해야 할 사항에 대해 자세히 설명합니다.
Astro
Astro는 실험적으로 4.2에서 Speculation Rules API를 사용한 페이지 미리 렌더링을 추가하여 Astro를 사용하는 개발자가 이 기능을 쉽게 사용 설정할 수 있도록 했으며, Speculation Rules API를 지원하지 않는 브라우저의 경우 표준 미리 가져오기로 대체했습니다. 자세한 내용은 클라이언트 사전 렌더링 문서를 참고하세요.
결론
Speculation Rules API에 이러한 기능이 추가됨에 따라 사이트에서 이 흥미로운 새로운 성능 기능을 훨씬 더 간단하게 사용할 수 있으며, 사용되지 않은 추측으로 리소스가 낭비될 위험이 줄어듭니다. 이미 플랫폼에서 이 API를 사용하고 있다는 점이 기쁩니다. 2024년에는 이 API가 더 광범위하게 사용되어 궁극적으로 최종 사용자에게 더 나은 실적을 제공할 수 있기를 바랍니다.
Speculation Rules API가 제공하는 성능 향상 외에도 새로운 기회가 열릴 것으로 기대됩니다. 뷰 전환은 개발자가 탐색 간에 전환을 더 쉽게 지정할 수 있는 새로운 API입니다. 현재 단일 페이지 애플리케이션(SPA)에 사용할 수 있지만 다중 페이지 버전이 진행 중이며 Chrome에서 플래그를 통해 사용할 수 있습니다. 미리 렌더링은 전환이 제공하려는 사용자 환경 개선을 방해하는 지연이 없도록 하는 이 기능의 자연스러운 부가기능입니다. 이미 이 조합을 실험하는 사이트가 있습니다.
2024년 내내 Speculation Rules API가 더욱 확대 적용되기를 기대하며, API가 개선될 때마다 알려드리겠습니다.