Speculation Rules API Nedir? Tıklamadan Önce Sayfa Hızlandırma

Bir kullanıcı bağlantıya tıkladığında tarayıcı normalde hedef sayfanın HTML belgesini istemeye, gerekli dosyaları indirmeye ve sayfayı oluşturmaya ancak o anda başlar. Speculation Rules API ise yüksek olasılıkla ziyaret edilecek bir sonraki sayfa için bu işlerin bir bölümünü daha erken başlatmayı mümkün kılar. Doğru kullanıldığında geçişler belirgin biçimde hızlanabilir; yanlış kullanıldığında ise gereksiz bant genişliği, işlemci tüketimi ve sunucu yükü oluşturabilir.

Bu rehber, API'nin genel site hızlandırma tekniklerinden farkını; prefetch ve prerender seçeneklerini; kuralların nasıl sınırlandırılacağını ve canlı bir projede hangi kontrol adımlarıyla uygulanması gerektiğini açıklar. Konu, özellikle çok sayfalı web sitelerinde bir sonraki navigasyonu tahmin etme problemidir.

Speculation Rules API nedir?

Speculation Rules API, tarayıcıya kullanıcının gelecekte hangi belge URL'lerine gidebileceği hakkında yapılandırılmış ipuçları veren bir web platformu özelliğidir. Kurallar JSON biçiminde tanımlanır ve destekleyen tarayıcı, belirtilen sayfaları önceden getirmeyi veya önceden oluşturmayı kendi kaynak koşullarına göre değerlendirebilir. API, tekil görsel, CSS ya da JavaScript dosyalarından çok gelecekteki belge navigasyonlarını hedefler.

MDN, bu özelliğin belge URL'lerine odaklandığını ve bu nedenle çok sayfalı uygulamalarla daha doğal biçimde eşleştiğini belirtir. Alt kaynakların tek tek önceden yüklenmesi farklı mekanizmaların konusudur MDN Speculation Rules API. Bu ayrım önemlidir: amaç mevcut sayfanın kaynaklarını hızlandırmak değil, kullanıcının gitmesi muhtemel bir sonraki sayfayı hazırlamaktır.

Prefetch ve prerender nasıl çalışır?

API iki ana davranış sunar. Prefetch, hedef sayfanın HTML belgesini önceden indirir; hedef belgenin referans verdiği CSS, JavaScript, görsel ve diğer alt kaynakları bu aşamada tamamlamak zorunda değildir. Kullanıcı daha sonra sayfaya giderse tarayıcı kritik ilk belgeyi hazır bulduğu için navigasyon daha hızlı başlayabilir.

Prerender daha ileri gider. Hedef belgeyi ve gerekli alt kaynakları yükleyebilir, JavaScript'i çalıştırabilir ve sayfayı görünmeyen bir arka plan bağlamında oluşturabilir. Kullanıcı gerçekten o bağlantıya giderse hazırlanmış sayfa etkinleştirilir ve geçiş çok daha hızlı hissedilebilir. Chrome geliştirici belgeleri, prerender işlemini gizli bir arka plan sekmesine benzeyen ayrı bir oluşturma süreci olarak açıklar Chrome DevTools Speculation Rules.

Prerender her zaman prefetch'ten daha iyi değildir. Tahmin doğruluğu düşükse veya hedef sayfa ağırsa daha agresif yöntem kullanıcı ve sunucu tarafında gereksiz maliyet üretir. Bu nedenle teknik seçim, “en hızlı seçenek hangisi?” sorusundan önce “hangi sayfaya gidileceğini ne kadar güvenle biliyoruz?” sorusuyla başlamalıdır.

Kurallar nasıl tanımlanır?

Kurallar sayfanın içine JSON olarak eklenebilir, JavaScript ile dinamik biçimde üretilebilir veya Speculation-Rules HTTP yanıt başlığının işaret ettiği harici bir JSON dosyasından okunabilir. Harici dosya yönteminde kaynağın uygun MIME türüyle sunulması gerekir. MDN'ye göre bu dosyalar application/speculationrules+json türünü kullanmalıdır MDN Speculation-Rules Header.

