Mengoptimalkan LCP menggunakan Signed HTTP Exchange

Cara mengukur dan mengoptimalkan Signed HTTP Exchange untuk mendapatkan peningkatan maksimal

Signed HTTP Exchange (SXG) adalah cara untuk meningkatkan kecepatan halaman—terutama Largest Contentful Paint (LCP). Saat merujuk situs (saat ini Google Penelusuran) ke sebuah halaman, situs dapat mengambil data terlebih dahulu ke cache browser sebelum pengguna mengklik link.

Anda dapat membuat halaman web yang, saat pengambilan data, tidak memerlukan jaringan di jalur penting untuk merender halaman. Pada koneksi 4G, pemuatan halaman ini berubah dari 2,8 detik menjadi 0,9 detik (0,9 detik sisanya sebagian besar karena penggunaan CPU):

Sebagian besar pengguna yang memublikasikan SXG saat ini menggunakan fitur Automatic Signed Exchange (ASX) Cloudflare yang mudah digunakan (meskipun opsi open source juga tersedia):

Dalam banyak kasus, mencentang kotak untuk mengaktifkan fitur ini sudah cukup untuk mendapatkan jenis peningkatan substansial seperti yang ditampilkan di atas. Terkadang, ada beberapa langkah lagi untuk memastikan SXG ini berfungsi sebagaimana mestinya di setiap tahap pipeline, dan untuk mengoptimalkan halaman agar dapat sepenuhnya memanfaatkan pengambilan data.

Dalam beberapa bulan terakhir sejak peluncuran Cloudflare, saya telah membaca dan menjawab pertanyaan di berbagai forum serta mempelajari cara memberikan saran ke situs tentang cara memastikan situs tersebut mendapatkan hasil maksimal dari deployment SXG. Postingan ini adalah kumpulan saran saya. Saya akan memandu Anda melakukan langkah-langkah untuk:

• Menganalisis performa SXG menggunakan WebPageTest.
• Lakukan debug pada pipeline SXG jika langkah Analisis menunjukkan bahwa pipeline tersebut tidak berfungsi.
• Optimalkan halaman untuk pengambilan data SXG, termasuk menyetel max-age yang optimal dan pramuat subresource yang memblokir render.
• Ukur peningkatan SXG menggunakan Google Analytics dengan memilih grup eksperimen dan kontrol yang sesuai.

Pengantar

SXG adalah file yang berisi URL, serangkaian header respons HTTP, dan isi respons—semuanya ditandatangani secara kriptografis oleh sertifikat Web PKI. Saat memuat SXG, browser akan memverifikasi semua hal berikut:

• SXG belum habis masa berlakunya.
• Tanda tangan cocok dengan URL, header, isi, dan sertifikat.
• Sertifikat valid dan cocok dengan URL.

Jika verifikasi gagal, browser akan meninggalkan SXG dan mengambil URL yang ditandatangani. Jika verifikasi berhasil, browser akan memuat respons bertanda tangan, dan memperlakukannya seolah-olah berasal langsung dari URL yang ditandatangani. Hal ini memungkinkan SXG dihosting ulang di server mana pun selama belum habis masa berlakunya atau diubah sejak ditandatangani.

Untuk Google Penelusuran, SXG memungkinkan pengambilan data halaman di hasil penelusurannya. Untuk halaman yang mendukung SXG, Google Penelusuran dapat mengambil data salinan halaman yang di-cache, yang dihosting di webpkgcache.com. URL webpkgcache.com ini tidak memengaruhi tampilan atau perilaku halaman karena browser mematuhi URL asli yang ditandatangani. Pengambilan data dapat membuat halaman Anda dimuat lebih cepat.

Analisis

Untuk melihat manfaat SXG, mulailah dengan menggunakan alat lab untuk menganalisis performa SXG dalam kondisi berulang. Anda dapat menggunakan WebPageTest untuk membandingkan waterfall—dan LCP—dengan dan tanpa pengambilan data SXG.

Buat pengujian tanpa SXG sebagai berikut:

