İmzalanmış Takasları Kullanarak LCP'yi Optimize Etme

İmzalı exchange'lerden en iyi şekilde yararlanmak için bunları ölçme ve optimize etme

İmzalı takaslar (SXG'ler), sayfanızın hızını artırmanın bir yoludur; temel olarak Largest Contentful Paint (LCP) kullanılır. Yönlendiren siteler (şu anda Google Arama), bir sayfaya bağlantı verirken kullanıcı bağlantıyı tıklamadan önce sayfayı tarayıcı önbelleğine ön besleyebilir.

Önceden getirildiğinde sayfayı oluşturmanın kritik yolunda hiçbir ağ gerektirmeyen web sayfaları yapabilirsiniz. 4G bağlantıda bu sayfa yükleme süresi 2,8 sn'den 0,9 sn'ye düşer (kalan 0,9 saniye çoğunlukla CPU kullanımıdır):

Günümüzde SXG yayınlayan çoğu kullanıcı, Cloudflare'ın kullanımı kolay otomatik imzalı takas (ASX) özelliğini kullanıyor (açık kaynak seçenekleri de mevcuttur):

Çoğu durumda, bu özelliği etkinleştirmek için kutuyu işaretlemek, yukarıda gösterilen türde önemli bir iyileştirme elde etmek için yeterlidir. Bazen bu SXG'lerin ardışık düzenin her aşamasında amaçlandığı şekilde çalıştığından emin olmak ve sayfaları önceden getirme özelliğinden tam olarak yararlanacak şekilde optimize etmek için atılacak birkaç adım daha vardır.

Cloudflare'ın kullanıma sunulmasından bu yana geçen birkaç ay içinde, çeşitli forumlarda soruları okuyup yanıtladım ve sitelere SXG dağıtımlarından en iyi şekilde nasıl yararlanacakları konusunda nasıl tavsiyede bulunacağımı öğrendim. Bu yayın, verdiğimiz tavsiyelerin bir derlemesidir. Adımları şurada açıklayacağım:

• WebPageTest'i kullanarak SXG performansını analiz edin.
• Analiz adımının çalışmadığı görünüyorsa SXG ardışık düzeninde hata ayıklayın.
• Optimum max-age ayarlama ve oluşturmayı engelleyen alt kaynakları önceden yükleme dahil olmak üzere sayfaları SXG önceden getirme için optimize edin.
• Uygun deneme ve kontrol gruplarını seçerek Google Analytics kullanarak SXG iyileştirmesini ölçün.

Giriş

SXG, bir URL, bir HTTP yanıtı üstbilgisi grubu ve bir yanıt gövdesi içeren bir dosyadır. Bunların tümü bir Web PKI sertifikası tarafından kriptografik olarak imzalanır. Tarayıcı bir SXG yüklediğinde aşağıdakilerin tümünü doğrular:

• SXG'nin süresi dolmamış olmalıdır.
• İmza, URL, üstbilgiler, gövde ve sertifikayla eşleşiyor.
• Sertifika geçerli ve URL ile eşleşiyor.

Doğrulama başarısız olursa tarayıcı SXG'yi terk eder ve bunun yerine imzalı URL'yi getirir. Doğrulama başarılı olursa tarayıcı, imzalı yanıtı, doğrudan imzalanmış URL'den gelmiş gibi ele alarak yükler. Bu sayede, imzalandıktan sonra süresi dolmamış veya değiştirilmemiş SXG'ler herhangi bir sunucuda yeniden barındırılabilir.

Google Arama'da SXG, arama sonuçlarındaki sayfaların önceden getirilmesini etkinleştirir. Google Arama, SXG'leri destekleyen sayfalar için sayfanın webpkgcache.com üzerinde barındırılan önbelleğe alınmış kopyasını önceden getirebilir. Tarayıcı, orijinal, imzalı URL'ye uyduğu için bu webpkgcache.com URL'leri sayfanın görünümünü veya davranışını etkilemez. Önceden getirme, sayfanızın çok daha hızlı yüklenmesini sağlayabilir.

Analiz et

SXG'lerin avantajını görmek için SXG performansını tekrarlanabilir koşullarda analiz etmek üzere bir laboratuvar aracı kullanmaya başlayın. Şelaleleri ve LCP'yi SXG ön getirme ile ve ön getirme olmadan karşılaştırmak için WebPageTest'i kullanabilirsiniz.

Aşağıdaki gibi SXG içermeyen bir test oluşturun:

• WebPageTest'e gidin ve oturum açın. Oturum açarak test geçmişinizi kaydedebilirsiniz. Böylece, daha sonra karşılaştırma yapabilirsiniz.
• Test etmek istediğiniz URL'yi girin.
• Gelişmiş Yapılandırma'ya gidin. (SXG testi için Gelişmiş Yapılandırma'ya ihtiyacınız olacağından, burada kullanmak test seçeneklerinin aynı olmasını sağlar.)
• Test Ayarları sekmesinde, Bağlantı'yı 4G olarak ayarlamak ve "Çalıştırılacak Test Sayısı"nı 7'ye çıkarmak faydalı olabilir.
• Testi başlat'ı tıklayın.