En basit yaklaşım, hedef URL'leri açık bir listeyle tanımlamaktır. Örneğin bir yazının sonraki bölümü veya ödeme akışında kullanıcının gitme ihtimali yüksek bir doğrulama sayfası listeye eklenebilir. Daha büyük sitelerde ise sayfadaki bağlantıları kuralla seçen document rules yaklaşımı kullanılabilir. Bu modelde URL deseni, bağlantının CSS seçicisi veya bunların birleşimi üzerinden adaylar belirlenir.

Basitleştirilmiş örnek kural: Sayfadaki .next-step sınıfına sahip bağlantıları, kullanıcı etkileşimi belirginleştiğinde prerender adayı yap; çıkış, sepet değiştirme ve yönetim işlemlerini kapsam dışında bırak.

Bir bağlantıyı yalnızca sınıfı nedeniyle seçmek yeterli güvenlik sağlamaz. URL'nin ne yaptığı, GET isteğinin durum değiştirip değiştirmediği, sayfanın kişisel veri içerip içermediği ve prerender sırasında çalışacak kodların yan etki üretip üretmediği ayrıca incelenmelidir.

List ve document kaynakları arasındaki fark nedir?

List kaynağı

List yaklaşımında hedefler açık URL dizisiyle belirtilir. Tahmin edilen sayfaların sayısı az ve biliniyorsa en kontrollü yöntemdir. Örneğin bir çok adımlı başvuru akışında bir sonraki sayfa, bir ürün detayından sonra açılması beklenen karşılaştırma ekranı veya içerik serisinin sonraki bölümü açıkça listelenebilir.

Document kaynağı

Document yaklaşımı, mevcut belgedeki bağlantıları kurallarla eşleştirir. href_matches URL desenlerine, selector_matches ise bağlantının CSS seçicisine göre filtreleme yapabilir. “and”, “or” ve “not” mantıklarıyla güvenli adaylar seçilip çıkış, ödeme başlatma, sepet değiştirme, dosya indirme veya yönetim bağlantıları hariç tutulabilir.

Document kuralları ölçeklenebilirlik sağlar ancak kapsam fazla geniş tutulursa onlarca gereksiz aday üretilebilir. Bu nedenle “site içindeki bütün bağlantıları prerender et” gibi genel bir kural yerine, kullanıcı yolculuğu ve gerçek navigasyon verileriyle belirlenmiş dar bir seçim uygulanmalıdır.

Eagerness seviyeleri neyi değiştirir?

Eagerness, tarayıcının spekülatif yüklemeyi ne kadar erken tetikleyebileceğini belirleyen ayardır. Güncel uygulamalarda conservative, moderate, eager ve immediate gibi seviyeler görülebilir. Bu değerler kesin bir zamanlayıcı değildir; tarayıcı kullanıcı etkileşimi, cihaz koşulları, veri tasarrufu ayarları ve kendi kaynak sınırları doğrultusunda kararı yönetir.

• conservative: Navigasyon niyeti çok belirginleştiğinde çalışır; yanlış tahmin riski düşüktür ancak kazanılacak süre de sınırlı olabilir.
• moderate: Masaüstünde bağlantı üzerine gelme veya mobilde görünürlük gibi daha erken sinyallerle devreye girebilir.
• eager: Adayları daha erken hazırlamayı hedefler; yalnızca güçlü tahmin yapılan az sayıdaki sayfada kullanılmalıdır.
• immediate: Kural görüldüğünde mümkün olan en erken anda işlemi başlatabilir; yüksek maliyet nedeniyle çok seçici kullanılmalıdır.

Chrome'un uygulama rehberi, tahmin güveni düşük olduğunda daha az agresif seviyelerle prefetch başlatmayı; güven arttıkça prerender'a geçmeyi önerir. Aynı rehber, spekülatif yüklemenin kullanıcı bant genişliği ve arka uç kaynakları açısından gerçek bir maliyeti olduğunu vurgular Chrome Uygulama Rehberi.

Hangi sayfalar iyi adaydır?

