İmzalı takaslardan en iyi şekilde yararlanmak için nasıl ölçüm ve optimize edilir?
İ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):
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):
![Otomatik İmzalı Takas'ı etkinleştirme onay kutusu içeren Cloudflare ayarlar paneli](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/cloudflare-settings-panel-5a154cefaeee.png?authuser=0000&hl=tr)
Ç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.
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.
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:
![URL dahil önbellek bilgilerini gösteren SXG Doğrulayıcı](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/sxg-validator-showing-cac-cd00f49c76676.png?authuser=0000&hl=tr)
Bu testler tamamlandıktan sonra Test Geçmişi'ne gidin, iki testi seçin ve Karşılaştır'ı tıklayın:
![İki testin işaretli olduğu ve Karşılaştır düğmesinin vurgulandığı Test Geçmişi](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/test-history-two-tests-c-c2bdb42542715.png?authuser=0000&hl=tr)
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:
![Bir onay işareti (✅) ve bir uygulama/İmzalı-exchange;v=b3 İçerik Türü gösteren SXG Doğrulayıcı](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/sxg-validator-showing-ch-663e5b3cc9f67.png?authuser=0000&hl=tr)
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:
![Çarpı işareti (❌) ve metin/html İçerik Türü gösteren SXG Doğrulayıcı](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/sxg-validator-showing-cr-555ac59fdd27f.png?authuser=0000&hl=tr)
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üçükmax-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.
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.
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:
![Webpkgcache.com adresine yönlendiren bir bağlantı etiketinin gösterildiği Geliştirici Araçları'nın yer aldığı Google Arama sonuçları](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/google-search-results-de-57d0db7b9c20a.png?authuser=0000&hl=tr)
Google Arama, kullanıcının sonucu tıklama olasılığının yüksek olduğunu düşünürse sonucu önceden getirir:
![webpkgcache.com için rel=prefetch gösteren bağlantıyı gösteren Geliştirici Araçları'nı içeren Google Arama sonuçları](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/google-search-results-de-3127d5a0a1ef9.png?authuser=0000&hl=tr)
<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:
![Search Console URL Denetleme aracı, Taranan Sayfayı Görüntüle'yi ve ardından Daha Fazla Bilgi'yi tıklayarak](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/search-console-url-inspec-3f054b4eeeef4.png?authuser=0000&hl=tr)
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 (✅) olmasına rağmen uyarı mesajı gösterilmeyen SXG Doğrulayıcı](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/sxg-validator-showing-ch-1282069b578ae.png?authuser=0000&hl=tr)
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:
![SXG Doğrulayıcı'da çarpı işareti (❌) ve şu uyarı mesajı gösteriliyor:](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/sxg-validator-showing-cr-69db2da79bd7b.png?authuser=0000&hl=tr)
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:
![Kum saati (⌛) ve uyarı mesajı gösterilmeyen SXG Doğrulayıcı](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/sxg-validator-showing-ho-dcbdc4694a3f.png?authuser=0000&hl=tr)
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ç verirmax-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.
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ındanVary
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:
![/sub/.../image.jpg dosyasının önceden yüklendiğini gösteren Geliştirici Araçları Ağı sekmesini içeren Google Arama sonuçları](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/google-search-results-de-50436b3876448.png?authuser=0000&hl=tr)
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.
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.)
"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.)
![Önerilen ayarlarla Google Analytics boyut düzenleyici](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/google-analytics-dimensio-f031123b0438f.png?authuser=0000&hl=tr)
"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ıyorBrowser
,Chrome
ile tam olarak eşleşiyorBrowser
Sürüm,^(9[8-9]|[0-9]{3})
normal ifadesiyle eşleşiyorisSXG
,false
ile tam olarak eşleşiyor
![Önerilen filtrelerle Google Analytics segment düzenleyici](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/google-analytics-segment-14980677de979.png?authuser=0000&hl=tr)
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:
![%12, 5 Benzersiz Etkinlik Gösteren SXG segmenti içeren Google Analytics Etkinlikleri raporu](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/google-analytics-events-r-cbf7d46bbd64e.png?authuser=0000&hl=tr)
Son olarak, Web Vitals Raporu'na gidin, "Segment seçin"i ve "SXG karşı olgusu"nu seçin ve "SXG" gibi.
![SXG karşı gerçek ve SXG seçimlerini içeren Web Verileri Raporu](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/web-vitals-report-select-d978e48f3498e.png?authuser=0000&hl=tr)
"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:
![SXG karşı olgusu ve SXG için LCP dağıtımlarını gösteren Web Verileri Raporu](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/web-vitals-report-showing-07708e1eca8c5.png?authuser=0000&hl=tr)
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.