Geri-ileri önbellek

Philip Walton

Barry Pollard

Geri-ileri önbellek (veya bfcache), hızlı ileri ve geri gezinmeyi sağlayan bir tarayıcı optimizasyonudur. Özellikle yavaş ağlara veya cihazlara sahip kullanıcılar için göz atma deneyimini büyük ölçüde iyileştirir.

Web geliştiriciler olarak, kullanıcılarınızın bu avantajlardan yararlanabilmesi için sayfalarınızı bfcache için nasıl optimize edeceğinizi anlamanız çok önemlidir.

Tarayıcı uyumluluğu

96. sürümden itibaren Chrome, Firefox ve Safari dahil olmak üzere tüm büyük tarayıcılarda bfcache bulunur.

geri-ileri önbellek ile ilgili temel bilgiler

Geri/ileri önbelleği (bfcache) ile, kullanıcı sayfadan ayrıldığında sayfayı yok etmek yerine yok etme işlemini erteliyor ve JS yürütmesini duraklatıyoruz. Kullanıcı kısa süre içinde geri dönerse sayfayı tekrar görünür hale getirir ve JS yürütmesini devam ettiririz. Bu sayede kullanıcı, sayfalar arasında neredeyse anında geçiş yapabilir.

Bir web sitesini kaç kez ziyaret ettiniz ve başka bir sayfaya gitmek için bir bağlantıyı tıkladınız, ancak istediğiniz şey olmadığını fark edip geri düğmesini tıkladınız? Bu durumda, bfcache önceki sayfanın ne kadar hızlı yüklendiği konusunda büyük bir fark yaratabilir:

Gezinmelerde hızlanma sağlamak için bfcache'in nasıl çalıştığını bu videodan öğrenebilirsiniz:

Videoda, bfcache'in kullanıldığı örnek, kullanılmadığı örneğe göre oldukça hızlıdır.

bfcache yalnızca gezinmeyi hızlandırmakla kalmaz, kaynakların tekrar indirilmesi gerekmediğinden veri kullanımını da azaltır.

Chrome kullanım verileri, masaüstünde her 10 gezinmeden 1'inin, mobil cihazlarda ise her 5 gezinmeden 1'inin geri veya ileri gezinme 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ükleme süresini ortadan kaldırabilir.

"Önbellek"in işleyiş şekli

bfcache tarafından kullanılan "önbellek", tekrarlanan gezinmeleri hızlandırmada kendi rolünü oynayan HTTP önbelleğinden farklıdır. bfcache, JavaScript yığını da dahil olmak üzere bellekteki tüm sayfanın anlık görüntüsüdür. HTTP önbelleği ise yalnızca daha önce yapılan isteklerin yanıtlarını içerir. Bir sayfanın yüklenmesi için gereken tüm isteklerin HTTP önbelleğinden karşılanması çok nadir olduğundan, bfcache geri yüklemeleri kullanılarak yapılan tekrar ziyaretler, en iyi şekilde optimize edilmiş bfcache dışı gezinmelerden bile her zaman daha hızlıdır.

Bir sayfayı dondurarak daha sonra tekrar etkinleştirmek, devam eden kodu en iyi şekilde koruma açısından biraz karmaşık bir işlemdir. Örneğin, sayfa bfcache'teyken zaman aşımına uğrayan setTimeout() aramalarını nasıl işlersiniz?

Tarayıcılar, bfcache'deki sayfalar için bekleyen zamanlayıcıları veya çözümlenmemiş sözleri (JavaScript görev kuyruklarındaki bekleyen görevlerin neredeyse tamamı dahil) duraklatır ve sayfa bfcache'den geri yüklenirse görevleri işlemeye devam eder.

Zaman aşımları ve sözler gibi bazı durumlarda bu oldukça düşük risklidir ancak diğer durumlarda kafa karıştırıcı veya beklenmedik davranışlara yol açabilir. Örneğin, tarayıcı bir IndexedDB işlemi kapsamında gerekli olan bir görevi duraklatırsa aynı IndexedDB veritabanlarına aynı anda birden fazla sekme tarafından erişilebileceğinden bu durum, aynı kaynakta açık olan diğer sekmeleri etkileyebilir. Sonuç olarak, tarayıcılar genellikle IndexedDB işlemi ortasında veya diğer sayfaları etkileyebilecek API'ler kullanılırken sayfaları önbelleğe almaya çalışmaz.

