서명된 교환을 사용하여 LCP 최적화

서명된 교환을 최대한 개선하기 위해 서명된 교환을 측정하고 최적화하는 방법

데빈 멀린스
데빈 멀린스

서명된 교환 (SXG)은 페이지 속도를 개선하는 수단이며, 주로 최대 콘텐츠 렌더링 시간 (LCP)입니다. 추천 사이트 (현재 Google 검색)에서 페이지로 연결되는 링크를 걸면 사용자가 링크를 클릭하기 전에 브라우저 캐시로 페이지를 미리 가져올 수 있습니다.

미리 가져올 때 페이지를 렌더링하는 주요 경로에서 네트워크가 필요 없는 웹페이지를 만들 수 있습니다. 4G 연결에서 이 페이지 로드는 2.8초에서 0.9초로 줄어듭니다 (나머지 0.9초는 대부분 CPU 사용량임).

현재 SXG를 게시하는 대부분의 사용자는 Cloudflare의 사용하기 쉬운 자동 서명된 교환 (ASX) 기능을 사용하고 있습니다 (오픈소스 옵션도 있음).

자동 서명된 교환을 사용 설정하는 체크박스가 있는 Cloudflare 설정 패널

대부분의 경우 이 기능을 사용하도록 설정하는 확인란을 선택하는 것만으로도 위에 표시된 상당한 개선 효과를 얻을 수 있습니다. 파이프라인의 각 단계에서 이러한 SXG가 의도한 대로 작동하는지 확인하고 미리 가져오기를 최대한 활용하도록 페이지를 최적화하기 위해 몇 가지 단계를 더 거쳐야 할 수 있습니다.

Cloudflare가 출시된 후 지난 몇 달 동안 저는 다양한 포럼에서 질문을 읽고 답변하며, 사이트에 SXG 배포를 최대한 활용하는 방법에 관해 조언하는 방법을 배웠습니다. 이 게시물은 제가 하는 조언입니다. 다음 단계를 따르세요.

소개

SXG는 URL, HTTP 응답 헤더 집합, 응답 본문을 포함하는 파일로, 이 파일들은 모두 웹 PKI 인증서에 의해 암호화 방식으로 서명됩니다. 브라우저는 SXG를 로드할 때 다음 항목을 모두 확인합니다.

  • SXG가 만료되지 않았습니다.
  • 서명은 URL, 헤더, 본문, 인증서와 일치합니다.
  • 인증서가 유효하고 URL과 일치합니다.

인증에 실패하면 브라우저는 SXG를 중단하고 대신 서명된 URL을 가져옵니다. 인증에 성공하면 브라우저는 서명된 응답을 로드하며, 응답이 서명된 URL에서 직접 온 것처럼 취급됩니다. 따라서 SXG가 서명 후 만료되거나 수정되지 않는 한 모든 서버에서 SXG를 다시 호스팅할 수 있습니다.

Google 검색의 경우 SXG에서 검색 결과에서 페이지를 미리 가져오는 사용 설정합니다. SXG를 지원하는 페이지의 경우 Google 검색에서는 webpkgcache.com에 호스팅된 페이지의 캐시된 사본을 미리 가져올 수 있습니다. 브라우저에서는 서명된 원래 URL을 따르기 때문에 이러한 webpkgcache.com URL은 페이지의 표시나 동작에 영향을 미치지 않습니다. 미리 가져오기를 사용하면 페이지를 훨씬 빠르게 로드할 수 있습니다.

분석

SXG의 이점을 확인하려면 먼저 실험실 도구를 사용하여 반복 가능한 조건에서 SXG 성능을 분석하세요. WebPageTest를 사용하여 SXG 미리 가져오기 사용 여부와 관계없이 폭포식 구조(LCP)를 비교할 수 있습니다.

