Geri/İleri Önbelleği (bfcache)

TL;DR — Geri/ileri önbelleği (bfcache), bir sayfadan ayrıldığınızda sayfanın tamamını bellekte donduran bir tarayıcı özelliğidir. Böylece tarayıcı, dondurulmuş sayfayı önceden bellekten çıkarmadığı sürece Geri veya İleri düğmesine bastığınızda sayfayı yeniden yüklemeden anında geri getirebilir. Bu bir tarayıcı özelliğidir, Google sıralama faktörü değildir. Ancak geri yüklenen bir sayfa neredeyse anında yüklendiğinden, geri yüklemenin gerçekleştiği Geri/İleri gezinmelerindeki Core Web Vitals değerlerini fark ettirmeden iyileştirir. Bu nedenle bir performans denetimi size “bfcache uygunluğunu düzeltmenizi” önerebilir.

Bfcache nedir?

Tarayıcının Geri düğmesine tıkladığınızda iki şeyden biri olur. Tarayıcı ya önceki sayfayı dosyaları yeniden indirerek, JavaScript’i yeniden çalıştırarak ve sayfanın tamamının düzenini yeniden hesaplayarak sıfırdan oluşturur ya da sayfayı tam bıraktığınız hâliyle anında geri yükler. Bu anında geri yükleme mekanizmasına geri/ileri önbelleği, yani bfcache denir.

İşin püf noktası şudur: Tarayıcı, sayfadan ayrıldığınızda eski sayfayı atmak yerine çalışan JavaScript dâhil sayfanın tamamını bellekte dondurur ve bekletir. Kısa süre içinde geri gelirseniz ve dondurulmuş sayfa hâlâ tarayıcıda bulunuyorsa, tarayıcı sayfanın donmasını çözer ve tam bıraktığınız hâli yeniden gösterir; ağ isteği veya bekleme olmaz. Bu, mümkün olan bir geri yüklemedir; garanti değildir. Tarayıcı siz Geri düğmesine basmadan önce düşük bellek, zaman aşımı veya belirli etkinlikler nedeniyle dondurulmuş sayfayı bellekten çıkarabilir. Bu durumda normal bir yeniden yükleme gerçekleşir.

Google’ın kendi tek cümlelik açıklaması bunu açıkça ifade eder: bfcache, “a browser optimization that enables instant back and forward navigation.”

Neden bildiğiniz “önbellek” değildir?

İnsanların karıştırdığı nokta budur. “Önbellek” denince muhtemelen tarayıcınızın yeniden indirmemek için kaydettiği dosyalardan (görseller, betikler ve stil sayfaları) oluşan tarayıcı önbelleğini veya HTTP önbelleğini düşünürsünüz. Bfcache bu değildir. Bu önbellekler dosyaları saklarken bfcache, JavaScript durumu dâhil çalışır durumdaki sayfanın tamamını bir anlık görüntü olarak saklar. Chrome’un kendi belgeleri farkı açıkça belirtir: bfcache “differs from browser cache and HTTP cache.”

Ayrıca bazen bfcache ile aynı gruba konan iki mekanizma daha vardır: Tarayıcının geçerli oturum için sakladığı derlenmiş betikler ve kodu çözülmüş görsellerden oluşan bellek içi kaynak önbelleği ile bir service worker’ın caches.open() aracılığıyla sitenin açıkça yönettiği istek/yanıt çiftlerini içeren Cache Storage alanı. Bunların ikisi de bfcache ile aynı sayfada etkin olabilir; ancak ayrı mekanizmalardır ve bfcache’in kendisi değildir.

Ayrıca Google ve Bing’in eskiden arama sonuçlarında sunduğu, kayıtlı sayfa sürümünü küçük bir açılır menüde gösteren eski “cached page” veya “cached snapshot” özelliği de değildir. Bu bir arama özelliğiydi ve kullanımdan kaldırıldı. Bfcache, arama sonuçlarıyla hiçbir ilgisi olmayan canlı bir tarayıcı özelliğidir.

Bfcache SEO’ya yardımcı olur mu?

Doğrudan değil. Bfcache bir Google sıralama faktörü değildir; Google’ın kendi Core Web Vitals sıralama belgelerinde bundan hiç söz edilmez. Bfcache, gerçekten geri yükleme alan ziyaretçiler için Geri/İleri gezinmelerini neredeyse anında yükler ve tarayıcılar bunu mükemmel bir “sayfa yüklemesi” olarak ölçer. Bu nedenle ziyaretçileriniz Geri ve İleri düğmelerini sık kullanıyorsa (alışveriş, arama sonuçlarına göz atma veya makaleler arasında okuma gibi), bfcache sitenizin genel Core Web Vitals alan verilerini iyileştirebilir. Google, bunun sıralama sistemlerinin ödüllendirdiği deneyimle uyumlu birçok unsurdan biri olduğunu söyler. Bu ilişki, “bfcache sıralamaları yükseltir” iddiasından iki adım uzaktadır ve geri yükleme oranınızı, genel Core Web Vitals değerlendirmenizi ya da sıralamalarınızı garanti etmez; ancak gerçektir ve ölçülebilir.

Bfcache’i tam olarak nelerin engellediğini, nasıl test edileceğini ve Core Web Vitals ile arasındaki kesin ve abartısız bağlantıyı görmek mi istiyorsunuz? Gelişmiş sekmesine geçin.

TL;DR — Bfcache, yeniden getirilebilir bir HTTP yanıtı, tarayıcının bellek içi kaynak önbelleği veya bir service worker’ın Cache Storage alanı değil; sayfanın tamamının bellek içi anlık görüntüsüdür (DOM + JS heap + çalışma durumu). Kavranması gereken bir numaralı kavramsal ayrım budur. Sayfadan ayrılırken tarayıcı JS’yi duraklatır ve sayfayı dondurur. Geri/İleri gezinmesinde, eğer bu dondurulmuş anlık görüntü hâlâ mevcutsa, donmayı çözüp sıfır ağ isteğiyle sayfayı anında yeniden gösterir. Ancak bellekten çıkarılma her zaman mümkündür; bu nedenle geri yüklemeyi garanti değil, olasılık olarak değerlendirin. Bfcache, belgelenmiş bir Google Arama sıralama faktörü değildir; Search Central’ın Core Web Vitals belgelerinde bundan hiç söz edilmez. İlgisi dolaylı ve sınırlıdır: Geri yüklenen gezinmelerin alan CWV ölçümleri (özellikle LCP ve CLS) üzerinden etki eder; geri yükleme oranını, toplam CWV değerlendirmesini, sıralamaları veya dönüşümü garanti etmez. En büyük uygunluk engeli unload işleyicisidir (Chrome’daki isabet oranında ~18 yüzde puanı). Tarihsel olarak en büyük engel ise Cache-Control: no-store idi (mobil geçmiş gezinmelerinin ~17%‘sini, masaüstündekilerin ~7%‘sini engelliyordu). Ancak Chrome, 2025 dağıtımından sonra birçok no-store sayfası için belirli koşullarla bfcache’e izin veriyor; kimlik doğrulama/çerez değişiminde sayfa bellekten çıkarılıyor ve aynı açık bağlantı API’leri engel olmaya devam ediyor. Açık bağlantılar, zamanlayıcılar ve gözlemciler pagehide/freeze sırasında kapatılmalı veya duraklatılmalı, pageshow/resume sırasında yeniden kurulmalıdır. window.opener, izin politikaları ve çerçeveler de engel olabilir; varsayımda bulunmak yerine DevTools veya notRestoredReasons içindeki çerçeve başına nedeni kontrol edin. Tek seferlik testler için Chrome DevTools’u, alan tanılaması için yalnızca Chrome’da bulunan notRestoredReasons API’sini kullanın (null sonucu geri yükleme kanıtı değildir ve neden metni kararlı değildir). Her tarayıcının kendi uygunluk kuralları vardır; SPA’lerin yumuşak gezinmeleri aynı şekilde işlenmez.