Ç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ı makaleyi inceleyin.

Geri-ileri önbellek ve iframe'ler

Bir sayfada yerleştirilmiş iFrame'ler varsa bu iFrame'ler bfcache için ayrı ayrı uygun değildir. Örneğin, bir iFrame içinde başka bir URL'ye giderseniz önceki içerik bfcache'e girmez ve geri giderseniz tarayıcı ana çerçevede değil, iFrame içinde "geri" gider ancak iFrame içindeki geri gitme işlemi bfcache'i kullanmaz.

Ancak ana çerçeve bfcache'den geri yüklendiğinde, yerleştirilmiş iFrame'ler sayfa bfcache'e girerken olduğu gibi geri yüklenir.

Yerleştirilmiş bir iFrame, bunu engelleyen API'ler kullanıyorsa ana çerçeve de bfcache'in kullanılmasını engelleyebilir. Bunu önlemek için ana çerçevede ayarlanan izin politikası veya sandbox özelliklerinin kullanımı tercih edilebilir.

Geri-ileri önbellek ve tek sayfalık uygulamalar (SPA)

bfcache, tarayıcı tarafından yönetilen gezinmelerle çalıştığı için tek sayfalık uygulamalardaki (SPA) "yumuşak gezinmeler" için çalışmaz. Ancak bfcache, bir SPA'ya geri dönerken bu uygulamayı baştan tekrar tamamen yeniden başlatmak yerine yine de yardımcı olabilir.

Geri-ileri önbelleği gözlemlemek için kullanılan API'ler

Geri/ileri önbelleği, tarayıcıların otomatik olarak yaptığı bir optimizasyon olsa da geliştiricilerin bu durumun ne zaman gerçekleştiğini bilmesi önemlidir. Böylece sayfalarını buna göre optimize edebilir ve metrikleri veya performans ölçümlerini buna göre ayarlayabilirler.

bfcache'i gözlemlemek için kullanılan temel etkinlikler, çoğu tarayıcı tarafından desteklenen sayfa geçişi etkinlikleri pageshow ve pagehide'dir.

Daha yeni Page Lifecycle etkinlikleri olan freeze ve resume, sayfalar bfcache'e girerken veya bfcache'ten çıkarken ve CPU kullanımını en aza indirmek için arka plan sekmesi dondurulduğunda olduğu gibi bazı başka durumlarda da gönderilir. Bu etkinlikler yalnızca Chromium tabanlı tarayıcılarda desteklenir.

Bir sayfanın bfcache'ten ne zaman geri yüklendiğini gözlemleyin