• Buka WebPageTest dan login. Login akan menyimpan histori pengujian Anda untuk perbandingan yang lebih mudah nanti.
• Masukkan URL yang ingin Anda uji.
• Buka Konfigurasi Lanjutan. (Anda memerlukan Konfigurasi Lanjutan untuk pengujian SXG, jadi menggunakannya di sini akan membantu memastikan opsi pengujiannya sama.)
• Di tab Test Settings, sebaiknya setel Koneksi ke 4G dan tingkatkan "Number of Tests to Run" ke 7.
• Klik Start Test.

Buat pengujian dengan SXG menggunakan langkah yang sama seperti di atas, tetapi sebelum mengklik Start Test, buka tab Script, tempel skrip WebPageTest berikut, lalu ubah kedua URL navigate sesuai petunjuk:

// 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

Untuk URL navigate pertama, jika halaman Anda belum muncul di hasil Google Penelusuran, Anda dapat menggunakan halaman pengambilan data ini untuk membuat halaman hasil penelusuran palsu untuk tujuan ini.

Untuk menentukan URL navigate kedua, kunjungi halaman menggunakan ekstensi Chrome Validator SXG, lalu klik ikon ekstensi untuk melihat URL cache:

Setelah pengujian selesai, buka Test History, pilih kedua pengujian tersebut, lalu klik Compare:

Tambahkan &medianMetric=LCP ke URL perbandingan sehingga WebPageTest memilih proses yang dijalankan dengan LCP median untuk setiap sisi perbandingan. (Nilai defaultnya adalah median menurut Indeks Kecepatan.)

Untuk membandingkan waterfall, luaskan bagian Opasitas Waterfall dan tarik penggeser. Untuk melihat video, klik Sesuaikan Setelan Setrip Film, scroll ke bawah dalam dialog tersebut, lalu klik Lihat Video.

Jika pengambilan data SXG berhasil, Anda akan melihat bahwa waterfall "dengan SXG" tidak menyertakan baris untuk HTML, dan pengambilan untuk subresource dimulai lebih cepat. Misalnya, bandingkan "Sebelum" dan "Sesudah" di sini:

Men-debug

Jika WebPageTest menunjukkan bahwa SXG sedang diambil data, berarti SXG telah berhasil di semua langkah pipelinenya. Anda dapat langsung ke bagian Optimalkan untuk mempelajari cara meningkatkan LCP lebih lanjut. Jika tidak, Anda harus mencari tahu di mana kegagalannya pada pipeline dan alasannya; baca terus untuk mempelajari caranya.

Memublikasikan

Pastikan halaman Anda dibuat sebagai SXG. Untuk melakukannya, Anda harus berpura-pura menjadi crawler. Cara termudah adalah menggunakan ekstensi Chrome Validator SXG:

Ekstensi mengambil URL saat ini dengan header permintaan Accept yang menyatakan bahwa ekstensi lebih memilih versi SXG. Jika Anda melihat tanda centang (✅) di samping Origin, artinya SXG telah ditampilkan. Anda dapat langsung melanjutkan ke bagian Pengindeksan.

Jika Anda melihat tanda silang (❌), artinya SXG tidak dikembalikan:

Jika Cloudflare ASX diaktifkan, maka kemungkinan besar tanda silang (❌) adalah karena header respons kontrol cache mencegahnya. ASX melihat header dengan nama berikut:

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

Jika salah satu header ini berisi salah satu nilai header berikut, SXG tidak akan dihasilkan:

• private
• no-store
• no-cache
• max-age kurang dari 120, kecuali jika diganti oleh s-maxage yang lebih besar dari atau sama dengan 120

ASX tidak membuat SXG dalam kasus ini karena SXG dapat di-cache dan digunakan kembali untuk beberapa kunjungan dan beberapa pengunjung.

Kemungkinan alasan lainnya untuk tanda silang (❌) adalah adanya salah satu header respons stateful ini, kecuali Set-Cookie. ASX menghapus header Set-Cookie untuk mematuhi spesifikasi SXG.

Alasan lain yang mungkin adalah adanya header respons Vary: Cookie. Googlebot mengambil SXG tanpa kredensial pengguna dan dapat menayangkannya ke banyak pengunjung. Jika Anda menayangkan HTML yang berbeda kepada pengguna yang berbeda berdasarkan cookie mereka, pengguna tersebut dapat melihat pengalaman yang salah seperti tampilan logout.