Bfcache gerçekte nedir? (doğruluğun temeli)

Doğru anlaşılması gereken en önemli nokta şudur: bfcache, önbelleğe alınmış bir HTTP yanıtı değil, sayfanın tamamının bellek içi anlık görüntüsüdür. Bir sayfadan ayrıldığınızda tarayıcı sayfayı ortadan kaldırmak yerine JavaScript yürütmesini duraklatır ve DOM, JS heap, devam eden zamanlayıcılar ve diğer her şey dâhil sayfanın tamamını dondurarak bellekte tutar. Bu dondurulmuş anlık görüntü hâlâ mevcutken Geri veya İleri düğmesine basarsanız tarayıcı donmayı çözer ve bıraktığınız sayfayı sıfır ağ isteği ve sıfır yeniden işleme ile yeniden gösterir. Bu, mümkün olan bir geri yüklemedir; garanti değildir. Tarayıcı siz geri dönmeden önce bellek baskısı, zaman aşımı veya belirli olaylar nedeniyle anlık görüntüyü bellekten çıkarabilir ya da tarayıcıya özgü bir kural yeni yüklemeyi zorunlu kılabilir. Böyle bir durumda sıradan bir geçmiş gezinmesi gerçekleşir. Google’ın yerleşik tanımı şöyledir: bfcache, “a browser optimization that enables instant back and forward navigation.”

Bunu HTTP/tarayıcı önbelleğiyle karıştırmak, rakip içeriklerde tekrar tekrar görülen hatanın nedenidir. HTTP önbelleği, yeniden sunabileceği dosyalar olan önceki isteklerin yanıtlarını saklar. Bfcache ise canlı ve çalışır durumdaki sayfayı saklar. Chrome’un DevTools belgeleri ayrımı açıkça yapar: bfcache “differs from browser cache and HTTP cache.” HTTP önbelleğini yapılandırdığınız gibi önbellekleme başlıklarıyla bfcache’i “açmazsınız”. Başlıkların konuya dâhil olduğu tek nokta, Cache-Control: no-store değerinin eskiden bir sayfayı uygunsuz kılmasıdır (aşağıda daha ayrıntılı ele alınmıştır).

Aynı ayrım, insanların bazen bfcache ile karıştırdığı iki başka önbellek için de geçerlidir: Geçerli oturum boyunca tutulan derlenmiş betikleri ve kodu çözülmüş görselleri içeren tarayıcının bellek içi kaynak önbelleği ile sitenin caches.open() üzerinden kendisinin yönettiği açık istek/yanıt çiftlerini içeren bir service worker’ın Cache Storage alanı. İkisi de bfcache ile aynı anda aynı sayfada etkin olabilir; ancak hiçbiri bfcache değildir. Bfcache, önbelleğe alınmış varlıklar veya yakalanan yanıtlar değil, özellikle dondurulmuş sayfa örneğidir.

Hâlâ karışıklığa yol açtığı için bir ayrımı daha belirtmek gerekir: bfcache’in, Google’ın (ve Bing’in) bir zamanlar sonuçlarda sunduğu eski “cached page” arama özelliğiyle hiçbir ilgisi yoktur. O özellik, arama dizininde saklanan bir sayfa anlık görüntüsüydü ve kullanımdan kaldırıldı. Bfcache, istemci tarafında çalışan bir işleme motoru özelliğidir.

Geri/İleri gezinmeleri gerçekte ne kadar yaygın?

Bu, nadir görülen uç bir durum değildir. web.dev’e göre, “1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward.” E-ticarette kategori-ürün-geri akışları, arama sonuçları, sayfalandırılmış içerikler ve makaleler arası okuma gibi tekrarlanan Geri/İleri akışlarına sahip herhangi bir sitede bu, neredeyse anında gerçekleşmesini sağlayabileceğiniz gerçek gezinmelerin büyük bir bölümüdür.

Tarayıcı desteği

“All major browsers include a bfcache, including Chrome since version 96, Firefox and Safari.” Firefox ve Safari’nin daha uzun süredir kullanılan kendi bfcache uygulamaları vardır; Chromium tabanlı tüm tarayıcılar (Edge, Brave, Opera, Arc) Chrome’un uygulamasını devralır. Microsoft’un Edge politika belgeleri aynı özelliği şöyle açıklar: Bir sayfadan ayrılırken sayfanın geçerli durumu (belge ağacı, betik vb.) geri/ileri önbelleğinde korunabilir. Tarayıcı sayfaya geri dönerse sayfa bu önbellekten geri yüklenerek önbelleğe alınmadan önceki durumunda gösterilebilir. Özellik Edge’de varsayılan olarak etkindir; tek kapatma seçeneği site sahibinin değil, BT yöneticisinin denetlediği kurumsal politikadır.

Önemli uyarı: Her tarayıcının bfcache’i kendi uygunluk kurallarını uygular. Chrome DevTools’un “Test back/forward cache” testini geçen bir sayfanın Firefox veya Safari’de uygun olacağı garanti değildir. Chrome’dan geçmeyi gerekli ancak yeterli olmayan bir koşul olarak değerlendirin.

Bfcache uygunluğunu neler engeller?

unload olayı — en büyük engel

Bu makaleden tek bir şey çıkaracaksanız şu olsun: unload olayını kullanmayı bırakın. web.dev, bir Google belgesinde nadiren görülen bir vurguyla şöyle der: “Never use the unload event. Ever!” Chrome’da unload işleyicileri, bfcache isabet oranında yaklaşık 18 yüzde puanlık düşüşe yol açar ve açık ara en büyük, kişinin kendi oluşturduğu uygunsuzluk nedenidir.

Chrome’un bunu etkin biçimde kullanımdan kaldırmasının iki nedeni vardır. Birincisi, en büyük bfcache engeli olmasıdır. İkincisi, unload zaten son derece güvenilmezdir: Mobil cihazlarda sekmeler arka plana alınıp kapatıldığı ve tarayıcı unload olayını tetiklemek yerine bfcache’e öncelik verdiği için çoğu zaman hiç tetiklenmez. Dolayısıyla “temizlik” için güvendiğiniz olay çoğu zaman hiç çalışmaz ve gerçek bir performans kazancını engeller.

Düzeltmeler:

• unload yerine pagehide kullanın. pagehide olayı, unload olayının tetiklendiği her durumda ve ayrıca sayfa bfcache’e girdiğinde tetiklenir; bu nedenle kesin bir iyileştirmedir. Güvenilir “kullanıcı ayrılıyor” temizliği için visibilitychange kullanın.
• Bfcache geri yüklemesini pageshow ile algılayın. pageshow olayını dinleyip event.persisted değerini kontrol edin. Değer true ise sayfa bfcache’ten geri yüklenmiştir; bu, eski verileri yenilemeniz veya bir sayfa görüntülemesini yeniden saymanız gerektiğini gösterir.
• Permissions-Policy: unload=() yanıt başlığıyla unload dinleyicilerini önceden engelleyin. Bu başlık, herhangi bir unload işleyicisinin kaydedilmesini tamamen önler. Chrome, varsayılan politikayı aşamalı olarak reddetme yönünde değiştiriyor (unload için Permissions-Policy, Chrome 115 ile sunuldu).

Cache-Control: no-store — tarihsel olarak en büyük engel, artık daha ayrıntılı

Rakip içeriklerin çoğunun yanlış aktardığı güncellik noktası budur. Tarihsel olarak Cache-Control: no-store, sayfaların bfcache dışında bırakılmasının tek başına en büyük nedeniydi. Chrome’un kendi rakamlarına göre mobil geçmiş gezinmelerinin yaklaşık 17%‘sini, masaüstündekilerin ise 7%‘sini etkiliyordu. Birçok site eski bir sayfa sunmamak için savunma amacıyla no-store ayarlar. Ancak Google’ın savı, bu gerekçenin bfcache bağlamında zayıfladığıdır: Bfcache geri yüklemesi eski ve önbelleğe alınmış bir yanıtı yüklemez; sekme açık bırakılmışçasına canlı sayfanın tam hâlini yeniden gösterir.

Bu nedenle Chrome davranışı değiştirdi; ancak evrensel değil, koşullu olarak. Denemeler Chrome 116’da başladı ve Mart ile Nisan 2025 boyunca kullanıcıların 100%‘üne nihai dağıtım yapıldı. Chrome artık genel bir istisna yerine belirli güvenlik koşullarına bağlı olarak birçok no-store sayfası için bfcache’e izin veriyor. Chrome’un kendi belgelerine göre bunun gerçek kısıtlamaları vardır: Sayfa donmuşken kimlik doğrulama durumu veya çerezler değişirse bfcache’ten çıkarılır. Böylece çıkış yapmış veya çerezlerini temizlemiş bir ziyaretçi, oturumun açık olduğu eski bir anlık görüntüyü görmez. Ayrıca aşağıda ele alınan aynı açık bağlantı API’lerinden oluşan sabit liste (IndexedDB, WebSocket, WebRTC ve diğerleri), diğer sayfalarda olduğu gibi bir no-store sayfasını da bfcache dışında bırakmaya devam eder. Bu, belirli bir sürüm aralığına özgü Chrome davranışıdır; diğer tarayıcıların veya eski Chrome sürümlerinin izlediğini varsayabileceğiniz bir kural değildir. Sabit bir genel kurala güvenmek yerine gerçekten test ettiğiniz tarayıcı ve sürüm için güncel DevTools/notRestoredReasons raporunu alın. Pratik sonuç: no-store değerini koşulsuz ve kalıcı bir bfcache engeli olarak listeleyen her rehber (bu rehberin eski sürümleri dâhil) güncelliğini yitirmiştir; ancak sorunun tamamen çözüldüğünü söylemek de güncel değildir. Bir sayfa için güncellik gerçekten önemliyse Chrome belgeleri, no-store yerine no-cache veya kısa bir max-age (ör. max-age=60) önerir.

Açık bağlantılar, gözlemciler ve diğer engeller

Gezinme anında belirli açık kaynaklar uygunluğu hâlâ engelleyebilir. Tam olarak hangilerinin engel olduğu ve bunların uygunluğu doğrudan mı engellediği yoksa kapatılıp yeniden bağlanabilir mi hâle geldiği tarayıcıya ve sürüme göre değişir. Aşağıdaki listeyi sabit ve kalıcı bir engel listesi olarak değil, bir örüntünün örnekleri olarak değerlendirin:

• Devam eden fetch() / XMLHttpRequest istekleri.
• Açık IndexedDB işlemleri.
• Açık WebSocket / WebRTC bağlantıları, zamanlayıcılar ve gözlemciler (MutationObserver, IntersectionObserver ve benzerleri). Bu alan etkin biçimde gelişmektedir. Yakın tarihli Microsoft Edge sürüm notları, açık bir WebSocket’ın artık sayfa bfcache’e girdiğinde önbelleğe almayı doğrudan engellemek yerine kapatıldığını gösteriyor. pageshow olayındaki event.persisted kontrolüyle yeniden bağlanılması öneriliyor. Bu, Chrome’un sayfaları dışlamak yerine engelleri azaltma yönündeki daha geniş eğilimini yansıtır.

Sabit bir listeyi ezberlemek yerine uygulamanız gereken genel örüntü şudur: pagehide/freeze işlemlerinizde açık bağlantıları, zamanlayıcıları ve gözlemcileri kapatın veya duraklatın; event.persisted true olduğunda bunları pageshow/resume işlemlerinizde yeniden kurun. Bu örüntü, tarayıcı hangi API’lerin uygunluğu doğrudan engellediğini ve hangilerini artık yalnızca askıya alıp yeniden bağlanmanıza izin verdiğini değiştirse bile geçerliliğini korur.

window.opener, izin politikaları ve çerçeveler. Bir window.opener başvurusu, belirli izin politikaları ve gömülü (aynı veya farklı kaynaklı) iframe’ler de uygunluğu etkileyebilir. Bunlar, Ahrefs CLS rehberinde ve Chrome belgelerinde derlediğim kontrol listesinde yer alır. Ancak genel bir kontrol listesine bakarak gerçek nedenin hangisi olduğunu varsaymayın. Chrome’un DevTools paneli ve notRestoredReasons API’si, engelleme nedenlerini çerçeve başına, yani üst çerçeve ve her iframe için ayrı ayrı bildirir. Bunun nedeni, engelden gerçekten sorumlu olan çerçevenin her zaman üst düzey sayfa olmamasıdır. Genel bir listeden tahminde bulunmak yerine test ettiğiniz tarayıcının çerçeve düzeyindeki raporundan gerçek nedeni alın.

Yaşam döngüsü olay/durum sırasını doğru kurma

Her yaşam döngüsü olayının gerçekte neyi kanıtladığı ile yalnızca neye işaret ettiğini karıştırmak, yukarıdaki uygunluk hatalarından sonra burada görülen en yaygın ikinci doğruluk hatasıdır:

Pratik kural şudur: pagehide.persisted değerini kanıt değil, niyet olarak değerlendirin; sayfa bir geri yükleme görülmeden önce bellekten çıkarılabilir. Yalnızca pageshow.persisted === true, geri yüklemenin gerçekleştiğinin kanıtıdır. Temizliği pagehide/freeze sırasında koşulsuz yapın; sıradan gezinmede bile ucuz ve güvenlidir. Geri yüklemeye özgü işleri ise yalnızca event.persisted koşuluyla pageshow/resume sırasında yapın. Böylece sıradan yeni yüklemede verileri gereksiz yere yenilemez veya bir analiz görüntülemesini iki kez saymazsınız.

Bfcache nasıl test ve teşhis edilir?

Laboratuvar / tek seferlik: Chrome DevTools

