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

İmzalı takaslardan en iyi şekilde yararlanmak için nasıl ölçüm ve optimize edilir?

Devin Mullins

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

Ö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):

Not: Daha önce bu yayında 6 saniyeden 0, 9 saniyeye iyileşme görüldü. Bu doğrudu, ancak test edilen site o zamanlar normalde olduğundan daha yavaştı. Bununla birlikte, daha fazla alt kaynağa, daha yavaş sunuculara sahip kullanıcılara veya daha yavaş bağlantı türlerine sahip kullanıcıları temsil edebilir.

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

Çoğu durumda, bu özelliği etkinleştirmek için ilgili kutuyu işaretlemek, yukarıda gösterilen önemli türde iyileştirmeler için yeterli olacaktır. 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'in kullanıma sunulmasından bu yana geçen 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 olmalarını sağlamak için sitelere nasıl tavsiyede bulunabileceğimi öğreniyorum. Bu gönderi tavsiyelerimden derlenmiştir. 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 ayarını belirlemek ve oluşturmayı engelleyen alt kaynakları önceden yüklemek de 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; tümü Web PKI sertifikası tarafından kriptografik olarak imzalanmış bir URL, bir dizi HTTP yanıt başlığı ve yanıt gövdesi içeren bir dosyadır. Tarayıcı bir SXG yüklediğinde şunların tümünü doğrular:

• SXG'nin geçerlilik süresi dolmamış olmalıdır.
• İmza; URL, üstbilgi, gövde ve sertifika ile eşleşir.
• 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 değerlendirerek yükler. Bu, imzalandıktan sonra süresi dolmadığı veya değiştirilmediği sürece SXG'lerin herhangi bir sunucuda yeniden barındırılmasına olanak tanır.

Google Arama söz konusu olduğunda SXG, arama sonuçlarında sayfaların önceden getirilmesini etkinleştirir. Google Arama, SXG'leri destekleyen sayfalar için sayfanın webpkgcache.com adresinde barındırılan önbelleğe alınmış kopyasını önceden getirebilir. Tarayıcı orijinal, imzalı URL'ye saygı gösterdiğinden, 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.

Not: SXG'ler, bu makalede ele alınmayan diğer kullanım alanları için faydalı olabilir. Örneğin, bağlantı esnekliğini etkinleştirebilirler: Sayfa SXG'yi destekliyorsa sohbet uygulaması, kullanıcıya gönderilen bir bağlantıyı önceden indirebilir. Böylece, daha sonra çevrimdışıyken görüntüleyebilir. Olası kullanım alanlarının kapsamlı listesini inceleyin.

Analiz et

SXG'lerin avantajlarını görmek için öncelikle bir laboratuvar aracı kullanarak SXG performansını tekrarlanabilir koşullarda analiz edin. SXG önceden getirme işlemi etkinken ve olmadan şelaleleri ve LCP'yi karşılaştırmak için WebPageTest'i kullanabilirsiniz.

Dikkat: Laboratuvar sonuçları gerçek kullanıcı deneyimlerinden farklı olabilir ancak nerede optimizasyon yapılacağını ve hızlıca yineleme gerektiğini teşhis etmek açısından faydalı bir araçtır. Elde edilen gerçek kullanıcı metriklerinin nasıl ölçüleceğini Ölçüm bölümünde ele alacağız.

Aşağıdaki gibi SXG olmadan 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 olacak. Bu nedenle, burada kullanmanız test seçeneklerinin aynı olmasını sağlar.)
• Test Ayarları sekmesinde, Bağlantıyı 4G'ye ayarlamak ve "Çalıştırılacak Test Sayısı"nı artırmak yararlı olabilir 7'ye.
• 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 için, sayfanız henüz hiçbir Google Arama sonucunda görünmüyorsa, bu amaçla rol amaçlı bir arama sonuçları sayfası oluşturmak üzere bu önceden 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 Dizini'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ı Ayarla'yı tıklayın, iletişim kutusunun içini aşağı kaydırın ve Videoyu Görüntüle'yi tıklayın.

SXG önceden getirme işlemi başarılı olursa "with SXG" (SXG ile) şelalede HTML satırı bulunmaz ve alt kaynak getirme işlemleri daha erken başlar. Örneğin, "Öncelikle" ve "After" (Sonra) buradan inceleyebilirsiniz:

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 Optimize et bölümüne atlayabilirsiniz. Aksi takdirde, hatanın ardışık düzenin neresinde, 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. Bunun için bir tarayıcı gibi davranmanız gerekir. En kolay yol SXG Validator Chrome uzantısını kullanmaktır:

Not: SXG'ler, önceden getirmeyi etkinleştirmek için SXG özellikli tarayıcılara yöneliktir. Kullanıcılar sitenizi doğrudan ziyaret ettiğinde, önceden getirilmeyeceği için onlara SXG yayınlamamalısınız. Aksi takdirde, yalnızca ek yük getirirler. Cloudflare ASX, bu içerik anlaşmasını otomatik olarak gerçekleştirir.

Uzantı, mevcut URL'yi, SXG sürümünü tercih ettiğini belirten bir Accept istek başlığıyla getirir. Origin'in yanında bir onay işareti (✅) görürseniz bir SXG döndürüldü demektir; Dizine ekleme bölümüne geçebilirsiniz.

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

Cloudflare ASX etkinse çarpı işaretinin (❌) en olası nedeni ö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 herhangi birini içeriyorsa bir SXG oluşturulmasını engeller:

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

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.

Çarpı işaretinin (❌) bir başka olası nedeni de Set-Cookie hariç bu durum bilgili yanıt başlıklarından birinin varlığıdır. ASX, SXG spesifikasyonuna uymak için Set-Cookie başlığını kaldırır.

Not: Bu kısıtlamalar ASX kodunda daha ayrıntılı bir şekilde incelenebilir. Örneğin, önbellek kontrol üstbilgileri, ne zaman imzalanacağını ve imza süresinin ne kadar olması gerektiğini belirleyen kod tarafından incelenir. Diğer başlıklar bu yapılandırma tarafından veya bu kod kullanılarak imzalamadan önce kaldırılır. Diğer başlıklar başka şekilde sadeleştirilmemişse imzalamayı engeller.

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 bunları birden çok 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.

Not: Vary: Cookie kullanan sayfalar gelecekte yalnızca siteniz için çerezleri olmayan ziyaretçilere gösterilerek SXG tarafından desteklenecektir. Bu özellik Chromium'da uygulanır ve tam olarak kullanıma sunulduğunda Google Arama'da etkinleştirilecektir.

Chrome uzantısı yerine 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ılı bir şekilde dizine eklendiğinden emin olun. Chrome Geliştirici Araçları'nı açın, ardından sayfanız için Google araması yapın. Sayfa SXG olarak dizine eklendiyse Google'ın sayfanıza bağlantısında webpkgcache.com kopyasını işaret eden bir data-sxg-url yer alır:

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 indirme talimatı verir. Kullanıcı <a> öğesini tıkladığında, tarayıcı sayfayı oluşturmak için önbelleğe alınan SXG'yi kullanır.

Önceden getirme işleminin kanıtlarını, Geliştirici Araçları'ndaki Ağ sekmesine gidip webpkgcache içeren URL'leri arayarak da 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. Besleme bölümüne geçebilirsiniz.

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

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

Bir digest üst bilgisi yoksa bu, bir SXG'nin Googlebot'a sunulmadığını veya SXG'leri etkinleştirmenizden bu yana dizinin güncellenmediğinin göstergesi olabilir.

Bir SXG başarıyla tarandıysa ancak hâlâ bağlanmıyorsa bu durum SXG önbellek koşullarının karşılanamaması olabilir. Bunlar bir sonraki bölümde ele alınmıştır.

Besleme

Google Arama bir SXG'yi dizine eklediğinde kopyasını Google SXG Önbelleğine göndererek ö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'yi etkinleştirmeden önce olduğu gibi çalışır. Google, sayfaya SXG önceden getirme olmadan 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'deki Google geliştirici dokümanında, önbelleği manuel olarak sorgulama ile ilgili talimatlar da yer almaktadır.

Optimize etme

SXG Validator Chrome uzantısı tüm onay işaretlerini (✅) gösteriyorsa kullanıcılara sunabileceğiniz bir SXG 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.

maks. yaş

SXG'lerin süresi dolduğunda Google SXG Önbelleği, arka planda yeni bir kopya getirir. Bu getirme beklenirken kullanıcılar, önceden getirilmemiş olan orijinal ana makinesindeki sayfaya yönlendirilir. Cache-Control: max-age değerini ne kadar uzun süre ayarlarsanız arka planda getirme o kadar az gerçekleşir ve böylece önceden getirme ile LCP'nin düşürülme sıklığı o kadar artar.