Sebagai alternatif untuk ekstensi Chrome, Anda dapat menggunakan alat seperti curl:

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

atau dump-signedexchange:

dump-signedexchange -verify -uri $URL

Jika SXG ada dan valid, Anda akan melihat cetakan SXG yang dapat dibaca manusia. Jika tidak, Anda akan melihat pesan error.

Pengindeksan

Pastikan SXG Anda berhasil diindeks oleh Google Penelusuran. Buka Chrome DevTools, lalu lakukan Google Penelusuran untuk halaman Anda. Jika halaman telah diindeks sebagai SXG, link Google ke halaman Anda akan menyertakan data-sxg-url yang mengarah ke salinan webpkgcache.com:

Jika Google Penelusuran menganggap pengguna kemungkinan akan mengklik hasil, Google Penelusuran juga akan mengambil data hasil tersebut:

Elemen <link> memerintahkan browser untuk mendownload SXG ke cache pengambilan data. Saat pengguna mengklik elemen <a>, browser akan menggunakan SXG yang di-cache tersebut untuk merender halaman.

Anda juga dapat melihat bukti pengambilan data dengan membuka tab Jaringan di DevTools dan menelusuri URL yang berisi webpkgcache.

Jika <a> mengarah ke webpkgcache.com, artinya pengindeksan Google Penelusuran untuk pertukaran bertanda tangan berfungsi. Anda dapat langsung membuka bagian Proses Transfer.

Atau, mungkin Google belum meng-crawl ulang halaman Anda sejak Anda mengaktifkan SXG. Coba Alat Inspeksi URL Google Search Console:

Munculnya header digest: mi-sha256-03=... menunjukkan bahwa Google berhasil meng-crawl versi SXG.

Jika header digest tidak ada, hal ini dapat menjadi indikasi bahwa SXG tidak ditayangkan ke Googlebot, atau indeks belum diperbarui sejak Anda mengaktifkan SXG.

Jika SXG berhasil di-crawl, tetapi masih belum ditautkan, berarti SXG tersebut mungkin gagal memenuhi persyaratan cache SXG. Hal ini dibahas di bagian berikutnya.

Penyerapan

Saat mengindeks SXG, Google Penelusuran akan mengirimkan salinannya ke Cache SXG Google, yang memvalidasinya berdasarkan persyaratan cache. Ekstensi Chrome menampilkan hasil:

Jika melihat tanda centang (✅), Anda dapat langsung membuka bagian Optimalkan.

Jika gagal memenuhi persyaratan, Anda akan melihat tanda silang (❌) dan pesan peringatan yang menunjukkan alasannya:

Dalam hal ini, halaman akan berfungsi seperti sebelum mengaktifkan SXG. Google akan menautkan ke halaman di host aslinya tanpa pengambilan data SXG.

Jika salinan dalam cache telah habis masa berlakunya dan sedang diambil kembali di latar belakang, Anda akan melihat jam pasir (⌛):

Dokumen developer Google di SXG juga memiliki petunjuk untuk melakukan kueri cache secara manual.

Pengoptimalan

Jika ekstensi Chrome Validator SXG menampilkan semua tanda centang (✅), Anda memiliki SXG yang dapat ditampilkan kepada pengguna. Lanjutkan membaca untuk mengetahui cara mengoptimalkan halaman web sehingga Anda mendapatkan peningkatan LCP yang maksimal dari SXG.

max-age

Saat masa berlaku SXG habis, Cache SXG Google akan mengambil salinan baru di latar belakang. Selagi menunggu pengambilan tersebut, pengguna diarahkan ke halaman di host aslinya, yang tidak dilakukan pengambilan data. Semakin lama Anda menetapkan Cache-Control: max-age, semakin jarang pengambilan latar belakang ini terjadi, sehingga semakin sering LCP dapat dikurangi dengan pengambilan data.

Hal ini merupakan kompromi antara performa dan kesegaran, dan cache memungkinkan pemilik situs memberikan batas usia maksimum antara 2 menit hingga 7 hari bagi SXG, agar sesuai dengan kebutuhan khusus setiap halaman. Secara anekdot, kami menemukan bahwa:

