즉각적인 페이지 탐색을 위해 Chrome에서 페이지 사전 렌더링

Barry Pollard

브라우저 지원

• 109
• 109
• x
• x

Chrome팀은 사용자가 이동할 가능성이 있는 향후 페이지의 전체 사전 렌더링을 다시 가져오는 옵션을 개발해 왔습니다.

사전 렌더링의 간략한 기록

이전에는 Chrome에서 <link rel="prerender" href="/next-page"> 리소스 힌트를 지원했지만 Chrome 외에는 광범위하게 지원되지 않았고 표현력이 뛰어난 API도 아니었습니다.

링크 rel=prerender 힌트를 사용하는 이 기존 사전 렌더링은 지원 중단되었으며 대신 향후 페이지에 필요한 리소스를 가져왔지만 페이지를 완전히 사전 렌더링하거나 자바스크립트를 실행하지는 NoState Prefetch로 대체되었습니다. NoState Prefetch는 리소스 로드를 개선하여 페이지 성능을 개선하는 데 도움이 되지만 전체 사전 렌더링처럼 즉시 페이지 로드를 제공하지는 않습니다.

이제 Chrome팀은 Chrome에 전체 사전 렌더링을 다시 도입했습니다. 기존 사용의 복잡성을 방지하고 향후 사전 렌더링 확장을 허용하기 위해 이 새로운 사전 렌더링 메커니즘은 NoState Prefetch를 위해 그대로 유지되는 <link rel="prerender"...> 문법을 사용하지 않으며, 향후 특정 시점에 이를 사용 중지할 수 있습니다.

페이지는 어떻게 사전 렌더링되나요?

페이지는 탐색 속도를 높이는 것을 목표로 하는 네 가지 방법 중 하나로 사전 렌더링할 수 있습니다.

1. Chrome 주소 표시줄('검색주소창'이라고도 함)에 URL을 입력하면 Chrome은 사용자가 해당 페이지를 방문할 것이라고 확신하는 경우 페이지를 자동으로 사전 렌더링할 수 있습니다.
2. Chrome 주소 표시줄에 검색어를 입력하면 Chrome은 검색엔진의 지시에 따라 검색결과 페이지를 자동으로 사전 렌더링할 수 있습니다.
3. 사이트에서는 Speculation Rules API를 사용하여 Chrome에 사전 렌더링할 페이지를 프로그래매틱 방식으로 알릴 수 있습니다. 이 기능은 <link rel="prerender"...>에서 이전에 실행했던 작업을 대체하며, 사이트에서 페이지의 추측 규칙에 따라 사전에 페이지를 사전 렌더링할 수 있습니다. 이러한 태그는 페이지에 정적으로 존재할 수도 있고, 페이지 소유자에게 적합하다고 판단하면 자바스크립트에 의해 동적으로 삽입될 수도 있습니다.

이러한 각 경우에 사전 렌더링은 페이지가 보이지 않는 백그라운드 탭에서 열린 것처럼 동작한 다음 포그라운드 탭을 사전 렌더링된 페이지로 대체하여 '활성화'됩니다. 페이지가 완전히 사전 렌더링되기 전에 활성화되면 현재 상태가 '포그라운드'이고 계속 로드됩니다. 이는 여전히 순조롭게 시작할 수 있음을 의미합니다.

사전 렌더링된 페이지가 숨겨진 상태에서 열릴 때 방해가 되는 동작을 유발하는 API (예: 프롬프트)는 이 상태에서 활성화되지 않으며 대신 페이지가 활성화될 때까지 지연됩니다. 드물지만 사전 렌더링이 불가능한 경우에는 사전 렌더링이 취소됩니다. Chrome팀은 사전 렌더링 취소 이유를 API로 노출하고 이러한 특이 사례를 쉽게 식별할 수 있도록 DevTools 기능을 향상시키기 위해 노력하고 있습니다.

참고: 사전 렌더링된 페이지는 힌트 및 점진적 개선으로 취급해야 합니다. preload와 달리 사전 렌더링은 추측 힌트이며 브라우저는 사용자 설정, 현재 메모리 사용량 또는 기타 휴리스틱에 따라 힌트에 따라 조치를 취하지 않도록 선택할 수 있습니다.

사전 렌더링의 영향

