이 페이지는 Cloud Translation API를 통해 번역되었습니다.

Speculation Rules API 개선

Barry Pollard

Chrome팀은 향후 탐색을 미리 가져오거나 사전 렌더링하여 탐색 성능을 개선하는 데 사용되는 Speculation Rules 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 선택은 사이트에 맡겼습니다.

목록 규칙은 간단한 사용 사례 (다음 탐색이 다음과 같은 명확한 몇 가지 탐색에서 비롯된 경우) 또는 고급 사용 사례 (사이트 소유자가 사용하려는 휴리스틱에 따라 URL 목록이 동적으로 계산된 다음 페이지에 삽입되는 경우)의 옵션으로 남아 있습니다.

그 대안으로 문서 규칙을 사용하여 자동 링크 찾기를 위한 새로운 옵션을 제공합니다. 이는 where 조건에 따라 문서 자체에서 URL을 가져오는 방식으로 작동합니다. 이는 링크 자체를 기반으로 할 수 있습니다.

<script type="speculationrules">
{
  "prerender": [{
    "source": "document",
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"href_matches": "/logout/*"}}
      ]
    },
    "eagerness": "moderate"
  }]
}
</script>

CSS 선택자를 대안으로 사용하거나 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)

Chrome의 추측 한도

사용자 상호작용에 따른 moderate 및 conservative 설정은 선입 선출 (FIFO) 방식으로 작동합니다. 한도에 도달한 후 새 추측이 메모리 절약을 위해 가장 오래된 추측을 취소하고 새 예측으로 대체하게 됩니다.

사용자가 moderate 및 conservative 추측을 트리거하므로 메모리를 절약하기 위해 더 적당한 임곗값 2를 사용할 수 있습니다. immediate 및 eager 설정은 사용자 작업에 의해 트리거되지 않으므로 브라우저에서 필요한 요소와 시기를 알 수 없기 때문에 한도가 더 높습니다.

FIFO 대기열에서 푸시되어 취소된 추측은 다시 트리거될 수 있으며(예: 해당 링크에 다시 마우스를 가져가면) 해당 URL이 다시 추측됩니다. 이 경우에는 이전의 추측으로 인해 브라우저가 해당 URL에 대한 HTTP 캐시의 일부 리소스를 캐시했을 가능성이 높으므로, 추측을 반복하면 네트워크 및 시간 비용이 크게 감소하게 됩니다.

immediate 및 eager 한도도 유동적입니다. 이러한 Eagerness 수준을 사용하는 예측 규칙 스크립트 요소를 삭제하면 삭제된 추측을 취소하여 용량을 생성합니다. 또한 이러한 URL이 새 URL 스크립트에 포함되어 있고 한도에 도달하지 않은 경우 다시 추측될 수 있습니다.

또한 Chrome은 다음과 같은 특정 조건에서 추측이 사용되는 것을 방지합니다.

데이터 저장.
에너지 절약 모드.
메모리 제약.
'페이지 미리 로드' 설정이 사용 중지되어 있는지 확인합니다 (uBlock Origin과 같은 Chrome 확장 프로그램에서도 명시적으로 사용 중지함).
페이지가 백그라운드 탭에서 열려 있습니다.

이러한 모든 조건은 과잉 추측이 사용자에게 해를 끼칠 때 그 영향을 줄이는 것을 목표로 합니다.

`source`(선택사항)

Chrome 122에서는 url 또는 where 키가 있는 경우 source 키를 추론할 수 있으므로 이 키는 선택사항입니다. 따라서 이 두 예측 규칙은 동일합니다.

<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에 대해 상대 URL이 됩니다. 이는 출처가 동일한 링크의 일부 또는 전체를 선택해야 하는 경우 특히 유용합니다.

캐시 재사용 개선

문서를 미리 가져오거나 사전 렌더링을 할 때 HTTP 캐시에 리소스를 저장하고 재사용할 수 있도록 Chrome의 캐싱에 여러 사항을 개선했습니다. 즉, 추측이 사용되지 않더라도 나중에 이익을 얻을 수 있습니다.

이렇게 하면 Chrome이 캐시 가능한 리소스에 HTTP 캐시를 사용하므로 재추측 (예: moderate Eagerness 설정이 있는 문서 규칙의 경우) 비용이 상당히 저렴합니다.

Google은 캐시 재사용을 더욱 개선하기 위해 새로운 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 기반 브라우저)에서만 지원됩니다.

추측 규칙은 No-Vary-Search HTTP 헤더가 반환될 것으로 예상되는 위치를 나타내기 위해 expects_no_vary_search 사용을 지원합니다. 이렇게 하면 불필요한 다운로드를 방지하는 데 도움이 됩니다.

<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 헤더가 포함될 것으로 예상된다는 것을 인지하고 미리 가져오기가 완료될 때까지 기다릴 수 있습니다.

데모

https://speculative-rules.glitch.me/common-fruits.html에 moderate 즉시 설정이 적용된 문서 규칙을 확인하는 데 사용할 수 있는 데모가 마련되어 있습니다.

과일 라벨이 지정된 여러 링크를 표시하는 결함으로 생성된 데모 사이트의 스크린샷 DevTools가 열려 있고 두 개의 링크 (apple.html 및 orange.html)가 이미 사전 렌더링되었음을 보여줍니다. — 예측 규칙 데모

DevTools를 열고 Application 패널을 클릭합니다. 그런 다음 백그라운드 서비스 섹션에서 추측 로드를 클릭한 다음 추측 창을 클릭하고 상태 열을 기준으로 정렬합니다.