pageshow etkinliği, sayfa ilk kez yüklenirken load etkinliğinden hemen sonra ve sayfa bfcache'ten her geri yüklendiğinde tetiklenir. pageshow etkinliğinin persisted özelliği vardır. Bu özellik, 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'ten geri yüklendiğinde (resume etkinliğinden hemen önce) ve kullanıcı dondurulmuş bir arka plan sekmesini yeniden ziyaret ettiğinde resume etkinliği tetiklenir.pageshow Dondurulan bir sayfanın durumunu (bfcache'deki sayfalar dahil) güncellemek istiyorsanız 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, analizleri ve performans ölçümünü nasıl etkiler? başlıklı makaleyi inceleyin.

Bir sayfanın bfcache'e ne zaman girdiğini gözlemleme

pagehide etkinliği, bir sayfa kaldırıldığında veya tarayıcı sayfayı bfcache'e yerleştirmeye çalıştığında tetiklenir.

pagehide etkinliğinde persisted özelliği de bulunur. Bu değer false ise sayfanın bfcache'e girmek üzere olmadığından emin olabilirsiniz. Ancak persisted olması, true bir sayfanın önbelleğe alınacağını garanti etmez. Bu, tarayıcının sayfayı önbelleğe almak istediği anlamına gelir ancak önbelleğe almayı imkansız kılan başka faktörler 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ı amaçladığı anlamına gelir. Ancak daha sonra açıklanan çeşitli nedenlerden dolayı yine de kartı silmesi gerekebilir.

Sayfalarınızı bfcache için optimize etme

Tüm sayfalar bfcache'te saklanmaz ve bir sayfa orada saklansa bile süresiz olarak kalmaz. Geliştiricilerin, önbellek isabet oranlarını en üst düzeye çıkarmak için sayfaları bfcache'e uygun (veya uygun olmayan) hale getiren faktörleri anlaması çok önemlidir.

Aşağıdaki bölümlerde, tarayıcının sayfalarınızı önbelleğe alabilme olasılığını en üst düzeye çıkaracak en iyi uygulamalar özetlenmektedir.

unload etkinliğini asla kullanmayın

Tüm tarayıcılarda bfcache için optimizasyon yapmanın en önemli yolu unload etkinliğini hiçbir zaman kullanmamaktır. Ever!

unload etkinliği, bfcache'ten önce geldiği ve internetteki birçok sayfa, unload etkinliği tetiklendikten sonra sayfanın varlığını sürdürmeyeceği (makul) varsayımı altında çalıştığı için tarayıcılar açısından sorunludur. Bu durum, söz konusu sayfaların birçoğu ayrıca kullanıcının ayrıldığı her durumda unload etkinliğinin tetikleneceği varsayımıyla oluşturulduğu için sorun teşkil eder. Bu varsayım artık geçerli değildir (ve uzun süredir geçerli değildir).

Bu nedenle tarayıcılar bir ikilemle karşı karşıya kalır. Kullanıcı deneyimini iyileştirebilecek ancak sayfanın bozulma riskini de taşıyan bir seçenekle karşı karşıyadırlar.

Masaüstünde Chrome ve Firefox, unload dinleyicisi ekleyen sayfaları bfcache için uygun olmamaya karar verdi. Bu, daha az riskli olsa da birçok sayfayı da diskalifiye ediyor. Safari, unload etkinlik dinleyicisi olan bazı sayfaları önbelleğe almaya çalışır ancak olası bozulmaları azaltmak için kullanıcı sayfadan ayrılırken unload etkinliğini çalıştırmaz. Bu da etkinliğin güvenilirliğini düşürür.

Mobil cihazlarda Chrome ve Safari, unload etkinliği mobil cihazlarda her zaman son derece güvenilmez olduğundan bozulma riski daha düşük olduğu için unload etkinlik dinleyicisi olan sayfaları önbelleğe almaya çalışır. Firefox, iOS hariç unload kullanan sayfaları geri-ileri önbelleğe alma için uygunsuz olarak değerlendirir. iOS'te tüm tarayıcıların WebKit oluşturma motorunu kullanması gerektiğinden bu tarayıcı Safari gibi davranır.

unload etkinliğini kullanmak yerine pagehide etkinliğini kullanın. pagehide etkinliği, unload etkinliğinin tetiklendiği tüm durumlarda tetiklenir ve bir sayfa bfcache'e yerleştirildiğinde de tetiklenir.

Hatta Lighthouse'ta, sayfalarındaki JavaScript'lerden (üçüncü taraf kitaplıklarındaki JavaScript'ler dahil) herhangi biri unload etkinlik dinleyicisi eklerse geliştiricileri uyaran bir no-unload-listeners denetimi bulunur.

Güvenilir olmaması ve bfcache'in performansını etkilemesi nedeniyle Chrome, unload etkinliğinin desteğini sonlandırmayı planlıyor.

Bir sayfada yükleme kaldırma işleyicilerinin kullanılmasını önlemek için izin politikasını kullanma

unload etkinlik işleyicilerini kullanmayan siteler, izin politikası kullanarak bunların eklenmediğinden emin olabilir.

Permissions-Policy: unload=()

Bu, üçüncü tarafların veya uzantıların, unload işleyicileri ekleyerek siteyi yavaşlatmasını ve bfcache için uygun hale getirmesini de engeller.

Yalnızca koşullu olarak beforeunload dinleyici ekleyin

beforeunload etkinliği, sayfalarınızın modern tarayıcıların bfcache'inde bfcache için uygun olmamasını sağlamaz. Ancak daha önce bu durum geçerliydi ve etkinlik hâlâ güvenilir değildir. Bu nedenle, kesinlikle gerekli olmadığı sürece kullanmaktan kaçının.

Ancak unload etkinliğinden farklı olarak beforeunload için meşru kullanım alanları vardır. Örneğin, kullanıcıyı sayfadan ayrılırsa kaybedeceği kaydedilmemiş değişiklikler konusunda uyarmak istediğinizde. Bu durumda, yalnızca kullanıcı kaydedilmemiş değişikliklere sahip olduğunda beforeunload dinleyici eklemeniz ve kaydedilmemiş değişiklikler kaydedildikten sonra bunları hemen kaldırmanız önerilir.

window.addEventListener('beforeunload', (event) => {
  if (pageHasUnsavedChanges()) {
    event.preventDefault();
    return event.returnValue = 'Are you sure you want to exit?';
  }
});

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);
});