DevTools → Application → Background services → Back/forward cache yolunu açın ve “Test back/forward cache” seçeneğine tıklayın. Chrome otomatik olarak chrome://terms/ adresine gidip geri döner ve ardından başarıyı veya engelleme nedenlerinin belirli bir listesini bildirir. Her seferinde tek bir URL’yi kontrol etmek için uygundur.

Alan / üretim: notRestoredReasons API’si

Daha önce uygunluğu kontrol etmenin tek yolu, her seferinde tek URL üzerinde yapılan manuel DevTools testiydi; gerçek kullanıcıların gezinmelerinin neden engellendiğini görmek mümkün değildi. PerformanceNavigationTiming üzerindeki notRestoredReasons özelliği (Chrome 123+ ile sunuldu) bu açığı kapatır: Gerçek alan verilerinde üst çerçeve ve aynı kaynaklı iframe’ler için belirli engelleme nedenlerini bildirir.

const nav = performance.getEntriesByType('navigation')[0];
console.log(nav.notRestoredReasons);

Chrome’un kendi API rehberine göre kullanırken doğru değerlendirmeniz gereken birkaç nokta vardır:

• Yalnızca Chrome’da kullanılabilir (123+). Firefox ve Safari eşdeğer bir alan API’si sunmaz. Bu nedenle bu tarayıcılardaki geri yükleme oranınızı öğrenmek için manuel nokta kontrolleri yapmanız gerekir.
• null sonucu yeşil ışık değil, belirsiz bir sonuçtur. Sayfanın geri yüklendiği veya tarayıcının herhangi bir neden toplamadığı anlamına gelebilir. Chrome’un kendi belgeleri, null değerinin başarılı geri yükleme kanıtı olarak değerlendirilmemesini söyler.
• Neden metni kararlı bir sözleşme değildir. Kesin ifade Chrome sürümleri arasında değişebileceğinden metin üzerinde sabit kodlanmış dize eşleşmeleri kullanmayın; bunun yerine sonuçları nedene göre gruplayıp eğilimi izleyin.

Pratikte, bir düzeltmenin yayımlanmasından önce ve sonra notRestoredReasons verilerini pageshow.persisted geri yükleme oranlarıyla birlikte alın ve tek bir anlık görüntü yerine eğilimi karşılaştırın. API’nin erişemediği tarayıcılar için bunu Firefox ve Safari’deki manuel DevTools/laboratuvar kontrolleriyle eşleştirin. RUM/üretim ortamında büyük ölçekte bfcache tanısı koyarken URL’leri tek tek kontrol etmek yerine başvurulacak araç budur; ancak bunu resmin tamamı olarak görmeyin.

Bfcache ve Core Web Vitals — kesin ilişki

Rakip içeriklerin çoğunun bulanıklaştırdığı ayrıntı ve sahiplenmeye değer yaklaşım şudur.

Bfcache geri yüklemesi nasıl ölçülür? Tarayıcılar ve dolayısıyla CrUX alan verileri, bfcache üzerinden geri yüklenen bir gezinmeyi son derece hızlı bir “sayfa yüklemesi” olarak sayar: Neredeyse anında LCP ve sayfa doğru uygulandığında (hiçbir şeyin düzeninin yeniden hesaplanması gerekmediğinde), yeniden işleme yapılmadığı için fiilen sıfır ek CLS elde edilir. DebugBear’ın gerçek dünya karşılaştırmasında bfcache üzerinden geri yüklenen bir sayfa, önbelleksiz yüklemedeki ~427 ms’ye karşılık yaklaşık 100ms’de LCP’ye ulaştı. Bfcache’in kendi Ahrefs CLS kontrol listemde CLS ve LCP üzerinde etkili bir araç olarak yer almasının nedeni tam olarak budur. Orada bunu kısaca şöyle ifade ettim: “Make sure your pages are eligible for bfcache. The back/forward cache keeps pages in the browser cache. It allows for instant loading of a page that was already loaded, meaning no layout shifts will happen.”

Rakip içeriklerin genellikle aşırı iddiada bulunduğu nokta burası olduğundan iki kapsam uyarısını kesin biçimde belirtmek gerekir. Birincisi, bu yalnızca CrUX’un navigation-type boyutunda back/forward olarak sınıflandırdığı gezinmeleri etkiler; çoğu sitedeki trafiğin büyük bölümünü oluşturan ilk ziyaret veya yeniden yükleme gezinmeleri hakkında hiçbir şey söylemez. İkincisi, geri yükleme alan kullanıcılar için ölçülen deneyimin iyileşmesi bir garanti değildir. Bfcache’ten çıkarılan bir kullanıcı (yukarıdaki yaşam döngüsü tablosuna bakın) normal, iyileştirilmemiş bir yükleme alır. Dolayısıyla bfcache uygunluğu çalışmaları, toplam trafiğinizin sabit bir payını değil, Geri/İleri gezinmelerindeki geri yükleme oranınızı değiştirir; toplam alan Core Web Vitals değerlendirmenizi, sıralamalarınızı veya dönüşüm oranınızı garanti etmez. Bu, genel bir performans veya SEO çözümü değil; belirli ve sınırlı kapsama sahip gerçek ve ölçülebilir bir kaldıraçtır.

Bfcache bir sıralama faktörü müdür? Hayır. Savunulabilir ve farklılaştırılmış iddia budur. Google’ın kendi Core Web Vitals sıralama belgelerinde bfcache’ten hiç söz edilmez. Etkinin dürüst zinciri şöyledir: bfcache uygunluğu → geri/ileri gezinmelerinde daha iyi alan CWV değerleri (özellikle LCP/CLS) → Core Web Vitals, Google’ın sıralama sistemlerinin zaten ödüllendirdiği deneyimle uyumlu olduğunu söylediği birçok “sayfa deneyimi” sinyalinden biridir. Bu, “bfcache sıralamaları yükseltir” iddiasından önemli ölçüde daha zayıf ama daha kesin bir iddiadır. Rakip içeriklerin öne sürmesi gereken, ancak genellikle dikkatle ele almadığı iddia da budur. Ayrıca bfcache doğru biçimde bir işleme motoru özelliğidir; tarayıcı özelliği değildir. Googlebot veya Bingbot’ın sayfalarınızı nasıl taradığıyla hiçbir ilgisi yoktur. Bu nedenle robots.txt veya site haritalarında olduğu gibi “Bing’in SEO için bfcache görüşü” diye bir şey yoktur.

SPA’ler ve yumuşak gezinmeler. Bfcache, gerçek tarayıcı gezinmeleri ve geçmiş olayları üzerinde çalışır. Tek sayfalı bir uygulamadaki istemci taraflı “yumuşak” rota değişikliği (gerçek tarayıcı gezinmesini tetiklemeyen, JS ile gerçekleştirilen görünüm değişimi) bir bfcache olayı değildir ve aynı şekilde işlenmez. Bazı RUM araçlarının Core Web Vitals değerlerini yumuşak gezinmelere atfetme girişimleri, CrUX ile RUM arasında ölçüm uyuşmazlıkları oluşturabilir. JS framework’ü kullanan bir siteyi denetliyorsanız bunu özellikle belirtmek gerekir.

Bfcache engelleri gerçek dünyada ne kadar yaygın?