다음 동영상과 같이 사전 렌더링은 거의 즉각적인 페이지 로드를 허용합니다.

사전 렌더링의 영향 예시

예시 사이트는 이미 빠른 사이트이지만 이 사이트를 통해서도 사전 렌더링이 사용자 환경을 어떻게 개선하는지 확인할 수 있습니다. 따라서 이는 사이트의 코어 웹 바이탈에 직접적인 영향을 주어 LCP가 0에 가깝고 CLS가 감소하고 (모든 로드는 초기 보기 전에 로드 CLS가 발생하므로) INP가 개선됩니다 (사용자가 상호작용하기 전에 로드가 완료되어야 함).

페이지가 완전히 로드되기 전에 활성화되는 경우에도 페이지 로드를 앞당기면 로드 환경이 개선됩니다. 사전 렌더링이 계속 진행 중일 때 링크가 활성화되면 사전 렌더링 페이지가 기본 프레임으로 이동하고 계속 로드됩니다.

단, 사전 렌더링은 추가 메모리 및 네트워크 대역폭을 사용합니다. 너무 사전 렌더링하지 않도록 주의하세요. 너무 많은 사용자 리소스가 제공됩니다. 페이지로 이동할 가능성이 높은 경우에만 사전 렌더링합니다.

분석에서 실제 성능 영향을 측정하는 방법에 대한 자세한 내용은 실적 측정 섹션을 참고하세요.

Chrome의 주소 표시줄 예상 검색어 보기

첫 번째 사용 사례의 경우 chrome://predictors 페이지에서 Chrome의 URL 예측을 확인할 수 있습니다.

Chrome 예측자 페이지

녹색 선은 사전 렌더링을 트리거할 만큼의 신뢰도를 나타냅니다. 이 예에서 's'를 입력하면 적절한 신뢰도 (황색)가 제공되지만 'sh'를 입력하면 Chrome은 사용자가 거의 항상 https://sheets.google.com로 이동할 만큼 확신을 갖게 됩니다.

이 스크린샷은 비교적 최근에 Chrome을 설치하고 0 신뢰도 예측을 필터링한 것으로 나타났지만, 자체 예측 변수를 보면 훨씬 더 많은 항목이 표시되고 신뢰도가 높은 수준에 도달하는 데 필요한 문자도 더 많아질 수 있습니다.

이러한 예측자는 사용자가 눈치채셨을 만한 주소 표시줄의 추천 옵션을 주도하는 요인이기도 합니다.

주소 표시줄 '미리 입력' 기능

Chrome은 사용자의 입력 및 선택에 따라 예측 변수를 지속적으로 업데이트합니다.

• 신뢰 수준이 50% 를 초과하는 경우 (황색으로 표시) Chrome은 도메인에 사전 연결하지만 페이지를 사전 렌더링하지는 않습니다.
• 신뢰 수준이 80% 를 초과하면 (녹색으로 표시) Chrome에서 URL을 사전 렌더링합니다.

Speculation Rules API

세 번째 사전 렌더링 옵션의 경우 웹 개발자가 페이지에 JSON 지침을 삽입하여 사전 렌더링할 URL을 브라우저에 알릴 수 있습니다.

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["next.html", "next2.html"]
    }
  ]
}
</script>

또는 href 또는 CSS 선택자를 기반으로 문서에서 찾은 링크를 사전 렌더링하는 문서 규칙 (Chrome 121에서 사용 가능)을 사용합니다.

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel=nofollow]"}}
      ]
    }
  }]
}
</script>

참고: Speculation Rules API는 목록 URL의 경우 list 또는 문서 URL의 경우 document로 설정된 source 키를 포함하는 데 사용되었지만 이는 상호 배타적인 urls 또는 where 키가 있다는 것을 통해 암시할 수 있으므로 Chrome 121에서는 이 요구사항이 삭제되었습니다. 일부 사이트 또는 예시 코드에서는 이 source 키가 계속 사용될 수 있습니다.

적극성

브라우저 지원

• 121
• 121
• x
• x

eagerness 설정은 추측이 실행되어야 하는 시기를 나타내는 데 사용되며, 문서 규칙에 특히 유용합니다.