Cache-Control: no-store kullanımını en aza indirin.

Cache-Control: no-store, web sunucularının yanıtlarda ayarlayabileceği bir HTTP başlığıdır. Bu başlık, tarayıcıya yanıtı herhangi bir HTTP önbelleğinde depolamamasını bildirir. Giriş yapılan sayfalar gibi hassas kullanıcı bilgileri içeren kaynaklar için kullanılır.

Geri-ileri önbellek bir HTTP önbelleği olmasa da geçmişte Cache-Control: no-store, sayfa kaynağının kendisinde (herhangi bir alt kaynak yerine) ayarlandığında tarayıcılar sayfayı geri-ileri önbellekte depolamamayı tercih etmiştir. Bu nedenle, Cache-Control: no-store kullanan sayfalar geri-ileri önbelleğe alınmaya uygun olmayabilir. Chrome'un bu davranışını gizliliği koruyacak şekilde değiştirmek için çalışmalar devam etmektedir.

Cache-Control: no-store, bir sayfanın bfcache için uygunluğunu kısıtladığından yalnızca hassas bilgiler içeren ve hiçbir türde ö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ı talimatını verir 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 yapılmaz.

Bununla birlikte, bfcache geri yüklemeleri anında gerçekleştiği ve sayfalar bfcache'de çok uzun süre kalmadığı için içeriğin güncel olmaması pek olası değildir. Bu nedenle, bu durum yine de daha iyi bir kullanıcı deneyimi sunar. Ancak içeriğiniz her dakika değişiyorsa bir sonraki bölümde açıklandığı gibi pageshow etkinliğini kullanarak güncellemeleri getirebilirsiniz.

bfcache geri yüklemesinden sonra eski veya hassas verileri güncelleme

Siteniz kullanıcı durumunu (özellikle hassas kullanıcı bilgilerini) saklıyorsa sayfa bfcache'ten geri yüklendikten sonra bu verilerin güncellenmesi veya temizlenmesi gerekir.

Örneğin, bir kullanıcı ödeme sayfasına gidip alışveriş sepetini güncellerse bfcache'ten eski bir sayfa geri yüklenirse geri gitme işlemi eski bilgileri açığa çıkarabilir.

Daha kritik bir örnek ise bir kullanıcının herkese açık bir bilgisayarda bir siteden çıkış yapması ve sonraki kullanıcının geri düğmesini tıklamasıdır. Bu durum, kullanıcının oturumu kapattığında temizlendiğini düşündüğü özel verilerin açığa çıkmasına neden olabilir.

Bu tür durumları önlemek için event.persisted true ise pageshow etkinliğinden sonra sayfayı her zaman güncellemeniz iyi olur:

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    // Do any checks and updates to the page
  }
});

İçeriği yerinde güncellemek ideal olsa da bazı değişiklikler için tam yeniden yüklemeyi zorlamak isteyebilirsiniz. Aşağıdaki kod, pageshow etkinliğinde siteye özel bir çerezin varlığını kontrol eder ve çerez bulunamazsa yeniden yükler:

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ükleme, geçmişi koruma (ileri gezinmeye izin verme) avantajına sahiptir ancak bazı durumlarda yönlendirme daha uygun olabilir.

Reklamlar ve bfcache geri yükleme

Her geri/ileri gezinmede yeni bir reklam grubu yayınlamak için bfcache kullanımından kaçınmak cazip gelebilir. Ancak bu davranışın performans üzerinde etkisi olmasının yanı sıra daha iyi reklam etkileşimi sağlayıp sağlamadığı da tartışmalıdır. Kullanıcılar, tıklamak için geri dönmeyi planladıkları bir reklamı fark etmiş olabilir ancak bfcache'den geri yüklemek yerine yeniden yükleyerek reklama tıklayamayabilirler. Varsayımda bulunmadan önce bu senaryoyu (tercihen A/B testiyle) test etmek önemlidir.