HTTP Archive’ın Web Almanac çalışması bunu izler. Bu, kapanmış eski bir konu değil; canlı ve değişen bir alandır. 2022 sürümünde mobil sayfaların en az ~22%‘si yalnızca unload ve no-store ölçütleri nedeniyle bfcache için uygun değildi. O zamandan beri site katmanları ve cihazlar genelinde unload işleyicisi kullanımı azalıyor; ancak Cache-Control: no-store kullanımı arttı. 2025 bölümü, bu değeri 2024’teki ~21%‘den yaklaşık 23%‘e yükselmiş olarak veriyor ve artışı kısmen daha fazla kimlik doğrulamalı/kişiselleştirilmiş deneyime ve daha katı uyumluluk gereksinimlerine bağlıyor.

Alıntılanmaya değer, sezgilere aykırı bulgu şu: Daha büyük ve daha yoğun trafikli sitelerin kendi bfcache kullanımını engelleme olasılığı orantısız derecede yüksektir. En büyük 1 000 sitede masaüstü sayfalarının yaklaşık %28’i ve mobil sayfaların %20’si hâlâ unload işleyicileri kullanırken, tüm sitelerde bu oranlar masaüstünde yalnızca ~%11, mobilde ise ~%10’dur. Bunun nedeni çoğunlukla büyük sitelerin daha fazla eski analiz sistemi ve unload bağımlı kod taşımasıdır. Geri/İleri trafiğinden en fazla kaybedecek siteler, çoğu zaman hâlâ kendi önlerine engel koyanlardır.

Bunun yeri

Bfcache, bu gruptaki çeşitli performans araçlarından biridir. Geri yüklenen bir sayfa, düzeni yeniden hesaplanmadan anında yeniden gösterildiğinden sağladığı kazanç Core Web Vitals alan verilerine — özellikle Cumulative Layout Shift ve Largest Contentful Paint ölçümlerine — yansır. Canlı bir sayfa anlık görüntüsü yerine dosyaları saklayan önbelleklemeden farklıdır; ancak Cache-Control başlığı, ikisinin kesiştiği bir noktadır. Bfcache ile Interaction to Next Paint arasında doğrudan bir bağ yoktur; dolayısıyla böyle bir bağlantıyı zorlamayacağım.

Yapay zekâ özeti

Gelişmiş sürümün kısa özeti:

• Bfcache = sayfanın tamamının bellek içindeki anlık görüntüsü (DOM + JS heap + çalışma durumu); yeniden getirilebilir bir HTTP yanıtı, tarayıcının bellek içi kaynak önbelleği veya bir service worker’ın Cache Storage alanı değildir. Başka bir sayfaya gidildiğinde tarayıcı JS’yi duraklatıp sayfayı dondurur; Geri/İleri gezinmesinde bu donmuş anlık görüntü hâlâ mevcutsa görüntünün donmasını çözer ve sayfayı sıfır ağ isteğiyle anında yeniden gösterir. Anlık görüntünün bellekten çıkarılması her zaman mümkündür; dolayısıyla geri yükleme muhtemeldir, garanti değildir. Chrome belgelerinde belirtildiği gibi bfcache, “differs from browser cache and HTTP cache.” Ayrıca kullanımdan kaldırılan eski “cached page” arama özelliği de değildir.
• Sıralama faktörü değildir ve kapsamı sınırlıdır. Google’ın kendi Core Web Vitals sıralama belgelerinde bfcache’ten hiç söz edilmez. Gerçek zincir dolaylıdır: bfcache uygunluğu → geri yüklenen Geri/İleri gezinmelerinde daha iyi alan CWV değerleri (özellikle LCP/CLS) → CWV, Google’ın sıralama sistemleriyle uyumlu olduğunu belirttiği sayfa deneyimi girdilerinden biridir. Bfcache; geri yükleme oranını, toplam CWV’yi, sıralamaları veya dönüşümü garanti etmez ve yalnızca CrUX’un back/forward olarak sınıflandırdığı gezinmeleri etkiler.
• Ölçek: “1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward.” Destek: v96’dan beri Chrome’un yanı sıra Firefox ve Safari; ancak her tarayıcının kendi uygunluk kuralları vardır.
• En büyük engel: unload olayıdır (“Never use the unload event. Ever!”) — Chrome’un isabet oranına etkisi ~18 yüzde puanıdır. Bunun yerine pagehide + visibilitychange kullanın; geri yüklemeleri pageshow / event.persisted ile algılayın; unload kullanımını Permissions-Policy: unload=() ile engelleyin.
• Cache-Control: no-store, geçmişteki en büyük engeldi (mobil geçmiş gezinmelerinin ~%17’si / masaüstündekilerin ~%7’si). Chrome, 2025 Mart–Nisan dağıtımından sonra birçok no-store sayfası için koşullu olarak bfcache kullanımına izin vermeye başladı: Kimlik doğrulama veya çerezler değişirse sayfa bellekten çıkarılıyor, aynı açık bağlantı API’leri engel olmaya devam ediyor ve bu değişiklik yalnızca Chrome için geçerli. no-store değerini mutlak bir engel olarak niteleyen eski rehberler güncelliğini yitirmiştir; ancak sorunu tamamen çözülmüş saymak da aynı ölçüde yanlıştır.
• Diğer engeller: Devam eden fetch/XHR işlemleri, zamanlayıcılar, gözlemciler, açık IndexedDB, WebSocket/WebRTC (pagehide/freeze sırasında kapatın veya duraklatın, pageshow/resume sırasında yeniden bağlayın), window.opener, izin politikaları ve çerçeveler. Varsayımda bulunmak yerine DevTools/notRestoredReasons aracılığıyla her çerçevenin nedenini alın.
• Yaşam döngüsünün doğru yönetimi: pagehide.persisted bir niyettir, kanıt değildir; geri yüklemeyi yalnızca pageshow.persisted === true doğrular. Temizliği pagehide/freeze sırasında koşulsuz yapın; hassas verileri yenileme, yeniden bağlanma ve tek bir analiz görüntülemesi sayma gibi geri yüklemeye özgü işlemleri yalnızca pageshow/resume sırasında gerçekleştirin.
• Test: Tek seferlik laboratuvar testi için Chrome DevTools’taki “Test back/forward cache”; alan verileri için yalnızca Chrome’da bulunan notRestoredReasons API’si (Chrome 123+). null değeri geri yükleme kanıtı değildir, neden metni kararlı değildir ve Firefox/Safari’de manuel nokta kontrolleri gerekir. Bir düzeltmeden önceki ve sonraki notRestoredReasons ile pageshow.persisted oranlarını karşılaştırın.
• SPA’ler: İstemci tarafındaki yumuşak gezinmeler bfcache olayı değildir ve aynı şekilde işlenmez; bu durum CrUX ile RUM arasında uyuşmazlığa yol açabilir.
• Benimsenme (Web Almanac): no-store kullanımı artıyor (~%21→%23), unload kullanımı en büyük sitelerde daha yüksek (en büyük 1 000 sitenin masaüstü sayfalarında ~%28) — büyük siteler çoğu zaman kendi bfcache kullanımının önünü kesiyor.

Resmî belgeler

