Geri-ileri önbellek (veya bfcache), hızlı geri ve ileri gezinmeyi sağlayan bir tarayıcı optimizasyonudur. Özellikle yavaş ağları veya cihazları olan kullanıcılar için tarama deneyimini önemli ölçüde iyileştirir.
Web geliştiricileri olarak, kullanıcılarınızın avantajlardan yararlanabilmeleri için sayfalarınızı bfcache için nasıl optimize edeceğinizi anlamanız çok önemlidir.
Tarayıcı uyumluluğu
bfcache yıllardır hem Firefox hem de Safari'de masaüstü ve mobil cihazlarda desteklenmektedir.
Sürüm 86'dan itibaren Chrome, kullanıcıların küçük bir yüzdesi için Android'de siteler arası gezinme için bfcache'i etkinleştirmiştir. Sonraki sürümlerde ek destek kademeli olarak kullanıma sunuldu. bfcache, sürüm 96'dan itibaren masaüstü ve mobil cihazlardaki tüm Chrome kullanıcıları için etkinleştirilmiştir.
bfcache ile ilgili temel bilgiler
bfcache, kullanıcı sayfadan ayrılırken sayfanın tam anlık görüntüsünü (JavaScript yığını dahil) depolayan bellek içi önbellektir. Tüm sayfa bellekteyken, kullanıcı geri dönmeye karar verirse tarayıcı sayfayı hızlı bir şekilde geri yükleyebilir.
Kaç kez bir web sitesini ziyaret ettiniz ve başka bir sayfaya gitmek için bir bağlantıyı tıkladınız. Kaç kez, istediğinizi fark edip geri düğmesini tıkladınız? Bu sırada bfcache önceki sayfanın yüklenme hızı konusunda büyük bir fark yaratabilir:
| Bfcache etkin olmadan | Önceki sayfanın yüklenmesi için yeni bir istek başlatılır ve söz konusu sayfanın yinelenen ziyaretler için ne kadar iyi optimize edildiğine bağlı olarak tarayıcının az önce indirdiği kaynakların bazılarını (veya tümünü) yeniden indirmesi, yeniden ayrıştırması ve yeniden çalıştırması gerekebilir. |
| Bfcache etkin olduğunda | Önceki sayfa aslında anında yüklenir çünkü tüm sayfa ağa gitmek zorunda kalmadan bellekten geri yüklenebilir. |
Gezinmelere nasıl hız kazandırabileceğini anlamak için bfcache'in nasıl çalıştığını gösteren bu videoyu izleyin:
Videoda, bfcache içermeyen örnek, bfcache içermeyen örnekten biraz daha hızlıdır.
bfcache yalnızca gezinmeyi hızlandırmakla kalmaz, aynı zamanda kaynakların tekrar indirilmesini gerektirmediğinden veri kullanımını da azaltır.
Chrome kullanım verileri, masaüstünde 10 gezinmeden 1'inin mobilde ise 5'te 1'inin geri veya ileri olduğunu gösteriyor. Bfcache etkinleştirildiğinde tarayıcılar, her gün milyarlarca web sayfası için veri aktarımını ve yüklenme süresini ortadan kaldırabilir.
"Önbellek" nasıl çalışır?
Bfcache tarafından kullanılan "önbellek", yinelenen gezinmelerin hızlandırılmasında rolünün üstlendiği HTTP önbelleğinden farklıdır. bfcache, JavaScript yığını da dahil olmak üzere tüm sayfanın bellekteki anlık görüntüsüdür. HTTP önbelleği ise yalnızca önceden yapılan isteklere ilişkin yanıtları içerir. HTTP önbelleğinden yerine getirilecek bir sayfanın yüklenmesi için gereken tüm istekler çok nadir gerçekleştiğinden, bfcache geri yüklemelerinin kullanıldığı yinelenen ziyaretler, en iyi optimize edilmiş bfcache olmayan gezinmelerden bile her zaman daha hızlıdır.
Ancak, bir sayfanın bellekteki anlık görüntüsünü oluşturmak, devam etmekte olan kodun en iyi şekilde nasıl korunacağı açısından bazı karmaşık işlemler gerektirir. Örneğin, sayfa bfcache'deyken zaman aşımına ulaşıldığında setTimeout() çağrılarını nasıl ele alırsınız?
Bunun nedeni, tarayıcıların JavaScript görev sıralarındaki neredeyse tüm bekleyen görevler de dahil olmak üzere Bfcache'daki sayfalar için bekleyen zamanlayıcıları veya çözülmemiş vaatleri duraklatması ve sayfa bfcache'den geri yüklenirse işleme görevlerine devam etmesidir.
Zaman aşımları ve vaatler gibi bazı durumlarda bu, oldukça düşük bir risk teşkil eder. Ancak bazı durumlarda, kafa karıştırıcı veya beklenmeyen davranışlara yol açabilir. Örneğin, tarayıcı bir IndexedDB işleminin parçası olarak gerekli bir görevi duraklatırsa, aynı IndexedDB veritabanlarına aynı anda birden çok sekme tarafından erişilebildiğinden, bu durum aynı kaynaktaki diğer açık sekmeleri etkileyebilir. Sonuç olarak tarayıcılar genellikle bir IndexedDB işleminin ortasında veya diğer sayfaları etkileyebilecek API'leri kullanırken sayfaları önbelleğe almayı denemez.
Çeşitli API kullanımlarının bir sayfanın bfcache uygunluğunu nasıl etkilediği hakkında daha fazla bilgi için Sayfalarınızı bfcache için optimize etme başlıklı makaleye bakın.
Bfcache ve iframe'ler
Bir sayfa yerleştirilmiş iframe'ler içeriyorsa iframe'lerin kendileri bfcache için uygun olmaz. Örneğin, bir iframe içindeki başka bir sayfaya gider, ancak daha sonra geri dönerseniz, tarayıcı ana çerçeve yerine iframe içinde "geri" gider, ancak iframe içindeki geri gezinme bfcache'i kullanmaz.
Yerleştirilmiş bir iframe bunu engelleyen API'ler kullanıyorsa ana çerçevenin bfcache kullanması da engellenebilir. Bunu önlemek için ana çerçevede ayarlanan İzin Politikası veya sandbox özelliklerinin kullanımı kullanılabilir.
Bfcache ve Tek Sayfalık Uygulamalar (SPA)
Bfcache tarayıcı tarafından yönetilen gezinmelerle çalıştığından, tek sayfalık bir uygulamadaki (SPA) "soft gezinmeler" için çalışmaz. Ancak bfcache, bir SPA'ya dönerken söz konusu uygulamayı baştan tekrar tamamen başlatmak yerine yine de yardımcı olabilir.
Bfcache gözlemlenecek API'ler
Bfcache, tarayıcıların otomatik olarak yaptığı bir optimizasyon olsa da geliştiricilerin, sayfalarını bunun için optimize edebilmeleri ve tüm metrikleri veya performans ölçümlerini buna göre ayarlayabilmeleri için sorunun ne zaman olduğunu bilmesi önemlidir.
Bfcache'i gözlemlemek için kullanılan birincil etkinlikler, çoğu tarayıcı tarafından desteklenen sayfa geçiş etkinlikleri pageshow ve pagehide'dir.
Daha yeni Sayfa Yaşam Döngüsü etkinlikleri (freeze ve resume), sayfalar bfcache'a girdiğinde veya buradan ayrıldığında ve CPU kullanımını en aza indirmek için bir arka plan sekmesinin donması gibi başka durumlarda da dağıtılır. Bu etkinlikler yalnızca Chromium tabanlı tarayıcılarda desteklenir.
Bir sayfa bfcache'den geri yüklendiğinde gözlemleme
pageshow etkinliği, load etkinliğinden hemen sonra sayfa ilk kez yüklenirken ve sayfa bfcache'den her geri yüklendiğinde tetiklenir. pageshow etkinliğinin bir persisted özelliği vardır. Sayfa bfcache'den geri yüklendiyse true, aksi takdirde false olur. Normal sayfa yüklemelerini bfcache geri yüklemelerinden ayırt etmek için persisted özelliğini kullanabilirsiniz. Örneğin:
window.addEventListener('pageshow', (event) => {
if (event.persisted) {
console.log('This page was restored from the bfcache.');
} else {
console.log('This page was loaded normally.');
}
});
Page Lifecycle API'yi destekleyen tarayıcılarda, sayfalar bfcache'den geri yüklendiğinde (pageshow etkinliğinden hemen önce) ve kullanıcı dondurulmuş bir arka plan sekmesini yeniden ziyaret ettiğinde resume etkinliği tetiklenir. Bir sayfanın dondurulduktan sonra durumunu güncellemek istiyorsanız (bfcache'daki sayfalar dahildir) resume etkinliğini kullanabilirsiniz, ancak sitenizin bfcache isabet oranını ölçmek istiyorsanız pageshow etkinliğini kullanmanız gerekir. Bazı durumlarda her ikisini de kullanmanız gerekebilir.
Bfcache ölçümüyle ilgili en iyi uygulamalar hakkında ayrıntılı bilgi için Bfcache analiz ve performans ölçümünü nasıl etkiler? başlıklı makaleyi inceleyin.
Bir sayfa bfcache'e girdiğinde gözlemle
pagehide etkinliği, bir sayfa kaldırıldığında veya tarayıcı sayfayı bfcache'ye yerleştirmeye çalıştığında tetiklenir.
pagehide etkinliğinin bir persisted özelliği de vardır. false ise, o sayfanın bfcache'ye girmek üzere olmadığından emin olabilirsiniz. Ancak persisted değerinin true olması, sayfanın önbelleğe alınacağını garanti etmez. Bu, tarayıcının sayfayı önbelleğe almak intends anlamına gelir, ancak önbelleğe alınmasını imkansız hale getiren başka faktörler de olabilir.
window.addEventListener('pagehide', (event) => {
if (event.persisted) {
console.log('This page *might* be entering the bfcache.');
} else {
console.log('This page will unload normally and be discarded.');
}
});
Benzer şekilde, persisted true ise freeze etkinliği pagehide etkinliğinden hemen sonra tetiklenir, ancak bu yalnızca tarayıcının sayfayı önbelleğe almayı intends anlamına gelir. Daha sonra açıklanan çeşitli nedenlerden dolayı hesabın silinmesi gerekebilir.
Sayfalarınızı Bfcache için optimize edin
Tüm sayfalar bfcache'de depolanmaz ve bir sayfa orada depolansa bile süresiz olarak orada kalmaz. Geliştiricilerin önbellek isabet oranlarını en üst düzeye çıkarmak için sayfaları bfcache için uygun (ve uygun olmayan) yapan şeyleri anlaması çok önemlidir.
Aşağıdaki bölümlerde, tarayıcının sayfalarınızı önbelleğe alabilmesi için mümkün olan en iyi uygulamalar özetlenmektedir.
unload etkinliğini hiçbir zaman kullanma
Tüm tarayıcılarda bfcache için optimizasyon yapmanın en önemli yolu, unload etkinliğini hiçbir zaman kullanmamaktır. Hep!
unload etkinliği, bfcache tarihinden önce olduğundan ve internetteki birçok sayfanın unload etkinliği tetiklendikten sonra bir sayfanın var olmayacağı (makul) varsayımıyla çalıştığından tarayıcılar için sorunludur. Bu durum bir zorluk teşkil ediyor çünkü bu sayfaların birçoğu aynı zamanda, kullanıcı sayfadan ayrıldığında unload etkinliğinin tetikleneceği varsayımıyla oluşturulmuş. Bu durum artık geçerli değil (ve uzun süredir doğru değil).
Dolayısıyla tarayıcılar bir ikilemle karşı karşıya kaldığı için, kullanıcı deneyimini iyileştirebilecek bir şey seçmek zorunda kalıyorlar ama sayfayı kırma riski de taşıyorlar.
Masaüstünde Chrome ve Firefox, bir unload işleyicisi eklemeleri halinde sayfaları bfcache için uygun olmayacak şekilde ayarlamıştır. Bu işlem daha az risk taşır, ancak aynı zamanda çok sayıda sayfayı diskalifiye eder. Safari, bir unload etkinlik işleyiciyle bazı sayfaları önbelleğe almaya çalışır, ancak olası kesintileri azaltmak için kullanıcı sayfadan ayrılırken unload etkinliğini çalıştırmaz. Bu da etkinlik güvenilirliğini son derece güvenilmez hale getirir.
Mobil cihazlarda Chrome ve Safari, unload etkinlik işleyicisi içeren sayfaları önbelleğe almaya çalışır. Bunun nedeni, unload etkinliğinin mobil cihazlarda her zaman son derece güvenilmez olması nedeniyle bozulma riski daha azdır. Firefox, unload kullanan sayfaları iOS hariç, bfcache için uygun değil olarak değerlendirir. iOS'te tüm tarayıcıların WebKit oluşturma motorunu kullanması gerekir, bu nedenle de Safari gibi davranır.
unload etkinliğini kullanmak yerine pagehide etkinliğini kullanın. pagehide etkinliği, unload etkinliğinin tetiklendiği her durumda tetiklenir. Bir sayfa bfcache'e yerleştirildiğinde de ayrıca tetiklenir.
Lighthouse'un, sayfalarında herhangi bir JavaScript'in (üçüncü taraf kitaplıklardakiler de dahil) unload etkinlik işleyici eklemesi durumunda geliştiricileri uyaran bir no-unload-listeners denetimi bulunmaktadır.
Chrome, güvenilmezliği ve bfcache için performans üzerindeki etkisi nedeniyle unload etkinliğini kullanımdan kaldırmak istiyor.
Bir sayfada kaldırma işleyicilerin kullanılmasını önlemek için İzin Politikası'nı kullanın
unload etkinlik işleyicilerini kullanmayan siteler, Chrome 115 İzin Politikası kullanarak bunların eklenmemesini sağlayabilir.
Permission-Policy: unload()
Bu ayrıca, üçüncü tarafların veya uzantıların kaldırma işleyicileri ekleyerek ve siteyi bfcache için uygun olmayan hale getirerek siteyi yavaşlatmasını da önler.
Yalnızca beforeunload işleyicileri koşullu olarak ekle
beforeunload etkinliği, sayfalarınızı modern tarayıcılarda bfcache için uygun olmayan bir hale getirmez. Ancak daha önce böyle yapıyordu ve hâlâ güvenilir değil. Bu nedenle, kesinlikle gerekli olmadığı sürece bu etkinliği kullanmaktan kaçının.
Bununla birlikte, unload etkinliğinin aksine beforeunload için geçerli kullanımlar vardır. Örneğin, kullanıcıyı kaydedilmemiş değişiklikleri olduğu konusunda uyarmak istediğinizde,
sayfadan ayrılmaları durumunda bu değişiklikleri kaybedecekleri konusunda sizi uyarmak isteriz. Bu durumda, beforeunload işleyicileri yalnızca kullanıcıda kaydedilmemiş değişiklikler varsa eklemeniz ve ardından kaydedilmemiş değişiklikler kaydedildikten hemen sonra bunları kaldırmanız önerilir.
window.addEventListener('beforeunload', (event) => {
if (pageHasUnsavedChanges()) {
event.preventDefault();
return event.returnValue = 'Are you sure you want to exit?';
}
});
Bu kod, koşulsuz olarak bir beforeunload işleyicisi ekler.
function beforeUnloadListener(event) {
event.preventDefault();
return event.returnValue = 'Are you sure you want to exit?';
};
// A function that invokes a callback when the page has unsaved changes.
onPageHasUnsavedChanges(() => {
window.addEventListener('beforeunload', beforeUnloadListener);
});
// A function that invokes a callback when the page's unsaved changes are resolved.
onAllChangesSaved(() => {
window.removeEventListener('beforeunload', beforeUnloadListener);
});
Bu kod, beforeunload işleyicisini yalnızca gerekli olduğunda ekler (ve gerektiğinde kaldırır).
Cache-Control: no-store kullanımını en aza indir
Cache-Control: no-store, web sunucularının tarayıcıya yanıtı herhangi bir HTTP önbelleğinde depolamamasını söyleyen yanıtlar üzerinde ayarlayabileceği bir HTTP üst bilgisidir. Hassas kullanıcı bilgileri içeren kaynaklar (ör. giriş yapılarak erişilen sayfalar) için kullanılır.
bfcache bir HTTP önbelleği olmasa da geçmişte, Cache-Control: no-store sayfa kaynağının kendisinde ayarlandığında (herhangi bir alt kaynağın aksine) tarayıcılar sayfayı bfcache'de depolamamayı seçmiştir. Gizliliği koruyacak şekilde Chrome'da bu davranışı değiştirmek için çalışmalar yapılmaktadır, ancak şu anda Cache-Control: no-store kullanan sayfalar bfcache için uygun değildir.
Cache-Control: no-store bir sayfanın bfcache için uygunluğunu kısıtladığından, yalnızca hassas bilgiler içeren sayfalarda hiçbir şekilde önbelleğe almanın uygun olmadığı sayfalarda ayarlanmalıdır.
Her zaman güncel içerik sunması gereken ve hassas bilgiler içermeyen sayfalar için Cache-Control: no-cache veya Cache-Control: max-age=0 kullanın. Bu yönergeler, tarayıcıya içeriği sunmadan önce yeniden doğrulamasını söyler ve sayfanın bfcache uygunluğunu etkilemez.
Bir sayfa bfcache'den geri yüklendiğinde HTTP önbelleğinden değil bellekten geri yüklendiğini unutmayın. Sonuç olarak, Cache-Control: no-cache veya Cache-Control: max-age=0 gibi yönergeler dikkate alınmaz ve içerik kullanıcıya gösterilmeden önce yeniden doğrulama işlemi yapılmaz.
Bununla birlikte, bfcache geri yüklemesi anında yapıldığı ve sayfalar çok uzun süre bfcache'de kalmadığı için içeriğin güncelliği pek olası değildir. Bu nedenle, bu durum büyük olasılıkla daha iyi bir kullanıcı deneyimi sağlar. Ancak içeriğiniz dakika dakika değişiyorsa bir sonraki bölümde açıklandığı gibi pageshow etkinliğini kullanarak güncellemeleri alabilirsiniz.
Bfcache geri yüklendikten sonra eski veya hassas verileri güncelleme
Siteniz kullanıcı durumunu, özellikle de hassas kullanıcı bilgilerini koruyorsa, bir sayfa bfcache'den geri yüklendikten sonra bu verilerin güncellenmesi veya temizlenmesi gerekir.
Örneğin, kullanıcı bir ödeme sayfasına gider ve ardından alışveriş sepetini güncellerse eski bir sayfa bfcache'den geri yüklenirse geri gezinme menüsünde güncel olmayan bilgiler gösterilebilir.
Daha kritik bir başka örnek de bir kullanıcının herkese açık bir bilgisayarda siteden çıkış yapması ve sonraki kullanıcının geri düğmesini tıklamasıdır. Bu durum, kullanıcı oturumunu kapattığında temizlendiğini düşündüğü gizli verileri açığa çıkarabilir.
event.persisted true ise bunun gibi durumlardan kaçınmak için sayfayı bir pageshow etkinliğinden sonra her zaman güncellemek iyi bir fikirdir:
window.addEventListener('pageshow', (event) => {
if (event.persisted) {
// Do any checks and updates to the page
}
});
İdeal koşullarda içeriği yerinde güncellersiniz, ancak bazı değişiklikler için tam yeniden yüklemeyi zorlamak isteyebilirsiniz. Aşağıdaki kod, pageshow etkinliğinde siteye özgü bir çerezin olup olmadığını kontrol eder ve çerez bulunamazsa yeniden yüklenir:
window.addEventListener('pageshow', (event) => {
if (event.persisted && !document.cookie.match(/my-cookie)) {
// Force a reload if the user has logged out.
location.reload();
}
});
Yeniden yüklemenin geçmişi koruma avantajı vardır (ileriye gitmeye olanak sağlamak için) ancak bazı durumlarda yeniden yönlendirme daha uygun olabilir.
Ads ve Bfcache geri yükleme
Her geri-ileri gezinme işleminde yeni bir reklam grubu sunmak için bfcache kullanmaktan kaçınmak cazip gelebilir. Ancak, bu davranışın performans üzerindeki etkisinin yanı sıra daha iyi reklam etkileşimi sağlayıp sağlamadığı da şüphe uyandırıyor. Kullanıcılar, tıklamaya dönmek istedikleri bir reklamı, ancak bunu yapamadıkları bfcache'den geri yüklemek yerine yeniden yükleyerek fark etmiş olabilirler. Varsayımlarda bulunmadan önce bu senaryoyu (ideal olarak A/B testiyle) test etmek önemlidir.
Bfcache geri yüklemesinde reklamları yenilemek ve ardından event.persisted true olduğunda yalnızca pageshow etkinliğindeki reklamları yenilemek isteyen siteler için sayfa performansı etkilenmeden bu işlem gerçekleşebilir. Reklam sağlayıcınızla görüşün. Ancak bunun Google Yayınlama Etiketi ile nasıl yapılacağına ilişkin bir örneği burada bulabilirsiniz.
window.opener referanslarından kaçının
Daha eski tarayıcılarda, bir sayfa rel="noopener" belirtilmeden target=_blank içeren bir bağlantıdan window.open() kullanılarak açıldıysa açılış sayfasında, açılan sayfanın pencere nesnesine bir referans bulunur.
Güvenlik riski olmasının yanı sıra, boş olmayan bir window.opener referansı olan bir sayfa, erişmeye çalışan sayfaların bozulmasına neden olabileceği için güvenli bir şekilde bfcache'e yerleştirilemez.
Bu nedenle, window.opener referansları oluşturmaktan kaçınmak en iyisidir. Bunu, mümkün olduğunda rel="noopener" kullanarak yapabilirsiniz (bu özelliğin artık tüm modern tarayıcılarda varsayılan ayardır). Siteniz bir pencere açmayı ve window.postMessage() ile bu pencerenin kontrol edilmesini veya doğrudan pencere nesnesine referans verilmesini gerektiriyorsa ne açılan pencere ne de açıcı bfcache için uygun olmaz.
Kullanıcı gitmeden önce açık bağlantıları kapatın
Daha önce de belirtildiği gibi, bir sayfa bfcache'a yerleştirildiğinde, programlanmış tüm JavaScript görevlerini duraklatır ve sayfa önbellekten çıkarıldığında bunları devam ettirir.
Bu zamanlanmış JavaScript görevleri yalnızca DOM API'lerine (veya yalnızca geçerli sayfaya izole başka API'lara) erişiyorsa, sayfanın kullanıcı tarafından görülemeyeceği bir zamanda bu görevlerin duraklatılması herhangi bir soruna neden olmaz.
Ancak bu görevler, aynı kaynaktaki diğer sayfalardan da erişilebilen API'lere (örneğin: IndexedDB, Web Locks, WebSockets) bağlıysa bu görevlerin duraklatılması diğer sekmelerdeki kodun çalışmasını engelleyeceğinden bu durum sorun yaratabilir.
Sonuç olarak bazı tarayıcılar, aşağıdaki senaryolarda bir sayfayı bfcache'ye yerleştirmeyi denemez:
- Açık IndexedDB bağlantısına sahip sayfalar
- Devam eden fetch() veya XMLHttpRequest öğesi içeren sayfalar
- Açık WebSocket veya WebRTC bağlantısına sahip sayfalar
Sayfanız bu API'lerden herhangi birini kullanıyorsa pagehide veya freeze etkinliği sırasında bağlantıları ve gözlemcileri kaldırmanızı veya bağlantılarını kaldırmanızı kesinlikle öneririz. Böylece tarayıcı, diğer açık sekmeleri etkileme riski olmadan sayfayı güvenli bir şekilde önbelleğe alabilir.
Ardından, sayfa bfcache'den geri yüklenirse pageshow veya resume etkinliği sırasında bu API'leri yeniden açabilir veya bu API'lere yeniden bağlanabilirsiniz.
Aşağıdaki örnekte, pagehide etkinlik işleyicide açık bir bağlantıyı kapatarak IndexedDB kullanan sayfaların bfcache için uygun olmasını nasıl sağlayacağınız gösterilmektedir:
let dbPromise;
function openDB() {
if (!dbPromise) {
dbPromise = new Promise((resolve, reject) => {
const req = indexedDB.open('my-db', 1);
req.onupgradeneeded = () => req.result.createObjectStore('keyval');
req.onerror = () => reject(req.error);
req.onsuccess = () => resolve(req.result);
});
}
return dbPromise;
}
// Close the connection to the database when the user leaves.
window.addEventListener('pagehide', () => {
if (dbPromise) {
dbPromise.then(db => db.close());
dbPromise = null;
}
});
// Open the connection when the page is loaded or restored from bfcache.
window.addEventListener('pageshow', () => openDB());
Sayfalarınızın önbelleğe alınabilir olup olmadığını test edin
Chrome Geliştirici Araçları, sayfalarınızın Bfcache için optimize edildiğinden emin olmak amacıyla sayfalarınızı test etmenize ve uygun olmalarını engelleyebilecek sorunları belirlemenize yardımcı olabilir.
Bir sayfayı test etmek için:
- Chrome'da sayfaya gidin.
- DevTools'da Uygulama -> Geri-İleri Önbellek'e gidin.
- Testi Çalıştır düğmesini tıklayın. Daha sonra Geliştirici Araçları, sayfanın bfcache'den geri yüklenip yüklenemeyeceğini belirlemek için sayfadan ayrılmayı dener.
Test başarılı olursa panel "Geri-ileri önbellekten geri yüklendi" bildiriminde bulunur.
Başarısız olursa panel bunun nedenini belirtir. Neden, geliştirici olarak ele alabileceğiniz bir konuysa panel bunu İşlem Yapılabilir olarak işaretler.
Bu örnekte, unload etkinlik işleyicinin kullanılması sayfayı bfcache için uygunsuz hale getirir. unload ürününden pagehide kullanımına geçerek bu sorunu düzeltebilirsiniz:
window.addEventListener('pagehide', ...);
window.addEventListener('unload', ...);
Lighthouse 10.0, benzer bir test gerçekleştiren bir bfcache denetimi de ekledi. Daha fazla bilgi için bfcache denetiminin belgelerine göz atın.
Bfcache analiz ve performans ölçümünü nasıl etkiler?
Sitenize yapılan ziyaretleri ölçmek için bir analiz aracı kullanıyorsanız, Chrome daha fazla kullanıcı için bfcache'i etkinleştirdiğinden, raporlanan toplam sayfa görüntüleme sayısında bir düşüş fark edebilirsiniz.
Aslında, birçok popüler analiz kitaplığı bfcache geri yüklemelerini yeni sayfa görüntülemeler olarak ölçmediği için, bfcache uygulayan diğer tarayıcılardan gelen sayfa görüntüleme sayılarını eksik raporluyor olabilirsiniz.
Sayfa görüntüleme sayınıza bfcache geri yüklemelerini dahil etmek üzere pageshow etkinliği için işleyiciler ayarlayın ve persisted özelliğini kontrol edin.
Aşağıdaki örnekte, bu işlemin Google Analytics ile nasıl yapılacağı gösterilmektedir. Diğer analiz araçları da muhtemelen benzer bir mantık kullanır:
// Send a pageview when the page is first loaded.
gtag('event', 'page_view');
window.addEventListener('pageshow', (event) => {
// Send another pageview if the page is restored from bfcache.
if (event.persisted) {
gtag('event', 'page_view');
}
});
Bfcache isabet oranınızı ölçün
Ayrıca, bfcache kullanmayan sayfaları belirlemeye yardımcı olması için bfcache'ın kullanılıp kullanılmadığını ölçmek de isteyebilirsiniz. Bu, sayfa yüklemeleri için gezinme türünü ölçerek yapılabilir:
// Send a navigation_type when the page is first loaded.
gtag('event', 'page_view', {
'navigation_type': performance.getEntriesByType('navigation')[0].type;
});
window.addEventListener('pageshow', (event) => {
if (event.persisted) {
// Send another pageview if the page is restored from bfcache.
gtag('event', 'page_view', {
'navigation_type': 'back_forward_cache';
});
}
});
back_forward gezinme ve back_forward_cache gezinme sayılarını kullanarak bfcache isabet oranınızı hesaplayın.
Geri/İleri gezinmesinin bfcache'i kullanmadığı, site sahiplerinin kontrolü dışında kalan çeşitli senaryolar olduğunun anlaşılması önemlidir. Örneğin:
- Kullanıcı tarayıcıdan çıkıp tarayıcıyı yeniden başlattığında
- Kullanıcı bir sekmeyi yinelediğinde
- Kullanıcı bir sekmeyi kapatıp yeniden açtığında
Bazı durumlarda, orijinal gezinme türü bazı tarayıcılar tarafından korunabilir ve bu nedenle Geri/İleri gezinme olmamasına rağmen bir back_forward türü gösterilebilir.
Bu hariç tutmalar olmasa bile bfcache bellekten tasarruf etmek için bir süre sonra silinir.
Dolayısıyla, web sitesi sahipleri tüm back_forward gezinmeleri için% 100 bfcache isabet oranı beklememelidir. Bununla birlikte, oranını ölçmek, sayfanın ileri ve geri gezinmelerin büyük bir kısmı için bfcache kullanımını engellediği sayfaları belirlemek açısından yararlı olabilir.
Chrome ekibi, geliştiricilerin bfcache isabet oranlarını iyileştirebilmesi için sayfaların neden bfcache kullanmadığını açığa çıkarmak amacıyla NotRestoredReasons API'sini ekledi. Chrome ekibi, CrUX'a gezinme türleri de ekledi. Bu sayede, bfcache gezinmelerinin sayısını kendiniz ölçmeden de görebilirsiniz.
Performans ölçümü
bfcache, sahada toplanan performans metriklerini, özellikle de sayfa yüklenme sürelerini ölçen metrikleri olumsuz şekilde etkileyebilir.
Bfcache gezinmeleri yeni bir sayfa yüklemesi başlatmak yerine mevcut bir sayfayı geri yüklediğinden, bfcache etkinleştirildiğinde toplanan sayfa yüklemelerinin toplam sayısı azalır. Buradaki kritik nokta, sayfa yüklemelerinin yerine bfcache geri yüklemesi yapılan sayfa yüklemelerinin, veri kümenizdeki en hızlı sayfa yüklemelerinden bazıları olabileceğidir. Bunun nedeni, tanımı gereği, geri ve ileri gezinmelerin yinelenen ziyaretler olması ve tekrarlanan sayfa yüklemelerinin genellikle ilk kez gelen ziyaretçilerden gelen sayfa yüklemelerinden daha hızlı olmasıdır (daha önce de belirtildiği gibi HTTP önbelleğine alma nedeniyle).
Bunun sonucunda, kullanıcı tarafından deneyimlenen performans büyük olasılıkla iyileşmiş olsa da veri kümenizde daha az hızlı sayfa yükleme elde edilir ve bu durum büyük olasılıkla dağıtım daha yavaştır.
Bu sorunu çözmenin birkaç yolu vardır. Bunlardan biri, tüm sayfa yükleme metriklerine ilgili gezinme türleriyle ek açıklama eklemektir: navigate, reload, back_forward veya prerender. Bu sayede, genel dağılım negatif olsa bile bu gezinme türlerindeki performansınızı izlemeye devam edebilirsiniz. Bu yaklaşımı, İlk Bayt Süresi (TTFB) gibi kullanıcı merkezli olmayan sayfa yükleme metrikleri için öneririz.
Önemli Web Verileri gibi kullanıcı merkezli metrikler için kullanıcı deneyimlerini daha doğru şekilde temsil eden bir değer raporlamak daha iyi bir seçenektir.
Core Web Vitals'a Etkisi
Önemli Web Verileri, kullanıcının web sayfasıyla ilgili deneyimini çeşitli boyutlara göre ölçer (yükleme hızı, etkileşim, görsel kararlılık) ve kullanıcılar tam sayfa yüklemelerine göre daha hızlı gezinme olarak bfcache geri yüklemesi deneyimi yaşadığından Core Web Vitals metriklerinin bunu yansıtması önemlidir. Sonuçta kullanıcı, bfcache'in etkin olup olmamasıyla ilgilenmiyor; yalnızca gezinmenin hızlı olmasıyla ilgileniyor.
Chrome Kullanıcı Deneyimi Raporu gibi Önemli Web Verileri metriklerini toplayan ve raporlayan araçlar, bfcache geri yüklemelerini veri kümesinde ayrı sayfa ziyaretleri olarak ele alır. bfcache geri yüklendikten sonra bu metrikleri ölçmek için özel web performansı API'leri olmasa da mevcut web API'lerini kullanarak bunların değerlerini yaklaşık olarak tahmin edebilirsiniz:
- Largest Contentful Paint (LCP) için, karedeki tüm öğeler aynı anda boyanacağı için
pageshowetkinliğinin zaman damgası ile sonraki boyanan karenin zaman damgası arasındaki deltayı kullanın. Bfcache geri yüklemesi durumunda LCP ve FCP aynıdır. - Sonraki Boyamayla Etkileşim (INP) için mevcut Performans Gözlemcinizi kullanmaya devam edin ancak mevcut INP değerini 0 olarak sıfırlayın.
- Cumulative Layout Shift (CLS) için, mevcut Performans Gözlemcinizi kullanmaya devam edin ancak geçerli CLS değerini 0 olarak sıfırlayın.
Bfcache'in her bir metriği nasıl etkilediğiyle ilgili daha fazla bilgi için bağımsız Core Web Vitals metrik kılavuzları sayfalarına bakın. Bu metriklerin bfcache sürümlerinin nasıl uygulanacağına ilişkin belirli bir örnek için bunları web-vitals JS kitaplığına ekleyen PR bölümüne bakın.
Web-vitals JavaScript kitaplığı, bildirdiği metriklerde bfcache geri yüklemelerini destekler.
Ek Kaynaklar
- Firefox'ta Önbelleğe Alma (Firefox'ta bfcache)
- Sayfa Önbelleği (Safari'de bfcache)
- Geri-ileri önbellek: web'de açık davranış (tarayıcılar arasındaki bfcache farklılıkları)
- bfcache tester (farklı API'lerin ve etkinliklerin tarayıcılarda bfcache'i nasıl etkilediğini test edin)
- Performance Game Changer: Tarayıcı Geri/İleri Önbelleği (bfcache'i etkinleştirerek Önemli Web Verileri'nde önemli iyileştirmeler yapıldığını gösteren Smashing Magazine'den örnek olay)