bfcache geri yüklemede reklamları yenilemek isteyen siteler için, pageshow etkinliğinde yalnızca reklamların yenilenmesi, event.persisted true olduğunda sayfa performansını etkilemeden bu işlemin gerçekleşmesine olanak tanır. Reklam sağlayıcınıza danışın ancak Google Yayıncı Etiketi ile bunu nasıl yapacağınıza dair bir örneği burada bulabilirsiniz.

window.opener referanslarından kaçının

Daha eski tarayıcılarda, rel="noopener" belirtilmeden target=_blank içeren bir bağlantıdan window.open() kullanılarak bir sayfa açılırsa açılan sayfada, açılan sayfanın pencere nesnesine referans verilir.

Boş olmayan bir window.opener referansı olan bir sayfa, güvenlik riski oluşturmasının yanı sıra, bfcache'e güvenli bir şekilde yerleştirilemez. Aksi takdirde, sayfaya erişmeye çalışan tüm sayfalar bozulabilir.

Bu nedenle, window.opener referansları oluşturmaktan kaçınmanız önerilir. Mümkün olduğunda rel="noopener" kullanarak bunu yapabilirsiniz (Bu, artık tüm modern tarayıcılarda varsayılan olarak ayarlanmıştır). Siteniz bir pencerenin açılmasını ve window.postMessage() üzerinden kontrol edilmesini veya doğrudan pencere nesnesine referans verilmesini gerektiriyorsa açılan pencere de açıcı da bfcache için uygun olmaz.

Kullanıcı sayfadan ayrılmadan önce açık bağlantıları kapatın

Daha önce belirtildiği gibi, bir sayfa bfcache'te tutulduğunda planlanmış tüm JavaScript görevleri duraklatılır ve sayfa önbellekten çıkarıldığında devam ettirilir.

Bu planlanmış JavaScript görevleri yalnızca DOM API'lerine veya yalnızca geçerli sayfayla sınırlı diğer API'lere erişiyorsa sayfa kullanıcıya görünür değilken bu görevlerin duraklatılması herhangi bir soruna neden olmaz.

Ancak bu görevler, aynı kaynakta bulunan diğer sayfalardan da erişilebilen API'lere (ör. IndexedDB, Web Locks, WebSockets) bağlıysa bu durum sorunlu olabilir. Çünkü bu görevleri duraklatmak, diğer sekmelerdeki kodun çalışmasını engelleyebilir.

Sonuç olarak, bazı tarayıcılar aşağıdaki senaryolarda bir sayfayı bfcache'e yerleştirmeye çalışmaz:

• Açık bir IndexedDB bağlantısı olan sayfalar
• Devam eden fetch() veya XMLHttpRequest içeren sayfalar
• Açık bir WebSocket veya WebRTC bağlantısı olan sayfalar

Sayfanız bu API'lerden herhangi birini kullanıyorsa pagehide veya freeze etkinliği sırasında bağlantıları kapatmanızı ve gözlemcileri kaldırmanızı ya da bağlantılarını kesmenizi önemle tavsiye ederiz. Bu sayede tarayıcı, diğer açık sekmeleri etkileme riski olmadan sayfayı güvenli bir şekilde önbelleğe alabilir.

Ardından, sayfa bfcache'ten geri yüklenirse pageshow veya resume etkinliği sırasında bu API'leri yeniden açabilir ya da bunlara yeniden bağlanabilirsiniz.

Aşağıdaki örnekte, IndexedDB kullanan sayfaların pagehide etkinlik işleyicisinde açık bir bağlantı kapatılarak bfcache için uygun olmasının nasıl sağlanacağı 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 olduğundan emin olmak için test etme

Chrome Geliştirici Araçları, sayfalarınızın bfcache için optimize edildiğinden emin olmak üzere test etmenize ve uygun olmalarını engelleyebilecek sorunları belirlemenize yardımcı olabilir.

Bir sayfayı test etmek için:

1. Chrome'da sayfaya gidin.
2. Geliştirici Araçları'nda Uygulama -> Geri/İleri Önbelleği'ne gidin.
3. Testi Çalıştır düğmesini tıklayın. Ardından, sayfanın bfcache'ten geri yüklenip yüklenemeyeceğini belirlemek için Geliştirici Araçları, sayfadan uzaklaşmaya ve geri dönmeye çalışır.