• max-age=86400 (1 hari) atau lebih lama berfungsi dengan baik untuk performa
• max-age=120 (2 menit) tidak

Kita berharap bisa mempelajari lebih lanjut nilai di antara keduanya, selagi kita mempelajari data lebih lanjut.

user-agent

Satu kali, saya melihat peningkatan LCP saat menggunakan SXG yang diambil terlebih dahulu. Saya menjalankan WebPageTest, membandingkan hasil median tanpa dan dengan pengambilan data SXG. Klik Setelah di bawah:

Saya melihat bahwa pengambilan data berfungsi. HTML dihapus dari jalur penting dan, dengan demikian, semua subresource dapat dimuat lebih awal. Namun, LCP—garis putus-putus hijau tersebut—meningkat dari 2 detik menjadi 2,1 detik.

Untuk mendiagnosis hal ini, saya melihat potongan film. Saya mendapati bahwa halaman dirender secara berbeda di SXG. Dalam HTML biasa, Chrome menentukan bahwa "elemen terbesar" untuk LCP adalah judulnya. Namun, dalam versi SXG, halaman menambahkan banner yang dimuat lambat, yang mendorong judul ke paruh bawah dan menyebabkan elemen baru terbesar adalah dialog izin cookie yang dimuat lambat. Semuanya dirender lebih cepat dari sebelumnya, tetapi perubahan tata letak menyebabkan metrik melaporkannya sebagai lebih lambat.

Kami mencari tahu lebih lanjut dan menemukan alasan perbedaan dalam tata letak adalah karena halaman bervariasi menurut User-Agent, dan terdapat error dalam logika. URL tersebut menayangkan halaman desktop meskipun header crawl SXG menunjukkan halaman seluler. Setelah masalah ini diperbaiki, browser kembali mengidentifikasi judul halaman sebagai elemen terbesarnya.

Sekarang, mengklik "Setelah", saya melihat bahwa LCP yang diambil data turun menjadi 1,3 detik:

SXG diaktifkan untuk semua faktor bentuk. Untuk mempersiapkan hal itu, pastikan salah satu kondisi berikut terpenuhi:

• Halaman Anda tidak Vary pada User-Agent (misalnya, menggunakan desain responsif atau URL seluler/desktop terpisah).
• Jika menggunakan penayangan dinamis di halaman Anda, halaman tersebut menganotasinya sendiri sebagai khusus seluler atau desktop menggunakan <meta name=supported-media content=...>.

Sub-resource

SXG dapat digunakan untuk mengambil data subresource (termasuk gambar) bersama dengan HTML. Cloudflare ASX akan memindai HTML untuk menemukan elemen <link rel=preload> origin yang sama (pihak pertama) dan mengonversinya menjadi header Link yang kompatibel dengan SXG. Detail dalam kode sumber di sini dan di sini.

Jika berfungsi, Anda akan melihat pengambilan data tambahan dari Google Penelusuran:

Untuk mengoptimalkan LCP, perhatikan waterfall Anda dengan cermat, dan cari tahu resource mana yang berada di jalur penting untuk merender elemen terbesar. Jika tidak dapat diambil data, pertimbangkan apakah keduanya dapat diambil dari jalur penting. Cari skrip yang menyembunyikan halaman hingga selesai dimuat.

Cache SXG Google memungkinkan hingga 20 pramuat subresource dan ASX memastikan bahwa batas ini tidak terlampaui. Namun, ada risiko menambahkan terlalu banyak pramuat subresource. Browser hanya akan menggunakan sub-resource yang dimuat sebelumnya jika semuanya telah selesai mengambil, untuk mencegah pelacakan lintas situs. Semakin banyak subresource yang ada, semakin kecil kemungkinan semuanya selesai melakukan pengambilan data sebelum pengguna mengklik ke halaman Anda.

Validator SXG saat ini tidak memeriksa subresource; sementara itu, untuk melakukan debug, gunakan curl atau dump-signedexchange.

Ukur

Setelah mengoptimalkan peningkatan LCP di WebPageTest, sebaiknya ukur dampak pengambilan data SXG terhadap keseluruhan performa situs Anda.

