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

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

서명된 교환을 측정하고 최적화하여 이를 최대한 활용하는 방법

Devin Mullins

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

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

</ph>

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

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

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

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

WebPageTest를 사용하여 SXG 성능을 분석합니다.
분석 단계에서 작동하지 않는 것으로 표시되면 SXG 파이프라인을 디버그합니다.
최적의 max-age 설정 및 렌더링 차단 하위 리소스를 미리 로드하는 것을 포함하여 SXG 미리 가져오기를 위해 페이지를 최적화합니다.
Google 애널리틱스로 적절한 실험 그룹과 통제 그룹을 선택하여 SXG 개선을 측정합니다.

소개

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

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

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

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

분석

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

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

WebPageTest로 이동하여 로그인합니다. 로그인하면 테스트 기록이 저장되어 나중에 쉽게 비교할 수 있습니다.
테스트할 URL을 입력합니다.
고급 구성으로 이동합니다. SXG 테스트에는 고급 구성이 필요하므로 여기서 이를 사용하면 테스트 옵션이 동일한지 확인할 수 있습니다.
테스트 설정 탭에서 연결을 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을 확인합니다.

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

WebPageTest가 비교의 각 측면에 중앙값 LCP를 사용하여 실행을 선택하도록 비교 URL에 &medianMetric=LCP을 추가합니다. 기본값은 속도 지수의 중앙값입니다.

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

SXG 미리 가져오기가 성공하면 'with SXG' 폭포식 구조에는 HTML 행이 포함되어 있지 않으며 하위 리소스 가져오기가 더 빨리 시작됩니다. 예를 들어 '이전'을 및 'After' 여기:

SXG 미리 가져오기가 없는 네트워크 폭포식 구조 첫 번째 행은 1050ms가 소요되는 HTML 가져오기입니다. SXG 미리 가져오기를 사용한 네트워크 폭포식 구조 HTML이 미리 가져오기되어 모든 하위 리소스가 1050ms 전에 가져오기를 시작할 수 있습니다.

디버그

WebPageTest에서 SXG를 미리 가져오는 것으로 표시되면 파이프라인의 모든 단계에서 성공한 것입니다. 최적화 섹션으로 건너뛰어 LCP를 더 개선하는 방법을 알아볼 수 있습니다. 그렇지 않으면 파이프라인에서 실패한 위치와 그 이유를 찾아야 합니다. 방법을 알아보려면 계속 읽어보세요.

게시 중

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

체크표시 (✅)와 애플리케이션/서명된 교환;v=b3의 콘텐츠 유형이 표시된 SXG 검사기

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

크로스 기호 (❌)가 있으면 SXG가 반환되지 않은 것입니다.

크로스 기호 (❌)와 text/html의 콘텐츠 유형이 표시된 SXG 검사기

Cloudflare ASX가 활성화된 경우 크로스 기호 (❌)가 발생하는 가장 큰 이유는 캐시 제어 응답 헤더가 이를 차단하기 때문일 수 있습니다. ASX는 다음 이름의 헤더를 확인합니다.

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

이러한 헤더에 다음 헤더 값이 포함되어 있으면 SXG가 생성되지 않습니다.

private
no-store
no-cache
120 미만의 max-age(120 이상의 s-maxage로 재정의되지 않는 경우)

이러한 경우 ASX는 SXG를 생성하지 않습니다. SXG가 여러 번의 방문과 여러 방문자에 대해 캐시되고 재사용될 수 있기 때문입니다.

크로스 기호(❌)가 있는 또 다른 이유는 Set-Cookie를 제외하고 스테이트풀(Stateful) 응답 헤더 중 하나가 있기 때문일 수 있습니다. ASX는 SXG 사양을 준수하기 위해 Set-Cookie 헤더를 삭제합니다.

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

참고: 앞으로 Vary: Cookie를 사용하는 페이지는 사이트 쿠키가 없는 방문자에게만 표시되므로 SXG에서 지원됩니다. 이 기능은 Chromium에서 구현되며, 완전히 출시되면 Google 검색에서 사용 설정됩니다.

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의 네트워크 탭으로 이동하고 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 캐시 요구사항을 충족하지 못한 것일 수 있습니다. 다음 섹션에서 설명합니다.

수집

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

체크표시 (✅)가 보이면 최적화로 건너뛰어도 됩니다.

요구사항을 충족하지 못하면 크로스 기호 (❌)와 그 이유를 나타내는 경고 메시지가 표시됩니다.

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

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

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

최적화

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

최대-연령

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

이는 성능과 최신 상태 간의 절충이며, 사이트 소유자는 캐시를 통해 SXG에 각 페이지의 특정 요구에 맞게 2분에서 7일 사이의 max-age를 제공할 수 있습니다. 연구 결과를 보면 다음과 같은 결과가 나타났습니다.