다음과 같이 SXG 없이 테스트를 생성합니다.

  • WebPageTest로 이동하여 로그인합니다. 로그인하면 나중에 쉽게 비교할 수 있도록 테스트 기록이 저장됩니다.
  • 테스트할 URL을 입력합니다.
  • 고급 구성으로 이동합니다. SXG 테스트에는 고급 구성이 필요하므로 여기에서 사용하여 테스트 옵션이 동일한지 확인할 수 있습니다.
  • Test Settings(테스트 설정) 탭에서 연결을 4G로 설정하고 '실행할 테스트 수'를 7로 늘리는 것이 도움이 될 수 있습니다.
  • 테스트 시작을 클릭합니다.

위와 동일한 단계를 사용하여 SXG를 사용하여 테스트를 생성하되 테스트 시작을 클릭하기 전에 스크립트 탭으로 이동하여 다음 WebPageTest 스크립트를 붙여넣고 안내에 따라 두 개의 navigate URL을 수정합니다.

// Disable log collection for the first step. We only want the waterfall for the target navigation.
logData 0

// Visit a search result page that includes your page.
navigate https://google.com/search?q=site%3Asigned-exchange-testing.dev+image

// Wait for the prefetch to succeed.
sleep 10

// Re-enable log collection.
logData 1

// Navigate to the prefetched SXG on the Google SXG Cache.
navigate https://signed--exchange--testing-dev.webpkgcache.com/doc/-/s/signed-exchange-testing.dev/sxgs/valid-image-subresource.html

첫 번째 navigate URL의 경우 페이지가 아직 Google 검색결과에 표시되지 않는 경우 이 프리패치 페이지를 사용하여 가짜 검색결과 페이지를 생성할 수 있습니다.

두 번째 navigate URL을 확인하려면 SXG 검사기 Chrome 확장 프로그램을 사용하여 페이지를 방문한 다음 확장 프로그램 아이콘을 클릭하여 캐시 URL을 확인합니다.

URL을 포함한 캐시 정보를 보여주는 SXG 검사기

테스트가 완료되면 테스트 기록으로 이동하여 두 테스트를 선택한 후 비교를 클릭합니다.

두 개의 테스트가 선택되어 있고 비교 버튼이 강조 표시된 테스트 기록

WebPageTest에서 각 비교의 LCP 중앙값으로 실행을 선택하도록 비교 URL에 &medianMetric=LCP를 추가합니다. (기본값은 속도 색인의 중앙값입니다.)

폭포식 구조를 비교하려면 폭포식 구조 불투명도 섹션을 펼치고 슬라이더를 드래그합니다. 동영상을 보려면 슬라이드 설정 조정을 클릭하고 해당 대화상자 내에서 아래로 스크롤한 다음 동영상 보기를 클릭합니다.

SXG 미리 가져오기가 성공하면 'with SXG' 폭포식 구조에 HTML 행이 포함되지 않고 하위 리소스의 가져오기가 더 빨리 시작됩니다. 예를 들어 여기에서 '이전'과 '이후'를 비교하세요.

SXG 미리 가져오기가 없는 네트워크 폭포식 구조. 첫 번째 행은 HTML 가져오기로, 1050밀리초가 걸립니다. SXG 미리 가져오기가 포함된 네트워크 폭포식 구조. HTML을 미리 가져옴으로써 모든 하위 리소스를 1050ms 일찍 가져오기 시작할 수 있습니다.

디버그

WebPageTest에 SXG가 미리 가져오기로 표시되면 파이프라인의 모든 단계에서 성공한 것입니다. 최적화 섹션으로 건너뛰어 LCP를 더욱 개선하는 방법을 알아볼 수도 있습니다. 그렇지 않은 경우에는 파이프라인의 어느 부분에서 오류가 발생했는지와 그 이유를 파악해야 합니다. 계속해서 방법을 알아보세요.

게시

페이지가 SXG로 생성되고 있는지 확인하세요. 그러려면 크롤러로 가장해야 합니다. 가장 쉬운 방법은 SXG 검사기 Chrome 확장 프로그램을 사용하는 것입니다.

체크표시 (✅)와 application/signed-Exchange;v=b3의 콘텐츠 유형을 보여주는 SXG 검사기

확장 프로그램은 SXG 버전을 선호한다는 Accept 요청 헤더로 현재 URL을 가져옵니다. 출처 옆에 체크표시 (✅)가 표시되면 SXG가 반환되었다는 의미입니다. 색인 생성 섹션으로 건너뛰어도 됩니다.