• 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 설정은 사이트에 따라 다릅니다. 가볍고 정적인 사이트의 경우 더 적극적으로 추측하면 비용이 거의 들지 않고 사용자에게 도움이 될 수 있습니다. 아키텍처가 더 복잡하고 페이지 페이로드가 무거운 사이트의 경우 낭비를 줄이기 위한 사용자의 긍정적인 신호를 받을 때까지 추측을 적게 하여 낭비를 줄이는 것이 좋습니다.

주의: 과장된 추측은 대역폭, 메모리, CPU 비용뿐만 아니라 사이트 자체 비용도 사용자에게 부담을 줄 수 있습니다. 추측을 구현할 때 사용자에게 미치는 영향에 유의하세요. eagerness 설정을 사용하면 추측이 낭비될 가능성을 줄일 수 있습니다. 또한 Chrome은 과다 사용에 따른 영향을 줄이기 위해 추측에 제한을 둡니다.

moderate 옵션은 중간 수준이며 많은 사이트에서 마우스 오버 또는 포인터 다운 시 모든 링크를 기본적이지만 강력한 추측 규칙 구현으로 사전 렌더링하는 다음과 같은 추측 규칙을 통해 이점을 얻을 수 있습니다.

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

프리페치

추측 규칙은 전체 사전 렌더링 없이 페이지를 미리 가져오는 데도 사용할 수 있습니다. 이는 사전 렌더링으로 전환하는 좋은 첫 단계일 때가 많습니다.

<script type="speculationrules">
{
  "prefetch": [
    {
      "urls": ["next.html", "next2.html"]
    }
  ]
}
</script>

참고: 방금 HTTP 캐시로 미리 가져온 이전 <link rel="prefetch"> 리소스 힌트와 달리, 추측 규칙을 사용하여 로드된 문서는 탐색이 렌더링되지만 렌더링되지 않는 것과 동일한 방식으로 처리되고 메모리에 보관되므로 필요할 때 브라우저에서 더 빠르게 사용할 수 있습니다. 따라서 HTTP 캐시에 캐시할 수 없는 문서도 미리 가져올 수 있습니다. <link rel="prefetch">를 사용한 문서 미리 가져오기 관련 문제로 인해 향후에는 추측 규칙을 사용하는 것이 좋습니다. <link rel="prefetch">는 하위 리소스 미리 가져오기에만 사용됩니다.

Chrome 한도

Chrome에는 Speculation Rules API의 남용을 방지하기 위해 다음과 같은 제한이 있습니다.

열의	프리페치	사전 렌더링
immediate/eager	50명	10
moderate/conservative	2 (FIFO)	2 (FIFO)

Chrome의 추측 한도

사용자 상호작용에 따라 달라지는 moderate 및 conservative 설정은 선입 선출 (FIFO) 방식으로 작동합니다. 한도에 도달한 후에는 새 추측이 가장 오래된 추측이 취소되고 메모리를 절약하기 위해 최신 예측으로 대체됩니다. 취소된 추측은 링크 위로 다시 마우스를 가져가는 등의 방법으로 다시 트리거될 수 있으며, 이렇게 하면 해당 URL이 다시 예측되어 가장 오래된 추측이 푸시됩니다. 이 경우 이전 추측은 해당 URL에 대한 HTTP 캐시에 캐시 가능한 리소스를 모두 캐시하므로 향후 추측을 하면 비용이 줄어듭니다. 이 때문에 한도가 중간 기준점인 2로 설정되어 있습니다. 정적 목록 규칙은 사용자 작업에 의해 트리거되지 않으며 브라우저가 어떤 규칙이 언제 필요한지 알 수 없으므로 한도가 더 높습니다.

immediate 및 eager 한도도 동적이므로 list URL 스크립트 요소를 삭제하면 삭제된 예측을 취소하여 용량을 확보하게 됩니다.

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

• 데이터 저장.
• 에너지 절약 모드는 사용 설정되어 있으며 배터리가 부족할 때 작동합니다.
• 메모리 제약 조건.
• '페이지 미리 로드' 설정이 사용 중지된 경우 (uBlock Origin과 같은 Chrome 확장 프로그램에서도 이 설정이 명시적으로 사용 중지됨)
• 페이지가 백그라운드 탭에서 열렸습니다.

또한 Chrome은 활성화될 때까지 사전 렌더링된 페이지에서 교차 출처 iframe을 렌더링하지 않습니다.

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

페이지에 추측 규칙을 포함하는 방법