Bfcache hakkındaki birincil kaynak belgeler. Kaynak ayrımına dikkat edin: Bfcache, Google Search Central’da değil, Chrome / işleme motoru belgelerinde (Google’ın bu konudaki kurumsal sesi) yer alır. Bu ayrımın kendisi önemlidir.

Google / Chrome

• Back/forward cache — temel belge: tanım, mekanizma, 1-in-10 / 1-in-5 istatistiği ve unload rehberliği.
• Test back/forward cache — DevTools test adımları, başlıca engeller ve açık “differs from browser cache and HTTP cache” ifadesi.
• Enabling bfcache for Cache-Control: no-store — 2025 politika değişikliği, 17% / 7% rakamları ve dağıtım zaman çizelgesi.
• Deprecating the unload event — unload olayının neden aşamalı olarak kaldırıldığı ve Permissions-Policy geçişi.
• Back/forward cache notRestoredReasons API — PerformanceNavigationTiming üzerinde alan tanılaması (Chrome 123+).
• Understanding Core Web Vitals and Google Search results — Google Search Central’ın sıralama belgesi; burada bfcache’ten hiç söz etmediğinin kanıtı olarak aktarılmıştır.

Microsoft / Edge

• Microsoft Edge policy: BackForwardCacheEnabled — Edge’in tanımı, aynı unload uyarısı ve kurumsal politikayla kapatma seçeneği.

MDN / web standartları

• bfcache — MDN Glossary — genel web geliştirme tanımı ve HTTP önbelleği ayrımı.
• Monitoring bfcache blocking reasons — MDN — notRestoredReasons özelliğinin pratikte kullanımı.

Kaynaktan alıntılar

Kaynak belgelerde kayda geçmiş ifadeler. Her bağlantı, kaynak sayfadaki alıntılanan bölüme giden derin bir bağlantıdır.

Google / Chrome — bfcache nedir ve neden önemlidir?

• “Back/forward cache (or bfcache) is a browser optimization that enables instant back and forward navigation.” — web.dev. Alıntıya git
• “1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward. With bfcache enabled, browsers could eliminate the data transfer and time spent loading for billions of web pages every single day!” Alıntıya git
• “All major browsers include a bfcache, including Chrome since version 96, Firefox and Safari.” Alıntıya git

Google / Chrome — bir numaralı optimizasyon kuralı

• “Never use the unload event. Ever!” — web.dev. Alıntıya git

Chrome DevTools — bfcache, HTTP önbelleği değildir

• “Back/forward cache differs from browser cache and HTTP cache.” — Chrome DevTools belgeleri. Alıntıya git

Microsoft Edge — aynı özellik, aynı uyarı

• “When navigating away from a page, its current state (document tree, script, and so on) may be preserved in the back-forward cache. If the browser navigates back to the page, the page may be restored from the back-forward cache and displayed in the state it was in before being cached.” — Microsoft Edge politika belgeleri. Alıntıya git

Patrick Stox (ben) — bir CLS kaldıracı olarak bfcache

• “Make sure your pages are eligible for bfcache. The back/forward cache keeps pages in the browser cache. It allows for instant loading of a page that was already loaded, meaning no layout shifts will happen.” — Ahrefs CLS rehberim. Okuyun

Bfcache uygunluk kontrol listesi

Sayfalarınızın geri/ileri önbelleğine girebildiğini doğrulamak için yapılacak kontroller:

• Sayfanın hiçbir yerinde (size veya üçüncü taraf betiklere ait) unload olay dinleyicisi yok. Bu, tek başına en büyük engeldir.
• Temizleme/analiz kodu unload üzerinden pagehide ve visibilitychange olaylarına taşındı.
• Bir pageshow dinleyicisi, bfcache geri yüklemesinden sonra eski verileri yenilemek ve sayfa görüntülemelerini doğru biçimde yeniden saymak için event.persisted değerini kontrol ediyor.
• Herhangi bir unload dinleyicisinin kaydedilmesini engellemek için Permissions-Policy: unload=() yanıt başlığını değerlendirin.
• Cache-Control: no-store değerini inceleyin. Savunma amacıyla ayarladıysanız hâlâ gerekli olduğunu doğrulayın (Chrome 2025+, birçok no-store sayfasında bfcache’e koşullu olarak izin verir; kimlik doğrulama/çerez değişiminde sayfa bellekten çıkarılır ve aynı açık bağlantı API’leri engel olmaya devam eder. Diğer tarayıcıların veya sürümlerin aynı davranacağını varsaymayın). Güncellik önemliyse no-cache veya kısa bir max-age tercih edin.
• Gezinme sırasında açık bağlantı, zamanlayıcı veya gözlemci bırakılmamış: Devam eden fetch/XHR, açık IndexedDB işlemleri, WebSocket/WebRTC, MutationObserver/IntersectionObserver (pagehide/freeze sırasında kapatın veya duraklatın; event.persisted true olduğunda pageshow/resume sırasında yeniden kurun).
• Sayfayı uygunsuz bırakan window.opener başvurusu, kısıtlayıcı izin politikası veya engellenmiş çerçeve yok. Hangisinin geçerli olduğunu varsaymak yerine DevTools/notRestoredReasons içindeki çerçeve başına nedeni kontrol edin.
• Sayfayı Chrome DevTools → Application → Back/forward cache → “Test back/forward cache” yolundan laboratuvarda test edin.
• RUM ortamınızda notRestoredReasons ile büyük ölçekte alan tanılaması yapın (yalnızca Chrome; null geri yükleme kanıtı değildir ve neden metni kararlı bir sözleşme değildir. Dizeleri sabit kodlamayın, nedene göre eğilimi izleyin).
• Chrome testinden geçmenin her yerde uygunluk anlamına geldiğini varsaymayın; kendi kurallarını uygulayan Firefox ve Safari’de nokta kontrolleri yapın.

Bfcache kısa başvuru kılavuzu

Neler engeller ve nasıl düzeltilir?

Bilinmesi gereken olaylar

Test etme

Kısa bilgiler

• Bfcache = bellekteki canlı sayfanın tamamı; dosyalar, kaynak önbelleği veya service worker Cache Storage değildir. Chrome’a göre “differs from browser cache and HTTP cache.”
• Bir Google sıralama faktörü değildir; Search Central’ın CWV belgelerinde bundan hiç söz edilmez. Geri yükleme, bunu alan kullanıcıların ölçülen LCP/CLS değerlerini iyileştirir; geri yükleme oranını, toplam CWV’yi, sıralamaları veya dönüşümü garanti etmez.
• Destek: Chrome 96+, Firefox ve Safari; her birinin kendi kuralları vardır.
• Masaüstü gezinmelerinin 1 in 10, mobil gezinmelerin 1 in 5 kadarı Geri/İleri gezinmesidir.

Bfcache karşıtı kalıplar (ve arkalarındaki yanlış inanışlar)

“Bfcache yalnızca HTTP/tarayıcı önbelleğimdir; onu Cache-Control ile yapılandırırım.” Hayır. Bfcache, sayfanın tamamının ayrı bir bellek içi anlık görüntüsüdür. Chrome belgelerine göre “differs from browser cache and HTTP cache.” Önbellekleme başlıkları yalnızca no-store değerinin eskiden sayfayı uygunsuz kılması bakımından önemlidir. Önbellek başlıklarıyla “bfcache’i açmazsınız”.