Test başarılı olursa panelde "Geri-ileri önbellekten geri yüklendi" mesajı gösterilir.

İşlem başarısız olursa panelde bunun nedeni belirtilir. Nedeni geliştirici olarak ele alabileceğiniz bir durumsa panel, bunu İşleme Alınabilir olarak işaretler.

Bu örnekte, unload etkinlik işleyicinin kullanılması sayfayı geri-ileri önbelleğe alma için uygunsuz hale getirir. unload yerine pagehide kullanmaya geçerek bu sorunu düzeltebilirsiniz:

window.addEventListener('pagehide', ...);

window.addEventListener('unload', ...);

Lighthouse 10.0'da da benzer bir testi gerçekleştiren bfcache denetimi eklendi. Daha fazla bilgi için bfcache denetiminin dokümanlarına bakın.

Geri/ileri önbelleği, analizleri ve performans ölçümünü nasıl etkiler?

Sitenize yapılan ziyaretleri ölçmek için bir analiz aracı kullanıyorsanız Chrome, bfcache'i daha fazla kullanıcı için etkinleştirdikçe bildirilen toplam sayfa görüntüleme sayısında düşüş olduğunu fark edebilirsiniz.

Hatta birçok popüler analiz kitaplığı bfcache geri yüklemelerini yeni sayfa görüntülemeleri olarak ölçmediğinden, bfcache'i uygulayan diğer tarayıcılardan gelen sayfa görüntülemelerini muhtemelen zaten eksik raporluyorsunuz.

Sayfa görüntüleme sayınıza bfcache geri yüklemelerini dahil etmek için pageshow etkinliği için dinleyiciler 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 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');
  }
});

Geri/ileri önbelleği isabet oranınızı ölçme

Geri-ileri önbelleğin kullanılıp kullanılmadığını ölçerek geri-ileri önbelleği kullanmayan sayfaları belirleyebilirsiniz. Bu işlem, sayfa yüklemeleri için gezinme türü ölçülerek 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 navigasyonları ve back_forward_cache navigasyonlarının sayımlarını kullanarak bfcache isabet oranınızı hesaplayın.

Geri/İleri gezinme işleminin bfcache'i kullanmayacağı, site sahiplerinin kontrolü dışında kalan çeşitli senaryolar olduğunu anlamak önemlidir. Örneğin:

• Kullanıcı tarayıcıdan çıkıp tekrar başlattığında
• Kullanıcı bir sekmeyi kopyaladığında
• Kullanıcı bir sekmeyi kapatıp yeniden açtığında

Bu durumlardan bazılarında, orijinal gezinme türü bazı tarayıcılar tarafından korunabilir ve bu nedenle, Geri/İleri gezinmeleri olmamasına rağmen back_forward türü gösterilebilir.

Bu hariç tutmalar olmasa bile, belleği korumak için bfcache bir süre sonra atılır.

Bu nedenle, web sitesi sahipleri tüm back_forward gezinmelerinde% 100 bfcache isabet oranı beklememelidir. Ancak bu oranın ölçülmesi, geri ve ileri gezinmelerin büyük bir bölümünde sayfanın kendisinin bfcache kullanımını engellediği sayfaları belirlemek için yararlı olabilir.

Chrome ekibi, sayfaların neden bfcache kullanmadığını ortaya çıkarmak için NotRestoredReasons API'yi ekledi. Böylece geliştiriciler bfcache isabet oranlarını artırabilir. Chrome ekibi ayrıca CrUX'a gezinme türleri ekledi. Bu sayede, kendiniz ölçmeseniz bile bfcache gezinmelerinin sayısını görebilirsiniz.

Performans ölçümü

bfcache, alanda toplanan performans metriklerini de olumsuz etkileyebilir. Özellikle sayfa yükleme sürelerini ölçen metrikler bu durumdan etkilenir.