추측 규칙은 페이지의 HTML에 정적으로 포함하거나 자바스크립트를 통해 페이지에 동적으로 삽입할 수 있습니다.

• 정적으로 포함된 추측 규칙: 예를 들어 뉴스 미디어 사이트 또는 블로그에서는 최신 기사를 사전 렌더링할 수 있으며, 많은 사용자가 다음 탐색을 할 때 이 기사가 자주 사용되는 경우, moderate 또는 conservative를 사용하는 문서 규칙을 사용하여 사용자가 링크와 상호작용할 때 추측할 수 있습니다.
• 동적으로 삽입된 추측 규칙: 애플리케이션 로직을 기반으로 하거나, 사용자에게 맞춤설정되거나, 기타 휴리스틱을 기반으로 할 수 있습니다.

이전에 많은 라이브러리에서 <link rel=prefetch>를 사용해 했던 것처럼 마우스 오버 또는 링크 클릭과 같은 작업을 기반으로 동적 삽입을 선호하는 경우 브라우저에서 많은 사용 사례를 처리할 수 있으므로 문서 규칙을 살펴보는 것이 좋습니다.

추측 규칙은 기본 프레임에서 <head> 또는 <body>에 추가할 수 있습니다. 서브프레임의 추측 규칙은 실행되지 않으며, 사전 렌더링된 페이지의 추측 규칙은 해당 페이지가 활성화된 후에만 실행됩니다.

Speculation-Rules HTTP 헤더

브라우저 지원

• 121
• 121
• x
• x

소스

추측 규칙은 문서의 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을 기준으로 합니다. 이는 동일 출처 링크의 일부 또는 전체를 선택해야 하는 경우에 특히 유용할 수 있습니다.

추측 규칙 및 SPA

추측 규칙은 브라우저에서 관리하는 전체 페이지 탐색에만 지원되며 단일 페이지 앱 (SPA) 또는 앱 셸 페이지에는 지원되지 않습니다. 이러한 아키텍처는 문서 가져오기를 사용하지 않고 대신 데이터 또는 페이지의 API 또는 부분 가져오기를 수행하여 현재 페이지에 처리되어 표시됩니다. 소위 '소프트 탐색'에 필요한 데이터는 추측 규칙 외부에서 앱에서 미리 가져올 수 있지만 사전 렌더링될 수는 없습니다.

추측 규칙은 이전 페이지의 애플리케이션 자체를 사전 렌더링하는 데 사용할 수 있습니다. 이를 통해 일부 SPA의 추가적인 초기 로드 비용을 상쇄할 수 있습니다. 그러나 앱 내의 경로 변경사항은 사전 렌더링할 수 없습니다.

추측 규칙 디버그

이 새로운 API를 보고 디버깅하는 데 도움이 되는 새로운 Chrome DevTools 기능은 추정 규칙 디버깅 전용 게시물을 참고하세요.

여러 추측 규칙

같은 페이지에 여러 추측 규칙을 추가할 수도 있으며, 이는 기존 규칙에 추가됩니다. 따라서 다음과 같은 여러 가지 방법으로 모두 one.html 및 two.html 사전 렌더링이 생성됩니다.

URL 목록:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html", "two.html"]
    }
  ]
}
</script>

여러 speculationrules:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    }
  ]
}
</script>
<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

한 speculationrules 세트 내의 여러 목록

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    },
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

No-Vary-Search 지원

브라우저 지원

• 121
• 121
• x
• x

소스

페이지를 미리 가져오거나 사전 렌더링할 때 특정 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 검색 매개변수를 사용하여 제품 데이터를 가져오기 위해 자바스크립트를 사용하는 클라이언트 측 렌더링에 따라 페이지 콘텐츠가 달라집니다. 따라서 이 URL을 미리 가져오고 No-Vary-Search HTTP 헤더를 반환하여 페이지가 모든 id 검색 매개변수에 사용될 수 있음을 보여줍니다.