“Bfcache bir Google sıralama faktörüdür; dolayısıyla düzeltmek sıralamaları yükseltir.” Bu, herhangi bir resmî Google Arama kaynağı tarafından ortaya konmamıştır. Google’ın Core Web Vitals sıralama belgesinde bfcache’ten söz edilmez. Gerçek ilişki dolaylıdır (Geri/İleri gezinmelerinde daha iyi alan LCP/CLS değerleri); bu, daha zayıf ve daha kesin bir iddiadır.

“Cache-Control: no-store, bfcache’i her zaman ve kalıcı olarak engeller.” Tarihsel olarak doğruydu ve hâlâ en büyük tarihsel nedendir. Ancak Chrome’un no-store için güvenli bfcache’i 2025’te tamamen dağıtmasından sonra artık kesin olarak doğru değildir. Değişiklikten önceki rehberler tam bu noktada güncelliğini yitirmiştir; ancak sorunu tamamen çözülmüş saymak da güncel değildir. Chrome’un istisnası koşulludur (kimlik doğrulama/çerez değişimlerinde sayfa bellekten çıkarılır ve aynı açık bağlantı API’leri engel olmaya devam eder), Chrome’a özgüdür ve evrensel bir yeşil ışık değildir.

“pagehide olayını persisted: true ile tetikleyen bir sayfa kesinlikle önbelleğe alınmıştır.” Hayır; bu kanıt değil, niyettir. Tarayıcı sayfayı bir geri yükleme görülmeden önce yine de bellekten çıkarabilir. Geri yüklemenin gerçekten gerçekleştiğini yalnızca pageshow.persisted === true doğrular.

“Chrome DevTools bfcache testini geçerse her yerde uygundur.” Yanlış. Chrome, Firefox ve Safari kendi kısıtlamalarını uygular; birindeki başarı diğerindeki uygunluğu garanti etmez.

“unload, çıkış/temizleme kodunu çalıştırmak için uygundur; kullanmaya devam edeceğim.” Hayır. Chrome bunun son derece güvenilmez olduğunu (mobilde çoğu zaman hiç tetiklenmediğini) belirtir ve tam da en büyük bfcache engeli olduğu için bir Permissions-Policy aracılığıyla etkin biçimde kullanımdan kaldırmaktadır. pagehide + visibilitychange kullanın.

“Bfcache, çok sayfalı bir siteye yardımcı olduğu gibi SPA’ime de yardımcı olur.” Açıklama yapılmadan doğru değildir. Bfcache gerçek tarayıcı gezinmelerine bağlıdır; istemci taraflı “yumuşak” rota değişikliği aynı olay değildir ve aynı şekilde işlenmez. Bu durum, SPA ağırlıklı sitelerde CrUX ile RUM arasında uyuşmazlıklara da neden olur.

“Bfcache çözüldü / eski bir konu; denetlenmeye değmez.” Web Almanac’ın kendi verileri bununla çelişir: no-store kullanımı artıyor ve unload kullanımı en büyük, en yoğun trafikli sitelerde belirgin ölçüde daha yüksek kalıyor. Bunlar, kaybedecek en fazla Geri/İleri trafiğine sahip sitelerdir.

Bfcache’i test ve teşhis etme araçları

• Chrome DevTools — Back/forward cache paneli. Application → Background services → Back/forward cache → “Test back/forward cache.” Otomatik olarak chrome://terms/ adresine gidip geri döner ve ardından başarıyı veya kesin engelleme nedenlerini bildirir. Tek URL üzerinde bir defalık laboratuvar kontrolü için en uygunudur.
• notRestoredReasons API’si (Chrome 123+). Yalnızca manuel laboratuvar testi yapmak yerine, aynı kaynaklı iframe’ler dâhil gerçek kullanıcıların engelleme nedenlerini büyük ölçekte görmek için RUM ortamınızda performance.getEntriesByType('navigation')[0].notRestoredReasons değerini okuyun.
• PageSpeed Insights / Lighthouse / CrUX. “Back/forward cache” önerisi veya işaretinin bir denetimde genellikle ilk göründüğü ve bfcache’e uygun bir sitenin alan CWV yararının ortaya çıktığı araçlardır.
• Permissions-Policy: unload=() başlığı. Test aracı değil, yaptırım kaldıracıdır: Üçüncü taraflara ait olanlar dâhil herhangi bir unload dinleyicisinin kaydedilmesini etkin biçimde önlemek için ayarlayın.
• Web Almanac (HTTP Archive) Performance bölümü. Cihaza ve site sıralaması katmanına göre bfcache engellerinin web genelinde ne kadar yaygın olduğunu kıyaslamak için kullanılır.

DevTools, bir unload işleyicisinin geri yüklemeyi engellediğini söylüyor

Belirti: Back/forward cache testi unload adını veriyor. Olası neden: Birinci veya üçüncü taraf kodu bir unload dinleyicisi kaydetmiştir. Düzeltme: Temizleme işlemini pagehide/visibilitychange ile değiştirin, uygun yerlerde Permissions-Policy: unload=() ekleyin ve etkilenen her betik değişikliğinden sonra testi yeniden çalıştırın.

Geri yüklenen sayfa eski kullanıcı verilerini gösteriyor

Belirti: Geri dönüş anında gerçekleşiyor ancak hesap durumu, envanter veya başka bir dinamik değer eski kalıyor. Olası neden: Sayfa, zamana duyarlı verileri yenilemeden dondurulmuş durumundan devam etmiştir. Düzeltme: pageshow olayını dinleyin, event.persisted değerini kontrol edin ve yalnızca gerekli verileri yenileyin. Hem sıradan yüklemelerin hem geri yüklemelerin doğru davrandığını doğrulayın.

Analytics, Geri/İleri görüntülemelerini kaçırıyor veya iki kez sayıyor

Belirti: Sayfa görüntülemeleri gerçek geçmiş gezinmelerinden farklıdır. Olası neden: Analytics yalnızca ilk yüklemede çalışıyor veya geri yüklemeyi ayırt etmeden iki kez çalışıyordur. Düzeltme: pageshow olayını açıkça işleyin ve geri yüklenen gezinmeyi bir kez saymak için event.persisted değerini kullanın.

Laboratuvar testi geçiyor ancak alan geri yükleme oranı düşük kalıyor

Belirti: Örneklenen bir URL DevTools testini geçerken RUM çok sayıda geri yüklenmeme bildiriyor. Olası neden: Diğer şablonlar, tarayıcılar, gerçek kullanıcı durumları veya aralıklı açık bağlantılar ek engeller oluşturuyordur. Düzeltme: notRestoredReasons verilerini toplayın, nedene ve şablona göre gruplandırın ve tek bir başarılı testten genelleme yapmak yerine alandaki baskın durumu yeniden üretin.

Bfcache düzeltmesinin devreye alındığını kanıtlama

Uygunluk testi

Çalıştırılacak test: DevTools → Application → Back/forward cache → Test back/forward cache. Beklenen sonuç: Sayfa hiçbir engelleme nedeni olmadan başarıyla geri yüklenir. Başarısızlık yorumu: En az bir uygunluk engeli kalmıştır. İzleme aralığı: Test edilen durumda Chrome için anında. Geri alma tetikleyicisi: Düzeltmenin temizleme, güvenlik veya gerekli uygulama davranışını bozması.