과일 위로 마우스를 가져가면 사전 렌더링된 페이지가 표시됩니다. 이 버튼을 클릭하면 사전 렌더링되지 않은 레시피보다 훨씬 빠르게 LCP 시간이 표시됩니다. 이 데모는 다음 동영상에도 설명되어 있습니다.

또한 DevTools를 사용하여 예측 규칙을 디버그하는 방법에 관한 자세한 내용은 이전의 예측 규칙 디버깅 블로그 게시물을 참고하세요.

예측 규칙에 대한 플랫폼 지원

추측 규칙은 <script type="speculationrules"> 요소에 규칙을 삽입하여 비교적 간단히 구현할 수 있지만, 플랫폼 지원을 사용하면 클릭 한 번으로 간단하게 구현할 수 있습니다. Google은 추측 규칙을 보다 쉽게 출시할 수 있도록 다양한 플랫폼 및 파트너와 협력해 왔습니다.

또한 다른 브라우저에서도 원하는 경우 이 흥미로운 API를 구현할 수 있도록 Web Incubator Community Group (WICG)을 통해 API를 표준화하기 위해 노력하고 있습니다.

WordPress

WordPress Core Performance팀 (Google 개발자 포함)에서 Speculation Rules 플러그인을 만들었습니다. 이 플러그인을 사용하면 한 번의 클릭으로 모든 WordPress 사이트에 문서 규칙 지원을 추가할 수 있습니다. 이 플러그인은 WordPress Performance Lab 플러그인을 통해 설치할 수도 있습니다. 이 플러그인을 설치하면 팀에서 제공하는 관련 성능 플러그인에 대한 최신 정보를 얻을 수 있습니다.

추측 모드와 열성 설정이라는 두 가지 설정 그룹을 사용할 수 있습니다.

추측 규칙 설정이 표시된 WordPress 설정 읽기 패널의 스크린샷 미리 가져오기 또는 사전 렌더링 옵션이 있는 추측 모드와 보수적, 보통, 적극성 설정을 사용하는 적극성 설정의 두 가지 옵션이 있습니다. — WordPress Speculation Rules 플러그인

특정 URL을 미리 가져오거나 사전 렌더링하지 않도록 제외하는 등 더 복잡한 설정은 문서를 참조하세요.

Akamai

Akamai는 세계 최고의 CDN 제공업체 중 하나로, 한동안 Speculation Rules API를 적극적으로 실험해 왔습니다. Akamai는 고객이 CDN 설정에서 이 API를 사용 설정하는 방법에 대한 문서를 발표했습니다. 또한 이 새로운 API가 가져올 수 있는 놀라운 결과를 공유한 바 있습니다.

NitroPack

NitroPack은 맞춤형 Navigation AI를 사용하여 예측 규칙에 추가할 페이지를 예측하는 성능 최적화 솔루션입니다. 이 솔루션은 링크 위로 마우스를 가져가는 것보다 긴 리드 타임을 제공하는 것을 목표로 하지만, 관찰된 모든 링크에 대해 불필요하게 추측할 필요가 없습니다. 자세한 내용은 Nitropack Speculation Rules API 문서를 참조하세요. 이 혁신적인 솔루션은 사이트별 통계와 함께 사용했을 때 기존의 목록 규칙도 여전히 충분히 활용할 수 있음을 보여줍니다.

또한 Chrome팀은 더 많은 정보를 원하는 사용자를 위해 NitroPack과 함께 Speculation Rules API에 관한 웹 세미나를 진행했습니다. 여기에는 추측을 조기에 자주, 자주 그리고 늦게 또는 덜 자주 예측하는 데 필요한 고려사항에 대한 논의가 포함됩니다.

Astro

Astro는 4.2에서 Speculation Rules API를 사용하여 사전 렌더링 페이지를 실험적으로 추가했으며, 이를 통해 Astro를 사용하는 개발자는 Speculation Rules API를 지원하지 않는 브라우저의 경우 표준 미리 가져오기로 되돌아갈 수 있습니다. 자세한 내용은 클라이언트 사전 렌더링 문서를 참조하세요.

결론

Speculation Rules API에 대한 이러한 추가를 통해 사이트에 대해 이 흥미로운 새 성능 기능을 훨씬 간편하게 사용할 수 있으며 추측이 사용되지 않아 리소스를 낭비할 위험이 줄어듭니다. 플랫폼에서 이미 이 API를 활용하고 있다는 것은 매우 흥미진진한 일입니다. 2024년에는 이 API를 더 광범위하게 채택하여 궁극적으로 최종 사용자에게 더 나은 성능을 제공할 수 있기를 바랍니다.

Speculation Rules API가 제공하는 성능 향상 외에도, 이 API를 통해 어떤 새로운 기회가 열리게 될지 기대됩니다. 뷰 전환은 개발자가 탐색 간 전환을 더 쉽게 지정할 수 있는 새로운 API입니다. 이 기능은 현재 단일 페이지 애플리케이션 (SPA)에서 사용할 수 있지만 다중 페이지 버전이 진행 중입니다 (Chrome에서는 플래그 뒤에서 사용 가능). 사전 렌더링은 이 기능의 자연스러운 부가기능으로, 지연이 발생하지 않도록 하는 기능으로, 그렇지 않으면 전환 시 제공하려는 사용자 환경 개선을 방해합니다. 이미 이 조합을 실험 중인 사이트가 확인되었습니다.

2024년 한 해 동안 Speculation Rules API가 추가로 도입될 예정입니다. API의 추가 개선사항에 관한 소식을 계속 전해 드리겠습니다.

감사의 말씀

Unsplash에 Robbie Down 제공 썸네일