Bir ziyaretçi ürün listesinden ayrıntı sayfasına geçip tarayıcının geri düğmesine bastığında, önceki sayfanın yeniden indirilmesini ve JavaScript'in baştan çalışmasını beklemek zorunda olmayabilir. Modern tarayıcılar uygun sayfayı tamamen yok etmek yerine bellekte dondurabilir; kullanıcı geri veya ileri gittiğinde aynı durumu çok kısa sürede yeniden gösterebilir. Bu mekanizmanın adı back/forward cache, yaygın kısaltmasıyla bfcache'tir.
bfcache, ilk sayfa açılışını hızlandıran genel bir optimizasyon değildir. Yalnızca tarayıcı geçmişi içindeki geri ve ileri navigasyonlarını hedefler. Bu nedenle CDN, klasik HTTP cache, görsel optimizasyonu veya önceden yükleme tekniklerinin yerine geçmez; farklı bir kullanıcı hareketindeki gecikmeyi azaltır. Bu rehber, bfcache'in nasıl çalıştığını, hangi uygulama davranışlarının geri yüklemeyi engellediğini ve canlı sistemlerde nasıl ölçülmesi gerektiğini ele alır.
bfcache nedir?
bfcache, kullanıcının ayrıldığı bir web sayfasının tamamını tarayıcı belleğinde geçici olarak saklayan geçmiş navigasyonu optimizasyonudur. Tarayıcı yalnızca HTML, CSS ve görsel yanıtlarını değil; DOM durumunu, JavaScript heap'ini, form alanlarını, kaydırma konumunu ve sayfanın ekrandaki mevcut halini koruyabilir. Kullanıcı geçmişteki bu sayfaya döndüğünde yeni bir ağ isteği ve tam yükleme döngüsü yerine dondurulmuş belge yeniden etkinleştirilir.
web.dev, tüm büyük tarayıcıların bir bfcache uygulaması bulunduğunu ve uygun sayfalarda geri veya ileri navigasyonun ağ kullanılmadan bellekteki sayfa durumundan geri getirilebildiğini belirtir web.dev bfcache rehberi. Tarayıcı özelliği otomatik çalışır; siteye “bfcache ekleyen” ayrı bir JavaScript kütüphanesi kurulmaz. Geliştiricinin görevi, sayfanın bu optimizasyona uygun kalmasını sağlamak ve geri yükleme sonrasında güncelliğini yitirebilecek durumları doğru yönetmektir.
bfcache teknik olarak nasıl çalışır?
Kullanıcı başka bir belgeye giderken tarayıcı uygun bulduğu sayfayı hemen imha etmez. JavaScript yürütmesini duraklatır, belgenin durumunu bellekte tutar ve sayfayı geçmiş girdisiyle ilişkilendirir. Kullanıcı kısa süre içinde geri dönerse belge yeniden görünür hâle getirilir ve yürütme devam eder. Bu süreçte normal bir navigasyonda görülen DNS, bağlantı, sunucu yanıtı, kaynak indirme, parse ve yeniden oluşturma adımlarının büyük bölümü gerçekleşmez.
Sayfanın bellekte tutulması garanti değildir. Tarayıcı cihaz belleğini korumak için kaydı silebilir, belirli API'lerin açık kalmasını riskli görebilir veya sayfa davranışının geri yüklemeyle uyumsuz olduğuna karar verebilir. Kullanıcı tarayıcıyı kapattığında, sekmeyi çoğalttığında ya da eski bir geçmiş girdisine çok sonra döndüğünde de bfcache kullanılmayabilir. Bu yüzden hedef yüzde yüz geri yükleme değil, site kaynaklı engelleri azaltmaktır.
bfcache, HTTP cache ve önceden yükleme aynı şey mi?
Üç yaklaşımın ortak amacı bekleme süresini azaltmaktır; fakat sakladıkları şey ve devreye girdikleri navigasyon türü farklıdır. bfcache'i doğru değerlendirmek için onu HTTP cache ve prefetch veya prerender tekniklerinden ayırmak gerekir.
| Yöntem | Ne saklar veya hazırlar? | Ne zaman devreye girer? | Temel sınırlama |
|---|---|---|---|
| bfcache | DOM ve JavaScript durumu dâhil tam sayfa anlık görüntüsü | Tarayıcı geçmişinde geri veya ileri giderken | Uygunluk tarayıcıya ve sayfa yaşam döngüsüne bağlıdır |
| HTTP cache | Daha önce alınmış HTTP yanıtları ve kaynak dosyaları | Kaynak yeniden istendiğinde | Sayfa yine parse, JavaScript çalıştırma ve render adımlarına ihtiyaç duyabilir |
| Prefetch | Gelecekte gerekebilecek kaynak veya belge yanıtı | Olası bir sonraki navigasyondan önce | Kullanıcının gerçekten tıklamayacağı kaynakları indirebilir |
| Prerender | Muhtemel sonraki sayfanın önceden oluşturulmuş hâli | Tahmin edilen yeni navigasyonda | Kaynak tüketimi ve yan etki riski nedeniyle dikkatli kullanılmalıdır |
bfcache geçmiş navigasyonuna özgüdür. Bir kullanıcı siteye ilk kez geliyorsa ya da daha önce açmadığı yeni bir bağlantıya tıklıyorsa bfcache yardımcı olmaz. Bu alanlarda web sitesi hız optimizasyonu, doğru cache başlıkları ve kaynak önceliklendirmesi hâlâ gereklidir.
Hangi sitelerde bfcache daha görünür fayda sağlar?
Geri düğmesinin yoğun kullanıldığı akışlar bfcache'in etkisini daha belirgin hâle getirir. Kullanıcıların liste ve detay arasında gidip geldiği e-ticaret, ilan, haber, katalog, dokümantasyon ve arama sonuçları bu gruptadır. Örneğin bir ziyaretçi ürün listesindeki beş ürünü sırayla inceliyorsa her geri dönüşte liste konumunun ve filtrelerin korunması yalnızca hız değil, bağlam sürekliliği de sağlar.
- Ürün, ilan veya içerik listesi ile ayrıntı sayfası arasında sık geçiş yapılan akışlar
- Uzun bir sayfada kaydırma konumunun kaybolmasının kullanıcıyı zorlayacağı deneyimler
- Mobil ağ veya düşük donanım nedeniyle tam yeniden yüklemenin pahalı olduğu oturumlar
- Form alanlarının ve geçici arayüz durumunun geri dönüşte korunmasının yararlı olduğu sayfalar
- Kullanıcının karşılaştırma yapmak için birkaç sayfayı peş peşe açtığı araştırma yolculukları
Bununla birlikte bellekte tutulan durum her zaman güncel olmayabilir. Stok, fiyat, kullanıcı oturumu veya yetki gibi kritik bilgiler için geri yüklemeden sonra doğrulama yapılmalıdır. Hız avantajı, güvenlik ve veri doğruluğu pahasına kullanılmamalıdır.
bfcache kullanımını en sık hangi sorunlar engeller?
Bir sayfanın bfcache'e girememesi tek bir nedene bağlı değildir. Engellerin bir bölümü geliştirici tarafından düzeltilebilir; bir bölümü tarayıcının henüz desteklemediği özelliklerden, alt frame'lerden veya cihaz belleği gibi site dışı koşullardan kaynaklanır. Chrome DevTools bu nedenleri “actionable”, “pending support” ve “not actionable” gibi gruplarla gösterebilir Chrome DevTools bfcache testi.
unload olayına güvenmek
En yaygın ve en net hatalardan biri unload olayını veri kaydetme, analitik gönderme veya kaynak kapatma amacıyla kullanmaktır. Bu olay modern sayfa yaşam döngüsünde güvenilir değildir ve bazı tarayıcılarda sayfayı bfcache için uygunsuz hâle getirir. Yerine navigasyon sırasında pagehide, görünürlük değişiminde visibilitychange ve yalnızca kaydedilmemiş değişiklik uyarısı gerektiğinde koşullu beforeunload kullanılmalıdır.
Chrome, unload davranışını 2026 boyunca kademeli biçimde varsayılan olarak devre dışı bırakmaktadır. Güncel takvim sayfa yüklemelerinin kapsama oranını aşamalı artırıyor; dolayısıyla eski kodun “sayfadan çıkarken kesin çalışır” varsayımı artık hem performans hem işlevsellik açısından sürdürülebilir değildir Chrome unload kullanımını kaldırma planı.
Cache-Control: no-store başlığını gereksiz kullanmak
Cache-Control: no-store, HTTP yanıtının saklanmamasını isteyen güçlü bir başlıktır ve hassas kullanıcı verisi içeren sayfalarda gerekli olabilir. Ancak sırf içerik güncel kalsın diye bütün dinamik sayfalara eklenmesi, bazı tarayıcılarda bfcache uygunluğunu azaltabilir. Güncellik gereksinimi hassas veri saklamama gereksinimiyle aynı değildir; çoğu durumda no-cache veya kısa yaşam süresi daha doğru olabilir.
Chrome, 2025'te güvenli gördüğü bazı no-store sayfalarını bfcache'e alacak davranışı yaygınlaştırdı; fakat bu yalnızca Chrome'a özgü sınırlı bir esnekliktir. Diğer tarayıcılar aynı başlığı engel kabul edebilir. Resmî Chrome belgesi de en iyi uygulamanın gereksiz no-store kullanımını azaltmak olduğunu vurgular Chrome no-store ve bfcache.
Açık bağlantılar ve devam eden işlemler
IndexedDB bağlantıları, devam eden fetch veya XMLHttpRequest işlemleri, WebRTC, WebTransport ve bazı gerçek zamanlı bağlantılar tarayıcıya göre geri yüklemeyi engelleyebilir. Uygulama, sayfa gizlenirken açık kaynakları kapatmalı; geri yükleme sırasında ihtiyaç varsa yeniden bağlanmalıdır. Bu yaşam döngüsü özellikle panel, sohbet, canlı takip ve kurumsal uygulamalarda yazılım geliştirme kararının parçası olmalıdır.
Tarayıcı davranışı zaman içinde değişir. Örneğin Chrome 149, açık WebSocket bağlantılarını bfcache'e girişte kapatarak sayfanın önbelleğe alınabilmesini desteklemeye başladı; buna karşın aynı davranış tüm tarayıcılarda aynı değildir web.dev Haziran 2026 web platformu güncellemeleri. Bu nedenle belirli bir API için ezberlenmiş eski uygunluk listesi yerine DevTools ve gerçek kullanıcı verisi kullanılmalıdır.
pageshow ve pagehide olayları nasıl kullanılmalı?
bfcache ile uyumlu bir sayfa, “sayfa bir kez yüklendi ve sonra tamamen yok oldu” varsayımıyla yazılmamalıdır. Belge dondurulabilir, bellekte bekleyebilir ve aynı JavaScript durumu daha sonra devam edebilir. Bu yaşam döngüsünü gözlemlemek için temel olaylar pagehide ve pageshow'dur.
- pagehide: Kullanıcı sayfadan ayrılırken çalışır. persisted değeri true ise tarayıcı sayfayı bfcache'e koymayı planlıyor olabilir; ancak bu, kesin olarak saklanacağı anlamına gelmez.
- pageshow: Hem ilk yüklemeden sonra hem de bfcache geri yüklemesinde çalışır. persisted değeri true olduğunda sayfanın bfcache'ten geri getirildiği anlaşılır.
- visibilitychange: Sekmenin görünür veya gizli duruma geçmesini izlemek ve kullanıcı verisini güvenilir bir anda kaydetmek için kullanılabilir.
- beforeunload: Yalnızca gerçekten kaydedilmemiş değişiklik varsa geçici olarak eklenmeli, değişiklik kaydedildiğinde kaldırılmalıdır.
MDN, engellenme nedenlerini izlemek için PerformanceNavigationTiming üzerindeki notRestoredReasons bilgisini önerir. Bu yapı üst belge ve iframe'ler için bfcache'in neden kullanılamadığını raporlayabilir MDN bfcache engel nedenlerini izleme. Destek bulunmayan tarayıcılarda ölçüm kodu hata üretmemeli; özellik kontrolüyle çalışmalıdır.
Geri yüklenen sayfada eski veya hassas veri nasıl yönetilir?
bfcache geri yüklemesi tam bir yeniden yükleme olmadığı için sunucudaki son durum otomatik alınmaz. Kullanıcı ürün detayından sepete gidip miktarı değiştirdikten sonra listeye döndüğünde eski sepet rozeti görülebilir. Benzer biçimde kullanıcı başka bir sekmede çıkış yaptıysa geçmişten dönen hesap sayfası kısa süreliğine eski oturum bilgisini gösterebilir.
Doğru çözüm bütün sayfayı her geri dönüşte zorla yenilemek değildir. pageshow olayı persisted true olduğunda yalnızca kritik durumu doğrulamak daha dengeli bir yaklaşımdır. Oturum geçerliliği, yetki, stok, fiyat, bildirim sayısı veya zaman hassasiyetli alanlar küçük bir API isteğiyle yenilenebilir; sayfanın geri kalanı bellekteki hâliyle korunabilir.
bfcache Chrome DevTools ile nasıl test edilir?
Manuel olarak geri ve ileri düğmelerine basmak hız farkını gösterebilir; fakat engelin kaynağını açıklamaz. Chrome DevTools içindeki Application bölümünde yer alan Back/forward cache paneli, sayfadan uzaklaşıp geri dönerek otomatik test yapar ve geri yüklemenin başarılı olup olmadığını raporlar.
- Test edilecek sayfayı normal veya gizli bir pencerede açın.
- DevTools içinden Application bölümüne gidin.
- Background services altında Back/forward cache panelini açın.
- Test back/forward cache komutunu çalıştırın.
- Başarısız sonuçta actionable nedenleri ve engel oluşturan frame'i inceleyin.
- unload dinleyicisi, response header, üçüncü taraf script veya açık bağlantı düzeltildikten sonra testi tekrarlayın.
Tek bir sayfada başarılı sonuç almak bütün sitenin uygun olduğu anlamına gelmez. Ana sayfa, liste, detay, giriş sonrası panel, form ve ödeme gibi farklı şablonlar ayrı test edilmelidir. Ayrıca tarayıcı eklentileri test sonucunu etkileyebileceği için temiz profil veya gizli pencere tercih edilmesi yararlıdır.
Canlı kullanıcı verisinde bfcache nasıl ölçülür?
Laboratuvar testi yalnızca test anındaki sayfayı değerlendirir. Canlı ortamda farklı tarayıcılar, üçüncü taraf script sürümleri, oturum durumları ve cihaz belleği nedeniyle sonuç değişebilir. Bu nedenle pageshow olayındaki persisted değeriyle geri yüklemeler sayılmalı, notRestoredReasons destekleniyorsa engel nedenleri anonim ve sınırlı biçimde toplanmalıdır.
Analitik sistemi bfcache geri yüklemelerini yeni bir sayfa görüntüleme olarak otomatik saymayabilir; çünkü klasik pageview kodu yalnızca ilk yüklemede çalışır. İşletme önce ölçüm tanımını belirlemelidir: Kullanıcının geri dönmesi yeni bir görüntüleme mi, aynı yolculuğun devamı mı kabul edilecek? Teknik uygulama, raporlama kararını sessizce değiştirmemelidir.
bfcache oranının yüzde yüz olmaması hata değildir. Tarayıcı bellek baskısı, sekme yaşam döngüsü ve site dışı nedenlerle kaydı silebilir. İzlenmesi gereken asıl sinyal, belirli şablonlarda sürekli tekrarlanan ve geliştirici tarafından düzeltilebilen engellerdir. Düzenli sürüm ve üçüncü taraf script değişiklikleri bu optimizasyonu bozabileceğinden, kontrol web sitesi bakım sürecine eklenmelidir.
bfcache optimizasyonu için uygulama kontrol listesi
- Kendi kodunuzda ve üçüncü taraf kütüphanelerde unload dinleyicisi bulunup bulunmadığını denetleyin.
- Kaydedilmemiş değişiklik uyarısı dışında beforeunload kullanmayın; gerektiğinde koşullu ekleyip kaldırın.
- Cache-Control: no-store başlığını yalnızca gerçek hassasiyet gereksinimi olan sayfalarda kullanın.
- pagehide veya freeze sırasında uygun bağlantıları kapatın; pageshow veya resume sırasında kontrollü biçimde yeniden kurun.
- pageshow persisted true olduğunda oturum, yetki, sepet, stok ve fiyat gibi kritik durumları doğrulayın.
- Ana sayfa yerine farklı şablon ve kullanıcı durumlarını DevTools ile ayrı ayrı test edin.
- iframe ve üçüncü taraf scriptlerin engel nedeni olup olmadığını frame ayrıntılarından kontrol edin.
- Canlı ortamda geri yükleme ve not-restored nedenlerini ölçün; yüzde yüz oran hedeflemek yerine düzeltilebilir sorunlara odaklanın.
- Tarayıcı güncellemeleriyle değişen API uygunluklarını periyodik olarak yeniden doğrulayın.
bfcache hangi sorunları çözmez?
bfcache yalnızca daha önce açılmış bir sayfaya geçmiş üzerinden dönüşü hızlandırır. İlk açılıştaki yavaş sunucu yanıtını, büyük JavaScript paketini, optimize edilmemiş görselleri, render engelleyici kaynakları veya kötü veri sorgularını düzeltmez. Kullanıcının yeni bir bağlantıya tıklaması da bfcache kapsamında değildir.
Ayrıca hız, geri yüklenen arayüzün doğru olduğu anlamına gelmez. Uygulama yaşam döngüsü hatalıysa aynı timer iki kez çalışabilir, bağlantılar çoğalabilir, eski yetki bilgisi görünebilir veya analitik eksik sayım yapabilir. Bu nedenle bfcache uyumluluğu yalnızca “test geçti” kutusu değil; veri tazeliği, güvenlik, ölçüm ve kaynak yönetimini birlikte ele alan bir mühendislik konusudur.
Sonuç: Anlık geri dönüş için sayfayı yeniden yükleme varsayımından çıkarın
bfcache, tarayıcının geçmişteki uygun sayfayı tam durumuyla bellekte tutup geri veya ileri navigasyonda yeniden etkinleştirmesidir. Kullanıcı açısından sonuç, listeye, forma ya da önceki içeriğe kaydırma konumu ve arayüz durumu korunarak çok hızlı dönmektir. Geliştirici açısından temel görevler unload bağımlılığını kaldırmak, gereksiz no-store kullanımını azaltmak, açık kaynakları yaşam döngüsüne göre yönetmek ve geri yüklemede kritik veriyi doğrulamaktır.
En sağlıklı yaklaşım DevTools testiyle başlar, farklı şablonlarda tekrarlanır ve canlı kullanıcı ölçümüyle sürdürülür. bfcache'i genel performans çalışmalarının yerine koymadan, geçmiş navigasyonuna özgü ayrı bir performans katmanı olarak ele almak hem teknik doğruluğu hem kullanıcı deneyimini korur.
Sıkça Sorulan Sorular
bfcache her web sitesinde otomatik olarak çalışır mı?
Tarayıcı bfcache'i otomatik yönetir; ancak her sayfa belleğe alınmaz. unload dinleyicileri, bazı açık bağlantılar, belirli response header'ları, iframe'ler, tarayıcı desteği ve cihaz belleği uygunluğu etkileyebilir. Siteye ayrı bir bfcache kütüphanesi eklemek gerekmez. Geliştirici, sayfanın yaşam döngüsünü uyumlu hâle getirir ve DevTools ile engelleri test eder. Tarayıcı bellek baskısı gibi site dışı nedenlerle uygun bir sayfa da her navigasyonda geri yüklenmeyebilir.
bfcache ile normal tarayıcı önbelleği arasındaki fark nedir?
HTTP cache daha önce alınmış HTML, CSS, JavaScript veya görsel yanıtlarını saklar. Sayfa tekrar açıldığında bu kaynaklar cache'ten gelse bile belge yeniden parse edilebilir ve JavaScript yeniden çalışabilir. bfcache ise DOM, JavaScript heap'i, form değerleri ve kaydırma konumu dâhil çalışır durumdaki sayfanın tamamını bellekte tutar. Bu nedenle geçmişte geri veya ileri giderken normal bir yeniden yüklemeden daha hızlı ve durum koruyucu bir deneyim sağlayabilir.
Cache-Control: no-store bfcache'i tamamen engeller mi?
Bu davranış tarayıcıya göre değişebilir. Birçok tarayıcı no-store bulunan ana belgeyi bfcache için uygunsuz kabul edebilir. Chrome ise güvenli gördüğü bazı no-store sayfalarını sınırlı koşullarda bfcache'e alabilmektedir. Bu esnekliğe güvenerek başlık stratejisi kurulmaz. Hassas veri gerçekten saklanmamalıysa no-store korunmalı; yalnızca içerik güncelliği amaçlanıyorsa no-cache veya kısa yaşam süresi gibi seçenekler değerlendirilmelidir.
Bir sayfanın bfcache'ten geri geldiği nasıl anlaşılır?
pageshow olayı hem ilk yüklemede hem de bfcache geri yüklemesinde çalışır. Olayın persisted özelliği true ise sayfa bfcache'ten geri getirilmiştir. Bu bilgi analitik olaylarını, kritik veri kontrolünü ve bağlantıların yeniden kurulmasını yönetmekte kullanılabilir. pagehide olayındaki persisted true değeri ise tarayıcının sayfayı cache'e koymayı planladığını gösterir; sayfanın kesin olarak saklandığı anlamına gelmez.
bfcache geri yüklemesinde stok ve oturum verisi eski kalır mı?
Kalabilir; çünkü sayfa sunucudan yeniden yüklenmez ve bellekteki önceki durumla görünür olur. Oturum, yetki, sepet, stok veya fiyat gibi zaman ve güvenlik hassasiyetli bilgiler pageshow sırasında persisted true olduğunda yeniden doğrulanmalıdır. Her şeyi baştan yüklemek yerine yalnızca kritik bileşenleri güncellemek, anlık geri dönüş avantajını korurken eski veya yetkisiz veri gösterme riskini azaltır.
bfcache Core Web Vitals değerlerini iyileştirir mi?
bfcache geri yüklemeleri kullanıcıya çok hızlı görünür ve gerçek kullanıcı deneyiminde geçmiş navigasyonlarını belirgin biçimde iyileştirebilir. Ancak bu mekanizma ilk sayfa yüklemesini veya yeni bir bağlantıya geçişi düzeltmez. Yavaş sunucu yanıtı, büyük JavaScript, görseller ve render sorunları ayrıca optimize edilmelidir. Bu nedenle bfcache, Core Web Vitals ve genel performans planının yerine geçen tek çözüm değil, geçmiş navigasyonuna özgü tamamlayıcı bir katmandır.