그러나 미리 가져오기가 완료되기 전에 사용자가 링크를 클릭하면 브라우저에 /products 페이지가 수신되지 않았을 수 있습니다. 이 경우 브라우저는 No-Vary-Search HTTP 헤더를 포함할지 알 수 없습니다. 그러면 브라우저는 링크를 다시 가져올지 또는 미리 가져오기가 완료될 때까지 기다렸다가 No-Vary-Search HTTP 헤더가 포함되어 있는지 확인할 수 있습니다. expects_no_vary_search 설정을 사용하면 브라우저에서 페이지 응답에 No-Vary-Search HTTP 헤더가 포함되어야 한다는 것을 인식하고 미리 가져오기가 완료될 때까지 기다릴 수 있습니다.

추측 규칙 제한사항 및 향후 개선사항

추측 규칙은 동일한 탭 내에서 열리는 페이지로 제한되지만, Google은 이러한 제한을 줄이기 위해 노력하고 있습니다. 기본적으로 사전 렌더링은 동일 출처 페이지로 제한됩니다.

동일한 사이트 교차 출처 페이지를 사전 렌더링합니다(예: https://a.example.com이(가) https://b.example.com에서 페이지를 사전 렌더링할 수 있습니다). 이 기능을 사용하려면 사전 렌더링된 페이지(이 예에서는 https://b.example.com)가 Supports-Loading-Mode: credentialed-prerender HTTP 헤더를 포함하여 선택해야 합니다. 그렇지 않으면 Chrome에서 사전 렌더링을 취소합니다.

또한 향후 버전에서는 교차 출처 페이지 (사이트에서 유사한 Supports-Loading-Mode: uncredentialed-prerender HTTP 헤더로 선택)에 사전 렌더링을 허용하고 새 탭에서 사전 렌더링을 사용 설정할 수 있습니다.

Detect Speculation Rules API 지원

표준 HTML 검사로 Speculation Rules API 지원 기능을 감지할 수 있습니다.

if (HTMLScriptElement.supports && HTMLScriptElement.supports('speculationrules')) {
  console.log('Your browser supports the Speculation Rules API.');
}

자바스크립트를 통해 추측 규칙을 동적으로 추가

다음은 JavaScript로 prerender 추측 규칙을 추가하는 예입니다.

if (HTMLScriptElement.supports &&
    HTMLScriptElement.supports('speculationrules')) {
  const specScript = document.createElement('script');
  specScript.type = 'speculationrules';
  specRules = {
    prerender: [
      {
        urls: ['/next.html'],
      },
    ],
  };
  specScript.textContent = JSON.stringify(specRules);
  console.log('added speculation rules to: next.html');
  document.body.append(specScript);
}

이 사전 렌더링 데모 페이지에서 JavaScript 삽입을 사용한 Speculation Rules API 사전 렌더링의 데모를 볼 수 있습니다.

추측 규칙 취소

추측 규칙을 삭제하면 사전 렌더링이 취소되지만, 이때쯤이면 사전 렌더링을 시작하는 데 리소스가 이미 사용되었을 가능성이 높으므로 사전 렌더링을 취소해야 할 가능성이 있다면 사전 렌더링을 하지 않는 것이 좋습니다.

추측 규칙 및 콘텐츠 보안 정책

추측 규칙은 <script> 요소를 사용하지만 JSON만 포함하더라도 사이트에서 해시나 nonce를 사용해 script-src 콘텐츠 보안 정책에 포함해야 합니다.

새 inline-speculation-rules를 script-src에 추가하여 해시 또는 nonced 스크립트에서 삽입된 <script type="speculationrules"> 요소를 지원할 수 있습니다. 이는 초기 HTML에 포함된 규칙을 지원하지 않으므로 엄격한 CSP를 사용하는 사이트의 경우 자바스크립트로 규칙을 삽입해야 합니다.

사전 렌더링 감지 및 사용 중지

사전 렌더링은 빠른 페이지 렌더링(종종 즉시)이 가능하므로 일반적으로 사용자에게 긍정적인 경험입니다. 이렇게 하면 사용자와 사이트 소유자 모두에게 유익합니다. 사전 렌더링된 페이지를 사용하면 다른 방법으로는 달성하기 어려울 수 있는 더 나은 사용자 환경을 제공할 수 있기 때문입니다.

하지만 페이지의 사전 렌더링을 원하지 않는 경우(예: 초기 요청 또는 페이지에서 실행되는 JavaScript에 따라 페이지 상태가 변경되는 경우)가 발생할 수 있습니다.

Chrome에서 사전 렌더링 사용 설정 및 사용 중지

사전 렌더링은 chrome://settings/performance/에서 '페이지 미리 로드' 설정을 사용하는 Chrome 사용자에게만 사용 설정됩니다. 또한 메모리가 부족한 기기나 운영체제가 데이터 저장 또는 에너지 절약 모드인 경우에도 사전 렌더링이 사용 중지됩니다. Chrome 한도 섹션을 참고하세요.

서버 측 사전 렌더링 감지 및 사용 중지

사전 렌더링된 페이지는 Sec-Purpose HTTP 헤더와 함께 전송됩니다.

Sec-Purpose: prefetch;prerender

Speculation Rules API를 사용하여 미리 가져온 페이지의 헤더는 prefetch로만 설정됩니다.

Sec-Purpose: prefetch

서버는 이 헤더를 기반으로 응답하여 추측 요청을 기록하거나 다른 콘텐츠를 반환하거나 사전 렌더링이 발생하지 않도록 할 수 있습니다. 비성공 응답 코드가 반환되면 (즉, 200 또는 304가 아님) 페이지가 사전 렌더링되지 않으며 모든 미리 가져오기 페이지가 삭제됩니다.

이는 특정 페이지가 사전 렌더링되지 않도록 하는 가장 좋은 방법입니다. 그러나 최상의 환경을 제공하려면 사전 렌더링을 허용하되, 실제로 페이지가 조회된 후에만 자바스크립트를 사용하여 작업을 지연시키는 것이 좋습니다.

JavaScript에서 사전 렌더링 감지

페이지가 사전 렌더링되는 동안 document.prerendering API는 true를 반환합니다. 이는 페이지가 실제로 활성화될 때까지 사전 렌더링 중에 특정 활동을 방지하거나 지연시키기 위해 페이지에서 사용할 수 있습니다.

사전 렌더링된 문서가 활성화되면 PerformanceNavigationTiming의 activationStart도 사전 렌더링이 시작된 시점과 문서가 실제로 활성화된 시점 사이의 시간을 나타내는 0이 아닌 시간으로 설정됩니다.

다음과 같이 사전 렌더링 페이지와 사전 렌더링된 페이지를 확인하는 함수를 사용할 수 있습니다.

function pagePrerendered() {
  return (
    document.prerendering ||
    self.performance?.getEntriesByType?.('navigation')[0]?.activationStart > 0
  );
}

페이지가 전체 또는 부분적으로 사전 렌더링되었는지 확인하는 가장 쉬운 방법은 페이지가 활성화된 후 DevTools를 열고 콘솔에 performance.getEntriesByType('navigation')[0].activationStart를 입력하는 것입니다. 0이 아닌 값이 반환되면 페이지가 사전 렌더링된 것입니다.

콘솔에서 사전 렌더링을 테스트합니다.

도움말: 추가적인 Chrome DevTools 디버깅 기능을 사용하여 미리 가져온 페이지와 사전 렌더링된 페이지를 디버깅할 수 있습니다. 자세한 내용은 추정 규칙 디버깅 게시물을 참고하세요.

페이지를 보는 사용자가 페이지를 활성화하면 prerenderingchange 이벤트가 document에 전달됩니다. 그러면 이전에는 페이지 로드 시 기본적으로 시작되었지만 사용자가 실제로 페이지를 볼 때까지 지연하려는 활동을 사용 설정할 수 있습니다.

이러한 API를 사용하면 프런트엔드 JavaScript가 사전 렌더링된 페이지를 적절하게 감지하고 이에 따라 조치를 취할 수 있습니다.

경고: PerformanceNavigationTiming.type는 이전의 원래 <link rel="prerender"...> 탐색 유형에 사용된 prerender 값을 사용하지 않습니다. 이는 향후 변경될 수 있지만 현재는 클라이언트가 document.prerendering API를 사용하여 사전 렌더링 페이지를 식별하고 0이 아닌 PerformanceNavigationTiming.activationStart 필드를 사용하여 이후 활성화된 사전 렌더링된 페이지를 식별해야 합니다.

분석에 미치는 영향

애널리틱스는 Google 애널리틱스를 사용하여 페이지 조회수와 이벤트를 측정하는 등 웹사이트 사용량을 측정하는 데 사용됩니다. 또는 RUM (Real User Monitoring)을 사용하여 페이지의 성능 측정항목을 측정합니다.

사용자가 페이지를 로드할 가능성이 높은 경우에만 페이지를 사전 렌더링해야 합니다. 이러한 이유로 Chrome 주소 표시줄 사전 렌더링 옵션은 가능성이 80% 를 초과하는 경우에만 표시됩니다.

하지만 특히 Speculation Rules API를 사용하는 경우 사전 렌더링된 페이지가 애널리틱스에 영향을 줄 수 있으며 사이트 소유자는 추가 코드를 추가하여 활성화 시 사전 렌더링된 페이지에 대해서만 분석을 사용 설정해야 할 수 있습니다. 모든 분석 제공업체가 기본적으로 이 작업을 실행하는 것은 아니기 때문입니다.

참고: Google 애널리틱스에서는 기본적으로 활성화될 때까지 지연시키는 방식으로 사전 렌더링을 처리합니다. Google 게시자 태그 (GPT), Google 애드센스도 마찬가지로 활성화될 때까지 지연이 발생합니다.

이렇게 하려면 문서가 사전 렌더링되는 경우 prerenderingchange 이벤트를 기다리거나 현재 진행 중인 경우 즉시 확인하는 Promise를 사용하면 됩니다.

// Set up a promise for when the page is activated,
// which is needed for prerendered pages.
const whenActivated = new Promise((resolve) => {
  if (document.prerendering) {
    document.addEventListener('prerenderingchange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenActivated;
  // Initialise your analytics
}

initAnalytics();

다른 접근 방식은 사전 렌더링 사례와 백그라운드에서 탭이 열릴 때 (예: 마우스 오른쪽 버튼으로 클릭하고 새 탭에서 열 때) 페이지가 처음 표시될 때까지 활동을 지연시키는 것입니다.

// Set up a promise for when the page is first made visible
const whenActivated = new Promise((resolve) => {
  if (document.hidden) {
    document.addEventListener('visibilitychange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenActivated;
  // Initialise your analytics
}

initAnalytics();

이는 분석 및 유사한 사용 사례에 적합할 수 있지만 경우에 따라 이러한 경우에 더 많은 콘텐츠를 로드해야 할 수 있으므로 사전 렌더링 페이지를 특별히 타겟팅하는 데 document.prerendering 및 prerenderingchange를 사용하는 것이 좋습니다.

성능 측정

성능 측정항목을 측정하려면 브라우저 API가 보고하는 페이지 로드 시간보다 활성화 시간을 기준으로 하여 측정하는 것이 더 좋은지 여부를 분석해야 합니다.

Chrome에서 Chrome 사용자 환경 보고서를 통해 측정하는 코어 웹 바이탈의 경우 사용자 환경을 측정하기 위한 것입니다. 활성화 시간을 기준으로 측정됩니다. 예를 들어 이 경우 LCP가 0초가 되는 경우가 많으며 이는 코어 웹 바이탈을 개선하는 좋은 방법입니다.

Chrome에서 코어 웹 바이탈을 측정하는 것과 동일한 방식으로 사전 렌더링된 탐색을 처리하도록 web-vitals 라이브러리가 버전 3.1.0부터 업데이트되었습니다. 또한 이 버전은 페이지가 완전히 또는 부분적으로 사전 렌더링된 경우 Metric.navigationType 속성에서 이러한 측정항목의 사전 렌더링된 탐색에 플래그를 지정합니다.

사전 렌더링 측정

페이지가 사전 렌더링되었는지 여부는 0이 아닌 activationStart 항목의 PerformanceNavigationTiming로 확인할 수 있습니다. 그런 다음 맞춤 측정기준을 사용하거나 페이지 조회수를 기록할 때 이와 유사한 방식으로 로깅할 수 있습니다(예: 앞에서 설명한 pagePrerendered 함수 사용).

// Set Custom Dimension for Prerender status
gtag('set', { 'dimension1': pagePrerendered() });
// Initialise GA - including sending page view by default
gtag('config', 'G-12345678-1');

이를 통해 애널리틱스에서 다른 유형의 탐색에 비해 사전 렌더링된 탐색 수를 표시할 수 있으며, 성능 측정항목 또는 비즈니스 측정항목을 이러한 다양한 탐색 유형과 연결할 수 있습니다. Google의 우수사례에서 볼 수 있듯이 페이지 속도가 빨라지면 사용자의 만족도가 높아질 수 있으며, 이는 비즈니스 측정에 실질적인 영향을 미치는 경우가 많습니다.

즉각적인 탐색을 위해 사전 렌더링 페이지가 비즈니스에 미치는 영향을 측정할 때 이 기술을 사용하여 더 많은 탐색이 사전 렌더링되도록 허용하는 데 더 많은 노력을 투자할 가치가 있는지, 또는 페이지가 사전 렌더링되지 않는 이유를 조사할 필요가 있는지 결정할 수 있습니다.

적중률 측정

사전 렌더링 후 방문한 페이지의 영향을 측정하는 것 외에도 사전 렌더링되고 나중에 방문하지 않은 페이지도 측정하는 것이 중요합니다. 이는 개발자가 너무 많이 사전 렌더링하고 있으며, 사용자의 귀중한 리소스를 거의 이익 없이 사용하고 있음을 의미할 수 있습니다.

이는 예측 규칙이 삽입될 때(브라우저에서 HTMLScriptElement.supports('speculationrules')를 사용하여 사전 렌더링을 지원하는지 확인한 후) 분석 이벤트를 실행하여 사전 렌더링이 요청되었음을 나타내는 방식으로 측정할 수 있습니다. (앞서 언급한 것처럼 사전 렌더링이 요청되었다고 해서 사전 렌더링이 시작되었거나 완료되었음을 의미하지는 않습니다. 사전 렌더링은 브라우저에 대한 힌트이며, 사용자 설정, 현재 메모리 사용량 또는 기타 휴리스틱에 따라 페이지를 사전 렌더링하지 않도록 선택할 수 있습니다.)

그런 다음 이러한 이벤트 수를 실제 사전 렌더링 페이지 조회수와 비교할 수 있습니다. 또는 더 쉽게 비교할 수 있는 경우 활성화 시 다른 이벤트를 실행합니다.

그런 다음 두 수치의 차이를 보고 '성공률'을 근사값으로 구할 수 있습니다. Speculation Rules API를 사용하여 페이지를 사전 렌더링하는 페이지의 경우 높은 적중률을 유지하도록 규칙을 적절하게 조정하여 사용자를 지원하는 사용자 리소스를 사용하는 것과 불필요하게 사용하는 것 사이의 균형을 유지할 수 있습니다.

추측 규칙뿐만 아니라 주소 표시줄 사전 렌더링으로 인해 일부 사전 렌더링이 발생할 수 있습니다. 이를 구분하려면 document.referrer (사전 렌더링된 주소 표시줄 탐색을 포함하여 주소 표시줄 탐색의 경우 비어 있음)를 선택하면 됩니다.

사전 렌더링이 없는 페이지도 확인해야 합니다. 이는 주소 표시줄에서도 이러한 페이지가 사전 렌더링에 적합하지 않음을 나타낼 수 있기 때문입니다. 이는 실적 향상의 이점을 누릴 수 없다는 의미일 수 있습니다. Chrome팀은 bfcache 테스트 도구와 유사할 수 있는 사전 렌더링 적합성을 테스트하는 도구를 추가하고, 사전 렌더링이 실패한 이유를 노출하는 API를 추가할 수도 있습니다.

확장 프로그램에 미치는 영향

Chrome 확장 프로그램: 인스턴트 탐색을 지원하도록 API 확장에 관한 전용 게시물을 참고하세요. 여기에는 사전 렌더링된 페이지에 관해 확장 프로그램 작성자가 고려해야 할 몇 가지 추가 고려사항이 자세히 설명되어 있습니다.

의견

Chrome팀에서 사전 렌더링을 적극적으로 개발 중이며 Chrome 108 버전에서 사용할 수 있는 기능의 범위를 확장할 계획이 있습니다. GitHub 저장소 또는 Issue Tracker에 관한 의견이 있으면 언제든지 알려주세요. 이 흥미로운 새 API의 우수사례를 듣고 공유할 수 있기를 기대합니다.

관련 링크

• 추측 규칙 디버깅
• NoState Prefetch 소개
• Speculation Rules API
• 탐색 추측 GitHub 저장소
• Chrome 확장 프로그램: 인스턴트 탐색을 지원하도록 API 확장

감사의 말

썸네일 이미지: Marc-Olivier Jodoin(Unsplash