Metrik sisi server

Saat mengukur metrik sisi server seperti Time to First Byte (TTFB), penting untuk diperhatikan bahwa situs Anda hanya menayangkan SXG ke crawler yang menerima format tersebut. Batasi pengukuran TTFB Anda ke permintaan yang berasal dari pengguna sebenarnya, dan bukan bot. Anda mungkin mendapati bahwa membuat SXG meningkatkan TTFB untuk permintaan crawler, tetapi ini tidak berdampak pada pengalaman pengunjung Anda.

Metrik sisi klien

SXG memberikan manfaat paling cepat untuk metrik sisi klien, terutama LCP. Saat mengukur dampaknya, Anda dapat mengaktifkan Cloudflare ASX, tunggu hingga di-crawl ulang oleh Googlebot, tunggu 28 hari tambahan untuk agregasi Data Web Inti (CWV), lalu lihat angka CWV baru Anda. Namun, perubahan itu mungkin sulit dikenali jika tercampur di antara semua perubahan lain selama jangka waktu ini.

Sebaliknya, saya merasa akan sangat membantu jika Anda "memperbesar" pemuatan halaman yang berpotensi terpengaruh, dan membingkainya sebagai, "SXG memengaruhi X% kunjungan halaman, meningkatkan LCP-nya sebesar Y milidetik pada persentil ke-75".

Saat ini, pengambilan data SXG hanya terjadi dalam kondisi tertentu:

• Browser Chromium (misalnya, Chrome atau Edge kecuali di iOS), versi M98 atau yang lebih baru
• Referer: google.com atau domain penelusuran Google lainnya. (Perhatikan bahwa di Google Analytics, tag rujukan berlaku untuk semua kunjungan halaman di sesi, sedangkan pengambilan data SXG hanya berlaku untuk kunjungan halaman pertama, yang ditautkan langsung dari Google Penelusuran.)

Baca Bagian studi kontemporer untuk mengetahui cara mengukur "X% kunjungan halaman" dan "meningkatkan LCP sebesar Y milidetik".

Studi kontemporer

Saat melihat data pemantauan pengguna sebenarnya (RUM), Anda harus membagi pemuatan halaman menjadi SXG dan non-SXG. Saat melakukannya, sangat penting untuk membatasi kumpulan pemuatan halaman yang Anda lihat, sehingga sisi non-SXG cocok dengan kondisi kelayakan untuk SXG, guna menghindari bias pemilihan. Jika tidak, semua hal berikut hanya akan ada di kumpulan pemuatan halaman non-SXG, yang mungkin memiliki LCP yang berbeda:

• Perangkat iOS: karena perbedaan kecepatan hardware atau jaringan di antara pengguna yang memiliki perangkat tersebut.
• Browser Chromium lama: karena alasan yang sama.
• Perangkat desktop: karena alasan yang sama atau karena tata letak halaman menyebabkan "elemen terbesar" yang berbeda dipilih.
• Navigasi situs yang sama (pengunjung yang mengikuti link dalam situs): karena mereka dapat menggunakan kembali subresource yang di-cache dari pemuatan halaman sebelumnya.

Di Google Analytics (UA), buat dua dimensi kustom dengan cakupan "Hit", satu bernama "isSXG" dan satu lagi bernama "perujuk". (Dimensi "Sumber" bawaan memiliki cakupan sesi, sehingga tidak mengecualikan navigasi situs yang sama.)

Buat segmen kustom bernama "SXG kontrafaktual" dengan filter berikut DAN digabungkan:

• referrer diawali dengan https://www.google.
• Browser sama persis dengan Chrome
• Browser Versi cocok dengan ekspresi reguler ^(9[8-9]|[0-9]{3})
• isSXG sama persis dengan false

Buat salinan segmen ini, bernama "SXG", kecuali dengan isSXG sama persis dengan true.

Di template situs, tambahkan cuplikan berikut di atas cuplikan Google Analytics. Ini adalah sintaksis khusus yang akan diubah ASX false menjadi true saat menghasilkan SXG:

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