X표 (❌)가 표시되면 SXG가 반환되지 않았다는 의미입니다.

교차 표시 (❌) 및 텍스트/HTML 콘텐츠 유형이 표시된 SXG 검사기

Cloudflare ASX가 사용 설정된 경우 교차 표시 (❌)가 발생하는 가장 큰 이유는 캐시 제어 응답 헤더로 인해 차단되기 때문입니다. ASX는 다음 이름의 헤더를 찾습니다.

  • Cache-Control
  • CDN-Cache-Control
  • Surrogate-Control
  • Cloudflare-CDN-Cache-Control

이러한 헤더 중 하나라도 다음 헤더 값을 포함하고 있으면 SXG가 생성되지 않습니다.

  • private
  • no-store
  • no-cache
  • max-age 120 보다 작음(s-maxage에 의해 재정의되지 않는 경우 120 이상)

이 경우 SXG가 여러 방문과 여러 방문자에게 캐시되어 재사용될 수 있으므로 ASX는 SXG를 만들지 않습니다.

교차 표시(❌)가 발생할 수 있는 또 다른 이유는 Set-Cookie를 제외한 스테이트풀(Stateful) 응답 헤더 중 하나가 있기 때문입니다. ASX는 SXG 사양을 준수하기 위해 Set-Cookie 헤더를 삭제합니다.

Vary: Cookie 응답 헤더가 있을 수도 있습니다. Googlebot은 사용자 인증 정보 없이 SXG를 가져와서 여러 방문자에게 제공할 수도 있습니다. 사용자의 쿠키를 기반으로 사용자별로 다른 HTML을 제공하면 사용자에게 로그아웃된 화면과 같은 잘못된 환경이 표시될 수 있습니다.

Chrome 확장 프로그램 외에도 curl와 같은 도구를 사용할 수 있습니다.

curl -siH "Accept: application/signed-exchange;v=b3" $URL | less

또는 dump-signedexchange:

dump-signedexchange -verify -uri $URL

SXG가 있고 유효하면 사람이 읽을 수 있는 SXG 출력이 표시됩니다. 그렇지 않으면 오류 메시지가 표시됩니다.

색인 생성

Google 검색에서 SXG의 색인이 생성되었는지 확인합니다. Chrome DevTools를 열고 페이지에 대해 Google 검색을 수행합니다. SXG로 색인이 생성된 경우 Google의 페이지 링크에 webpkgcache.com의 사본을 가리키는 data-sxg-url가 포함됩니다.

webpkgcache.com을 가리키는 앵커 태그를 보여주는 DevTools의 Google 검색 결과

Google 검색에서 사용자가 검색결과를 클릭할 가능성이 높다고 판단하는 경우 결과를 미리 가져옵니다.

webpkgcache.com에 대한 rel=prefetch 링크가 표시된 DevTools의 Google 검색 결과

<link> 요소는 브라우저에 SXG를 미리 가져오기 캐시로 다운로드하도록 지시합니다. 사용자가 <a> 요소를 클릭하면 브라우저에서 캐시된 SXG를 사용하여 페이지를 렌더링합니다.

DevTools의 Network 탭으로 이동하고 webpkgcache가 포함된 URL을 검색하여 미리 가져오기의 증거를 확인할 수도 있습니다.

<a>가 webpkgcache.com을 가리키는 경우 서명된 교환의 Google 검색 색인 생성이 진행되고 있다는 의미입니다. 처리 섹션으로 건너뛰어도 됩니다.

또는 SXG를 사용 설정한 이후 Google에서 페이지를 다시 크롤링하지 않았기 때문일 수 있습니다. Google Search Console URL 검사 도구를 사용해 보세요.

Search Console URL 검사 도구(크롤링된 페이지 보기를 클릭한 다음 추가 정보를 클릭)

digest: mi-sha256-03=... 헤더가 있으면 Google이 SXG 버전을 성공적으로 크롤링했음을 나타냅니다.