bfcache gezinmeleri yeni bir sayfa yüklemesi başlatmak yerine mevcut bir sayfayı geri yüklediğinden, bfcache etkinleştirildiğinde toplanan toplam sayfa yükleme sayısı azalır. Ancak önemli olan, bfcache geri yüklemeleriyle değiştirilen sayfa yüklemelerinin, veri kümenizdeki en hızlı sayfa yüklemelerinden bazıları olmasıdır. Bunun nedeni, geri ve ileri gezinmelerin tanım gereği tekrar ziyaretler olması ve tekrar sayfa yüklemelerinin genellikle ilk kez gelen ziyaretçilerin sayfa yüklemelerinden daha hızlı olmasıdır (daha önce belirtildiği gibi HTTP önbelleğe alma nedeniyle).

Sonuç olarak, veri kümenizde daha az sayıda hızlı sayfa yüklemesi olur. Bu durum, kullanıcının deneyimlediği performans muhtemelen iyileşmiş olsa da dağılımı yavaşlatır.

Bu sorunla başa çıkmanın birkaç yolu vardır. Birinci yöntem, tüm sayfa yükleme metriklerine ilgili gezinme türünü (navigate, reload, back_forward veya prerender) eklemektir. Bu sayede, genel dağılım olumsuz olsa bile bu gezinme türlerindeki performansınızı izlemeye devam edebilirsiniz. Bu yaklaşımı, Time to First Byte (TTFB) gibi kullanıcı odaklı olmayan sayfa yükleme metrikleri için öneririz.

Core Web Vitals gibi kullanıcı odaklı metrikler için daha iyi bir seçenek, kullanıcının deneyimini daha doğru şekilde temsil eden bir değer bildirmektir.

Core Web Vitals üzerindeki etkisi

Core Web Vitals, kullanıcının bir web sayfasındaki deneyimini çeşitli boyutlarda (yükleme hızı, etkileşim, görsel kararlılık) ölçer. Kullanıcılar, bfcache geri yüklemelerini tam sayfa yüklemelerinden daha hızlı gezinmeler olarak deneyimlediğinden Core Web Vitals metriklerinin bunu yansıtması önemlidir. Sonuçta kullanıcılar, bfcache'in etkinleştirilip etkinleştirilmediğini önemsemez. Onlar için önemli olan, gezinmenin hızlı olmasıdır.

Chrome Kullanıcı Deneyimi Raporu gibi Core Web Vitals metriklerini toplayıp raporlayan araçlar, bfcache geri yüklemelerini veri kümelerinde ayrı sayfa ziyaretleri olarak ele alır. bfcache geri yüklemelerinden sonra bu metrikleri ölçmek için özel web performansı API'leri olmasa da mevcut web API'lerini kullanarak değerlerini yaklaşık olarak belirleyebilirsiniz:

• Largest Contentful Paint (LCP) için, karedeki tüm öğeler aynı anda boyanacağından pageshow etkinliğinin zaman damgası ile bir sonraki boyanan karenin zaman damgası arasındaki farkı kullanın. bfcache geri yükleme durumunda LCP ve FCP aynıdır.
• Interaction to Next Paint (INP) için mevcut Performance Observer'ınızı kullanmaya devam edin ancak mevcut INP değerini 0 olarak sıfırlayın.
• Cumulative Layout Shift (CLS) için mevcut Performance Observer'ınızı kullanmaya devam edin ancak mevcut CLS değerini 0'a sıfırlayın.

bfcache'in her metriği nasıl etkilediği hakkında daha fazla bilgi için Core Web Vitals metrik kılavuz sayfalarına bakın. Bu metriklerin bfcache sürümlerinin nasıl uygulanacağına dair belirli bir örnek için web-vitals JS kitaplığına eklenmelerini sağlayan PR'ye bakın.

web-vitals JavaScript kitaplığı, raporladığı metriklerde bfcache geri yüklemelerini destekler.

Ek Kaynaklar

• Firefox'ta önbelleğe alma (Firefox'ta bfcache)
• Sayfa önbelleği (Safari'de bfcache)
• Geri/ileri önbelleği: web'e açık davranış (Tarayıcılar arasındaki bfcache farklılıkları)
• bfcache tester (farklı API'lerin ve etkinliklerin tarayıcılarda geri-ileri önbelleği nasıl etkilediğini test edin)
• Performansta Çığır Açan: Tarayıcı Geri/İleri Önbelleği (Smashing Magazine'den, bfcache'i etkinleştirerek Core Web Vitals'da önemli iyileşmeler sağlandığını gösteren bir örnek olay çalışması)