Prerender ve Prefetch Farkı: Ne Zaman Hangisi Kullanılır?

İki mekanizmanın çalışma mantığı

<link rel="prefetch"> bir HTML kaynak ipucu (resource hint): tarayıcıya "bu kaynağa yakında ihtiyacın olabilir, düşük öncelikle indir" diyor. Tarayıcı bunu dikkate alabilir veya almayabilir; koşullar uygunsa arka planda isteği atar, HTTP önbelleğine yazar. Sayfa açıldığında kaynak zaten önbellekte olur, ağ gecikmesi yaşanmaz. Ama bu kadar: prefetch yalnızca HTML belgesini veya belirli bir kaynağı alır, sayfayı parse etmez, scriptleri çalıştırmaz, DOM oluşturmaz.

Speculation Rules API çok daha ileri gider. Chrome 109'dan itibaren aşamalı olarak kullanılabilir hale gelen bu API, JSON formatında yazılan bir kural kümesiyle çalışır: hangi URL'lerin prefetch mi yoksa prerender mı yapılacağını, hangi koşulda tetikleneceğini belirler. Prerender modunda tarayıcı hedef sayfayı tam anlamıyla hazırlar: HTML indirilir, parse edilir, CSS hesaplanır, JavaScript çalıştırılır, LCP öğesi bile render edilir. Kullanıcı bağlantıya tıkladığında sayfa zaten hazırdır; activationStart zamanlamasıyla birlikte anında görünür.

Fark şu: prefetch bir dosyayı önbelleğe alır, prerender bir sayfayı bellekte canlı tutar. Bu ayrım hem maliyet hem güvenilirlik açısından belirleyici.

Prefetch'in bellek ve ağ maliyeti

Prefetch düşük maliyetli görünüyor; ancak "düşük" her durumda geçerli değil. Bir sayfa için HTML belgesi 50-100 KB aralığında olabilir, ama prefetch yalnızca belgeyi alır; sayfanın alt kaynakları (CSS, JS, görseller) için ayrı prefetch etiketleri gerekirdi. Tüm sayfayı önceden yüklemek istiyorsanız her kaynağı tek tek belirtmek zorundasınız, bu da pratik değil.

Bant genişliği maliyeti asıl kritik olan. Yavaş bir bağlantıda prefetch isteği büyük fark yaratmayabilir, ama 3G veya veri tasarruf modundaki bir kullanıcı için arka planda yapılan her istek bant genişliği tüketir. Tarayıcı, Save-Data başlığı gönderildiğinde prefetch'i otomatik devre dışı bırakır; bu koruyucu bir davranış. Ama Save-Data her zaman ayarlı değil: yavaş bağlantıdaki pek çok kullanıcı bu başlıkla gelmiyor.

Prefetch'in bellek maliyeti sınırlı. Tarayıcı yalnızca önbelleğe yazıyor, ayrıca bellekte canlı bir sayfa tutmuyor; kaynaklar HTTP önbelleğinde duruyor, kullanılmazsa TTL dolduğunda gidiyor. Prerender'a kıyasla çok daha az riskli, ama sağladığı kazanım da o kadar büyük değil.

Speculation Rules API ile prerender nasıl çalışır?

Speculation Rules API bir <script type="speculationrules"> bloğu içinde JSON alıyor. En basit biçimiyle:

<script type="speculationrules">
{
  "prerender": [
    {
      "where": { "href_matches": "/urun/*" },
      "eagerness": "moderate"
    }
  ]
}
</script>

eagerness değeri kritik: conservative yalnızca bağlantıya tıklandığında tetikler ve prerender'ın avantajını büyük ölçüde yitirir; moderate kullanıcı imleci bağlantı üzerinde yaklaşık 200 ms geçirdikten sonra başlar; eager URL eşleşmesi olur olmaz hemen başlar. Mobil için moderate çoğu durumda makul başlangıç noktasıdır.

Prerender edilen sayfa, tarayıcının arka plan ortamında çalışır. Bu sayfadaki JavaScript kodu çalışır; yani analitik çağrıları, document.cookie erişimleri ve form gönderimleri hepsi gerçekleşebilir. Sayfa prerender edildiğinde document.prerendering değeri true döner; bunu kontrol etmek, analitik sistemlerin hayalet görüntüleme (phantom pageview) kaydetmemesini sağlar. Kullanıcı hiç tıklamadan ayrılırsa analitik kaydı oluşmamalı; bu kontrolü yazmadan prerender'ı canlıya almak ölçüm verisini kirletir.

Prefetch'in yeterli olduğu durumlar

Bazı senaryolarda prerender gereksiz. Belge ağırlıklı, JavaScript minimal sayfalarda HTML indirildikten sonra parse ve render zaten hızlı gerçekleşiyorsa, prerender'ın ekstra CPU harcaması fazla ek değer üretmez. Navigasyon süresi zaten kısa olan sayfalarda prerender farkı algılanamaz kılar.