Sesuaikan skrip pelaporan Google Analytics Anda seperti yang direkomendasikan untuk mencatat LCP. Jika Anda menggunakan gtag.js, ubah perintah 'config' untuk menetapkan dimensi kustom (ganti 'dimension1' dan 'dimension2' dengan nama yang diizinkan Google Analytics):

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

Jika Anda menggunakan analytics.js, ubah perintah 'create' seperti yang didokumentasikan di sini.

Setelah menunggu beberapa hari untuk mengumpulkan beberapa data, buka laporan Peristiwa Google Analytics dan tambahkan perincian untuk segmen SXG. Kolom ini harus mengisi X untuk "SXG memengaruhi X% kunjungan halaman":

Terakhir, buka Laporan Data Web, pilih "Pilih segmen", lalu pilih "SXG kontrafaktual" dan "SXG".

Klik "Kirim", dan Anda akan melihat distribusi LCP untuk kedua segmen. Perintah ini akan mengisi Y untuk "meningkatkan LCP sebesar Y milidetik pada persentil ke-75":

Peringatan

Setelah Anda menerapkan semua filter di atas, pemuatan halaman kontrafaktual SXG harus terdiri dari hal-hal seperti berikut:

• Cache tidak ditemukan: Jika Cache SXG Google tidak memiliki salinan SXG baru untuk URL yang ditentukan, cache tersebut akan dialihkan ke URL asli di situs Anda.
• Jenis hasil lainnya: Saat ini, Google Penelusuran hanya mendukung SXG untuk hasil web standar dan beberapa jenis lainnya. Bagian lainnya, seperti Cuplikan Pilihan dan Carousel Berita Utama, akan ditautkan ke URL asli di situs Anda.
• URL yang tidak memenuhi syarat: Jika beberapa halaman di situs Anda tidak memenuhi syarat untuk SXG (mis. karena tidak dapat di-cache), halaman tersebut dapat muncul di kumpulan ini.

Mungkin masih ada bias yang tersisa antara pemuatan halaman SXG dan kumpulan pemuatan halaman non-SXG di atas, tetapi besaran tersebut seharusnya lebih kecil daripada bias yang disebutkan di bagian atas Bagian studi kontemporer. Misalnya, mungkin halaman yang tidak dapat di-cache lebih lambat atau lebih cepat dibandingkan halaman yang dapat di-cache. Jika Anda menduga hal ini dapat menjadi masalah, pertimbangkan untuk melihat data yang terbatas pada URL tertentu yang memenuhi syarat SXG untuk melihat apakah hasilnya cocok dengan keseluruhan studi.

Jika situs Anda memiliki beberapa halaman AMP, halaman tersebut mungkin tidak akan melihat peningkatan performa karena pengaktifan SXG, karena halaman tersebut dapat diambil datanya dari Google Penelusuran. Pertimbangkan untuk menambahkan filter guna mengecualikan halaman tersebut, untuk lebih "memperbesar" perubahan yang relevan.

Terakhir, meskipun dengan mengatasi semua bias pemilihan, ada risiko bahwa bias keberlangsungan dapat membuat peningkatan LCP terlihat seperti penurunan dalam statistik RUM. Artikel ini sangat tepat dalam menjelaskan risiko tersebut, dan menyarankan untuk melihat beberapa bentuk metrik pengabaian guna mendeteksi apakah hal ini terjadi.

Sebelum/setelah studi

Untuk menguatkan hasil dari studi kontemporer, sebaiknya lakukan perbandingan LCP sebelum dan sesudah mengaktifkan SXG. Jangan batasi kunjungan halaman pada SXG, untuk menghilangkan potensi bias yang disebutkan di atas. Sebagai gantinya, lihat hasil yang memenuhi syarat untuk SXG—definisi segmen di atas, tetapi tanpa batasan isSXG.

Perhatikan bahwa Google Penelusuran mungkin memerlukan waktu hingga beberapa minggu untuk meng-crawl ulang semua halaman di situs Anda guna mengidentifikasi bahwa SXG telah diaktifkan untuk halaman tersebut. Dalam beberapa minggu tersebut, ada potensi bias lain yang mungkin terjadi:

