서명된 교환을 측정하고 최적화하여 최대한 개선하는 방법
서명된 교환 (SXG)은 페이지 속도를 개선하는 수단으로, 주로 콘텐츠가 포함된 최대 페인트 (LCP)를 포함합니다. 추천 사이트 (현재 Google 검색)가 페이지에 링크를 걸면 사용자가 링크를 클릭하기 전에 브라우저 캐시로 해당 페이지를 미리 가져올 수 있습니다.
미리 가져올 때 페이지를 렌더링하는 주요 경로에 네트워크가 필요 없는 웹페이지를 만들 수 있습니다. 4G 연결에서는 이 페이지 로드가 2.8초에서 0.9초로 줄어듭니다 (나머지 0.9초는 대부분 CPU 사용량임).
현재 SXG를 게시하는 사용자 대부분은 Cloudflare의 사용하기 쉬운 ASX (Automatic Signed Exchanges) 기능을 사용하고 있습니다 (오픈소스 옵션도 있음).
대부분의 경우 이 기능을 사용하도록 설정하는 확인란을 선택하는 것만으로도 위에 표시된 상당한 개선 효과를 얻을 수 있습니다. 파이프라인의 각 단계에서 이러한 SXG가 의도한 대로 작동하는지 확인하고 미리 가져오기를 최대한 활용하도록 페이지를 최적화하기 위해서는 몇 가지 단계를 더 거쳐야 할 수 있습니다.
Cloudflare가 출시된 후 지난 몇 달 동안 저는 다양한 포럼에서 질문을 읽고 답변하며, 사이트에 SXG 배포를 최대한 활용하는 방법에 관해 조언하는 방법을 배웠습니다. 이 게시물은 제가 하는 조언입니다. 다음 단계를 따르세요.
- WebPageTest를 사용하여 SXG 성능을 분석합니다.
- 분석 단계에서 작동하지 않는 것으로 표시되면 SXG 파이프라인을 디버그합니다.
- 최적의
max-age설정 및 렌더링 차단 하위 리소스 미리 로드 등 SXG 미리 가져오기를 위해 페이지를 최적화합니다. - Google 애널리틱스를 사용하여 적절한 실험 및 통제 그룹을 선택하여 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 연결을 설정하고 'Number of Tests to Run(실행할 테스트 수)'을 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을 확인합니다.
테스트가 완료되면 테스트 기록으로 이동하여 두 테스트를 선택한 다음 비교를 클릭합니다.
WebPageTest에서 비교의 양쪽에 중앙값 LCP로 실행을 선택하도록 비교 URL에 &medianMetric=LCP를 추가합니다. (기본값은 속도 색인 기준 중앙값입니다.)
폭포식 구조를 비교하려면 폭포식 구조 불투명도 섹션을 펼치고 슬라이더를 드래그합니다. 동영상을 보려면 슬라이드 설정 조정을 클릭하고 대화상자 내에서 아래로 스크롤한 다음 동영상 보기를 클릭합니다.
SXG 미리 가져오기가 성공하면 'with SXG' 폭포식 구조에 HTML 행이 포함되지 않고 하위 리소스의 가져오기가 더 빨리 시작됩니다. 예를 들어 여기에서 '이전'과 '이후'를 비교해 보세요.
디버그
WebPageTest에 SXG가 프리페치 중이라고 표시되면 파이프라인의 모든 단계에서 성공한 것입니다. 최적화 섹션으로 건너뛰어 LCP를 더욱 개선하는 방법을 알아볼 수도 있습니다. 그렇지 않으면 파이프라인의 어떤 부분에서 실패했는지, 그 이유는 무엇인지 알아내야 합니다. 계속 읽어 가면서 방법을 알아보세요.
게시
페이지가 SXG로 생성되고 있는지 확인합니다. 이렇게 하려면 크롤러로 가장해야 합니다. 가장 쉬운 방법은 SXG 검사기 Chrome 확장 프로그램을 사용하는 것입니다.
확장 프로그램은 SXG 버전을 선호한다는 Accept 요청 헤더로 현재 URL을 가져옵니다. Origin 옆에 체크표시 (✅)가 표시되면 SXG가 반환되었다는 의미입니다. 색인 생성 섹션으로 건너뛰어도 됩니다.
X표 (❌)가 표시되면 SXG가 반환되지 않았다는 의미입니다.
Cloudflare ASX가 사용 설정된 경우 교차 표시 (❌)가 발생하는 가장 큰 이유는 캐시 제어 응답 헤더로 인해 차단되기 때문입니다. ASX는 다음 이름의 헤더를 확인합니다.
Cache-ControlCDN-Cache-ControlSurrogate-ControlCloudflare-CDN-Cache-Control
이러한 헤더 중 하나라도 포함된 경우 SXG가 생성되지 않습니다.
privateno-storeno-cache- 120보다 작은
max-age(s-maxage에 의해 재정의되지 않는 경우 120 이상)
이러한 경우 ASX는 SXG를 만들지 않습니다. 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 -verify -uri $URL
SXG가 존재하고 유효하면 사람이 읽을 수 있는 SXG 출력이 표시됩니다. 그렇지 않으면 오류 메시지가 표시됩니다.
색인 생성
Google 검색에서 SXG의 색인이 생성되었는지 확인합니다. Chrome DevTools를 열고 페이지에 대해 Google 검색을 실행합니다. SXG로 색인이 생성된 경우 Google의 페이지 링크에는 webpkgcache.com의 사본을 가리키는 data-sxg-url가 포함됩니다.
Google 검색에서 사용자가 결과를 클릭할 가능성이 높다고 판단하는 경우 결과를 미리 가져옵니다.
<link> 요소는 브라우저에 SXG를 미리 가져오기 캐시로 다운로드하도록 지시합니다. 사용자가 <a> 요소를 클릭하면 브라우저는 캐시된 SXG를 사용하여 페이지를 렌더링합니다.
DevTools의 Network 탭으로 이동하고 webpkgcache가 포함된 URL을 검색하여 미리 가져오기의 증거를 확인할 수도 있습니다.
<a>가 webpkgcache.com을 가리키는 경우 서명된 교환의 Google 검색 색인이 작동하고 있다는 의미입니다. 처리 섹션으로 건너뛸 수 있습니다.
또는 SXG를 사용 설정한 이후 Google에서 페이지를 아직 재크롤링하지 않았을 수 있습니다. Google Search Console URL 검사 도구를 사용해 보세요.
digest: mi-sha256-03=... 헤더가 있으면 Google이 SXG 버전을 성공적으로 크롤링했음을 나타냅니다.
digest 헤더가 없으면 SXG가 Googlebot에 제공되지 않았거나 SXG를 사용 설정한 이후 색인이 업데이트되지 않은 것일 수 있습니다.
SXG가 크롤링되었지만 여전히 연결되지 않는다면 SXG 캐시 요구사항을 충족하지 못한 것일 수 있습니다. 이에 대해서는 다음 섹션에서 다룹니다.
데이터 수집
Google 검색은 SXG의 색인을 생성할 때 사본을 Google SXG 캐시로 전송하여 캐시 요구사항에 따라 유효성을 검사합니다. Chrome 확장 프로그램에는 다음과 같은 결과가 표시됩니다.
체크표시 (✅)가 표시되면 최적화 도구로 건너뛸 수 있습니다.
요구사항을 충족하지 못하는 경우 교차 표시 (❌)와 그 이유를 나타내는 경고 메시지가 표시됩니다.
이 경우 페이지는 SXG를 사용 설정하기 전과 동일하게 작동합니다. Google에서는 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 미리 가져오기를 사용한 결과 중앙값을 비교했습니다. 아래의 이후를 클릭합니다.
미리 가져오기가 작동하는 것을 확인했습니다. HTML이 주요 경로에서 삭제되므로 모든 하위 리소스를 더 일찍 로드할 수 있습니다. 하지만 LCP(녹색 점선)는 2초에서 2.1초로 증가했습니다.
이것을 진단하기 위해 필름 스트립을 살펴봤습니다. SXG에서 페이지가 다르게 렌더링되는 것으로 확인되었습니다. 일반 HTML의 경우 Chrome은 LCP의 '가장 큰 요소'가 제목이라고 판단했습니다. 그러나 SXG 버전에서는 페이지에 지연 로드 배너를 추가했습니다. 지연 로드 배너는 광고 제목을 스크롤해야 볼 수 있는 부분에 푸시하여 가장 큰 새로운 요소가 지연 로드 쿠키 동의 대화상자가 되도록 했습니다. 모든 것이 이전보다 빠르게 렌더링되었지만 레이아웃 변경 시 측정항목에서 더 느리게 보고되었습니다.
자세히 알아본 결과 레이아웃 차이가 발생하는 이유는 페이지가 User-Agent에 따라 다르고 로직에 오류가 있기 때문입니다. SXG 크롤링 헤더에 모바일로 표시되어 있지만 데스크톱 페이지를 게재하고 있었습니다. 이 문제가 해결되면 브라우저가 페이지 제목을 다시 가장 큰 요소로 올바르게 식별했습니다.
이제 '이후'를 클릭하면 미리 가져온 LCP가 1.3초로 감소하는 것을 확인할 수 있습니다.
SXG는 모든 폼 팩터에 사용 설정됩니다. 이에 대비하려면 다음 중 하나에 해당하는지 확인하세요.
- 페이지가
User-Agent만큼Vary되지 않습니다 (예: 반응형 디자인 또는 별도의 모바일/데스크톱 URL 사용). - 페이지에서 동적 게재를 사용하는 경우
<meta name=supported-media content=...>를 사용하여 자체 모바일 또는 데스크톱 전용으로 주석이 달립니다.
하위 리소스
SXG를 사용하면 HTML과 함께 하위 리소스 (이미지 포함)를 미리 가져올 수 있습니다. Cloudflare ASX는 HTML에서 동일 출처 (퍼스트 파티) <link rel=preload> 요소를 스캔하여 SXG 호환 링크 헤더로 변환합니다. 여기와 여기에서 소스 코드를 자세히 알아보세요.
제대로 작동하면 Google 검색의 추가 미리 가져오기가 표시됩니다.
LCP에 최적화하려면 폭포식 구조를 자세히 살펴보고 가장 큰 요소를 렌더링하는 주요 경로에 어떤 리소스가 있는지 파악하세요. 미리 가져올 수 없는 경우 중요 경로에서 삭제할 수 있는지 고려하세요. 로드가 완료될 때까지 페이지를 숨기는 스크립트가 있는지 주의하세요.
Google SXG 캐시는 최대 20개의 하위 리소스 미리 로드를 허용하며 ASX는 이 한도를 초과하지 않도록 보장합니다. 하지만 하위 리소스 미리 로드를 너무 많이 추가할 위험이 있습니다. 크로스 사이트 추적을 방지하기 위해 브라우저는 미리 로드된 하위 리소스의 모든 가져오기가 완료된 경우에만 미리 로드된 하위 리소스를 사용합니다. 하위 리소스가 많을수록 사용자가 클릭하여 페이지로 이동하기 전에 하위 리소스가 모두 미리 가져오기를 완료할 가능성이 낮아집니다.
SXG 검사기는 현재 하위 리소스를 확인하지 않습니다. 디버그하려면 그동안 curl 또는 dump-signedexchange를 사용하세요.
측정
WebPageTest에서 LCP 개선을 최적화한 후에는 SXG 미리 가져오기가 사이트의 전체 성능에 미치는 영향을 측정하는 데 유용합니다.
서버 측 측정항목
TTFB (Time to First Byte)와 같은 서버 측 측정항목을 측정할 때는 사이트에서 형식을 허용하는 크롤러에만 SXG를 제공한다는 점에 유의해야 합니다. 봇이 아닌 실제 사용자의 요청으로 TTFB의 측정을 제한합니다. SXG를 생성하면 크롤러 요청의 TTFB가 증가할 수 있지만, 이는 방문자 경험에는 영향을 미치지 않습니다.
클라이언트 측 측정항목
SXG는 클라이언트 측 측정항목, 특히 LCP에서 가장 큰 속도 이점을 제공합니다. 이러한 영향을 측정할 때는 Cloudflare ASX를 사용 설정하고 Googlebot에서 다시 크롤링할 때까지 기다린 다음 CWV (Core Web Vitals) 집계를 위해 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 자격 조건과 일치하게 됩니다. 그렇지 않으면 다음의 모든 요소가 SXG가 아닌 페이지 로드 집합에만 존재하게 되어 LCP가 본질적으로 다를 수 있습니다.
- iOS 기기: 해당 기기를 사용하는 사용자 간 하드웨어 또는 네트워크 속도의 차이로 인해 발생합니다.
- 이전 Chromium 브라우저: 동일한 이유로 인해
- 데스크톱 기기: 같은 이유 또는 페이지 레이아웃에 따라 '가장 큰 요소'가 다르게 선택되기 때문입니다.
- 동일 사이트 탐색 (사이트의 링크를 따라가는 방문자): 이전 페이지 로드 시 캐시된 하위 리소스를 재사용할 수 있기 때문입니다.
Google 애널리틱스 (UA)에서 범위가 '조회'인 맞춤 측정기준 2개를 만듭니다. 하나는 'isSXG'이고 다른 하나는 '리퍼러'입니다. 기본 제공되는 '소스' 측정기준에는 세션 범위가 있으므로 동일 사이트 탐색을 제외하지 않습니다.
다음 필터를 AND로 조합하여 'SXG 반사실적'이라는 이름의 맞춤 세그먼트를 만듭니다.
referrer다음으로 시작https://www.google.Browser이(가)Chrome과(와) 정확히 일치함Browser버전이 정규식^(9[8-9]|[0-9]{3})과(와) 일치함isSXG이(가)false과(와) 정확히 일치함
이 세그먼트의 사본을 만들고 이름을 'SXG'로 지정합니다. 단, isSXG은(는) true과(와) 정확히 일치합니다.
사이트 템플릿에서 Google 애널리틱스 스니펫 위에 다음 스니펫을 추가합니다. 다음은 SXG를 생성할 때 ASX가 false를 true로 변경하는 특수 구문입니다.
<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 반사실적' 및 'SXG'를 선택합니다.
'제출'을 클릭하면 두 세그먼트의 LCP 분포가 표시됩니다. 이렇게 하면 '75번째 백분위수에서 LCP를 Y밀리초 개선'하기 위한 Y가 채워집니다.
주의사항
위의 필터를 모두 적용하면 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를 사용 중지하는 것입니다. 예를 들어 CDN-Cache-Control: no-store 헤더를 설정하여 Cloudflare ASX가 SXG를 생성하지 않도록 할 수 있습니다. 권장하지 않습니다.
다른 연구 방법보다 표본 선택 편향의 위험이 더 높을 가능성이 큽니다. 예를 들어, 사이트의 홈페이지 또는 유사한 인기 있는 URL을 대조군과 실험군에 포함시켰는지 여부에 따라 결과가 크게 달라질 수 있습니다.
홀드백 연구
영향을 측정하는 가장 좋은 방법은 홀드백 연구를 수행하는 것입니다. 유감스럽게도 현재 이러한 종류의 테스트는 수행할 수 없습니다. 향후 이러한 테스트를 지원할 예정입니다.
홀드백 연구에는 다음과 같은 속성이 있습니다.
- 실험 그룹에서 SXG에 해당하는 페이지 조회수의 임의 비율이 '홀드백'되고 대신 SXG가 아닌 콘텐츠로 게재됩니다. 이렇게 하면 동등한 사용자, 기기, 시나리오 및 페이지 간에 '비교'가 가능합니다.
- 이러한 홀드백 (반사실적) 페이지 조회수는 애널리틱스에서 이와 같이 라벨이 지정됩니다. 이렇게 하면 데이터를 '확대'하여 볼 수 있고 대조군의 SXG 페이지 로드를 실험의 SXG 반사실적과 비교할 수 있습니다. 이렇게 하면 SXG 미리 가져오기의 영향을 받지 않는 다른 페이지 로드의 노이즈가 줄어듭니다.
이렇게 하면 LCP 생존 편향의 위험이 제거되지는 않지만 앞서 언급한 선택 편향의 가능한 원인을 제거할 수 있습니다. 두 속성 모두 사용 설정하려면 브라우저나 리퍼러가 필요합니다.
결론
휴! 많은 내용이었군요. 이 실험을 통해 실험실 테스트에서 SXG 성능을 테스트하는 방법, 실험실 테스트로 긴밀한 피드백 루프에서 성능을 최적화하는 방법, 마지막으로 실제 환경에서 성능을 측정하는 방법을 보다 완벽하게 파악할 수 있기를 바랍니다. 이 모든 것을 종합하면 SXG를 최대한 활용하고 사이트와 사용자에게 혜택을 제공하는 데 도움이 됩니다.
SXG 실적을 얻는 방법에 관한 추가 조언이 있으면 알려주세요. 제안하는 개선사항을 포함하여 developer.chrome.com에 버그를 신고합니다.
서명된 교환에 관한 자세한 내용은 web.dev 문서 및 Google 검색 문서를 참고하세요.