Belirsizlik yüksekse prefetch yeterli. Bir blog anasayfasında hangi yazıya tıklanacağı belli değil; her yazıyı prerender etmek makul değil. HTML belgelerini prefetch etmek, tıklama anında yalnızca parse ve render süresini yaşatır ki bu genellikle kabul edilebilir. Sayfada kaç kaynak olduğuna ve JavaScript yüküne göre bu süre değişir; hafif sayfalarda fark çok küçük kalır.

Ayrıca sayfadaki JavaScript, prerender sırasında çalışması istenmeyen yan etkiler üretiyorsa prefetch daha güvenli bir seçim. Ödeme akışının erken başlatılması, kimlik doğrulama kontrollerinin prerender sırasında tetiklenmesi ya da A/B test segmenti atamalarının önceden gerçekleşmesi bu kategoride. Speculation Rules API'nin koşullu kural desteği bu durumları kısmen çözüyor, ama eklenen yapılandırma karmaşıklığı da artıyor.

Prerender'ın mantıklı olduğu navigasyon senaryoları

Prerender en yüksek değeri, sonraki navigasyonun yüksek olasılıkla öngörülebildiği durumlarda üretiyor. Tek adımlı checkout akışı bunun klasik örneği: ürün detay sayfasına gelen kullanıcının bir sonraki adımı sepete ekleme veya ödeme sayfasıdır. Funnel daralıyor, olasılık artıyor; prerender bu yapıda güçlü bir seçenek.

Makale serisi veya adım adım rehberler de benzer. "Bölüm 3 / 7" görüntüleyen bir içerikte kullanıcı büyük olasılıkla ileriye tıklayacak; bir eğitim platformunun ders sayfaları, bir belgenin bölüm gezintisi, sıralı onboarding adımları bu kategoride. Navigasyon sırası belirgin, belirsizlik az.

Arama sonuçları sayfası ilginç bir ara durum. İlk birkaç sonuç yüksek tıklanma olasılığına sahip, ama hangisi tıklanacak belirsiz. eagerness: moderate ile imlecin üzerine geldiğinde prerender tetiklemek bu belirsizliği dengeli yönetir. Çok agresif kural yazmak, hiç tıklanmayan sayfaları prerender ederek belleği boşu boşuna tüketir.

Mobil cihazlarda karar: maliyet ve yarar dengesi

Masaüstünde çalışan bir prerender kuralı, mobil cihazda farklı davranır. Bellek kısıtlı cihazlarda tarayıcı prerender isteğini sessizce reddedebilir veya daha az kaynak ayırır. Chrome, düşük bellekli cihazlarda spekülatif yüklemeyi kısıtlar; bu davranış belgelenmiş bir Chrome davranışı.

Bağlantı kalitesi de değişkeni etkiliyor. Yavaş bağlantıda prerender için gereken tüm alt kaynakları çekmek uzun sürer; prerender tamamlanmadan kullanıcı tıklarsa kazanım azalır veya tamamen yok olur. NetworkInformation API üzerinden bağlantı bilgisine erişilir; JavaScript ile koşullu prerender kuralı oluşturmak mümkün. Hızlı bağlantıda agresif, yavaş bağlantıda yalnızca prefetch tercih etmek makul bir strateji.

Sayfaların toplam boyutu da hesaba katılmalı. Ağır JavaScript bundle'ları olan tek sayfa uygulamalarında prerender daha fazla kaynak tüketir; hafif, sunucu taraflı render edilen sayfalarda maliyet daha düşük. Yapılandırma yazmadan önce hedef sayfanın kaynak profilini bilmek, doğru eagerness ve kural kapsamını belirlemek için gerekli.

Ölçüm ve doğrulama

Prerender çalışıyor mu? Chrome DevTools'da "Application" panelindeki "Speculation Rules" sekmesi prerender durumunu gösteriyor: bekliyor, başarılı, başarısız veya iptal edildi. Başarısız nedenleri orada görünür; yönlendirme (redirect) zinciri, Service Worker müdahalesi veya CSP ihlali en sık karşılaşılan nedenler arasında.

Alan verisinde prerender aktivasyonunu ölçmek için PerformanceNavigationTiming içindeki activationStart değerini kontrol etmek gerekiyor. Bu değer sıfırdan büyükse sayfa prerender'dan aktivasyon yoluyla açılmış demek. LCP süresini activationStart'a göre normalize ederek gerçek kullanıcı deneyimini ölçmek mümkün; bu adım atlanırsa LCP değerleri yanıltıcı görünebilir.

Prerender oranı düşükse olası nedenler şunlar: çok kısıtlayıcı URL deseni, redirect zinciri, yetersiz eagerness değeri veya tarayıcının cihaz kaynaklarını kısması. Her vakayı ayrı değerlendirmek gerekiyor; düşük prerender oranı otomatik olarak prefetch'e geçmek için tek başına yeterli neden değil. Sorunun kaynağını bulmak, konfigürasyonu doğru iyileştirmenin önkoşulu.