Yayınlanma tarihi: 7 Mart 2025
Tahmin Kuralları API'si, kullanıcıların daha hızlı ve hatta anında sayfa gezinmeleri sunmak için gelecekteki sayfa gezinmelerini önceden getirerek veya önceden işleyerek performans artışı elde etmelerine olanak tanır.
API, özellikle kolay uygulanabilirlik göz önünde bulundurularak tasarlanmıştır ancak özellikle karmaşık sitelerin kullanmadan önce dikkat etmesi gereken bazı noktalar vardır. Bu kılavuz, site sahiplerinin bu hususları anlamasına yardımcı olur.
Planlama
Spekülasyon kurallarını uygulamadan önce, API'nin nasıl uygulanacağını (birkaç seçenek olduğundan) ve spekülasyonların maliyetlerini (hangi sayfalarda spekülasyon yapacağınız konusunda size yol gösterecek) göz önünde bulundurmanız faydalı olacaktır.
Spekülasyon kurallarını nasıl uygulayacağınıza karar verme
Veriye dayalı spekülasyon kurallarını sitenize nasıl uygulayacağınıza karar vermeniz gerekir. Bunun için kullanabileceğiniz çeşitli yöntemler vardır:
- Doğrudan sayfanın HTML'sinde
- JavaScript kullanma
- HTTP üst bilgisi kullanma
Sonuçta her yöntemin etkisi aynıdır ancak uygulama kolaylığı ve esneklik açısından avantajları olabilir.
Siteler kendilerine en uygun seçeneği belirlemeli ve gerekirse bu seçeneklerin bir kombinasyonunu kullanmalıdır. Alternatif olarak, bir eklenti (ör. WordPress için Tahmini Yükleme eklentisi) veya kitaplıklar ya da platformlar kullanılarak da uygulanabilir. Bu seçenekler sizin için seçim yapabilir ancak yine de mevcut seçeneklerden haberdar olmanız faydalı olacaktır.
Spekülasyon kurallarını doğrudan sayfanın HTML'sine dahil etme
Spekülasyon Kuralları, HTML'ye <script type="speculationrules"> öğesi ekleyerek doğrudan sayfaya uygulanabilir. Bu, şablon kullanan statik siteler için derleme sırasında veya sayfa istendiğinde sunucu tarafından çalışma zamanında eklenebilir. Hatta uç çalışanlar tarafından HTML'ye eklenebilirler (ancak bu kılavuzun ilerleyen bölümlerinde açıklanan HTTP üst bilgisi yöntemi muhtemelen bunun için daha kolaydır).
Bu, sitenin tamamına statik kurallar eklemenize olanak tanır ancak belge kuralları, CSS sınıfları tarafından tetiklenecek kuralları kullanarak sayfadan oluşturulacak URL'leri seçmenize olanak tanıyarak dinamik olmaya devam edebilir:
<script type="speculationrules">
{
"prerender": [{
"where": { "selector_matches": ".prerender" }
}],
"prefetch": [{
"where": { "selector_matches": ".prefetch" }
}]
}
</script>
Önceki komut dosyası, prerender sınıfına sahip bağlantıları önceden oluşturur ve benzer şekilde, bağlantıda prefetch sınıfı varsa ön besleme yapar. Bu sayede geliştiriciler, spekülasyonları tetiklemek için bu sınıfları HTML'ye dahil edebilir.
Bu sınıfların bağlantıları, sayfanın ilk HTML'sine dahil edilmenin yanı sıra, uygulamanız tarafından dinamik olarak eklenirse de tahmin edilir. Bu sayede uygulamanız, gerektiğinde tahminleri tetikleyebilir (ve kaldırabilir). Bu, daha spesifik spekülasyon kuralları oluşturmaktan veya kaldırmaktan daha kolay olabilir. Sitenin çoğu tarafından kullanılan bir temel kural ve sayfaya özel kurallar istiyorsanız sayfa başına birden fazla spekülasyon kuralı da ekleyebilirsiniz.
Alternatif olarak, daha spesifik spekülasyon kuralları kullanmanız gerekiyorsa sayfaya veya şablona özel kurallar, belirli sayfalar ya da sayfa türleri için farklı kurallara izin verebilir.
Son olarak, sunucu tarafında oluşturulan sayfalar, sunucuya sunulan bilgilere (ör. ilgili sayfanın analiz bilgileri veya belirli sayfalar için ortak kullanıcı yolculukları) dayalı daha dinamik kurallara da sahip olabilir.
JavaScript kullanarak spekülasyon kuralları ekleme
Kuralları sayfa içi bir komut dosyasına eklemenin alternatifi, JavaScript kullanarak eklemektir. Bu sayede sayfa şablonlarında daha az güncelleme yapmanız gerekebilir. Örneğin, kuralları bir etiket yöneticisinin eklemesi, spekülasyon kurallarını kullanıma sunmanın hızlı bir yolu olabilir (ve gerekirse bunları hızlıca devre dışı bırakmanıza da olanak tanır).
Bu seçenek, kullanıcının sayfayla nasıl etkileşime geçtiğine bağlı olarak dinamik, istemci tarafı kurallara da olanak tanır. Örneğin, kullanıcı sepete bir öğe eklerse ödeme sayfasını önceden oluşturabilirsiniz. Alternatif olarak, belirli koşullara göre spekülasyonları tetiklemek için de kullanılabilir. API, temel etkileşime dayalı kurallara izin veren bir isteklilik ayarı içerirken JavaScript, geliştiricilerin ne zaman ve hangi sayfalarda tahminde bulunacağına karar vermek için kendi mantıklarını kullanmalarına olanak tanır.
Daha önce de belirtildiği gibi, yeni kurallar eklemenin alternatif bir yaklaşımı, sayfa üzerinde bir temel doküman kuralı bulundurmak ve JavaScript'in, bağlantılara uygun sınıflar ekleyerek doküman kurallarını tetiklemesini sağlamaktır. Böylece bağlantılar kuralla eşleşir.
HTTP üst bilgisi kullanarak spekülasyon kuralları ekleme
Geliştiriciler için son seçenek, kuralları bir HTTP başlığı kullanarak eklemektir:
Speculation-Rules: "/speculationrules.json"
Kurallar kaynağının (bu örnekte /speculationrules.json) nasıl yayınlandığı ve kullanıldığıyla ilgili bazı ek şartlar vardır.
Bu seçenek, belge içeriklerinde değişiklik yapmanıza gerek kalmadan CDN'lerin daha kolay dağıtımını sağlar. Bu, spekülasyon kurallarını JavaScript kullanarak dinamik olarak değiştirmenin bir seçenek olmadığı anlamına gelir. Ancak CSS seçici tetikleyicileri içeren belge kuralları, dinamik değişikliklere (ör. bir bağlantıdan prerender sınıfının kaldırılması) yine izin verebilir.
JavaScript seçeneğine benzer şekilde, spekülasyon kurallarını bir HTTP başlığıyla uygulamak, bu kuralların sitenin içeriğinden bağımsız olarak uygulanmasını sağlar. Bu da siteyi tamamen yeniden oluşturmadan kuralları eklemeyi ve kaldırmayı kolaylaştırabilir.
Maliyet etkilerini göz önünde bulundurun
Spekülasyon kurallarını uygulamadan önce, bu API'nin hem kullanıcılarınız hem de siteniz için maliyet etkilerini değerlendirmek için biraz zaman ayırmanız faydalı olacaktır. Maliyetlere bant genişliği (hem kullanıcılara hem de sitelere maliyetli!) ve işleme maliyetleri (hem istemci hem de sunucu tarafında) dahildir.
Kullanıcılar için maliyeti göz önünde bulundurun
Tahmini yükleme, kullanıcının yeni bir sayfaya gidebileceği yer hakkında bilgili bir tahminde bulunma anlamına gelir. Ancak bu gezinme gerçekleşmezse kaynakları boşa harcamış olabilirsiniz. Bu nedenle, kullanıcılar üzerindeki etkiyi göz önünde bulundurmanız gerekir. Özellikle:
- Gelecekteki bu gezinme öğelerini indirmek için kullanılan ek bant genişliği (özellikle bant genişliğinin daha kısıtlı olabileceği mobil cihazlarda).
- Ön oluşturma kullanılırken bu sayfaları oluşturmak için ek işleme maliyetleri.
Tamamen doğru tahminlerde, ziyaretçiler bu sayfaları daha sonra ziyaret edeceğinden ek maliyet yoktur. Tek fark, bu maliyetlerin önceden yüklenmesidir. Ancak geleceği tam olarak tahmin etmek imkansızdır ve spekülasyon stratejisi ne kadar agresif olursa israf riski de o kadar yüksek olur.
Chrome bu sorunu dikkatlice ele aldı ve API'de maliyetin düşündüğünüzden çok daha düşük olduğu anlamına gelen çeşitli özellikler yer alıyor. Özellikle HTTP önbelleğini yeniden kullanarak ve çapraz kaynaklı iFrame'leri yüklemeyerek, aynı sitedeki bir gezinme öğesinin önceden oluşturulması maliyeti genellikle önbelleğe alınmış kaynakların olmadığı tam bir sayfanın maliyetinden çok daha düşüktür. Bu da spekülatif yüklemeleri sanıldığından daha az maliyetli hale getirir.
Ancak bu önlemlere rağmen sitelerin hangi sayfaların spekülasyona tabi tutulacağını ve bu spekülasyonların kullanıcı maliyetini dikkatlice değerlendirmesi gerekir. Tahmini yükleme için iyi adaylar, yüksek güven düzeyiyle makul bir şekilde tahmin edilebilecek (belki de analizlere veya ortak kullanıcı yolculuklarına dayalı) ve maliyetin düşük olduğu (ör. daha az zengin sayfalar) öğelerdir.
Ayrıca, etkinleştirmeye kadar hangi JavaScript'in erteleneceğini de göz önünde bulundurabilirsiniz. İhtiyaç duyulana kadar içeriği gecikmeli yüklemeye benzer şekilde, bu işlem ön oluşturma işlemlerini daha ucuz hale getirebilir ancak çok daha iyi bir kullanıcı deneyimi sunabilir. Daha ucuz spekülasyonlarla daha sık veya hevesle spekülasyon yapabilirsiniz.
Bu mümkün olmadığında, orta veya muhafazakar isteklilik kuralları kullanan daha az agresif bir strateji önerilir. Alternatif olarak, güven düzeyi düşük olduğunda ön oluşturmaya kıyasla önemli ölçüde daha düşük maliyetli olan ön yüklemeyi kullanabilir ve ardından güven düzeyi artarsa (ör. fareyle bağlantının üzerine gelindiğinde veya bağlantı tıklandığında) tam ön oluşturmaya geçebilirsiniz.
Ek arka uç yükünü göz önünde bulundurun
Site sahipleri, kullanıcıdan gelen ek maliyetlerin yanı sıra kendi altyapı maliyetlerini de göz önünde bulundurmalıdır. Her sayfa iki, üç veya daha fazla sayfa yüklemesiyle sonuçlanıyorsa bu API'nin kullanılması arka uç maliyetlerini artırabilir.
Sayfalarınızın ve kaynaklarınızın önbelleğe alınabilir olmasını sağlamak, kaynak yükünün miktarını ve dolayısıyla genel riski önemli ölçüde azaltır. CDN ile birlikte kullanıldığında, kaynak sunucularınızda çok az ek yük oluşur. Ancak CDN maliyeti artışlarını göz önünde bulundurun.
sec-purpose HTTP üstbilgisi tarafından tanımlanan spekülasyon sonuçlarını kontrol etmek için bir sunucu veya CDN de kullanılabilir. Örneğin, Cloudflare'ın Speed Brain ürünü yalnızca bir CDN'nin uç sunucusunda önbelleğe alınmış spekülasyonlara izin verir ve isteklerini kaynağa geri göndermez.
Ancak, spekülatif yüklemeler genellikle aynı kaynaktan sayfa yüklemeleri için kullanıldığından, kullanıcıların tarayıcılarının önbelleği zaten paylaşılan kaynaklara sahiptir (önbelleğe alınabilir oldukları varsayılır). Bu nedenle, spekülasyon genellikle tam sayfa yükleme kadar maliyetli değildir.
Çok fazla veya çok az spekülasyon yapma arasında denge kurma
Spekülasyon Kuralları API'sinden en iyi şekilde yararlanmanın anahtarı, çok fazla spekülasyon yapma (yani maliyetlerin gereksiz yere ödendiği ve spekülasyonun kullanılmadığı durumlar) ile çok muhafazakar olma (çok az veya çok geç spekülasyon yapıldığında çok az fayda elde edildiği durumlar) arasında denge kurmaktır.
Maliyetlerin düşük olduğu durumlarda (ör. CDN uç düğümlerinde önbelleğe alınan küçük, statik olarak oluşturulmuş sayfalar) spekülasyonlar konusunda daha agresif olabilirsiniz.
Ancak CDN kenarında önbelleğe alınamayacak büyük ve zengin sayfalar için daha fazla özen gösterilmelidir. Benzer şekilde, yoğun kaynak kullanan sayfalar ağ bant genişliğini veya işlem gücünü tüketebilir. Bu da mevcut sayfayı olumsuz yönde etkileyebilir. API'nin amacı performansı iyileştirmek olduğundan performansta gerileme kesinlikle istemeyiz. Bu, ön oluşturma sayısını en fazla bir veya iki sayfayla sınırlamanın bir başka nedenidir (Chrome'un, istekliliğe bağlı olarak bir seferde iki veya on ön oluşturma işlemiyle sınırlı olduğunu da unutmayın).
Spekülasyon kurallarını uygulama adımları
Spekülasyon kurallarını nasıl uygulayacağınıza karar verdikten sonra, neyi tahmin edeceğinizi ve bunu nasıl kullanıma sunacağınızı planlamanız gerekir. Statik kişisel bloglar gibi daha basit siteler, belirli sayfaların tam ön oluşturma işlemine doğrudan atlayabilir ancak daha karmaşık sitelerde dikkate alınması gereken ek karmaşıklıklar vardır.
Ön getirme ile başlayın
Ön getirme, çoğu site için genellikle nispeten güvenli bir şekilde uygulanabilir. Cloudflare ve WordPress gibi büyük ölçekli kullanıma sunma işlemleri de dahil olmak üzere birçok kişi tarafından ilk yaklaşım olarak tercih edilir.
Dikkat edilmesi gereken en önemli sorunlar, bir URL'nin önceden getirilmesi durumunda, özellikle önbelleğe alınamayan sayfalar için durum değişikliklerine ve sunucu tarafı maliyetlere neden olabileceğidir. İdeal olarak durum değişiklikleri (örneğin, bir /logout sayfasının önceden getirilmesi) GET bağlantıları olarak uygulanmamalıdır ancak maalesef bu durum web'de yaygındır.
Aşağıdaki URL'ler kurallardan özel olarak hariç tutulabilir:
<script type="speculationrules">
{
"prefetch": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Ön getirmeler, moderate veya conservative eagerness ayarını kullanarak bir sayfadan diğerine yapılan yaygın gezinmelerle veya fareyle üzerine gelindiğinde ya da tıklandığında aynı kaynaktaki tüm bağlantılarla sınırlanabilir. conservative ayarı en düşük riski taşır ancak potansiyel ödülü de en düşüktür. Buradan başlıyorsanız en azından moderate'e geçmeyi hedefleyin. İdeal olarak eager'e geçmeniz daha fazla performans avantajı sağlar (ve ardından uygun olduğunda prerender'e yükseltme yapabilirsiniz).
Düşük riskli ön oluşturma işlemleri
Önceden getirme tahminlerinin dağıtılması daha kolaydır ancak API'nin performansına en büyük katkıyı önceden oluşturma sağlar. Sayfa, tahminden kısa bir süre sonra ziyaret edilmediğinde bu durum bazı ek hususları beraberinde getirebilir (bunları bir sonraki bölümde ele alacağız). Ancak moderate veya conservative ön oluşturma işleminde, gezinmenin kısa bir süre sonra gerçekleşme olasılığı yüksek olduğundan sonraki adım nispeten düşük riskli olabilir.
<script type="speculationrules">
{
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
İsteksiz ön oluşturma işlemlerini iyileştirmek için sık kullanılan sayfaları önceden getirme
Sık ziyaret edilen bir sonraki sayfaların daha az sayıdasını eager ayarıyla (URL listesinde belirterek veya selector_matches'ü kullanarak) yükleme sırasında ön beslemek ve ardından moderate ayarıyla ön oluşturma yapmak yaygın bir taktiktir. HTML ön getirme işlemi, fareyle bağlantının üzerine gelindiğinde tamamlanmış olacağından, bu işlem ön getirme olmadan fareyle üzerine gelindiğinde ön oluşturmaya kıyasla daha iyi performans sağlar.
<script type="speculationrules">
{
"prefetch": [{
"urls": ["next.html", "next2.html"],
"eagerness": "eager"
}],
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Önceki ön oluşturma işlemleri
moderate doküman kuralları, API'nin nispeten düşük riskli bir şekilde kullanılmasına ve kolayca uygulanmasına olanak tanısa da bu genellikle tam bir ön oluşturma için yeterli zaman değildir. Bu API'nin izin verdiği anında gezinme özelliğini elde etmek için muhtemelen bunun ötesine geçmeniz ve sayfaları daha hevesli bir şekilde önceden oluşturmanız gerekir.
Bu, statik bir URL listesi (önceki ön getirme örneği gibi) veya selector_matches ile az sayıda URL'nin (ideal olarak bir veya iki sayfa) tanımlanmasıyla ve diğer URL'leri kapsayan doküman kurallarıyla elde edilir:
<script type="speculationrules">
{
"prerender": [
{
"where": {
"selector_matches": : ".prerender"
},
"eagerness": "eager",
},
{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}
]
}
</script>
Bu, bir sonraki gezinme işlemini doğru şekilde tahmin etme şansını artırmak için trafik analizi yapılmasını gerektirebilir. Sitenizdeki tipik müşteri yolculuklarını anlamak, tahmini yükleme için iyi adaylar belirlemenize de yardımcı olabilir.
Daha istekli ön oluşturmaya geçmek, analizler, reklamlar ve JavaScript ile ilgili daha fazla hususu da gündeme getirebilir. Ayrıca, ön oluşturulmuş bir sayfayı güncel tutma veya hatta durum değişiklikleriyle ilgili tahminleri iptal etme ya da yenileme ihtiyacı da ortaya çıkabilir.
Analytics, reklamlar ve JavaScript
Daha karmaşık siteler, ön oluşturma özelliğini kullanırken analizlere olan etkiyi de göz önünde bulundurmalıdır. Genellikle, sayfa spekülasyona uğradığında ve yalnızca spekülasyon etkinleştirildiğinde sayfa (veya reklam) görüntülemesini günlüğe kaydetmek istemezsiniz.
Bazı analiz sağlayıcılar (ör. Google Analytics) ve reklam sağlayıcılar (ör. Google Yayıncı Etiketi) spekülasyon kurallarını zaten destekliyor ve sayfa etkinleştirilene kadar görüntülemeleri günlüğe kaydetmiyor. Ancak, uyguladığınız diğer sağlayıcılar veya özel analizler için ek değerlendirme gerekebilir.
Sayfalar etkinleştirilene veya görünür hale gelene kadar belirli kod parçalarının yürütülmesini önlemek için JavaScript'e kontroller ekleyebilir ve hatta <script> öğelerinin tamamını bu tür kontrollere sarmalayabilirsiniz. Sayfaların bu tür komut dosyalarını eklemek için etiket yöneticileri kullandığı durumlarda, etiket yöneticisi komut dosyasını geciktirerek bunların tümünü tek seferde ele almak mümkün olabilir.
Benzer şekilde, kullanıcı rızası yöneticileri, üçüncü taraf komut dosyalarını etkinleştirmeye kadar erteleme fırsatı sunar. Google, çeşitli kullanıcı rızası yöneticisi platformlarıyla birlikte çalışarak bu platformları ön oluşturma bilincine sahip hale getirmeye çalışıyor. Aynısını yapmak isteyen diğer kullanıcılara yardımcı olmaktan memnuniyet duyarız. PubTech, geliştiricilere ön oluşturma sırasında JavaScript'lerini çalıştırma veya engelleme seçeneği sunan bu tür şirketlerden biridir.
Uygulama kodu için de benzer şekilde, kodun yürütülmesini etkinleştirmeye kadar ertelemek üzere bir değişiklik ekleyebilirsiniz. Bu özellikle, sayfanın JavaScript kodunun oluşturulmasını gerektirmediği durumlarda önemlidir. Bu daha hızlı ve daha güvenli bir seçenektir ancak etkinleştirildiğinde tüm kodun bir kerede çalışacağı anlamına gelir. Bu durum, özellikle sayfa tamamen yüklenmiş ve etkileşime hazır göründüğü için etkinleştirme sırasında çok fazla çalışma yapılmasına neden olabilir ve INP'yi etkileyebilir.
Ayrıca, herhangi bir içerik JavaScript'e bağlıysa (ör. istemci tarafında oluşturulan içerik) bu işlemin geciktirilmesi, ön oluşturmanın LCP ve CLS üzerindeki olumlu etkisini azaltır. Ön oluşturma aşamasında daha fazla JavaScript'in çalışmasına izin veren daha hedefli bir yaklaşım, daha iyi bir deneyim sağlar ancak uygulanması daha zor olabilir.
Başlangıçta daha karmaşık siteler için birçok komut dosyası etiketini tamamen geciktirmek iyi bir strateji olabilir. Ancak API'den en iyi şekilde yararlanmak için ön oluşturma sırasında mümkün olduğunca fazla JavaScript'in çalıştırılmasına izin vermek nihai hedef olmalıdır.
Analiz veya reklamlarla ilgili endişeleri olan siteler, ön oluşturmayı desteklemek için yapılması gerekenleri değerlendirirken bu sorunların daha az olduğu ön beslemeyi kullanmaya başlayabilir.
Önizleme tahminlerini güncelleme
Sayfalar gezinmeden önce önceden oluşturulduğunda, önceden oluşturulmuş sayfanın güncelliğini kaybetme riski vardır. Örneğin, bir e-ticaret sitesinde önceden oluşturulmuş bir sayfa, ödeme sepeti içerebilir. Bu sepette öğeler bulunabilir veya diğer sayfalardaki sepetteki öğe sayısını gösteren bir sayaç bulunabilir. Alışveriş sepetine daha fazla öğe eklendikten sonra önceden oluşturulmuş bir sayfaya gidilirse kullanıcının eski ödeme durumunu görmesi kafa karıştırıcı olur.
Bu yeni bir sorun değil ve kullanıcılar tarayıcıda birden fazla sekme açtığında aynı sorunu yaşarlar. Ancak kullanıcı, ön oluşturmayı bilinçli olarak başlatmadığı için ön oluşturulmuş sayfalarda bu durum hem daha olası hem de daha beklenmediktir.
Broadcast Channel API, tarayıcıdaki bir sayfanın bu tür güncellemeleri diğer sayfalara yayınlamasına izin vermenin bir yoludur. Bu işlem, birden fazla sekme sorununu da çözer. Önceden oluşturulmuş sayfalar, yayın mesajlarını dinleyebilir ancak etkinleştirilene kadar kendi yayın mesajlarını gönderemez.
Alternatif olarak, önceden oluşturulmuş sayfalar sunucuyu kullanarak (düzenli bir fetch() veya WebSocket bağlantısı kullanarak) güncelleme alabilir ancak güncellemelerde gecikme olabilir.
Önizleme tahminlerini iptal etme veya yenileme
Önceden oluşturulmuş sayfaları güncellemek, kullanıcıların kafasını karıştırmadan önceden oluşturulmuş sayfaları kullanmaya devam etmek için önerilen yaklaşımdır. Bu mümkün olmadığında spekülasyonları iptal edebilirsiniz.
Bu, sitelerin ziyaret edilme olasılığı daha yüksek olan diğer sayfaları önceden oluşturmak istemesi durumunda Chrome'un sınırları içinde kalmak için de kullanılabilir.
Spekülasyonları iptal etmek için spekülasyon kurallarını sayfadan kaldırmanız veya bu yaklaşımı kullanıyorsanız sınıfları ya da diğer eşleme ölçütlerini kaldırmanız gerekir. Alternatif olarak, tahmin edilen sayfa artık geçerli olmadığını algılarsa window.close()'ü çağırabilir. Ancak sayfa bunu algılayabiliyorsa daha iyi bir seçenek, durumunu güncelleyerek tekrar güncel hale getirmektir.
Sayfaların yeniden ön oluşturulabilmesi için bu kuralları (veya eşleşme ölçütlerini) yeniden eklemek de mümkündür (ancak yine de, daha az kaynak tükettiği için mevcut bir sayfayı güncel tutmak genellikle daha iyi bir seçenektir). Tahmin kuralları kaldırıldıktan sonra, tarayıcının kaldırma işlemlerini fark etmesine ve tahminleri iptal etmesine izin vermek için yeniden ekleme işlemi yeni bir mikro görevde veya daha sonra tamamlanmalıdır. Tüm spekülasyon kuralı komut dosyalarını silmek ve kaldırmak için kullanılabilecek bir yaklaşım aşağıdaki örnekte gösterilmektedir:
async function refreshSpeculations() {
const speculationScripts = document.querySelectorAll('script[type="speculationrules"]');
for (const speculationScript of speculationScripts) {
// Get the current rules as JSON text
const ruleSet = speculationScript.textContent;
// Remove the existing script to reset prerendering
speculationScript.remove();
// Await for a microtask before re-inserting.
await Promise.resolve();
// Reinsert rule in a new speculation rules script
const newScript = document.createElement('script');
newScript.type = 'speculationrules';
newScript.textContent = ruleSet;
console.log(newScript);
// Append the new script back to the document
document.body.appendChild(newScript);
}
}
Kurallar kaldırıldığında mevcut iddiacılar (veya ön getirmeler) iptal edilir ancak kurallar yeniden eklendiğinde yalnızca anında veya istekli kurallar (anında varsayılanını kullanan URL listesi kuralları dahil) tahmin edilir. Bununla birlikte, ılımlı veya muhafazakar spekülasyonlar kaldırılır ancak bağlantıyla tekrar etkileşime geçilene kadar otomatik olarak yeniden tetiklenmez.
Bu yenileme seçeneği, JavaScript ile eklenen kurallarla sınırlı değildir. Standart bir DOM değişikliği olduğu için HTML'ye dahil edilen statik kurallar da aynı şekilde kaldırılabilir veya değiştirilebilir. HTTP spekülasyonu kuralları kaldırılamaz ancak eşleşme ölçütleri (örneğin, prerender sınıfları) kaldırılabilir ve JavaScript tarafından yeniden eklenebilir.
Chrome, sunucu yanıtlarının ön oluşturma işlemlerini iptal etmesine (ör. güncelleme sepeti isteği gönderildiğinde) izin vermek için Clear-Site-Header desteğini de eklemeyi düşünüyor.
Etkiyi ölçme
Spekülasyon kurallarını uyguladıktan sonra, otomatik olarak daha hızlı olduğunu varsaymak yerine başarıyı ölçmeniz gerekir. Daha önce de belirtildiği gibi, istemci veya sunucu aşırı yüke girerse aşırı spekülasyon performansın azalmasına neden olabilir.
Birden fazla adımda (ön besleme, düşük riskli ön oluşturma ve ardından erken ön oluşturma) uygularken her adımda ölçüm yapmanız gerekir.
Başarıyı ölçme
Spekülasyon kuralları, LCP gibi temel performans metrikleri (ve muhtemelen CLS ve INP) üzerinde olumlu bir etkiye sahip olmalıdır ancak bu durum site düzeyindeki genel metriklerde belirgin olmayabilir. Bunun nedeni, sitelerin ağırlıklı olarak diğer gezinme türlerinden (ör. açılış sayfaları) oluşması veya aynı kaynaktaki gezinmelerin zaten yeterince hızlı olması ve Chrome Kullanıcı Deneyimi raporunda (CrUX) belirtilen 75. yüzdelik dilim metriklerinin, bu gezinmelerin önemli ölçüde iyileştirilmesi durumunda bile etkilenmeyebileceğidir.
Gezinmelerin yüzde kaçının navigate_cache veya prerender olduğunu ve bu oranın zaman içinde artıp artmadığını kontrol etmek için CrUX'taki sayfa gezinme türlerini kullanabilirsiniz. Ancak ayrıntılı analiz için, verilerinizi tahmini gezintilere segmentlere ayırarak diğer gezintilere kıyasla ne kadar daha hızlı olduklarını görmek üzere gerçek kullanıcı izlemeyi kullanmanız gerekebilir.
Kullanımı ve israfı ölçme
Doğru sayfalarda spekülasyon yapıp yapmadığınızı ölçmek de önemli bir konudur. Bu sayede hem israfı önler hem de bu API'den en iyi şekilde yararlanmak için en iyi sayfaları hedeflediğinizden emin olabilirsiniz.
Ne yazık ki tahminleri başlatan sayfa, tahmin denemelerinin durumunu doğrudan göremez. Ayrıca tarayıcı belirli durumlarda tahminleri bekletebileceği için denemelerin tetiklendiği varsayılmaz. Bu nedenle, bu metrikler sayfanın kendisinde ölçülmelidir. Ayrıca, sayfanın spekülasyon yapıp yapmadığını veya spekülasyon yapıp yapmadığını görmek için iki API'nin kontrol edilmesi gerekir:
if (document.prerendering) {
console.log("Page is prerendering");
} else if (performance.getEntriesByType("navigation")[0]?.activationStart > 0) {
console.log("Page has already prerendered");
} else {
console.log("This page load was not using prerendering");
}
Bu sayfa, spekülasyon girişimini arka uç sunucularına kaydedebilir.
Analytics ile ilgili bir sorun, önceden oluşturmaya duyarlı olan ve sayfa etkinleştirilene kadar Analytics çağrılarını (hatta ayrı etkinlik çağrılarını) yok sayan sağlayıcılardır (Google Analytics gibi). Bu nedenle, Google Analytics kullanıcılarının sunucu tarafı günlük kaydı seçeneği için başka bir seçenek kullanması gerekir.
Bu işlem istemci tarafında da yapılabilir. Bu durumda, önceden oluşturulmuş her sayfa, önceden oluşturulmuş sayfayı paylaşılan depolama alanında kaydeder ve çağıran sayfa bunu okur. localStorage, bir sayfadan ayrılırken okunabildiği için en iyi sonucu verir (sessionStorage, önceden oluşturulmuş sayfalar için özel işleme sahip olduğundan kullanılamaz). Ancak localStorage değerinin işlem açısından güvenli olmadığını ve birden fazla sayfa önceden oluşturuluyorsa diğer sayfaların da aynı anda bu değeri güncelleyebileceğini unutmayın. Bu demo, bu tür sorunları önlemek için benzersiz bir karma oluşturma işlemi ve ayrı girişler kullanır.
Sonuç
Spekülasyon kuralları, sayfa performansınızda önemli bir artış elde etmenizi sağlar. Bu kılavuzda, olası sorunları önlemek ve API'den en iyi şekilde yararlanmak için bu API'yi uygularken dikkat edilmesi gereken noktalar hakkında öneriler verilmektedir.
Uygulamayı önceden planlamak, yeniden çalışmayı önler. Özellikle daha karmaşık siteler için, düşük riskli ön oluşturmaya ve ardından erken ön oluşturmaya geçmeden önce ön beslemeyle başlayan çok adımlı bir kullanıma sunma işlemi yapılmalıdır. Son olarak, API'yi en iyi şekilde kullandığınızdan emin olmak için iyileştirmeleri, kullanımları ve israfları ölçmek önemlidir.