Bu, performans ile güncellik arasında bir denge sağlar. Önbellek sayesinde site sahipleri, her sayfanın özel ihtiyaçlarına uygun olarak SXG'lere 2 dakika ile 7 gün arasında bir maksimum süre sağlayabilir. Analytics'te yaptığımız inceleme sonucunda şu sonuçları elde ederiz:

• max-age=86400 (1 gün) veya daha uzun bir süre performans için iyi sonuç verir
• max-age=120 (2 dakika) şunu yapmıyor:

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

Not: Önbellek temizleme API'si ekleyerek gelecekte bu dengenin daha kolay yönetilmesini planlıyoruz. Bu özellik webpackaging-announce bölümünde duyurulacaktır.

kullanıcı aracısı

Bir keresinde, önceden getirilen bir SXG kullanıldığında LCP artışı gözlemlemiştim. SXG önceden getirme işlemi olmadan ve bunları kullanmadan ortanca sonuçları karşılaştıran WebPageTest'i çalıştırdım. Aşağıda Sonra'yı tıklayın:

Önceden getirme işleminin ç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 LCP (yeşil kesikli çizgi) 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. Chrome, düz HTML'de "en büyük öğenin" büyük bir artış. 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şturuldu, ancak düzendeki bir değişiklik metriğin metriği daha yavaş olarak bildirmesine neden oldu.

Daha ayrıntılı inceleme yaptık ve düzendeki farkın, sayfanın User-Agent bazında değişmesi ve mantıkta bir hata olduğunu keşfettim. SXG tarama başlığında mobil olduğu belirtilse de masaüstü sayfası yayınlanıyordu. Bu sorun çözüldükten sonra tarayıcı, doğru şekilde sayfanın başlığını en büyük öğesi 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 geçerli olduğundan emin olun:

• Sayfanız User-Agent tarafından Vary yapılmıyor (ö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ü için not ekler.

Alt kaynaklar

SXG'ler, HTML ile birlikte alt kaynakları (resimler dahil) önceden getirmek 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. Kaynak kodundaki ayrıntılara buradan ve buradan ulaşabilirsiniz.

Ç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 öğeyi oluşturmak için kritik yolda hangi kaynakların olduğunu belirleyin. Önceden getirilemiyorsa kritik yoldan çıkarılıp çıkarılamayacaklarını değerlendirin. Yükleme işlemi tamamlanana kadar sayfayı gizleyen komut dosyalarına dikkat edin.

Google SXG Önbelleği 20'ye kadar alt kaynak önceden yüklenmesine 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 için önceden yüklenmiş alt kaynakları yalnızca tamamı getirme işlemini tamamladıysa kullanır. Ne kadar çok alt kaynak olursa kullanıcı sayfanızı tıklamadan önce bunların hepsinin önceden getirme işlemini tamamlamış olma olasılığı da o kadar azalır.

Not: ASX şu anda yalnızca aynı kaynaklı (birinci taraf) alt kaynaklar için önceden getirmeyi desteklemektedir. SXG'yi destekleyen üçüncü taraf alt kaynak sağlayıcıları biliyorsanız bu hatadan bize bildirin. Böylece kaynaklar arası destek eklemeye öncelik verebiliriz.

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

Ölçüm

WebPageTest'te LCP iyileştirmesini optimize ettikten sonra, SXG önceden getirmenin sitenizin genel performansı üzerindeki etkisini ölçmek yararlıdır.

Sunucu tarafı metrikleri

İlk Baytlama Süresi (TTFB) gibi sunucu tarafı metriklerini ölçerken, sitenizin yalnızca biçimi kabul eden tarayıcılara SXG'ler sunduğunu unutmamanız önemlidir. TTFB ölçümünüzü, botlardan değil gerçek kullanıcılardan gelen isteklerle sınırlayın. SXG oluşturmanın tarayıcı istekleri için TTFB'yi artırdığını fark edebilirsiniz, ancak bu durum ziyaretçilerinizin üzerinde herhangi bir etkisi olmaz. sahip olacaksınız.

İstemci tarafı metrikleri

SXG'ler, özellikle LCP olmak üzere istemci tarafı metrikler için en yüksek hız avantajını sunar. Etkilerini ölçerken Cloudflare ASX'i etkinleştirip Googlebot tarafından yeniden taranmasını bekleyebilir, Core Web Vitals (CWV) toplaması için 28 gün daha bekleyebilir ve yeni CWV sayılarınıza bakabilirsiniz. Ancak, bu zaman aralığında diğer tüm değişikliklerin arasına karıştığında, değişikliği fark etmek zor olabilir.

Bunun yerine yakınlaşmak” ekleyebilir ve bunu "SXG'ler sayfa görüntülemelerinin% X kadarını etkileyerek 75. yüzde birlik dilimde Y milisaniye düzeyinde LCP artışı sağlıyor" şeklinde çerçeve oluşturabilir.

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

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

ziyaret edin.

Not: Google Arama, masaüstü OS'leri ve daha fazlası dahil olmak üzere SXG önceden getirme işleminin gerçekleşebileceği bağlamları genişletmeyi planlıyor. Bu durum, zaman içinde% X'lik bir artışa neden olabilir. Ayrıca, bu değişikliğe uyum sağlamak için metriklerinizi güncellemek isteyebilirsiniz. Böyle bir durumda webpackaging-announce bölümünde duyurulacaktır.

"Sayfa görüntülemelerinin% X'i"nin nasıl ölçüleceğini öğrenmek için Güncel çalışma bölümünü okuyun. "LCP'lerini Y milisaniye iyileştirme".

Ç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 sırada, baktığınız sayfa yüklemeleri grubunu, seçim yanlılığını önlemek amacıyla SXG olmayan tarafın SXG'nin uygunluk koşullarıyla eşleşecek şekilde sınırlandırmanız önemlidir. Aksi takdirde, aşağıdakilerin tümü yalnızca, doğuştan farklı LCP'ye sahip olabilen SXG olmayan sayfa yükleme grubunda mevcut olur:

• iOS cihazlar: Bu cihazlara sahip kullanıcıların donanım veya ağ hızı farklılıklarından dolayı.
• Eski Chromium tarayıcıları: Aynı nedenlerle.
• Masaüstü cihazlar: Aynı nedenlerden dolayı veya sayfa düzeni farklı bir "en büyük öğeye" neden olduğundan seçilecek.
• Aynı sitede gezinmeler (site içindeki 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" adlı, "İsabet" kapsamıyla iki özel boyut oluşturun. ve biri "yönlendiren" olarak adlandırılmaktadır. (Yerleşik "Kaynak" boyutu oturum kapsamına sahip olduğundan aynı sitede gezinmeleri hariç tutmaz.)

"SXG karşı olgu" adlı bir özel segment oluşturun VE aşağıdaki filtreler bir arada tutulur:

• 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, 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'in 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 kaydetmek için Google Analytics raporlama komut dosyanızı önerildiği şekilde ö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ı önerilen adları yazın):

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

analytics.js kullanıyorsanız 'create' komutunu burada belgelendiği gibi 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. Bu, "SXG'ler sayfa görüntülemelerinin% X'ini etkiliyor" için X'i doldurmalıdır:

Son olarak, Web Vitals Raporu'na gidin, "Segment seçin"i ve "SXG karşı olgusu"nu seçin ve "SXG" gibi.

"Gönder"i tıklayın. İki segmentin LCP dağıtımlarını görürsünüz. Bu, "LCP'lerini 75. yüzdelik dilimde Y milisaniye oranında artırmak" için Y'yi doldurmalıdır:

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:

• Önbellekte yok: 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ç farklı tür için yalnızca SXG'yi desteklemektedir. Öne Çıkan Snippet'ler ve En Çok Okunan Haberler Bandı gibi diğer reklamlar, sitenizdeki orijinal URL'ye bağlantı verir.
• Uygun olmayan URL'ler: Sitenizdeki bazı sayfalar SXG için uygun değilse (ör. önbelleğe alınamadığı için) bu grupta görünebilir.

SXG sayfa yüklemeleri ile yukarıdaki SXG olmayan sayfa yüklemeleri arasında sapma olabilir. Ancak bu farkın boyutu, Güncel çalışma bölümünün üst kısmında belirtilen ağırlıklardan 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 sonuçlarının çalışmanın geneliyle eşleşip eşleşmediğini görmek için SXG'ye uygun belirli bir URL ile sınırlı verileri inceleyebilirsiniz.

Sitenizde bazı AMP sayfaları varsa bu sayfalar Google Arama'dan önceden getirilebildiği için muhtemelen SXG'nin etkinleştirilmesiyle performans artışı sağlanamayacaktır. Bu tür sayfaları daha fazla "yakınlaştırmak" için hariç tutmak üzere filtre ekleyebilirsiniz alakalı değişikliklere değinmekle yükümlüdür.

Son olarak, seçimle ilgili tüm ön yargılar giderilse bile hayatta kalma yanlılığının LCP iyileştirmelerinin RUM istatistiklerindeki düşüşler gibi görünmesine yol açabilir. 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ışma öncesi/sonrası

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ırlamayı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, sitenizdeki tüm sayfaları yeniden taramasının, söz konusu sayfalarda SXG'nin etkinleştirildiğinin belirlenmesi için birkaç hafta sürebileceğini unutmayın. Bu birkaç hafta içinde ortaya çıkabilecek başka potansiyel yanlılık da olabilir:

• Yeni tarayıcı sürümleri veya kullanıcı iyileştirmeleri donanımı sayfa yükleme işlemini hızlandırabilir.
• Tatil gibi önemli bir etkinlik, trafiği normalden sapmasına neden olabilir.

Yukarıdaki çalışmaları doğrulamak için öncesinde ve sonrasında genel 75. yüzdelik dilim LCP'ye bakmak da faydalı olacaktır. Nüfusun bir alt kümesi hakkında bilgi edinmek, bize her zaman genel nüfus 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üklemeleriyse bu durum 75. yüzdelik dilimi hiç etkilemeyecektir.
• En yavaş sayfa yüklemeleri% 10 ise ancak başlangıçta 75. yüzdelik dilim LCP'den 800 ms.den daha yavaşsa bu durum 75. yüzdelik dilimi hiç etkilemez.

Bunlar büyük olasılıkla gerçekleri yansıtmayan uç örneklerdir, ancak sorunu yansıttığını umuyoruz. Uygulamada, SXG'nin çoğu sitenin 75. yüzdelik dilimini etkilemesi muhtemeldir. Siteler arası gezinme, genellikle en yavaş olanlardır ve önceden getirme ile elde edilen iyileştirmeler önemli ölçüdedir.

Bazı URL'leri devre dışı 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ırakmak olabilir. Örneğin, Cloudflare ASX'in SXG oluşturmasını engellemek için bir CDN-Cache-Control: no-store başlığı ayarlayabilirsiniz. Bunu önermem.

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 veya benzer popülerlikteki bir URL'nin kontrol grubuna mı yoksa deneme grubuna mı seçilmesi, çok büyük bir fark yaratabilir.

Bekletme çalışması

Etkiyi ölçmenin ideal yolu, ayırma ç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.

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

• Deneme grubunda, sayfa görüntülemelerinin SXG olacak rastgele bir bölümü "bekletilir" ve bunun yerine SXG dışında bir ürün olarak sunulur. Bu, "elmalardan elmaya" benzer kullanıcılar, cihazlar, senaryolar ve sayfalar arasında karşılaştırma yapmak için kullanılır.
• Durdurulan (karşısayısal) sayfa görüntülemeleri, analizlerde bu şekilde etiketlenir. Bu özellik, görüntüleri yakınlaştırarak Burada, kontrol bölümündeki SXG sayfa yüklemelerini denemedeki SXG karşı gerçekleriyle karşılaştırabiliriz. 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 hayatta kalma yanlılığı riskini ortadan kaldırmaz. Bu özelliklerin her ikisi de, tarayıcının veya yönlendirenin etkinleştirilmesini gerektirir.

Sonuç

Bora Çok fazla çalıştım. Umarız bu araç; laboratuvar testinde SXG performansının 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 da gerçek dünyada SXG performansının nasıl ölçüleceği hakkında daha kapsamlı bilgi verir. Tüm bunları bir araya getirmek, SXG'lerden en iyi şekilde yararlanmanıza ve hem sitenizden hem de kullanıcılarınıza fayda sağlamanıza yardımcı olacaktır.

SXG performansını nasıl artırabileceğinizle ilgili daha fazla tavsiyeniz varsa lütfen bize bildirin. Önerdiğiniz iyileştirmelerle ilgili developer.chrome.com adresine hata bildiriminde bulunun.

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