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

İmzalı değişimlerden en iyi şekilde yararlanmak için imzalı takasları ölçme ve optimize etme

İmzalı takaslar (SXG'ler), sayfa hızınızı iyileştirmenin bir yoludur. Örneğin, Largest Contentful Paint (LCP). Yönlendiren siteler (şu anda Google Arama) bir sayfaya bağlantı oluştururken, kullanıcı bağlantıyı tıklamadan önce sayfayı tarayıcı önbelleğine önceden getirebilir.

Önceden getirildiğinde sayfanın oluşturulması için kritik yolda ağ gerektirmeyen web sayfaları oluşturmak mümkündür. 4G bağlantısında, bu sayfa yükleme işlemi 2,8 saniyeden 0,9 saniyeye çıkar (kalan 0,9 sn. çoğunlukla CPU kullanımına göredir):

Bugün SXG yayınlayan çoğu kişi Cloudflare'in kullanımı kolay Otomatik İmzalı Değişimler (ASX) özelliğini kullanıyor (ancak açık kaynak seçenekleri de mevcuttur):

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

Cloudflare'in kullanıma sunulmasından bu yana son birkaç ay içinde çeşitli forumlardaki soruları okuyup yanıtlıyor ve SXG dağıtımlarından en iyi şekilde yararlandıklarından emin olmak için sitelere nasıl tavsiyelerde bulunabileceğimi öğreniyorum. Bu gönderide bazı tavsiyeler yer alıyor. Adımları uygulayarak şu işlemleri gerçekleştireceğim:

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

Giriş

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

• SXG'nin geçerlilik süresi sona ermemiş.
• İmza; URL, üstbilgi, gövde ve sertifika ile eşleşiyor.
• Sertifika geçerli ve URL ile eşleşiyor.

Doğrulama başarısız olursa tarayıcı SXG'yi bırakır ve bunun yerine imzalı URL'yi getirir. Doğrulama başarılı olursa tarayıcı imzalı yanıtı yükler ve yanıtın doğrudan imzalanmış URL'den gelmiş gibi davranır. Bu, imzalandıktan sonra geçerlilik süresi dolmadığı veya değiştirilmediği sürece SXG'lerin herhangi bir sunucuda yeniden barındırılmasına izin verir.

Google Arama söz konusu olduğunda SXG, arama sonuçlarında sayfaların önceden getirilmesini etkinleştirir. SXG'leri destekleyen sayfalar için Google Arama, sayfanın webpkgcache.com adresinde barındırılan önbelleğe alınmış kopyasını önceden getirebilir. Bu webpkgcache.com URL'leri, tarayıcı orijinal imzalı URL'yi dikkate aldığından sayfanın görüntülenmesini veya davranışını etkilemez. Önceden getirme, sayfanızın çok daha hızlı yüklenmesini sağlayabilir.

Analiz etme

SXG'lerin yararını görmek için, tekrarlanabilir koşullarda SXG performansını analiz etmek üzere bir laboratuvar aracı kullanarak başlayın. SXG önceden getirmesi olan ve olmayan şelaleleri ve LCP'yi karşılaştırmak için WebPageTest'i kullanabilirsiniz.

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

• WebPageTest'e gidin ve oturum açın. Oturum açtığınızda, daha sonra kolayca karşılaştırma yapabilmeniz için test geçmişiniz kaydedilir.
• 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 vardır. Bu nedenle, bu yapılandırmayı burada kullanmanız test seçeneklerinin aynı olmasını sağlamanıza yardımcı olur.)
• Test Ayarları sekmesinde, Bağlantıyı 4G'ye ayarlayıp "Çalıştırılacak Test Sayısı"nı 7'ye yükseltmek yararlı olabilir.
• Testi Başlat'ı tıklayın.

Yukarıdaki adımları uygulayarak 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'yi 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

Sayfanız henüz hiçbir Google Arama sonucunda görünmüyorsa ilk navigate URL'si için bu önceden getirme sayfasını kullanarak bu amaçla bir sahte arama sonuçları sayfası oluşturabilirsiniz.

İkinci navigate URL'sini belirlemek için SXG Validator Chrome uzantısını kullanarak sayfanızı ziyaret edin ve önbellek URL'sini görmek üzere 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:

Karşılaştırma URL'sine &medianMetric=LCP ekleyin. Böylece WebPageTest, karşılaştırmanın her bir tarafı için ortanca LCP değerine sahip çalıştırmayı seçer. (Varsayılan, Hız Dizini tarafından ortanca değerdir.)

Şelaleleri karşılaştırmak için Şelale Opaklığı bölümünü genişletin ve kaydırma çubuğunu sürükleyin. Videoyu görüntülemek için Film Şeridi Ayarlarını Ayarla'yı tıklayın, ilgili iletişim kutusunun içine kaydırın ve Videoyu Göster'i tıklayın.

SXG önceden getirme işlemi başarılı olursa "SXG ile" şelalesinde HTML satırı bulunmadığını ve alt kaynakları getirme işlemlerinin 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ş demektir. LCP'yi nasıl daha da iyileştireceğinizi öğrenmek için Optimize etme bölümüne atlayabilirsiniz. Aksi takdirde, ardışık düzenin neresinde başarısız olduğunu ve neden başarısız olduğunu bulmanız gerekir. Nasıl yapılacağını öğrenmek için okumaya devam edin.

Yayıncılık

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

Uzantı, mevcut URL'yi SXG sürümünü tercih ettiğini belirten bir Accept istek başlığıyla getirir. Kaynak'ın yanında onay işareti (✅) görüyorsanız SXG iade edilmiş demektir. Bu durumda Dizine ekleme bölümüne atlayabilirsiniz.

Çapraz işareti (❌) görürseniz SXG iade edilmemiş demektir:

Cloudflare ASX etkinse çapraz işaretin (❌) en olası nedeni, bir önbellek kontrolü yanıt başlığının bunu engellemesidir. ASX şu adlara sahip başlıklara bakar:

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

Bu üstbilgilerden herhangi biri aşağıdaki üstbilgi değerlerinden birini içeriyorsa SXG oluşturulmasını engeller:

• private
• no-store
• no-cache
• max-age, 120'den büyük veya 120'ye eşit olduğunda s-maxage tarafından geçersiz kılınmadığı sürece 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 tür durumlarda ASX, SXG oluşturmaz.

Çapraz işaretin (❌) başka bir olası nedeni de Set-Cookie dışında bu durum bilgili yanıt başlıklarından birinin varlığıdır. ASX, SXG spesifikasyonuna uymak için Set-Cookie üst bilgisini kaldırır.

Olası başka bir neden de bir Vary: Cookie yanıt üst bilgisinin bulunmasıdır. Googlebot, SXG'leri kullanıcı kimlik bilgileri olmadan getirir ve bunları birden çok ziyaretçiye sunabilir. Çerezlerine göre farklı kullanıcılara farklı HTML sunarsanız kullanıcılar oturum kapalı görünüm gibi yanlış bir deneyimle karşılaşabilir.

Chrome uzantısına alternatif olarak, curl gibi bir araç da 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, ardından sayfanız için bir Google Araması gerçekleştirin. Sayfa SXG olarak dizine eklenmişse, Google'ın sayfanıza bağlantısında webpkgcache.com'un kopyasına işaret eden bir data-sxg-url bulunur:

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

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

Geliştirici Araçları'nda Ağ sekmesine gidip webpkgcache ifadesini içeren URL'leri arayarak da önceden getirme işleminin kanıtını görebilirsiniz.

<a>, webpkgcache.com adresine işaret ediyorsa imzalı değişimin Google Arama dizinine ekleme çalışıyor demektir. Besleme bölümüne atlayabilirsiniz.

Aksi takdirde, SXG'yi etkinleştirmenizden bu yana Google henüz sayfanızı yeniden taramamış olabilir. Google Search Console URL Denetleme Aracı'nı deneyin:

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

Bir digest üst bilgisi yoksa bu, Googlebot'a SXG sunulmadığını veya SXG'leri etkinleştirdikten sonra dizinin güncellenmediğini gösteriyor olabilir.

SXG başarıyla taranmasına rağmen hâlâ bağlanmıyorsa SXG önbellek şartlarının karşılanamaması olabilir. Bunlar bir sonraki bölümde ele alınmaktadır.

Besleme

Google Arama bir SXG'yi dizine eklediğinde bu kopyayı Google SXG Önbelleğine gönderir. Bu önbellekte, veriler önbellek gereksinimlerine göre doğrulanır. Chrome uzantısı sonucu gösterir:

Onay işareti (✅) görürseniz ileri atlayıp Optimize et'e geçebilirsiniz.

Uygulamanız gereksinimleri karşılayamazsa çapraz işareti (❌) ve bunun nedenini belirten bir uyarı mesajı görürsünüz:

Bu durumda sayfa, SXG'yi etkinleştirmeden önce olduğu gibi çalışır. Google, SXG önceden getirme işlemi olmadan orijinal ana makinesinde sayfaya 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 dokümanında, önbelleği manuel olarak sorgulama talimatları da bulunmaktadır.

Optimize etme

SXG Validator Chrome uzantısında tüm onay işaretleri gösteriliyorsa (✅) kullanıcılara sunulabilecek bir SXG'niz var demektir. SXG'den en yüksek 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, önceden getirilmemiş orijinal ana makinedeki sayfaya yönlendirilir. Cache-Control: max-age değerini ne kadar uzun ayarlarsanız bu arka planda getirme işlemi o kadar az olur ve bu nedenle, önceden getirme işleviyle LCP değeri o kadar sık azaltılabilir.

Bu, performans ile güncellik arasında bir denge oluşturur ve önbellek, site sahiplerinin her sayfanın özel ihtiyaçlarına uyması için site sahiplerinin SXG'lere 2 dakika ile 7 gün arasında bir maksimum yaş değeri sağlamasına olanak tanır. Anekdot olarak elde ettiğimiz veriler:

• max-age=86400 (1 gün) veya daha uzun bir süre performans gösterir
• max-age=120 (2 dakika) şunu yapmaz:

Verileri daha ayrıntılı olarak incelediğimizde, bu ikisi arasındaki değerler hakkında daha fazla bilgi edinmeyi umuyoruz.

kullanıcı aracısı

Bir keresinde, önceden getirilen SXG kullanırken LCP'de artış olduğunu gördüm. WebPageTest'i çalıştırdım ve SXG önceden getirmesi olmadan ve bu değerlerle elde edilen ortanca değeri karşılaştırdım. Aşağıda Sonra'yı tıklayın:

Önceden getirmenin çalıştığını gördüm. HTML kritik yoldan kaldırılır. Böylece, tüm alt kaynaklar daha erken yüklenebilir. Ancak bu yeşil kesik çizgisi olan LCP, 2 saniyeden 2,1 saniyeye yükseldi.

Bunu teşhis etmek için film şeritlerine baktım. Sayfanın SXG'de farklı şekilde oluşturulduğunu fark ettim. Düz HTML'de Chrome, LCP için "en büyük öğenin" başlık olduğunu belirlemiştir. 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 eskisinden daha hızlı oluşturuldu ancak düzendeki bir değişiklik metriğin daha yavaş olarak bildirmesine neden oldu.

Konuyu derinlemesine inceledim ve düzendeki farkın nedeninin, sayfanın User-Agent göre değişiklik göstermesi olduğunu ve mantıkta bir hata olduğunu keşfettim. SXG tarama başlığında mobil cihaz belirtilmesine rağmen bir masaüstü sayfası sunuluyordu. Bu durum düzeltildikten sonra tarayıcı, sayfanın başlığını doğru şekilde en büyük öğe olarak belirledi.

Şimdi, "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 aşağıdakilerden birinin doğru olduğundan emin olun:

• Sayfanız User-Agent tarafından Vary özelliğine sahip değil (ör. duyarlı tasarım veya ayrı mobil/masaüstü URL'leri kullanıyor).
• Sayfanız dinamik sunum kullanıyorsa <meta name=supported-media content=...> kullanarak kendisine yalnızca mobil veya masaüstü sürümü olarak ek açıklama ekler.

Alt kaynaklar

SXG'ler, HTML ile birlikte alt kaynakları (resimler dahil) önceden getirmek için kullanılabilir. Cloudflare ASX, HTML'yi aynı kaynak (birinci taraf) <link rel=preload> öğeleri için tarayıp SXG uyumlu Link üstbilgilerine dönüştürür. Kaynak kodundaki ayrıntıları burada ve burada bulabilirsiniz.

Çalışıyorsa Google Arama'dan ek önceden getirmeler görürsünüz:

LCP için optimizasyon yapmak üzere şelalenizi yakından inceleyin ve en büyük öğeyi oluşturma yolunda kritik yolda hangi kaynakların olduğunu belirleyin. Önceden getirilemiyorlarsa kritik yoldan çıkarılıp çıkarılamayacaklarını düşünün. Yüklenene kadar sayfayı gizleyen komut dosyalarına dikkat edin.

Google SXG Önbelleği, en fazla 20 alt kaynak ön yüklemesine izin verir ve ASX, bu sınırın aşılmamasını sağlar. Bununla birlikte, çok fazla alt kaynak önceden yüklemesi eklenmesi riski vardır. Tarayıcı, siteler arası izlemeyi önlemek amacıyla önceden yüklenmiş alt kaynakları yalnızca bunların tamamı getirme işlemi tamamlamışsa kullanır. Ne kadar çok alt kaynak olursa bunların hepsinin kullanıcı tıklayarak sayfanıza gitmeden önce ön getirme işlemini bitirme olasılığı da o kadar azalır.

SXG Doğrulayıcı şu anda alt kaynakları kontrol etmemektedir. Bu sırada hata ayıklamak için curl veya dump-signedexchange kullanın.

Ölçüm

WebPageTest altında LCP iyileştirmesini optimize ettikten sonra, SXG'nin önceden getirilmesinin sitenizin genel performansı üzerindeki etkisini ölçmek yararlı olacaktır.

Sunucu tarafı metrikler

İlk Bayt Süresi (TTFB) gibi sunucu tarafı metriklerini ölçerken sitenizin SXG'leri yalnızca biçimi kabul eden tarayıcılara sunduğunu unutmamanız önemlidir. TTFB ölçümünüzü botlardan değil, gerçek kullanıcılardan gelen isteklerle sınırlandırın. SXG oluşturmanın tarayıcı istekleri için TTFB'yi artırdığını görebilirsiniz, ancak bu durum ziyaretçilerinizin deneyimini etkilemez.

İstemci tarafı metrikleri

SXG'ler, hız avantajını istemci taraflı metriklerde (özellikle LCP) en yüksek seviyeye çıkarır. Etkilerini ölçtüğünüzde, Cloudflare ASX'i etkinleştirebilir, Googlebot tarafından yeniden taranmasını bekleyebilir, Core Web Vitals (CWV) toplama işlemi için 28 gün daha bekleyebilir ve yeni CWV sayılarınıza bakabilirsiniz. Ancak, bu zaman dilimindeki diğer tüm değişikliklerle bir arada kullanıldığında değişikliği fark etmek zor olabilir.

Bunun yerine, etkilenmiş olabilecek sayfa yüklemelerini "yakınlaştırmak" ve bunu, "SXG'ler sayfa görüntülemelerinin% X kadarını etkiliyor ve LCP'lerini 75. yüzdelik dilimde Y milisaniye artırıyor" şeklinde çerçevelemeyi yararlı buluyorum.

Şu anda, SXG önceden getirme işlemi yalnızca belirli koşullarda gerçekleşmektedir:

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

"Sayfa görüntülemelerinin% X'i"nin nasıl ölçüleceği ve "LCP'lerinin Y milisaniye artırılmasının" nasıl ölçüleceği hakkında bilgi edinmek için Güncel çalışma bölümünü okuyun.

Çağdaş çalışma

Gerçek kullanıcı izleme (RUM) verilerini incelerken, sayfa yüklemelerini SXG ve SXG olmayan şeklinde bölmeniz gerekir. Bunu yaparken, seçtiğiniz sayfa yüklemelerinin sayısını sınırlandırmak önemlidir. Böylece SXG'ye dahil olmayan taraf, SXG'nin uygunluk koşullarıyla eşleşir. Böylece seçim ön yargısını önleyebilirsiniz. Aksi takdirde, aşağıdakilerin tümü yalnızca, doğuştan farklı LCP'ye sahip olabilecek SXG olmayan sayfa yüklemeleri grubunda bulunur:

• iOS cihazlar: Bu cihazlara sahip olan kullanıcılar arasındaki donanım veya ağ hızı 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 (sitedeki bağlantıları takip eden ziyaretçiler): Önceki sayfa yüklemesinde önbelleğe alınmış alt kaynakları yeniden kullanabildikleri için.

Google Analytics'te (UA), biri "isSXG" diğeri "referrer" adlı, "İsabet" kapsamına sahip iki özel boyut oluşturun. (Yerleşik "Kaynak" boyutu oturum kapsamına sahip olduğundan aynı sitede gezinmeleri hariç tutmaz.)

Aşağıdaki filtreleri VE kullanılarak "SXG sayaçlı" adlı özel bir segment oluşturun:

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

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

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

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

LCP'yi kaydetmek için Google Analytics raporlama komut dosyanızı önerildiği gibi özelleştirin. gtag.js kullanıyorsanız özel boyutu ayarlamak için 'config' komutunu değiştirin ('dimension1' ve 'dimension2' yerine Google Analytics'in kullanmasını belirttiğ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ığı şekilde değiştirin.

Bazı verileri toplamak için birkaç gün bekledikten sonra, Google Analytics Etkinlikler raporuna gidin ve SXG segmenti için bir ayrıntılı inceleme ekleyin. "SXG'ler, sayfa görüntülemelerinin% X kadarını etkiler" bölümündeki X alanı doldurulmalıdır:

Son olarak, Web Verileri Raporu'na gidin, "Segment seçin"i, ardından "SXG karşı bilgiye dayalı" ve "SXG"yi seçin.

"Gönder"i tıkladığınızda iki segment için LCP dağılımlarını görürsünüz. Bu, "LCP'lerini 75. yüzdelik dilimde Y milisaniye iyileştirmek" için Y alanını doldurmalıdır:

Uyarılar

Yukarıdaki filtrelerin tümünü uyguladığınızda, SXG karşıolgusal sayfa yüklemeleri aşağıdakilere benzer olmalıdır:

• Önbellek eksik: Google SXG Önbelleğinde belirli bir URL için SXG'nin yeni bir kopyası yoksa sitenizdeki orijinal URL'ye yönlendirilir.
• Diğer sonuç türleri: Google Arama, şu anda standart web sonuçları ve birkaç başka tür için yalnızca SXG'yi desteklemektedir. Öne Çıkan Snippet'ler ve En Çok Okunan Haberler Bandı gibi diğerleri, sitenizdeki orijinal URL'ye bağlantı verir.
• Uygun olmayan URL'ler: Sitenizdeki bazı sayfalar SXG için uygun değilse (ör. önbelleğe alınabilir olmadıkları için) bu grupta gösterilebilir.

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

Sitenizde bazı AMP sayfaları varsa SXG'nin etkinleştirilmesi, bu sayfalar Google Arama'dan önceden alınabileceği için büyük olasılıkla performans artışı sağlamayacaktır. Bu tür sayfaları hariç tutmak ve alakalı değişiklikleri daha da "yakınlaştırmak" için filtre eklemeyi düşünebilirsiniz.

Son olarak, seçim yanlılığının tümünü ele almak olsa bile hayatta kalma yanlılığının LCP iyileştirmelerinin RUM istatistiklerinde düşüş gibi görünmesine yol açması riski vardır. Bu makale, söz konusu riski çok iyi açıklıyor ve böyle bir durum olup olmadığını tespit etmek için bir tür vazgeçme metriğine bakmanızı öneriyor.

Çalışmadan önce/sonra

Çağdaş çalışmadan elde edilen sonuçları desteklemek için SXG'nin etkinleştirilmesinden önce ve sonra LCP'nin karşılaştırmasını yapmak yararlı olabilir. Yukarıda belirtilen olası sapmaları ortadan kaldırmak için SXG sayfa görüntülemeleriyle sınırlamayın. Bunun yerine, isSXG kısıtlaması olmadan SXG'ye uygun sonuçlara (yukarıdaki segment tanımları) bakın.

Google Arama'nın, SXG'nin tüm sayfalar için etkinleştirildiğini belirlemek üzere sitenizdeki tüm sayfaları yeniden taramasının birkaç hafta sürebileceğini unutmayın. Bu birkaç haftada ortaya çıkabilecek başka olası sapmalar da vardır:

• Yeni tarayıcı sürümleri veya kullanıcıların donanımındaki iyileştirmeler sayfa yüklemelerini hızlandırabilir.
• Tatil gibi önemli bir olay, trafiği normalin dışına çıkarabilir.

Yukarıdaki çalışmaları doğrulamak için öncesinde ve sonrasında genel 75. yüzdelik dilim LCP'ye bakmak da yararlı olur. Nüfusun bir alt kümesi hakkında bilgi sahibi olmak bize nüfusun geneli hakkında bilgi vermez. Örneğin, SXG'nin sayfa yüklemelerinin% 10'unu 800 ms iyileştirdiğini varsayalım.

• Bunlar zaten en hızlı% 10 sayfa yüklemeleri ise 75. yüzdelik dilimi hiç etkilemez.
• En yavaş% 10 sayfa yüklemeleri olsaydı ancak bunlar başlangıçta 75. yüzdelik dilimdeki LCP'ye göre 800 ms'den daha yavaşsa bu durum 75. yüzdelik dilimi hiç etkilemez.

Bunlar uç örneklerdir ve muhtemelen gerçeği yansıtmaz, ancak soruna açıklık getirmelerini umuyoruz. Pratikte, SXG'nin çoğu site için 75. yüzdelik dilimi etkilemesi olasıdır. Siteler arası gezinmeler genellikle en yavaş çalışmalardan bazılarıdır ve önceden getirme kaynaklı iyileştirmeler önemli olmaya devam eder.

Bazı URL'leri devre dışı bırak

Son olarak, SXG performansını karşılaştırmanın bir yolu, sitenizdeki URL'lerin bir alt kümesi için SXG'yi devre dışı bırakmak olabilir. Örneğin, Cloudflare ASX'in SXG oluşturmasını önlemek için bir CDN-Cache-Control: no-store başlığı ayarlayabilirsiniz. Bunu önermem.

Muhtemelen diğer çalışma yöntemlerine kıyasla seçim yanlılığı riski daha yüksektir. Örneğin, sitenizin ana sayfasının veya benzer şekilde popüler olan bir URL'nin kontrol grubunda veya deneme grubunda seçilmesi büyük bir fark yaratabilir.

Engelleme çalışması

Etkiyi ölçmek için ideal yöntem, bir engelleme çalışması yapmaktır. Maalesef şu anda bu tür bir test yapamazsınız. Gelecekte bu tür bir test için destek sunmayı planlıyoruz.

Sağlama çalışması aşağıdaki özelliklere sahiptir:

• Deneme grubunda, SXG olabilecek sayfa görüntülemelerinin rastgele bir kısmı "ayırılıyor" ve bunun yerine SXG olmayan olarak yayınlanıyor. Bu sayede eşdeğer kullanıcılar, cihazlar, senaryolar ve sayfalar arasında "elmalar ile elmalar" karşılaştırması yapılabilir.
• Bu ayrılmış (karşı olgusal) sayfa görüntülemeleri, analizlerde bu şekilde etiketlenir. Bu, verilerin "yakınlaştırılmış" görünümüne olanak tanır. Böylece kontrol bölümündeki SXG sayfa yüklemelerini, denemedeki SXG karşı doğrulamasıyla karşılaştırabiliriz. Böylece, SXG önceden getirme işleminden etkilenmeyecek diğer sayfa yüklemelerinde gürültüyü azaltır.

Bu, LCP'de hayatta kalma yanlılığı riskini ortadan kaldırmasa da, yukarıda belirtilen olası seçim yanlılığı kaynaklarını ortadan kaldırır. Bu özelliklerin her ikisi de etkinleştirmek için tarayıcının veya yönlendirenin olmasını gerektirir.

Sonuç

Bora Sıkı çalıştınız. Bu aracın, SXG performansının laboratuvar testinde nasıl test edileceği, laboratuvar testiyle sıkı bir geri bildirim döngüsünde performansının nasıl optimize edileceği ve son olarak, performansın gerçek dünyada nasıl ölçüleceği konusunda daha kapsamlı bir görünüm sunacağını umuyoruz. Tüm bunları bir araya getirmek, SXG'lerden en iyi şekilde yararlanmanıza ve hem sitenize hem de kullanıcılarınıza fayda sağladığından emin olmanıza yardımcı olacaktır.

SXG performansını yakalama konusunda başka tavsiyeleriniz varsa lütfen bize bildirin. Önerdiğiniz iyileştirmeleri kullanarak developer.chrome.com adresinde hata bildiriminde bulunun.

İmzalı değişimler hakkında daha fazla bilgi için web.dev dokümanlarına ve Google Arama dokümanlarına bakın.