digest 헤더가 없으면 SXG가 Googlebot에 제공되지 않았거나 SXG를 사용 설정한 이후 색인이 업데이트되지 않았음을 의미할 수 있습니다.

SXG가 크롤링되었지만 SXG에 연결되지 않은 경우 SXG 캐시 요구사항을 충족하지 못한 것일 수 있습니다. 이러한 내용은 다음 섹션에서 다룹니다.

수집

Google 검색에서 SXG의 색인을 생성하면 Google SXG 캐시로 사본을 전송하여 캐시 요구사항에 따라 유효성을 검사합니다. Chrome 확장 프로그램에는 다음과 같은 결과가 표시됩니다.

체크표시 (✅)와 경고 메시지가 없는 SXG 검사기

체크표시 (✅)가 표시되면 최적화로 건너뛸 수 있습니다.

요구사항을 충족하지 못하는 경우 X표 (❌)와 경고 메시지가 표시되며 그 이유는 다음과 같습니다.

교차 표시 (❌) 및 다음의 경고 메시지가 표시된 SXG 검사기

이 경우 페이지는 SXG를 사용 설정하기 전과 동일하게 작동합니다. Google에서는 SXG 미리 가져오기 없이 원래 호스트의 페이지로 연결합니다.

캐시된 사본이 만료되어 백그라운드에서 다시 가져오는 경우 모래시계 (⌛)가 표시됩니다.

모래시계 (⌛)에 경고 메시지가 없는 SXG 검사기

SXG의 Google 개발자 문서에도 캐시를 수동으로 쿼리하는 방법이 나와 있습니다.

최적화

SXG 검사기 Chrome 확장 프로그램에 모든 체크표시 (✅)가 표시되면 사용자에게 제공할 수 있는 SXG가 있는 것입니다. SXG에서 LCP를 최대한 개선할 수 있도록 웹페이지를 최적화하는 방법을 알아보세요.

max-age

SXG가 만료되면 Google SXG 캐시가 백그라운드에서 새 사본을 가져옵니다. 가져오기를 기다리는 동안 사용자는 미리 가져오지 않은 원래 호스트의 페이지로 연결됩니다. Cache-Control: max-age를 더 오래 설정할수록 백그라운드 가져오기가 발생하는 빈도가 줄어들어 미리 가져오기로 LCP를 줄일 수 있는 빈도가 높아집니다.

이는 성능과 최신 상태 간의 절충안이며 캐시를 통해 사이트 소유자는 각 페이지의 특정 요구에 맞게 2분에서 7일 사이의 최대 수명을 SXG에 제공할 수 있습니다. 일례로 다음과 같은 사실을 알게 되었습니다.

  • max-age=86400 (1일) 이상이 실적에 도움이 됩니다.
  • max-age=120 (2분) 지연

데이터를 더 연구하면서 두 가지 사이의 가치에 대해 더 자세히 알 수 있기를 바랍니다.

user-agent

한 번은 미리 가져온 SXG를 사용할 때 LCP가 증가했습니다. WebPageTest를 실행하여 SXG 미리 가져오기를 사용하지 않은 경우와 사용하지 않은 경우의 결과 중앙값을 비교했습니다. 아래에서 이후를 클릭합니다.

SXG 미리 가져오기가 없는 네트워크 워터폴(LCP는 2초) SXG 미리 가져오기가 포함된 네트워크 폭포식 구조. HTML을 미리 가져옴으로써 모든 하위 리소스를 800ms 먼저 가져오기 시작할 수 있지만 LCP는 2.1초입니다.

미리 가져오기가 작동하는 것을 확인했습니다. HTML이 주요 경로에서 삭제되므로 모든 하위 리소스를 더 일찍 로드할 수 있습니다. 하지만 녹색 점선인 LCP는 2초에서 2.1초로 증가했습니다.

이것을 진단하기 위해 필름 스트립을 살펴봤습니다. SXG에서 페이지가 다르게 렌더링되는 것으로 나타났습니다. 일반 HTML에서 Chrome은 LCP의 '가장 큰 요소'가 제목이라고 판단했습니다. 하지만 SXG 버전에서는 페이지에 지연 로드 배너가 추가되어 헤드라인이 스크롤해야 볼 수 있는 부분으로 밀려 새로운 가장 큰 요소가 지연 로드 쿠키 동의 대화상자가 되었습니다. 모든 것이 전보다 빠르게 렌더링되었지만, 레이아웃 변경으로 인해 측정항목에서 더 느리게 보고되었습니다.