• Rilis browser baru atau peningkatan hardware pengguna dapat mempercepat pemuatan halaman.
• Peristiwa besar seperti hari libur dapat mendistorsi traffic dari biasanya.

Akan sangat membantu untuk melihat keseluruhan LCP persentil ke-75 sebelum dan sesudahnya, untuk mengonfirmasi studi di atas. Mempelajari sebagian populasi tidak selalu memberi tahu kita tentang populasi secara keseluruhan. Misalnya, SXG meningkatkan 10% pemuatan halaman sebesar 800 md.

• Jika ini sudah merupakan 10% pemuatan halaman tercepat, maka itu tidak akan memengaruhi persentil ke-75 sama sekali.
• Jika LCP adalah 10% pemuatan halaman paling lambat, tetapi halaman tersebut lebih lambat dari 800 md dibandingkan LCP persentil ke-75 pada awalnya, maka itu tidak akan memengaruhi persentil ke-75 sama sekali.

Ini adalah contoh-contoh ekstrem, yang kemungkinan tidak mencerminkan kenyataan, tetapi diharapkan dapat menggambarkan masalah. Dalam praktiknya, kemungkinan SXG akan memengaruhi persentil ke-75 untuk sebagian besar situs. Navigasi lintas situs cenderung menjadi yang paling lambat, dan peningkatan dari pengambilan data cenderung signifikan.

Memilih tidak menyertakan beberapa URL

Terakhir, salah satu cara untuk membandingkan performa SXG adalah dengan menonaktifkan SXG untuk beberapa subkumpulan URL di situs Anda. Misalnya, Anda dapat menetapkan header CDN-Cache-Control: no-store untuk mencegah Cloudflare ASX menghasilkan SXG. Saya tidak menyarankan hal ini.

Hal ini kemungkinan memiliki risiko bias seleksi yang lebih besar daripada metode penelitian lainnya. Misalnya, mungkin akan membuat perbedaan besar apakah beranda situs Anda atau URL yang serupa populer dipilih ke dalam grup kontrol atau grup eksperimen.

Studi penahanan

Cara yang ideal untuk mengukur dampak adalah dengan melakukan studi penahanan. Sayangnya, saat ini Anda tidak dapat melakukan pengujian semacam ini. Kami berencana menambahkan dukungan untuk pengujian tersebut pada masa mendatang.

Studi penahanan memiliki sifat berikut:

• Dalam grup eksperimen, beberapa bagian acak kunjungan halaman yang akan ditetapkan ke SXG akan "ditahan", dan berfungsi sebagai non-SXG. Hal ini memungkinkan perbandingan "apel-ke-apel" antara pengguna, perangkat, skenario, dan halaman yang setara.
• Kunjungan halaman yang ditahan (alias kontrafaktual) diberi label sedemikian rupa di analisis. Hal ini memungkinkan tampilan data yang "diperbesar", tempat kami dapat membandingkan pemuatan halaman SXG di kontrol dengan kontrafaktual SXG dalam eksperimen. Hal ini akan mengurangi derau dari pemuatan halaman lain yang tidak akan terpengaruh oleh pengambilan data SXG.

Tindakan ini akan menghilangkan kemungkinan sumber bias seleksi yang disebutkan di atas, meskipun tidak akan menghilangkan risiko bias kelangsungan LCP. Kedua properti ini membutuhkan browser atau perujuk untuk mengaktifkannya.

Kesimpulan

Fiuh! Materi tadi sungguh banyak. Semoga pembelajaran ini memberikan gambaran yang lebih lengkap tentang cara menguji performa SXG dalam uji lab, cara mengoptimalkan performanya dalam feedback loop yang ketat dengan uji lab, dan terakhir cara mengukur performanya di dunia nyata. Menyatukan semua hal ini akan membantu Anda mendapatkan hasil maksimal dari SXG, dan memastikan bahwa SXG menguntungkan situs dan pengguna Anda.

Jika Anda memiliki saran lainnya tentang cara mengetahui performa SXG, harap beri tahu kami. Laporkan bug pada developer.chrome.com dengan peningkatan yang Anda sarankan.

Untuk informasi selengkapnya tentang Signed HTTP Exchange, lihat dokumentasi web.dev dan dokumentasi Google Penelusuran.