En iyi adaylar, kullanıcının sonraki adım olarak seçme olasılığı yüksek, GET isteğiyle durum değiştirmeyen ve arka planda hazırlanması güvenli olan sayfalardır. Bir web tasarım projesinde bilgi mimarisi kurulurken yalnızca menü yapısı değil, sık tekrarlanan navigasyon zincirleri de belirlenebilir. Bu zincirler ölçülmeden bütün bağlantıları spekülatif yüklemeye almak doğru değildir.

1. İçerik serisinin sonraki sayfası: “Sonraki bölüm” gibi tek ve güçlü bir aday varsa prefetch veya ölçülü prerender düşünülebilir.
2. Liste detay geçişi: Kullanıcı belirli bir ürün ya da hizmet kartıyla etkileşime girdiğinde ilgili detay sayfası hazırlanabilir.
3. Çok adımlı form: Bir sonraki adım yan etkisiz ve kişisel veri işlemiyorsa, akışın gecikmesi azaltılabilir.
4. Arama sonucu veya kategori sayfası: Kullanıcının imleç, odak veya görünürlük sinyali verdiği az sayıdaki kart prefetch edilebilir.
5. Giriş sonrası ana ekran: Kimlik doğrulama tamamlanmak üzereyken hedef ekranın güvenli bölümleri hazırlanabilir; ancak kişisel içerik ve oturum davranışı dikkatle test edilmelidir.

Özel akışlarda spekülatif kuralların sunucu verileri, oturum yapısı ve sayfa yaşam döngüsüyle birlikte planlanması gerekir. Bu nedenle uygulama yalnızca ön yüz etiketi eklemekten ibaret görülmemeli; gerektiğinde yazılım geliştirme mimarisinin parçası olarak ele alınmalıdır.

Hangi sayfalar kapsam dışında bırakılmalıdır?

Bir URL, yalnızca kullanıcı gerçekten ziyaret ettiğinde çalışması gereken bir işlem yapıyorsa prefetch veya prerender için güvenli değildir. Çıkış bağlantıları, sepete ürün ekleme veya çıkarma işlemleri, sipariş onayı, tek kullanımlık bağlantılar, dosya üretme, e-posta gönderme ve yönetim komutları bu gruba girer. GET isteğinin veri değiştirdiği eski uygulamalar özellikle risklidir.

• Oturumu kapatan veya yetki durumunu değiştiren URL'ler
• Sepet, favori, abonelik veya rezervasyon durumunu değiştiren bağlantılar
• Gerçek görüntülenme olmadan analitik ya da reklam olayı üreten sayfalar
• Tek kullanımlık token veya süresi sınırlı imza tüketen URL'ler
• Yüksek arka uç maliyeti oluşturan rapor, dışa aktarma ve kişiselleştirme sayfaları
• Kullanıcının henüz görmediği içeriği “görüntülendi” olarak işaretleyen sistemler

Prerender sırasında JavaScript çalışabileceği için analytics, oturum sayacı, okunma durumu ve kişiselleştirme kodları gerçek görüntülenmeden önce tetiklenebilir. MDN, prerender durumunun Document.prerendering ile kontrol edilebildiğini ve etkinleştirme sonrasında çalışması gereken işlemlerin prerenderingchange olayına ertelenebileceğini açıklar MDN Speculation Rules API.

Tarayıcı desteği ve progressive enhancement nasıl ele alınmalı?

Speculation Rules API 2026 itibarıyla bütün yaygın tarayıcılarda aynı düzeyde desteklenen bir Baseline özelliği değildir. MDN özelliği “limited availability” ve deneysel teknoloji olarak işaretler. Bu nedenle bir sitenin temel navigasyonu bu API'ye bağımlı tasarlanmamalıdır; desteklemeyen tarayıcılar normal bağlantı akışıyla sorunsuz çalışmaya devam etmelidir.

Destek kontrolü HTMLScriptElement.supports("speculationrules") yaklaşımıyla yapılabilir. Ancak çoğu durumda kural bloğunu desteklemeyen tarayıcının yok sayması yeterlidir. Daha eski prefetch yöntemleriyle fallback kurulacaksa iki mekanizmanın aynı belgeyi gereksiz yere tekrar istemediği test edilmelidir.