더 자세히 알아본 결과 레이아웃이 다른 이유는 페이지가 User-Agent에 따라 다르고 로직에 오류가 있기 때문입니다. SXG 크롤링 헤더에 모바일로 표시되었지만 데스크톱 페이지를 게재하고 있었습니다. 이 문제를 해결한 후 브라우저가 페이지 제목을 다시 가장 큰 요소로 올바르게 식별했습니다.

이제 '이후'를 클릭하면 미리 가져온 LCP가 1.3초로 떨어지는 것을 확인할 수 있습니다.

SXG 미리 가져오기가 없는 네트워크 워터폴(LCP는 2초) SXG 미리 가져오기가 포함된 네트워크 워터폴(LCP는 1.3초)

SXG는 모든 폼 팩터에 사용 설정됩니다. 이에 대비하려면 다음 중 하나에 해당하는지 확인하세요.

하위 리소스

SXG를 사용하면 HTML과 함께 하위 리소스 (이미지 포함)를 미리 가져올 수 있습니다. Cloudflare ASX는 HTML에서 동일 출처 (퍼스트 파티) <link rel=preload> 요소를 스캔하여 SXG 호환 링크 헤더로 변환합니다. 여기여기에서 소스 코드에 관해 자세히 알아보세요.

제대로 작동하면 Google 검색에서 추가 미리 가져오기가 표시됩니다.

/sub/.../image.jpg의 미리 가져오기를 보여주는 DevTools Network 탭이 있는 Google 검색 결과

LCP를 최적화하려면 폭포식 구조를 자세히 살펴보고 가장 큰 요소를 렌더링하는 주요 경로에 있는 리소스를 파악하세요. 미리 가져올 수 없는 경우 중요 경로에서 삭제할 수 있는지 고려합니다. 로드가 완료될 때까지 페이지를 숨기는 스크립트가 있는지 살펴보세요.

Google SXG 캐시는 최대 20개의 하위 리소스를 미리 로드하도록 허용하며 ASX는 이 한도가 초과되지 않도록 확인합니다. 그러나 하위 리소스 미리 로드를 너무 많이 추가할 위험이 있습니다. 크로스 사이트 추적을 방지하기 위해 브라우저는 미리 로드된 하위 리소스를 모두 가져오기가 완료된 경우에만 미리 로드된 하위 리소스를 사용합니다. 하위 리소스가 많을수록 사용자가 클릭하여 페이지로 이동하기 전에 하위 리소스가 모두 미리 가져오기를 완료할 가능성이 낮아집니다.

SXG 검사기는 현재 하위 리소스를 확인하지 않습니다. 디버그하려면 그동안 curl 또는 dump-signedexchange를 사용하세요.

측정

WebPageTest에서 LCP 개선을 최적화한 후에는 SXG 미리 가져오기가 사이트의 전체 성능에 미치는 영향을 측정하는 것이 유용합니다.

서버 측 측정항목

TTFB (첫 바이트까지의 시간)와 같은 서버 측 측정항목을 측정할 때는 사이트에서 이 형식을 허용하는 크롤러에만 SXG를 제공한다는 점에 유의해야 합니다. TTFB의 측정을 봇이 아닌 실제 사용자의 요청으로 제한합니다. SXG를 생성하면 크롤러 요청에 대한 TTFB가 증가할 수 있지만 이는 방문자 경험에는 영향을 미치지 않습니다.

클라이언트 측 측정항목

SXG가 클라이언트 측 측정항목, 특히 LCP에서 가장 빠른 속도를 제공합니다. 영향을 측정할 때는 Cloudflare ASX를 사용 설정하고 Googlebot이 다시 크롤링할 때까지 기다린 다음 코어 웹 바이탈 (CWV) 집계를 28일 더 기다린 다음 새로운 CWV 수치를 확인하면 됩니다. 그러나 이 기간 동안 다른 모든 변화와 함께 이러한 변화를 파악하기가 어려울 수 있습니다.