Geri yükleme davranışı testi

Çalıştırılacak test: Başka bir sayfaya gidip Geri düğmesine basın; ardından pageshow olayının event.persisted === true aldığını ve zamana duyarlı verilerin yenilendiğini doğrulayın. Beklenen sonuç: Bir anlık geri yükleme, doğru veriler ve bir analiz görüntülemesi. Başarısızlık yorumu: Sayfa önbelleğe alınmamıştır veya geri yükleme işleme mantığı eksiktir. İzleme aralığı: Temsilî oturumu açık/ kapalı durumlarda anında. Geri alma tetikleyicisi: Geri yüklemeden sonra eski hassas veriler veya yinelenen işlemler.

Alan nedeni testi

Çalıştırılacak test: RUM ortamında PerformanceNavigationTiming.notRestoredReasons değerini izleyin. Beklenen sonuç: Hedeflenen engel, etkilenen şablonlarda yerini yeni bir baskın engele bırakmadan azalır. Başarısızlık yorumu: Laboratuvar örneği üretimi temsil etmemiştir veya sorun başka bir bağımlılığa aittir. İzleme aralığı: Aynı şablon karışımını karşılaştırmaya yetecek gerçek Geri/İleri trafiği. Geri alma tetikleyicisi: Değişiklikle bağlantılı önemli bir uygulama veya veri bütünlüğü gerilemesi.

İzlenmeye değer bfcache metrikleri

Geri yükleme isabet oranı

Metrik: Bfcache’ten geri yüklenen uygun Geri/İleri gezinmeleri. Size ne söyler: Kullanıcıların anında gezinme avantajını ne sıklıkla elde ettiğini gösterir. Nasıl alınır: Tarayıcı ve şablona göre bölümlenmiş RUM gezinme girdileri ile pageshow.persisted. Kıyaslama / gerçekçi aralık: Tarayıcı kuralları, sayfa durumu ve gezinme karışımı değiştiğinden kendi temel değerinizi oluşturun. Sıklık: Haftalık ve yaşam döngüsü değişikliklerinden sonra.

Geri yüklenmeme nedenleri

Metrik: notRestoredReasons değerine göre gruplandırılmış geçmiş gezinmeleri. Size ne söyler: Hangi engellerin en fazla gerçek geri yüklemeye mal olduğunu gösterir. Nasıl alınır: Destekleyen tarayıcılardaki PerformanceNavigationTiming API’si. Kıyaslama / gerçekçi aralık: Tarayıcı/API kapsamını etiketleyerek kendi kodunuzun denetlediği engeller için sıfırı hedefleyin. Sıklık: Haftalık önceliklendirme.

Geri yüklenen gezinmenin doğruluğu

Metrik: Geri yüklemeden sonraki hatalar, eski veri olayları ve yinelenen analiz/ işlemler. Size ne söyler: Daha yüksek uygunluğun uygulama doğruluğunu koruyup korumadığını gösterir. Nasıl alınır: pageshow.persisted ile ilişkilendirilmiş RUM hata olayları, uygulama izleme ve analiz kalite güvencesi. Kıyaslama / gerçekçi aralık: Bilinen sıfır doğruluk veya gizlilik hatası. Sıklık: Sürekli uyarılar ve sürüm kalite güvencesi.

Zaman ayırmaya değer kaynaklar

İlgili yazılarım

• What Is Cumulative Layout Shift (CLS) & How To Improve It — kısa engel kontrol listesiyle birlikte bfcache uygunluğunu bir CLS iyileştirme taktiği olarak listelediğim yazı.
• What Are Core Web Vitals (CWVs) & How To Improve Them — bfcache’in birçok CLS kaldıracından biri olduğu üst düzey metrikler.
• The Beginner’s Guide to Technical SEO — web performansının büyük resimdeki yeri.

Konuşmalarım

• How Search Works (SlideShare) — bfcache gibi bir işleme motoru özelliğinin neden Arama’nın sıralama sinyalleri dışında kaldığını açıklamak üzere tarama, işleme, dizine ekleme ve sıralama süreçlerini anlattığım sunum. (Her zaman kullandığım sorumluluk reddi geçerlidir: “This is my understanding of systems… not going to be 100% complete or accurate.”)

Resmî

• Back/forward cache (web.dev) — temel belge.
• Enabling bfcache for Cache-Control: no-store ve Deprecating the unload event (Chrome for Developers) — eski rehberleri güncelliğini yitirmiş hâle getiren iki değişiklik.
• Understanding Core Web Vitals and Google Search results (Google Search Central) — dikkat çekici biçimde bfcache’ten hiç söz etmeyen sıralama belgesi.

Sektörden kaynaklar

• bfcache — MDN Glossary — doğru, motordan bağımsız tanım ve HTTP önbelleği ayrımı.
• What Does The Back/Forward Cache Mean For Site Speed? (DebugBear) — gerçek bir site günlüğü ve somut LCP karşılaştırmasıyla (~100ms önbellekli ve ~427ms önbelleksiz) bu alandaki en veri odaklı içerik.
• Back Forward Cache Explained (SpeedVitals) — mekanizma, uygunluk, test ve CWV etkisi.
• Back/Forward Cache: What It Is and How to Implement It (NitroPack) — CMS/hosting kitlesi için uygulama odaklı içerik.
• Performance Game Changer: Browser Back/Forward Cache (Smashing Magazine) — sağlam bir teknik derinlemesine inceleme; ancak 2025 no-store değişikliğinden önce yayımlandığını unutmayın.
• Web Almanac — Performance chapter (2025) (HTTP Archive) — cihaz ve site sıralaması katmanına göre unload ile no-store yaygınlığına ilişkin gerçek dünya benimsenme verileri.

Alıntılanmaya değer istatistikler

• Geri/İleri gezinmeleri yaygındır: “1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward” — bu, istisnai bir durum değil, fırsatın ölçeğidir. Kaynak
• unload, Chrome’daki bfcache isabet oranına ~18 yüzde puanına mal olur — bu nedenle bir numaralı engeldir ve kullanımdan kaldırılmaktadır. Kaynak
• Cache-Control: no-store, geçmişteki en büyük engeldi — Chrome’un 2025 Mart–Nisan dağıtımı birçok no-store sayfasına bfcache olanağı sağlamadan önce mobil geçmiş gezinmelerinin yaklaşık %17’sini, masaüstündekilerin ise %7’sini etkiliyordu. Kaynak
• Bfcache geri yüklemesi neredeyse anlıktır: DebugBear, geri yüklenen bir sayfada yaklaşık 100ms; önbelleksiz yüklemede ise ~427 ms LCP ölçtü. Kaynak
• Büyük siteler en çok kendi önlerini kesiyor: En büyük 1 000 sitede masaüstü sayfalarının ~%28’i ve mobil sayfaların ~%20’si hâlâ unload işleyicileri kullanırken, tüm sitelerde bu oranlar ~%11 / %10’dur; ayrıca no-store kullanımı artmaktadır (%21→%23). Kaynak

Kendinizi test edin: Back/Forward Cache (bfcache)

Bfcache’in ne olduğu, nelerin onu engellediği ve SEO ile ilişkisi hakkında beş kısa soru. Her biri için bir yanıt seçip kontrol edin.

Değişiklik günlüğü