Performans kazancı nasıl ölçülür?

Başarılı uygulama, yalnızca kuralın DevTools'ta “ready” görünmesiyle kanıtlanmaz. Gerçek kullanıcıların ne kadarında spekülasyonun kullanıldığı, kaç isteğin boşa gittiği, arka uç yükünün nasıl değiştiği ve hedef navigasyonun kullanıcı deneyimine etkisi birlikte izlenmelidir. Chrome DevTools içindeki Application panelinde yer alan Speculative loads alanı; kuralları, aday URL'leri, tetiklenme durumunu ve hata nedenlerini incelemek için kullanılabilir.

Sunucu tarafında spekülatif istekler Sec-Purpose başlığı üzerinden ayırt edilebilir. Prefetch isteklerinde “prefetch”, prerender isteklerinde ise “prefetch;prerender” değeri görülebilir. Bu sinyal; ayrı loglama, maliyet analizi ve hatalı endpoint'lerin tespiti için değerlidir. Ancak başlığa güvenerek kişisel veya hassas davranış üretmek yerine endpoint'lerin zaten güvenli ve idempotent olması hedeflenmelidir.

Ölçüm planında en az şu metrikler bulunmalıdır:

• Spekülatif aday sayısı ve gerçekten kullanılan aday oranı
• Boşa giden veri miktarı ve ek sunucu isteği
• Prefetch veya prerender ile etkinleşen navigasyon sayısı
• Hedef sayfalardaki LCP ve kullanıcı tarafından algılanan geçiş süresi
• Hata, iptal ve uygunluk dışı kalma nedenleri
• Analitik olayların yalnızca gerçek etkinleştirme sonrası çalışıp çalışmadığı

Bir web sitesi hız optimizasyonu çalışmasında Speculation Rules API, sunucu yanıt süresi, görsel optimizasyonu veya JavaScript maliyetinin yerine geçmez. Yavaş sayfayı arka planda daha erken başlatabilir; fakat sayfanın temel performans sorunlarını ortadan kaldırmaz.

Canlıya almadan önce kontrol listesi

1. En sık gerçekleşen sonraki navigasyonları gerçek analitik veya kullanıcı yolculuğu verisiyle belirleyin.
2. İlk denemede az sayıdaki güvenli sayfa için prefetch kullanın.
3. Çıkış, sepet, ödeme, yönetim ve durum değiştiren URL'leri açıkça hariç tutun.
4. Prerender sırasında çalışan analytics ve yan etkili JavaScript kodlarını etkinleştirme anına erteleyin.
5. Mobil veri, CPU, bellek ve arka uç maliyetini hesaba katın.
6. Desteklemeyen tarayıcılarda normal navigasyonun bozulmadığını doğrulayın.
7. DevTools Speculative loads ekranından eşleşme ve hata nedenlerini kontrol edin.
8. Sunucu loglarında Sec-Purpose başlığını ayırarak boşa giden istekleri ölçün.
9. Kademeli yayın yapın; sorun halinde kuralları hızlıca kapatabilecek bir dağıtım yöntemi seçin.
10. Prerender'a yalnızca prefetch sonuçları ve gerçek kullanım verileri güven veriyorsa geçin.

Sonuç: En agresif kural değil, en doğru tahmin kazandırır

Speculation Rules API, çok sayfalı sitelerde gelecekteki navigasyonu erkenden hazırlayarak hissedilen geçiş süresini azaltabilir. Prefetch daha düşük maliyetli bir başlangıç noktasıdır; prerender ise güçlü tahmin, güvenli endpoint ve doğru yaşam döngüsü yönetimi olduğunda daha büyük deneyim kazancı sağlayabilir.

İyi uygulama; birkaç yüksek olasılıklı hedef seçer, yan etkili URL'leri dışarıda bırakır, destek durumunu progressive enhancement ile yönetir ve gerçek kullanıcı verisiyle ölçülür. Bütün bağlantıları erken yüklemek performans optimizasyonu değil, kaynak israfı olabilir.