대신 영향을 받았을 가능성이 있는 페이지 로드를 '확대'하고 'SXG가 페이지 조회수의 X% 에 영향을 미쳐 75번째 백분위수에서 LCP를 Y밀리초 개선'하는 것처럼 프레임에 넣는 것이 도움이 됩니다.

현재 SXG 미리 가져오기는 특정 조건에서만 발생합니다.

  • Chromium 브라우저(예: Chrome 또는 Edge(iOS 제외), 버전 M98 이상)
  • Referer: google.com 또는 기타 Google 검색 도메인 (Google 애널리틱스에서 추천 태그는 세션의 모든 페이지 조회에 적용되지만, SXG 미리 가져오기는 Google 검색에서 직접 연결된 첫 번째 페이지 조회에만 적용됩니다.)

동시 연구 섹션에서 '페이지 조회수의 X%'를 측정하고 'LCP를 Y밀리초 개선'하는 방법을 알아보세요.

현대 연구

실제 사용자 모니터링 (RUM) 데이터를 살펴볼 때 페이지 로드를 SXG 및 비 SXG로 분할해야 합니다. 이 경우 확인 중인 페이지 로드 집합을 제한해야 합니다. 따라서 선택 편향을 방지하기 위해 비 SXG 측이 SXG의 자격 조건과 일치하게 됩니다. 그렇지 않으면 LCP가 기본적으로 다른 SXG가 아닌 페이지 로드 집합에만 다음 항목이 존재하게 됩니다.

  • iOS 기기: 기기 사용자 간에 하드웨어 또는 네트워크 속도에 차이가 있기 때문입니다.
  • 이전 Chromium 브라우저: 동일한 이유로 인해
  • 데스크톱 기기: 동일한 이유 또는 페이지 레이아웃으로 인해 다른 '가장 큰 요소'가 선택되기 때문입니다.
  • 동일 사이트 탐색 (방문자가 사이트 내 링크를 따라가는 경우): 이전 페이지 로드 시 캐시된 하위 리소스를 재사용할 수 있기 때문입니다.

Google 애널리틱스 (UA)에서 범위가 '조회'인 맞춤 측정기준 2개를 만들고 하나는 'isSXG'이고 다른 하나는 '리퍼러'라는 이름으로 만듭니다. 기본 제공 '소스' 측정기준에는 세션 범위가 있으므로 동일 사이트 탐색은 제외되지 않습니다.

권장 설정이 적용된 Google 애널리틱스 측정기준 편집기

다음 필터를 AND로 조합하여 'SXG 반사실적'이라는 맞춤 세그먼트를 만듭니다.

  • referrer 다음으로 시작 https://www.google.
  • Browser이(가) Chrome과(와) 정확히 일치함
  • Browser 버전이 ^(9[8-9]|[0-9]{3}) 정규식과 일치함
  • isSXG이(가) false과(와) 정확히 일치함
추천 필터가 적용된 Google 애널리틱스 세그먼트 편집기

이 세그먼트의 사본을 만듭니다. 'SXG'는 이름을 'SXG'로 지정합니다. 단, isSXGtrue과 정확히 일치합니다.

사이트 템플릿에서 Google 애널리틱스 스니펫 위에 다음 스니펫을 추가합니다. 다음은 SXG를 생성할 때 ASX가 falsetrue로 변경하는 특수 구문입니다.

<script data-issxg-var>window.isSXG=false</script>

권장사항에 따라 Google 애널리틱스 보고 스크립트를 맞춤설정하여 LCP를 기록합니다. gtag.js를 사용하는 경우 다음과 같이 'config' 명령어를 수정하여 맞춤 측정기준을 설정합니다 ('dimension1''dimension2'을 Google 애널리틱스에서 사용하도록 지정한 이름으로 대체).

gtag('config', 'YOUR_TRACKING_ID', {
  'dimension1': String(isSXG),
  'dimension2': document.referrer,
});