실적을 위해 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은 '가장 큰 요소'가 광고 제목이었습니다 하지만 SXG 버전에서는 페이지에 지연 로드 배너를 추가했습니다. 지연 로드 배너는 스크롤해야 볼 수 있는 부분으로 광고 제목을 밀어내며, 새로운 가장 큰 요소가 지연 로드 쿠키 동의 대화상자가 되도록 했습니다. 모든 것이 이전보다 빠르게 렌더링되었지만 레이아웃 변경으로 인해 측정항목이 더 느리게 보고되었습니다.

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

이제 '이후'를 클릭하면 미리 가져온 LCP가 1.3초로 떨어집니다.

SXG 미리 가져오기가 없는 네트워크 폭포식 구조 LCP는 2초입니다. SXG 미리 가져오기를 사용한 네트워크 폭포식 구조 LCP는 1.3초입니다.

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

페이지가 User-Agent에 의해 Vary되지 않습니다 (예: 반응형 디자인 또는 별도의 모바일/데스크톱 URL을 사용하는 경우).
페이지에서 동적 게재를 사용하는 경우 <meta name=supported-media content=...>를 사용하여 페이지에 모바일 또는 데스크톱 전용으로 주석이 추가됩니다.

하위 리소스

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이 다시 크롤링할 때까지 기다린 다음 Core Web Vitals (CWV) 집계를 위해 28일간 기다린 다음 새로운 CWV 수치를 확인하면 됩니다. 하지만 이 기간 동안 다른 모든 변경사항과 섞여 있으면 변경사항을 발견하기 어려울 수 있습니다.

그보다는 '확대'하는 것이 도움이 됩니다. 'SXG는 페이지 조회수의 X% 에 영향을 미쳐 75번째 백분위수에서 LCP를 Y밀리초 향상합니다.'라는 프레임으로 표시합니다.

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

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

를 통해 개인정보처리방침을 정의할 수 있습니다.

'페이지 조회수의 X%'를 측정하는 방법은 현대 연구 섹션을 참고하세요. 'LCP를 Y밀리초 개선하기'가 포함됩니다.

현대 연구

실제 사용자 모니터링 (RUM) 데이터를 볼 때 페이지 로드를 SXG 및 비 SXG로 분할해야 합니다. 이 때, 선택 편향을 방지하기 위해 SXG가 아닌 부분이 SXG의 자격 조건과 일치하도록 표시되는 페이지 로드를 제한하는 것이 중요합니다. 그렇지 않으면 다음 모든 요소가 SXG가 아닌 페이지 로드 집합에만 존재하며 본질적으로 LCP가 다를 수 있습니다.

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

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

'SXG 반사실적'이라는 맞춤 세그먼트 만들기 다음 필터와 함께 AND로 연결됩니다.

referrer 다음으로 시작 https://www.google.
Browser이(가) Chrome과(와) 정확하게 일치함
Browser 버전이 ^(9[8-9]|[0-9]{3}) 정규식과 일치함
isSXG이(가) false과(와) 정확하게 일치함

isSXG이 true와 정확히 일치하는 경우를 제외하고 'SXG'라는 이름의 이 세그먼트의 사본을 만듭니다.

사이트 템플릿에서 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가 채워져야 합니다.

순 이벤트 수가 12.5% 로 표시되는 SXG 세그먼트가 포함된 Google 애널리틱스 이벤트 보고서

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

'제출'을 클릭하면 두 세그먼트의 LCP 분포가 표시됩니다. '75번째 백분위수에서 LCP를 Y밀리초 개선하기'에 대한 Y를 입력해야 합니다.

SXG 반사실적 및 SXG의 LCP 분포를 보여주는 Web Vitals 보고서

주의사항

위의 필터를 모두 적용하면 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가 될 만한 페이지 조회수의 일부 임의 부분이 '홀드백(Holdback)'되며 대신 비 SXG로 게재됩니다. 이렇게 하면 상응하는 사용자, 기기, 시나리오 및 페이지 비교
이러한 홀드백 (반사실적) 페이지 조회는 애널리틱스에서 이와 같이 표시됩니다. 이렇게 하면 대조군의 SXG 페이지 로드를 실험의 SXG 반사실적 항목과 비교할 수 있습니다. 이렇게 하면 SXG 미리 가져오기의 영향을 받지 않는 다른 페이지 로드로 인한 노이즈를 줄일 수 있습니다.

이렇게 하면 LCP 생존 편향의 위험이 제거되지 않더라도 앞서 언급한 선택 편향의 가능한 원인이 제거될 수 있습니다. 두 속성 모두 브라우저 또는 리퍼러를 사용 설정해야 합니다.

결론

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

SXG 성능을 포착하는 방법에 관한 추가 조언이 있으면 알려주시기 바랍니다. 제안된 개선사항을 developer.chrome.com에 신고합니다.

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