이 페이지는 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을 전송하거나 클라이언트 측 자바스크립트를 통해 이 목록을 동적으로 작성하는 방식으로 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 한도도 동적입니다. 이러한 열의 수준을 사용하는 추측 규칙 스크립트 요소를 삭제하면 삭제된 추측을 취소하여 용량을 확보할 수 있습니다. 이러한 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 즉시 실행 설정이 있는 문서 규칙의 경우)이 훨씬 더 저렴해집니다.

캐시 재사용을 더욱 개선하기 위해 새로운 No-Vary-Search 제안도 지원합니다.

`No-Vary-Search` 지원

페이지를 미리 가져오거나 사전 렌더링할 때 특정 URL 매개변수 (기술적으로 검색 매개변수라고 함)는 서버에서 실제로 제공하는 페이지에는 중요하지 않을 수 있으며 클라이언트 측 JavaScript에서만 사용할 수 있습니다.

예를 들어 UTM 매개변수는 Google 애널리틱스에서 캠페인 측정에 사용되지만 일반적으로 서버에서 다른 페이지가 게재되도록 하지 않습니다. 즉, page1.html?utm_content=123 및 page1.html?utm_content=456가 서버에서 동일한 페이지를 전달하므로 캐시에서 동일한 페이지를 재사용할 수 있습니다.

마찬가지로 애플리케이션은 클라이언트 측에서만 처리되는 다른 URL 매개변수를 사용할 수 있습니다.

변하지 않는 검색 제안을 사용하면 서버에서 제공된 리소스에 아무런 영향을 주지 않는 매개변수를 지정할 수 있으므로 브라우저에서 이러한 매개변수만 다른 문서의 캐시된 버전을 재사용할 수 있습니다. 참고: 현재 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 검색 매개변수를 사용하여 제품 데이터를 가져오기 위해 자바스크립트를 사용하는 클라이언트 측 렌더링에 따라 페이지 콘텐츠가 달라집니다. 따라서 이 URL을 미리 가져오고 No-Vary-Search HTTP 헤더를 반환하여 페이지가 모든 id 검색 매개변수에 사용될 수 있음을 보여줍니다.

그러나 미리 가져오기가 완료되기 전에 사용자가 링크를 클릭하면 브라우저에 /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 Eagerness 설정이 적용된 문서 규칙을 확인하는 데 사용할 수 있습니다.

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

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

또한 이전 디버깅 규칙 블로그 게시물에서 DevTools를 사용하여 추측 규칙을 디버그하는 방법을 자세히 알아볼 수 있습니다.

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

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

또한 Google은 웹 인큐베이터 커뮤니티 그룹 (Web Incubator Community Group, WICG)을 통해 API를 표준화하여 다른 브라우저도 원하는 경우 이 흥미로운 API를 구현할 수 있도록 하기 위해 노력하고 있습니다.

WordPress

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

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

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

더 복잡한 설정(예: 특정 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에서는 플래그 지원을 통해 사용할 수 있습니다. 사전 렌더링은 이 기능에 대한 자연스러운 부가기능으로 지연이 발생하지 않도록 합니다. 그렇지 않으면 전환으로 인해 사용자 환경이 개선되는 것을 방지할 수 있습니다. 이 조합으로 실험하는 사이트도 이미 있습니다.

Google은 2024년 한 해 동안 Speculation Rules API를 더 많이 채택할 수 있기를 기대하고 있으며 향후 API가 개선되면 알려 드리겠습니다.

감사의 말

Unsplash의 Robbie Down 썸네일