analytics.js를 사용하는 경우 여기에 설명된 대로 'create' 명령어를 수정합니다.

데이터를 수집하기 위해 며칠간 기다린 후 Google 애널리틱스 이벤트 보고서로 이동하여 SXG 세그먼트에 대한 드릴다운을 추가합니다. 이렇게 하면 'SXG가 페이지 조회수의 X% 에 영향을 미칩니다.'에 대한 X가 채워집니다.

SXG 세그먼트가 포함된 Google 애널리틱스 이벤트 보고서(순 이벤트 수: 12.5%)

마지막으로 웹 바이탈 보고서로 이동하여 '세그먼트 선택'을 선택하고 'SXG 반사실적' 및 'SXG'를 선택합니다.

SXG 반사실적 및 SXG 항목이 선택된 웹 바이탈 보고서

'제출'을 클릭하면 두 세그먼트의 LCP 분포가 표시됩니다. 이렇게 하면 '75번째 백분위수에서 LCP를 Y밀리초 단위로 개선'하기 위한 Y가 채워집니다.

SXG 반사실적 및 SXG의 LCP 분포를 보여주는 웹 바이탈 보고서

주의사항

위의 필터를 모두 적용하면 SXG 반사실적인 페이지 로드가 다음과 같이 구성됩니다.

  • 캐시 부적중: Google SXG 캐시에 특정 URL에 관한 SXG의 새 사본이 없으면 사이트의 원래 URL로 리디렉션됩니다.
  • 기타 검색결과 유형: 현재 Google 검색은 표준 웹 검색 결과 및 몇 가지 다른 유형에 관해서만 SXG를 지원합니다. 추천 스니펫 및 주요 뉴스 캐러셀과 같은 다른 콘텐츠는 사이트의 원래 URL로 연결됩니다.
  • 사용할 수 없는 URL: 사이트의 일부 페이지에서 SXG를 사용할 수 없는 경우 (예: 캐시할 수 없는 경우) 이 집합에 표시될 수 있습니다.

SXG 페이지 로드와 위의 SXG가 아닌 페이지 로드 집합 사이에 편향이 남아 있을 수 있지만 동시 학습 섹션의 맨 위에 언급된 편향보다 규모는 작아야 합니다. 예를 들어 캐시할 수 없는 페이지가 캐시 가능한 페이지보다 느리거나 빠를 수 있습니다. 문제가 될 수 있다고 생각되면 특정 SXG 대상 URL로 제한된 데이터를 살펴보고 결과가 전체 연구와 일치하는지 확인하세요.

사이트에 AMP 페이지가 있는 경우 SXG를 사용 설정해도 성능이 개선되지 않을 수 있습니다. Google 검색에서 이미 페이지를 미리 가져올 수 있기 때문입니다. 이러한 페이지를 제외하는 필터를 추가하여 관련 변경사항을 더 '확대'해 보세요.

마지막으로, 모든 선택 편향을 해결하더라도 생존 편향으로 인해 LCP 개선이 RUM 통계에서 저하된 것처럼 보일 위험이 있습니다. 이 도움말에서는 이러한 위험을 잘 설명하고 있으며, 일종의 이탈 측정항목을 살펴보고 이러한 상황이 발생하는지 여부를 확인할 것을 제안합니다.

연구 전/후

현대 연구의 결과를 입증하려면 SXG 사용 전후의 LCP를 비교하는 것이 유용할 수 있습니다. 위에 설명된 잠재적인 편향을 제거하려면 SXG 페이지 조회수로 제한하지 마세요. 대신 SXG에 적합한 결과를 살펴보세요(위의 세그먼트 정의이지만 isSXG 제약조건 없음).

Google 검색에서 SXG가 사용 설정되었는지 확인하기 위해 사이트의 모든 페이지를 다시 크롤링하는 데 최대 몇 주가 걸릴 수 있습니다. 이 몇 주 동안 다음과 같은 다른 잠재적인 편향이 발생할 수 있습니다.

  • 새로운 브라우저 버전 또는 사용자 하드웨어의 개선사항이 페이지 로드 속도를 높일 수 있습니다.
  • 연말연시와 같은 중요한 이벤트는 트래픽이 평소보다 왜곡될 수 있습니다.