Yukarıdakiyle aynı adımları kullanarak SXG ile bir test oluşturun, ancak Testi Başlat'ı tıklamadan önce Komut Dosyası sekmesine gidin, aşağıdaki WebPageTest komut dosyasını yapıştırın ve iki navigate URL'sini belirtildiği şekilde değiştirin:

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

İlk navigate URL'si için sayfanız henüz herhangi bir Google Arama sonucunda görünmüyorsa bu amaçla sahte bir arama sonuçları sayfası oluşturmak için bu ön getirme sayfasını kullanabilirsiniz.

İkinci navigate URL'sini belirlemek için SXG Validator Chrome uzantısını kullanarak sayfanızı ziyaret edin ve önbellek URL'sini görmek için uzantı simgesini tıklayın:

Bu testler tamamlandıktan sonra Test Geçmişi'ne gidin, iki testi seçin ve Karşılaştır'ı tıklayın:

WebPageTest'in, karşılaştırmanın her tarafı için ortanca LCP ile çalıştırmayı seçmesi için karşılaştırma URL'sine &medianMetric=LCP ekleyin. (Varsayılan değer, Hız Endeksi'ne göre ortanca değerdir.)

Şelaleleri karşılaştırmak için Şelale Opaklığı bölümünü genişletip kaydırma çubuğunu sürükleyin. Videoyu görüntülemek için Film Şeridi Ayarlarını Düzenle'yi tıklayın, bu iletişim kutusunda aşağı kaydırın ve Videoyu Görüntüle'yi tıklayın.

SXG ön getirme işlemi başarılı olursa "SXG ile" şelalenin HTML için bir satır içermediğini ve alt kaynakların getirilmesinin daha erken başladığını görürsünüz. Örneğin, burada "Önce" ve "Sonra"yı karşılaştırın:

Hata Ayıklama

WebPageTest, SXG'nin önceden getirildiğini gösteriyorsa ardışık düzenin tüm adımlarında başarılı olmuştur. LCP'yi nasıl daha da iyileştireceğinizi öğrenmek için Optimizasyon bölümüne atlayabilirsiniz. Aksi takdirde, hatanın ardışık düzende nerede ve neden başarısız olduğunu bulmanız gerekir. Nasıl yapıldığını öğrenmek için okumaya devam edin.

Yayıncılık

Sayfalarınızın SXG olarak oluşturulduğundan emin olun. Bunun için bir tarayıcı gibi davranmanız gerekir. En kolay yol SXG Validator Chrome uzantısını kullanmaktır:

Uzantı, SXG sürümünü tercih ettiğini belirten bir Accept istek başlığıyla mevcut URL'yi getirir. Kaynak'ın yanında onay işareti (✅) varsa bir SXG döndürülmüştür. Dizine ekleme bölümüne atlayabilirsiniz.

Çarpı işareti (❌) görürseniz bir SXG döndürülmemiştir:

Cloudflare ASX etkinse çarpı işaretinin (❌) nedeni büyük olasılıkla bir önbellek denetimi yanıt üst bilgisinin bunu engellemesidir. ASX, aşağıdaki adlara sahip üstbilgileri inceler:

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

Bu üst başlıklardan herhangi biri aşağıdaki üst başlık değerlerinden herhangi birini içeriyorsa SXG oluşturulmaz:

• private
• no-store
• no-cache
• 120'den büyük veya eşit s-maxage tarafından geçersiz kılınmadığı sürece max-age 120'den küçük

SXG'ler birden fazla ziyaret ve birden fazla ziyaretçi için önbelleğe alınıp yeniden kullanılabileceğinden bu durumlarda ASX bir SXG oluşturmaz.

X işaretinin (❌) bir diğer olası nedeni, Set-Cookie hariç bu durum bilgisi içeren yanıt üst bilgilerinden birinin bulunmasıdır. ASX, SXG spesifikasyonuna uymak için Set-Cookie başlığını kaldırır.

Başka bir olası neden de Vary: Cookie yanıt başlığının varlığıdır. Googlebot, SXG'leri kullanıcı kimlik bilgileri olmadan getirir ve birden fazla ziyaretçiye sunabilir. Farklı kullanıcılara çerezlerine göre farklı HTML sunarsanız bu kullanıcılar, çıkış yapma görünümü gibi yanlış bir deneyimle karşılaşabilir.

Chrome uzantısına alternatif olarak curl gibi bir araç kullanabilirsiniz:

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

veya dump-signedexchange:

dump-signedexchange -verify -uri $URL

SXG mevcutsa ve geçerliyse SXG'nin okunabilir bir çıktısını görürsünüz. Aksi takdirde bir hata mesajı görürsünüz.

Dizine ekleme

SXG'lerinizin Google Arama tarafından başarıyla dizine eklendiğinden emin olun. Chrome Geliştirici Araçları'nı açın ve ardından sayfanız için Google Arama'yı kullanın. SXG olarak dizine eklendiyse Google'ın sayfanıza yönlendiren bağlantısı, webpkgcache.com'un kopyasına işaret eden bir data-sxg-url içerir:

Google Arama, kullanıcının sonucu tıklama olasılığının yüksek olduğunu düşünürse sonucu ön beslemeyi de yapar:

<link> öğesi, tarayıcıya SXG'yi önceden getirme önbelleğine indirmesini söyler. Kullanıcı <a> öğesini tıkladığında tarayıcı, sayfayı oluşturmak için bu önbelleğe alınmış SXG'yi kullanır.

DevTools'taki Ağ sekmesine gidip webpkgcache içeren URL'leri arayarak da ön getirmenin kanıtını görebilirsiniz.

<a>, webpkgcache.com adresine işaret ediyorsa bu, imzalı değişimin Google Arama dizine ekleme işleminin çalıştığı anlamına gelir. Besinlerin alınması bölümüne atlayabilirsiniz.

Aksi takdirde, SXG'yi etkinleştirdiğinizden beri Google sayfanızı henüz yeniden taramamış olabilir. Google Search Console URL Denetleme Aracı'nı deneyin:

digest: mi-sha256-03=... üst bilgisinin bulunması, Google'ın SXG sürümünü başarıyla taradığını gösterir.

digest üstbilgisi yoksa bu, bir SXG'nin Googlebot'a sunulmadığının veya SXG'leri etkinleştirdiğinizden beri dizinin güncellenmediğinin göstergesi olabilir.

Bir SXG başarıyla taranmışsa ancak hâlâ bağlanmıyorsa SXG önbellek şartlarının karşılanmaması söz konusu olabilir. Bu konular bir sonraki bölümde ele alınmaktadır.

Besleme

Google Arama, bir SXG'yi dizine eklediğinde kopyasını Google SXG önbelleğine gönderir. Önbellek, SXG'yi önbellek şartlarına göre doğrular. Chrome uzantısı sonucu gösterir:

Onay işareti (✅) görürseniz Optimize etme’ye atlayabilirsiniz.

Şartları karşılayamazsa bir çarpı işareti (❌) ve nedenini belirten bir uyarı mesajı görürsünüz:

Bu durumda sayfa, SXG etkinleştirilmeden önceki gibi çalışır. Google, SXG ön getirme olmadan sayfaya orijinal ana makinesinde bağlantı verir.

Önbelleğe alınan kopyanın süresinin dolması ve arka planda yeniden getirilmesi durumunda bir kum saati (⌛) görürsünüz:

SXG ile ilgili Google geliştirici belgesinde önbelleği manuel olarak sorgulama talimatları da yer alır.

Optimize etme

SXG Validator Chrome uzantısı tüm onay işaretlerini (✅) gösteriyorsa kullanıcılara sunulabilecek bir SXG'niz var demektir. SXG'den en fazla LCP iyileştirmesini elde etmek üzere web sayfanızı nasıl optimize edeceğinizi öğrenmek için okumaya devam edin.

max-age

SXG'lerin süresi dolduğunda Google SXG Önbelleği, arka planda yeni bir kopya getirir. Bu getirme işlemini beklerken kullanıcılar, orijinal ana makinesindeki sayfaya yönlendirilir. Bu sayfa önceden getirilmez. Cache-Control: max-age değerini ne kadar uzun süre ayarlarsanız bu arka plan getirme işlemi o kadar seyrek gerçekleşir ve ön getirme işlemiyle LCP o kadar sık azaltılabilir.

Bu, performans ile tazelik arasında bir dengedir. Önbellek, site sahiplerinin her sayfanın özel ihtiyaçlarına uyacak şekilde 2 dakika ile 7 gün arasında bir maksimum yaş değeriyle SXG'ler sağlamasına olanak tanır. Anekdot olarak şunu söyleyebiliriz:

• max-age=86400 (1 gün) veya daha uzun süreler performans için iyi sonuç verir.
• max-age=120 (2 dakika)

Verileri daha fazla inceledikten sonra bu ikisi arasındaki değerler hakkında daha fazla bilgi edinmeyi umuyoruz.

kullanıcı aracısı

Bir keresinde, önceden getirilmiş bir SXG kullanırken LCP'nin arttığını gördüm. SXG ön getirme olmadan ve SXG ön getirmeyle elde edilen ortalama sonuçları karşılaştırmak için WebPageTest'i çalıştırdım. Aşağıdaki Sonra'yı tıkladığınızda:

Ön beslemenin çalıştığını gördüm. HTML, kritik yoldan kaldırılır ve böylece tüm alt kaynaklar daha erken yüklenebilir. Ancak yeşil kesikli çizgi olan LCP 2 saniyeden 2,1 saniyeye yükseldi.

Bunu teşhis etmek için film şeritlerine baktım. Sayfanın SXG'de farklı bir şekilde oluşturulduğunu buldum. Basit HTML'de Chrome, LCP için "en büyük öğenin" başlığın olduğunu belirledi. Ancak SXG sürümünde sayfaya geç yüklenen bir banner eklendi. Bu banner, başlığı ekranın alt kısmına itti ve yeni en büyük öğenin geç yüklenen çerez izni iletişim kutusu olmasına neden oldu. Her şey öncekinden daha hızlı oluşturuluyor ancak düzendeki bir değişiklik, metriğin daha yavaş olarak raporlanmasına neden oldu.

Daha ayrıntılı bir inceleme yaptığımda, sayfanın User-Agent'e göre değiştiği ve mantıkta bir hata olduğu için düzendeki farkın ortaya çıktığını fark ettim. SXG tarama başlığı mobil cihazı belirtmesine rağmen masaüstü sayfası yayınlanıyordu. Bu hata düzeltildikten sonra tarayıcı, doğru şekilde sayfanın başlığını en büyük öğesi olarak belirledi.

"Sonra"yı tıkladığımda, önceden getirilen LCP'nin 1,3 saniyeye düştüğünü gördüm:

SXG'ler tüm form faktörleri için etkindir. Buna hazırlanmak için şunlardan birinin doğru olduğundan emin olun:

• Sayfanız Vary tarafından User-Agent (ör. duyarlı tasarım veya ayrı mobil/masaüstü URL'leri kullanıyor)
• Sayfanızda dinamik yayınlama kullanılıyorsa sayfa, <meta name=supported-media content=...> kullanarak kendisini yalnızca mobil veya masaüstü olarak notlar.

Alt kaynaklar

SXG'ler, HTML ile birlikte alt kaynakları (resimler dahil) önceden almak için kullanılabilir. Cloudflare ASX, aynı kaynak (birinci taraf) <link rel=preload> öğelerini bulmak için HTML'yi tarar ve bunları SXG uyumlu bağlantı başlıklarına dönüştürür. Ayrıntılar için buradaki ve buradaki kaynak koduna göz atın.

Çalışıyorsa Google Arama'dan gelen ek önceden getirme işlemleri görürsünüz:

LCP için optimizasyon yapmak istiyorsanız şelalenize yakından bakın ve en büyük öğenin oluşturulması için kritik yolda hangi kaynakların yer aldığını öğrenin. Önceden getirilemiyorlarsa kritik yoldan çıkarılıp çıkarılamayacaklarını değerlendirin. Yüklemeleri tamamlanana kadar sayfayı gizleyen komut dosyalarına dikkat edin.

Google SXG Önbelleği, 20'ye kadar alt kaynak ön yüklemesine izin verir ve ASX bu sınırın aşılmasını önler. Ancak çok fazla alt kaynak ön yükleme eklemenin riski vardır. Tarayıcı, siteler arası izlemeyi önlemek için önceden yüklenmiş alt kaynakları yalnızca tümünün getirilmesi tamamlandıysa kullanır. Alt kaynak sayısı arttıkça, kullanıcı sayfanızı tıklamadan önce bunların hepsinin ön getirme işlemini tamamlama olasılığı azalır.

SXG Doğrulayıcı şu anda alt kaynakları kontrol etmiyor. Hata ayıklamak için şu anda curl veya dump-signedexchange kullanın.

Ölçüm

WebPageTest'te LCP iyileştirmesini optimize ettikten sonra, SXG ön getirmenin sitenizin genel performansı üzerindeki etkisini ölçmek faydalı olur.

Sunucu tarafı metrikler

İlk Baytlama Süresi (TTFB) gibi sunucu tarafı metriklerini ölçerken sitenizin yalnızca bu biçimi kabul eden tarayıcılara SXG'ler sunduğunu unutmayın. TTFB ölçümünüzü bot'lar yerine gerçek kullanıcılardan gelen isteklerle sınırlayın. SXG oluşturmanın tarayıcı isteklerinin TTFB'sini artırdığını fark edebilirsiniz ancak bu durum ziyaretçilerinizin deneyimini etkilemez.

İstemci tarafı metrikleri

SXG'ler, özellikle LCP olmak üzere istemci tarafı metrikler için en fazla hız avantajını sağlar. Etkilerini ölçerken Cloudflare ASX'yi etkinleştirebilir, Googlebot tarafından yeniden taranmasını bekleyebilir, Temel Web Vitals (CWV) toplama işlemi için 28 gün daha bekleyebilir ve ardından yeni CWV sayılarınıza bakabilirsiniz. Ancak bu zaman aralığındaki diğer tüm değişiklikler arasında bu değişikliğin fark edilmesi zor olabilir.

Bunun yerine, etkilenmiş olabilecek sayfa yüklemelerine "yakınlaştırma" yapmanın ve bunu "SXG'ler sayfa görüntülemelerinin %X'ini etkiliyor ve 75. yüzdelik dilimde LCP'yi Y milisaniye artırıyor" şeklinde ifade etmenin yararlı olduğunu düşünüyorum.

Şu anda SXG ön getirme işlemi yalnızca belirli koşullarda gerçekleşir:

• Chromium tarayıcı (ör. iOS hariç Chrome veya Edge), M98 veya sonraki sürüm
• Referer: google.com veya diğer Google arama alan adlarını kullanabilirsiniz. (Google Analytics'te yönlendiren etiketinin oturumdaki tüm sayfa görüntülemeleri için geçerli olduğunu, SXG ön getirmenin ise yalnızca doğrudan Google Arama'dan bağlantı verilen ilk sayfa görüntülemesi için geçerli olduğunu unutmayın.)

"Sayfa görüntülemelerinin %X'ini" ve "LCP'yi Y milisaniye iyileştirilmesini" nasıl ölçeceğinizi öğrenmek için Çağdaş çalışma bölümünü okuyun.

Çağdaş çalışma

Gerçek kullanıcı izleme (RUM) verilerine bakarken sayfa yüklemelerini SXG ve SXG olmayan olarak ayırmanız gerekir. Bu işlemi yaparken, seçim önyargısını önlemek için baktığınız sayfa yükleme grubunu sınırlamak önemlidir. Böylece, SXG olmayan taraf SXG'nin uygunluk koşullarıyla eşleşir. Aksi takdirde, aşağıdakilerin tümü yalnızca SXG olmayan sayfa yüklemelerinde bulunur. Bu sayfa yüklemelerinin LCP'si doğal olarak farklı olabilir:

• iOS cihazlar: Bu cihazlara sahip kullanıcılar arasındaki donanım veya ağ hızındaki farklılıklar nedeniyle.
• Eski Chromium tarayıcılar: Aynı nedenlerle.
• Masaüstü cihazlar: Aynı nedenlerle veya sayfa düzeni farklı bir "en büyük öğenin" seçilmesine neden olduğu için.
• Aynı sitede gezinme (ziyaretçilerin site içindeki bağlantıları takip etmesi): Önceki sayfa yüklemesinden önbelleğe alınmış alt kaynakları yeniden kullanabilirler.

Google Analytics'te (UA), "Hit" kapsamına sahip, biri "isSXG", diğeri "referrer" adlı iki özel boyut oluşturun. (Yerleşik "Kaynak" boyutu oturum kapsamına sahiptir, bu nedenle aynı sitedeki gezinmeleri hariç tutmaz.)

Aşağıdaki filtrelerin AND operatörüyle birlikte kullanıldığı "SXG karşıt gerçek" adlı bir özel segment oluşturun:

• referrer, https://www.google. değeriyle başlıyor
• Browser, Chrome ile tam olarak eşleşir
• Browser Sürüm, normal ifadeyle eşleşir ^(9[8-9]|[0-9]{3})
• isSXG, false ile tam olarak eşleşiyor

Bu segmentin, isSXG ile true tam olarak eşleşen "SXG" adlı bir kopyasını oluşturun.

Site şablonunuzda, aşağıdaki snippet'i Google Analytics snippet'inin üstüne ekleyin. Bu, ASX'nin SXG oluştururken false değerini true olarak değiştireceği özel bir söz dizimidir:

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

LCP'yi kaydetmek için Google Analytics raporlama komut dosyanızı önerilen şekilde özelleştirin. gtag.js kullanıyorsanız özel boyutu ayarlamak için 'config' komutunu değiştirin ('dimension1' ve 'dimension2' değerlerini Google Analytics'in kullanılmasını söylediği adlarla değiştirin):

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

analytics.js kullanıyorsanız 'create' komutunu burada açıklandığı gibi değiştirin.

Veri toplamak için birkaç gün bekledikten sonra Google Analytics Etkinlikler raporuna gidin ve SXG segmenti için ayrıntılı inceleme ekleyin. Bu işlem, "SXG'ler sayfa görüntülemelerinin %X'ini etkiliyor" ifadesi için X değerini doldurur:

Son olarak, Web Vitals raporu'na gidin, "Segment seçin"i, ardından "SXG karşıt gerçek" ve "SXG"yi seçin.

"Gönder"i tıklayın. İki segmentin LCP dağıtımlarını görürsünüz. Bu işlem, "LCP'yi yüzde 75'lik dilimde Y milisaniye artırma" için Y değerini doldurur:

Uyarılar

Yukarıdaki filtrelerin tümünü uyguladıktan sonra, SXG karşı olgusal sayfa yüklemeleri aşağıdakilere benzer öğelerden oluşmalıdır:

• Önbellek hataları: Google SXG önbelleği, belirli bir URL için SXG'nin yeni bir kopyasına sahip değilse sitenizdeki orijinal URL'ye yönlendirme yapar.
• Diğer sonuç türleri: Google Arama şu anda yalnızca standart web sonuçları ve birkaç başka tür için SXG'yi desteklemektedir. Öne çıkan snippet'ler ve En çok okunan haberler bandı gibi diğer özellikler ise sitenizdeki orijinal URL'ye bağlantı verir.
• Uygun olmayan URL'ler: Sitenizdeki bazı sayfalar SXG için uygun değilse (ör. önbelleğe alınamayacakları için) bu grupta görünebilir.

SXG sayfa yüklemeleri ile yukarıdaki SXG dışı sayfa yüklemeleri arasında kalan bir önyargı olabilir ancak bu önyargı, Çağdaş çalışma bölümünün üst kısmında belirtilen önyargılardan daha küçük olmalıdır. Örneğin, önbelleğe alınamayan sayfalarınız önbelleğe alınabilen sayfalarınızdan daha yavaş veya daha hızlı olabilir. Bunun bir sorun olabileceğinden şüpheleniyorsanız sonuçlarının genel çalışmayla eşleşip eşleşmediğini görmek için belirli bir SXG'ye uygun URL ile sınırlı verilere bakabilirsiniz.

Sitenizde bazı AMP sayfaları varsa bu sayfalar zaten Google Arama'dan önceden getirilebildiğinden, SXG'nin etkinleştirilmesiyle performansta iyileştirmeler görülmeyebilir. Alakalı değişikliklere daha fazla "yaklaşmak" için bu tür sayfaları hariç tutacak bir filtre ekleyebilirsiniz.

Son olarak, tüm seçim önyargılarını ele alsanız bile, sağ kalanlar önyargısının LCP iyileştirmelerini RUM istatistiklerinde düşüş gibi gösterme riski vardır. Bu makale bu riski çok iyi açıklamıştır ve bunun olup olmadığını tespit etmek için bir tür vazgeçme metriğine bakmanızı önerir.

Çalışmadan önce/sonra

Modern çalışmanın sonuçlarını desteklemek için SXG'yi etkinleştirmeden önce ve etkinleştirdikten sonra LCP karşılaştırması yapmak yararlı olabilir. Yukarıda belirtilen olası önyargıları ortadan kaldırmak için SXG sayfa görüntülemeleriyle sınırlı kalmayın. Bunun yerine, isSXG kısıtlaması olmadan yukarıdaki segment tanımları olan SXG'ye uygun sonuçlara bakın.

Google Arama'nın, SXG'nin etkinleştirildiğini belirlemek için sitenizdeki tüm sayfaları yeniden taramasının birkaç haftayı bulabileceğini unutmayın. Bu birkaç hafta içinde ortaya çıkabilecek diğer olası önyargılar şunlardır:

• Yeni tarayıcı sürümleri veya kullanıcı donanımında yapılan iyileştirmeler sayfa yüklemeyi hızlandırabilir.
• Tatil gibi önemli bir etkinlik, trafiği normalden farklı bir yöne çekebilir.

Yukarıdaki çalışmaları doğrulamak için öncesinde ve sonrasında genel 75. yüzdelik dilim LCP'ye bakmak da faydalı olacaktır. Popülasyonun bir alt kümesi hakkında bilgi edinmek, bize genel popülasyon hakkında bilgi vermeyebilir. Örneğin, SXG'nin sayfa yüklemelerinin% 10'unu 800 ms artırdığını varsayalım.

• Bunlar zaten en hızlı% 10 sayfa yüklemeleriyse bu durum 75. yüzdelik dilimi hiç etkilemeyecektir.
• Bu sayfa yüklemeleri, en yavaş %10'luk dilimde yer alıyorsa ancak başlangıçta 75. yüzdelik dilimdeki LCP'den 800 ms daha yavaşsa 75. yüzdelik dilimi hiç etkilemez.

Bunlar gerçekliği yansıtmayan uç örneklerdir ancak sorunu açıklamaya yardımcı olabilir. Uygulamada, SXG'nin çoğu sitenin 75. yüzdelik dilimini etkilemesi muhtemeldir. Siteler arası gezinmeler genellikle en yavaş işlemlerden biridir ve ön getirmeden elde edilen iyileştirmeler genellikle önemli olur.

Bazı URL'leri kapsam dışında bırakma

Son olarak, SXG performansını karşılaştırmanın bir yolu, sitenizdeki bazı URL alt kümeleri için SXG'yi devre dışı bırakmaktır. Örneğin, Cloudflare ASX'nin SXG oluşturmasını engellemek için bir CDN-Cache-Control: no-store üst bilgisi ayarlayabilirsiniz. Bunu yapmamanızı öneririm.

Bu yöntemin, diğer araştırma yöntemlerine kıyasla seçim yanlılığı riski daha büyük olabilir. Örneğin, sitenizin ana sayfasının mı yoksa benzer popülerlikte bir URL'nin mi kontrol grubuna veya deneme grubuna seçildiği büyük bir fark yaratabilir.

Ayrılma çalışması

Etkiyi ölçmenin ideal yolu, ayrılmış grup çalışması yapmaktır. Maalesef şu anda bu tür bir test yapamazsınız. İlerleyen zamanlarda bu tür bir test için destek sunmayı planlıyoruz.

Askıya alma çalışması aşağıdaki özelliklere sahiptir:

• Deneme grubunda, SXG olacak sayfa görüntülemelerinin rastgele bir kısmı "bekletilir" ve bunun yerine SXG olmayan bir şekilde yayınlanır. Bu sayede eşdeğer kullanıcılar, cihazlar, senaryolar ve sayfalar arasında "bire bir" karşılaştırma yapabilirsiniz.
• Engellenen (diğer adıyla karşıt gerçeklik) sayfa görüntülemeleri, analizlerde bu şekilde etiketlenir. Bu sayede, kontrol grubundaki SXG sayfa yüklemelerini denemedeki SXG karşıt gerçekleriyle karşılaştırabileceğimiz "yakınlaştırılmış" bir veri görünümü elde edebiliriz. Böylece, SXG önceden getirme özelliğinden etkilenmeyecek diğer sayfa yüklemelerinden kaynaklanan gürültüyü azaltır.

Bu, yukarıda belirtilen olası seçim yanlılığı kaynaklarını ortadan kaldırır ancak LCP sağ kalan yanlılığı riskini ortadan kaldırmaz. Bu özelliklerin her ikisi için de tarayıcının veya yönlendirenin etkinleştirmesi gerekir.

Sonuç

Bora Çok fazla çalıştım. Bu makalenin, SXG performansının laboratuvar testinde nasıl test edileceği, laboratuvar testiyle sıkı bir geri bildirim döngüsü içinde performansının nasıl optimize edileceği ve son olarak gerçek dünyadaki performansının nasıl ölçüleceği hakkında daha kapsamlı bir fikir verdiğini umuyoruz. Tüm bunları bir araya getirmek, SXG'lerden en iyi şekilde yararlanmanıza ve sitenize ve kullanıcılarınıza fayda sağladıklarından emin olmanıza yardımcı olacaktır.

SXG performansını yakalama konusunda daha fazla tavsiyeniz varsa lütfen bize bildirin. Önerdiğiniz iyileştirmeleri developer.chrome.com adresinde hata kaydı olarak gönderin.

İmzalı exchange'ler hakkında daha fazla bilgi için web.dev belgelerine ve Google Arama belgelerine göz atın.