또한 전후의 전반적인 75번째 백분위수 LCP를 검토하여 위의 연구를 확인하는 것도 도움이 됩니다. 모집단의 하위 집합에 대해 학습한다고 해서 반드시 전체 모집단에 대해 알 수 있는 것은 아닙니다. 예를 들어 SXG가 페이지 로드의 10% 를 800ms 개선한다고 가정해 보겠습니다.

  • 이미 10% 가장 빠른 페이지 로드였다면 75번째 백분위수에 영향을 미치지 않습니다.
  • 가장 느린 페이지 로드가 10% 가장 느렸지만 처음부터 75번째 백분위수 LCP보다 800ms 이상 느렸다면 75번째 백분위수에 전혀 영향을 미치지 않습니다.

극단적인 예로서 현실을 반영하지는 않지만 문제를 설명하기를 바랍니다. 실제로 SXG는 대부분의 사이트의 75번째 백분위수에 영향을 미칠 가능성이 높습니다. 크로스 사이트 탐색은 가장 느린 경향이 있으며, 프리패치를 통한 개선이 상당한 경향이 있습니다.

일부 URL 선택 해제

마지막으로 SXG 실적을 비교하는 한 가지 방법은 사이트의 일부 URL 하위 집합에 대해 SXG를 사용 중지하는 것입니다. 예를 들어 Cloudflare ASX가 SXG를 생성하지 않도록 CDN-Cache-Control: no-store 헤더를 설정할 수 있습니다. 이 방법은 권장되지 않습니다.

다른 연구 방법보다 표본 선택 편향의 위험이 더 높을 가능성이 큽니다. 예를 들어 사이트의 홈페이지 또는 유사한 인기 URL을 대조군 또는 실험 그룹에 선택하는지에 따라 큰 차이가 나타날 수 있습니다.

홀드백 연구

영향을 측정하는 가장 좋은 방법은 홀드백 연구를 수행하는 것입니다. 안타깝지만 현재로서는 이러한 종류의 테스트를 실행할 수 없습니다. 향후 이러한 테스트에 대한 지원을 추가할 계획입니다.

홀드백 학습에는 다음과 같은 속성이 있습니다.

  • 실험 그룹에서는 페이지 조회수 중 SXG가 아닌 임의의 일부분이 '홀드백'되어 대신 SXG가 아닌 버전으로 게재됩니다. 이렇게 하면 동등한 사용자, 기기, 시나리오 및 페이지를 '비교'할 수 있습니다.
  • 홀드백(Holdback)(즉, 반사실적) 페이지 조회수는 애널리틱스에서 이와 같이 라벨이 지정됩니다. 이렇게 하면 데이터를 '확대'하여 대조군의 SXG 페이지 로드를 실험의 SXG 반사실적과 비교할 수 있습니다. 따라서 결과적으로 SXG 미리 가져오기의 영향을 받지 않을 다른 페이지 로드의 노이즈가 줄어듭니다.

이렇게 하면 LCP 생존 편향의 위험이 제거되지는 않지만 앞서 언급한 선택 편향의 원인이 될 수 있는 것을 제거할 수 있습니다. 두 속성 모두 사용 설정하려면 브라우저나 리퍼러가 필요합니다.

결론

휴! 많이 했네요. 이 실험을 통해 실험실 테스트에서 SXG 성능을 테스트하는 방법, 실험실 테스트를 통해 긴밀한 피드백 루프에서 성능을 최적화하는 방법, 마지막으로 실제 환경에서 성능을 측정하는 방법을 더 완벽하게 파악할 수 있기를 바랍니다. 이 모든 것을 종합하면 SXG를 최대한 활용하고 사이트와 사용자에게 혜택을 제공하는 데 도움이 됩니다.

SXG 실적을 활용하는 방법에 관한 추가 조언이 있다면 알려주세요. 제안하는 개선사항과 함께 developer.chrome.com에 버그를 신고합니다.

서명된 교환에 관한 자세한 내용은 web.dev 문서Google 검색 문서를 참고하세요.