Geri-ileri önbellek

Philip Walton

Barry Pollard

Geri-ileri önbellek (veya bfcache), anında arama yapılmasına olanak tanıyan bir tarayıcı kullanabilirsiniz. Daha iyi hale getirmek için Özellikle yavaş ağları veya cihazlara sahip kullanıcılar için.

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

Tarayıcı uyumluluğu

bfcache hem Firefox hem de Safari'de uzun yıllardır masaüstü ve mobil cihazlarda desteklenmektedir.

Chrome, sürüm 86'dan itibaren kullanıcıların küçük bir yüzdesi için Android'de siteler arası gezinmeler için bfcache'yi etkinleştirdi. Sonraki sürümlerde ek destek kademeli olarak kullanıma sunulacaktır. bfcache, sürüm 96'dan bu yana masaüstü ve mobil cihazlardaki tüm Chrome kullanıcıları için etkindir.

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ı bunu hızlı bir şekilde geri yükleyebilir.

Kaç kez bir web sitesini ziyaret edip başka bir sayfaya gitmek için bir bağlantıyı tıkladınız? Ancak, bunun istediğiniz olmadığını fark edip geri düğmesini tıkladınız? O anda, bfcache önceki sayfanın yüklenme hızında büyük bir fark yaratabilir:

Bfcache'nin gezinmeye sağlayabileceği hızı anlamak için şu uygulama videosunu izleyin:

Videoda, bfcache ile alınan örnek, onsuz örneğe kıyasla oldukça daha hızlı.

bfcache yalnızca gezinmeyi hızlandırmakla kalmaz, aynı zamanda kaynakların tekrar indirilmesine gerek olmadığı için veri kullanımını da azaltır.

Chrome kullanım verileri, masaüstünde 10 gezinmeden 1'inin ve mobil cihazlarda 5 gezinmeden 1'inin geri veya ileri olduğunu göstermektedir. 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

"Önbellek" bfcache tarafından kullanılan HTTP önbelleği, tekrarlanan gezinmeleri hızlandırmada kendi rolü olan 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 önceden yapılan isteklere ait yanıtları içerir. Bir sayfayı HTTP önbelleğinden yüklemek için gereken tüm isteklerin çok nadir olması nedeniyle, bfcache geri yüklemelerinin kullanıldığı tekrarlanan ziyaretler, en iyi optimize edilmiş bfcache olmayan gezinmelerden bile her zaman daha hızlıdır.

Bununla birlikte, bir sayfanın bellekteki anlık görüntüsünü oluşturmak, devam etmekte olan kodu en iyi şekilde korumak açısından biraz karmaşıklık gerektirir. Örneğin, sayfa önbellekteyken zaman aşımına ulaşıldığında setTimeout() çağrılarını nasıl ele alırsınız?

Bunun yanıtı, JavaScript görev sıralarındaki hemen hemen tüm beklemedeki görevler de dahil olmak üzere tarayıcıların bfcache'deki sayfalar için beklemedeki zamanlayıcıları veya çözümlenmemiş vaatleri duraklatmaları ve sayfa bfcache'den geri yüklenirse görevleri işlemeye devam etmeleridir.

Zaman aşımları ve taahhütler gibi bazı durumlarda bu, oldukça düşük bir risktir ancak diğer durumlarda kafa karıştırıcı veya beklenmedik davranışlara yol açabilir. Örneğin, tarayıcı bir IndexedDB'nin parçası olarak gerekli bir görevi duraklatırsa işlemi yapıldığında, aynı IndexedDB veritabanlarına aynı anda birden çok sekme tarafından erişilebileceği için aynı kaynaktaki diğer açık sekmeleri etkileyebilir. Sonuç olarak, tarayıcılar genellikle bir IndexedDB işleminin ortasında veya başka sayfaları etkileyebilecek API'ler kullanırken sayfaları önbelleğe almayı denemez.

Çeşitli API kullanımının bir sayfanın bfcache uygunluğunu nasıl etkilediğiyle ilgili daha fazla ayrıntı için Sayfalarınızı bfcache için optimize etme başlıklı makaleyi inceleyin.

Bfcache ve iframe'ler

Bir sayfada yerleşik iframe'ler varsa iframe'lerin kendileri bfcache için uygun olmaz. Örneğin, bir iframe içindeki başka bir sayfaya gider ve sonra geri dönerseniz, tarayıcı "geri" döner. içinde yer alır; ancak iframe içindeki geri gezinme bfcache'yi kullanmaz.

Yerleştirilmiş bir iframe bunu engelleyen API'ler kullanıyorsa ana çerçevenin bfcache'yi 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, "yumuşak gezinmeler" için çalışmaz. tek sayfalık uygulamada (SPA) yer alır. Bununla birlikte, bfcache bir SPA'ya geri dönerken uygulamayı en baştan tamamen yeniden başlatmak yerine yine de yardımcı olabilir.

Bfcache'yi gözlemleme API'leri

bfcache, tarayıcıların otomatik olarak yaptığı bir optimizasyon olsa da geliştiricilerin bu işlemin 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'yi gözlemlemek için kullanılan birincil etkinlikler, çoğu tarayıcı tarafından desteklenen sayfa geçiş etkinlikleri pageshow ve pagehide'tir.

Daha yeni Sayfa Yaşam Döngüsü etkinlikleri (freeze ve resume), sayfalar bfcache'e girdiğinde ve bu önbellekten çıktığında ve örneğin, CPU kullanımını en aza indirmek için bir arka plan sekmesinin donması gibi bazı durumlarda da gönderilir. Bu etkinlikler yalnızca Chromium tabanlı tarayıcılarda desteklenir.

Bir sayfanın bfcache'den geri yüklendiğini gözlemleme

pageshow etkinliği, sayfa ilk kez yüklenirken ve bfcache'den her geri yüklendiğinde load etkinliğinden hemen sonra tetiklenir. pageshow etkinliğinin bir persisted özelliği vardır. Sayfa bfcache'den geri yüklendiyse true, geri yüklenmediyse 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 resume etkinliği, sayfalar bfcache'den geri yüklendiğinde (pageshow etkinliğinden hemen önce) ve kullanıcı, dondurulmuş bir arka plan sekmesini yeniden ziyaret ettiğinde tetiklenir. Bir sayfanın dondurulduktan sonra durumunu güncellemek isterseniz (bfcache'deki sayfalar dahil) 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ü en iyi uygulamaları hakkında ayrıntılar için bfcache analizleri ve performans ölçümünü nasıl etkiler? başlıklı makaleyi inceleyin.

Bir sayfanın bfcache'ye girdiğini gözlemle

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

pagehide etkinliğinin bir persisted özelliği de var. false ise bir sayfanın Bfcache'ye girmek üzere olmadığından emin olabilirsiniz. Ancak persisted öğesinin true olması, sayfanın önbelleğe alınacağını garanti etmez. Bu, tarayıcının sayfayı önbelleğe almayı istediği anlamına gelir, ancak önbelleğe almayı 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 almak istediği anlamına gelir. Bununla birlikte, daha sonra açıklanacak çeşitli nedenlerden dolayı öğenin silinmesi gerekebilir.

Sayfalarınızı Bfcache için optimize edin

Tüm sayfalar Bfcache'de depolanmaz ve bir sayfa orada saklansa 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) kıldığını anlamaları çok önemlidir.

Aşağıdaki bölümlerde, tarayıcının sayfalarınızı önbelleğe almasını mümkün olduğunca kolaylaştırmak için 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. Hiç!

unload etkinliği, bfcache'den önce olduğu ve internetteki birçok sayfanın, unload etkinliği tetiklendikten sonra bir sayfanın var olmaya devam etmeyeceği (makul) varsayılarak çalıştığı için tarayıcılar açısından sorunludur. Bu durum, söz konusu sayfaların birçoğu de kullanıcı sayfadan ayrılırken unload etkinliğinin tetikleneceği varsayılarak oluşturulduğu için bu durum bir zorluk teşkil etmektedir. Bu durum, artık geçerli değildir (ve uzun zamandır da uygulanmamıştır).

Tarayıcılar bir ikilemle karşı karşıya kalırken kullanıcı deneyimini iyileştirebilecek bir şeyden birini seçmek zorunda kalırlar. Ancak aynı zamanda sayfanın bozulmasına da yol açabilirler.

Chrome ve Firefox, masaüstünde bir unload işleyici eklemeleri durumunda sayfaların bfcache için uygun olmamasını seçti. Bu daha az riskli, ancak aynı zamanda birçok sayfanın diskalifiye olmasına neden oluyor. Safari, bazı sayfaları bir unload etkinlik işleyicisi ile önbelleğe almaya çalışır ancak olası kesintileri azaltmak için kullanıcı sayfadan ayrılırken unload etkinliğini çalıştırmaz. Bu nedenle etkinlik çok güvenilir değildir.

unload etkinliğinin mobil cihazlarda her zaman son derece güvenilir olmaması nedeniyle kesinti riski daha düşük olduğundan Chrome ve Safari, mobil cihazlarda sayfaları bir unload etkinlik işleyici ile önbelleğe almayı dener. Firefox, tüm tarayıcıların WebKit oluşturma motorunu kullanmasını gerektiren ve Safari gibi davranan iOS haricinde, unload kullanan sayfaları bfcache için uygun değil olarak değerlendirir.

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

Hatta Lighthouse, sayfalarındaki herhangi bir JavaScript (üçüncü taraf kitaplıklardakiler de dahil) bir unload etkinlik işleyici eklerse geliştiricileri uyaran bir no-unload-listeners denetimine sahiptir.

Güvenilirliği ve bfcache için performans üzerindeki etkisi nedeniyle Chrome, unload etkinliğini kullanımdan kaldırmak istiyor.

Bir sayfada kaldırma işleyicilerin kullanılmasını engellemek için İzin Politikası kullanma

unload etkinlik işleyicileri kullanmayan siteler, Chrome 115'ten bir İzin Politikası kullanarak bunların eklenmemesini sağlayabilir.

Permission-Policy: unload()

Bu, üçüncü tarafların veya uzantıların kaldırma işleyiciler ekleyerek ve siteyi bfcache için uygun olmayan hale getirerek siteyi yavaşlatmasını da önler.

Yalnızca beforeunload dinleyiciyi koşullu olarak ekle

beforeunload etkinliği, modern tarayıcılardaki bfcache'de sayfalarınızı bfcache için uygun hale getirmez. Ancak daha önce bu işlem güvenilir değildir. Bu nedenle, kesinlikle gerekli olmadığı sürece bu etkinliği kullanmaktan kaçının.

Bununla birlikte, unload etkinliğinin aksine beforeunload. Örneğin, kullanıcıyı yanlış yönlendirilmiş bir e-posta adresinin kaydedilmemiş değişiklikleri sayfadan ayrılırlarsa kaybederler. Bu örnekte beforeunload işleyicileri yalnızca kullanıcının kaydetmeme işlemini tamamladığında eklemenizi önerdi ve kaydedilmemiş değişiklikler kaydedildikten hemen sonra bunları kaldırabilirsiniz.

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, tarayıcıya yanıtı herhangi bir HTTP önbelleğinde depolamaması talimatını veren yanıtlarda ayarlanabilen bir HTTP üst bilgisidir. Giriş yapılarak ulaşılan sayfalar gibi hassas kullanıcı bilgileri içeren kaynaklar için kullanılır.

bfcache geçmişte bir HTTP önbelleği olmamasına rağmen Cache-Control: no-store, herhangi bir alt kaynak yerine sayfa kaynağının kendisinde ayarlandığında tarayıcılar sayfayı bfcache'de depolamamayı tercih etmiştir. Chrome'un bu davranışını gizliliği koruyacak şekilde değiştirmek için çalışmalar devam etmektedir, 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 herhangi bir türde önbelleğe almanın uygun olmadığı hassas bilgiler içeren sayfalarda ayarlanmalıdır.

Her zaman güncel içerik sunması gereken ve hassas bilgiler barındırmayan 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 bir sayfanın bfcache uygunluğunu etkilemez.

Bir sayfa bfcache'den geri yüklendiğinde HTTP önbelleğinden değil, bellekten geri yüklenir. 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, bu büyük olasılıkla daha iyi bir kullanıcı deneyimidir. Bununla birlikte, bfcache geri yükleme işlemleri anında gerçekleştiği ve sayfalar uzun süre önbellekte kalmadığı için içeriğin güncel olmaması pek olası değildir. Ancak içeriğiniz dakika dakika değişiyorsa sonraki bölümde özetlendiği gibi pageshow etkinliğini kullanarak güncellemeleri alabilirsiniz.

Bfcache geri yükleme işleminden sonra eski veya hassas verileri güncelle

Siteniz kullanıcı durumunu (özellikle de hassas kullanıcı bilgilerini) saklıyorsa bfcache'den bir sayfa 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 geri gezinme seçeneği, eski bir sayfa bfcache'den geri yüklenirse güncel olmayan bilgileri açığa çıkarabilir.

Daha önemli başka bir örnek de, kullanıcının herkese açık bir bilgisayarda siteden çıkış yapması ve bir sonraki kullanıcının geri düğmesini tıklamasıdır. Bu durum, kullanıcının çıkış yaptığında temizlendiğini varsaydığı gizli verilerin açığa çıkmasına neden olabilir.

Bunun gibi durumlardan kaçınmak için event.persisted değeri true ise sayfayı bir pageshow etkinliğinden sonra güncellemek her zaman iyidir:

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

İdeal olan, içeriği yerinde güncellemektir ancak bazı değişikliklerde içeriği tamamen yeniden yüklemeye zorlamak isteyebilirsiniz. Aşağıdaki kod, pageshow etkinliğinde siteye özel bir çerez 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ükleme, geçmişi koruyacak (ileri gezinmeye olanak sağlamak için) avantaja sahiptir, ancak bazı durumlarda yönlendirme daha uygun olabilir.

Reklamlar ve bfcache geri yükleme

Her geri-ileri gezinmede yeni bir reklam grubu sunmak için bfcache kullanmaktan kaçınmayı denemek cazip gelebilir. Ancak bu davranışın performans üzerindeki etkisinin yanı sıra, bu davranışın daha iyi reklam etkileşimi sağlayıp sağlamadığı da sorgulanıyor. Kullanıcılar, tıklamaya dönmeyi düşündükleri ancak önbellekten geri yükleme yapmak yerine sayfayı yeniden yüklemeyi düşündükleri bir reklam fark etmiş olabilirler. Varsayımlarda bulunmadan önce bu senaryoyu (tercihen bir A/B testiyle) test etmek önemlidir.

Bfcache geri yükleme işleminde reklamları yenilemek isteyen siteler için event.persisted true olduğunda yalnızca pageshow etkinliğindeki reklamların yenilenmesi, sayfa performansını etkilemeden bunun gerçekleşmesine olanak tanır. Reklam sağlayıcınıza danışın. Burada, Google Yayınlama Etiketi ile bunu nasıl yapacağınıza dair bir örnek bulabilirsiniz.

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

Eski tarayıcılarda, bir sayfa target=_blank içeren bir bağlantıdan window.open() kullanılarak ancak rel="noopener" belirtilmeden açılmışsa açılış sayfasında, açılan sayfanın pencere nesnesine başvuru bulunur.

Boş olmayan bir window.opener referansına sahip bir sayfa, güvenlik riski teşkil etmesinin yanı sıra, erişmeye çalışan sayfaları bozabileceğinden güvenli bir şekilde Bfcache içine yerleştirilemez.

Bu nedenle, window.opener referansları oluşturmaktan kaçınmanız önerilir. Bunu mümkün olduğunda rel="noopener" kullanarak yapabilirsiniz (bunun artık tüm modern tarayıcılarda varsayılan olduğunu unutmayın). Siteniz bir pencerenin açılmasını ve window.postMessage() aracılığıyla bu pencerenin kontrol edilmesini veya doğrudan pencere nesnesine referans verilmesini gerektiriyorsa açılan pencere veya açıcı, önbellek için uygun olmaz.

Kullanıcı gitmeden önce açık bağlantıları kapatın

Daha önce de belirtildiği gibi, bir sayfa Bfcache içine yerleştirildiğinde, planlanmış tüm JavaScript görevlerini duraklatır ve sayfa önbellekten çıkarıldığında devam ettirir.

Planlanmış bu JavaScript görevleri yalnızca DOM API'lerine veya yalnızca geçerli sayfayla izole edilmiş diğer API'lere erişiyorsa, bu görevlerin sayfa kullanıcı tarafından görülemediği bir zamanda duraklatılması herhangi bir soruna neden olmaz.

Ancak, bu görevler aynı kaynaktaki diğer sayfalardan da erişilebilen API'lere bağlıysa (örneğin: IndexedDB, Web Locks, WebSockets) bu görevlerin duraklatılması diğer sekmelerdeki kodun çalışmasını engelleyebileceği için bu sorunlu olabilir.

Sonuç olarak, aşağıdaki senaryolarda bazı tarayıcılar bir sayfayı bfcache içine yerleştirmeye çalışmayacaktır:

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

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

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

Aşağıdaki örnekte, IndexedDB kullanan sayfaların bfcache için uygun olmasını sağlamak amacıyla pagehide etkinlik işleyicide açık bir bağlantıyı nasıl kapatabileceğiniz 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 sayfaların uygun olması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'ya gidin -> Geri-ileri Önbellek.
3. Testi Çalıştır düğmesini tıklayın. Geliştirici Araçları daha sonra bu sayfadan uzaklaşmaya ve geri gitmeye çalışır öğesini kullanın.

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

Başarısız olursa panel bunun nedenini belirtir. Bu durumun nedeni 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 hizmetine 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 bakın.

bfcache 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'yi daha fazla kullanıcı için 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ğinden, muhtemelen bfcache kullanan diğer tarayıcılardan gelen sayfa görüntülemelerini eksik rapor etmiş olursunuz.

Bfcache geri yüklemelerini sayfa görüntüleme sayınıza dahil etmek için pageshow etkinliği için işleyicileri ayarlayın ve persisted özelliğini kontrol edin.

Aşağıdaki örnekte, bunu Google Analytics ile nasıl yapacağınız gösterilmektedir. Diğer analiz araçları 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çme

Ayrıca, bfcache kullanmayan sayfaları tanımlamanıza yardımcı olması için bfcache kullanılıp kullanılmadığını da ölçebilirsiniz. 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 gezinme işlevinin bfcache'yi kullanmayacağı durumlarda, site sahiplerinin kontrolü dışında birtakım senaryolar olduğunun anlaşılması önemlidir. Örneğin:

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

Bu gibi durumlarda orijinal gezinme türü bazı tarayıcılar tarafından korunabilir ve bu nedenle Geri/İleri gezinmeleri olmamalarına rağmen bir back_forward türü gösterilebilir.

Bu hariç tutmalar olmasa bile bfcache, belleği korumak için bir süre sonra silinir.

Bu nedenle, web sitesi sahipleri tüm back_forward gezinmeleri için% 100 Bfcache isabet oranı beklememelidir. Bununla birlikte, oranını ölçmek, büyük oranda geri ve ileri gezinmelerde sayfanın kendisinin bfcache kullanımını engellediği sayfaları belirlemek açısından faydalı olabilir.

Chrome ekibi, sayfaların bfcache kullanmama nedenlerini ortaya çıkarmaya yardımcı olmak için NotRestoredReasons API'yi ekledi. Böylece geliştiriciler bu sayede bfcache isabet oranlarını iyileştirebilirler. Chrome ekibi, CrUX'e gezinme türleri de ekledi. Bu sayede, kendiniz ölçmeseniz bile bfcache gezinmelerinin sayısını görebileceksiniz.

Performans ölçümü

bfcache da alanda toplanan performans metriklerini, özellikle de sayfa yükleme sürelerini ölçen metrikleri olumsuz etkileyebilir.

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

Sonuç olarak, veri kümenizdeki sayfa yükleme sayısı daha az olur. Bu durum, kullanıcının yaşadığı performansın artmış olmasına rağmen muhtemelen dağılımda sapmaya neden olur.

Bu sorunla başa çıkmanın birkaç yolu vardır. Bunlardan biri, tüm sayfa yükleme metriklerine ilgili gezinme türleriyle (navigate, reload, back_forward veya prerender) not eklemektir. Bu sayede, genel dağılım negatif olsa bile bu gezinme türlerinde performansınızı izlemeye devam edebilirsiniz. Bu yaklaşımı, İlk Bayt'a Kadar Geçen Süre (TTFB) gibi kullanıcı merkezli olmayan sayfa yükleme metrikleri için öneririz.

Core Web Vitals gibi kullanıcı odaklı metrikler için kullanıcının deneyimlerini daha doğru şekilde yansıtan bir değer raporlamak daha iyi bir seçenektir.

Core Web Vitals üzerindeki etki

Core Web Vitals, kullanıcının bir web sayfasıyla ilgili deneyimini çeşitli boyutlarda (yükleme hızı, etkileşim, görsel kararlılık) ölçer. Kullanıcılar tam sayfa yüklemelerinden daha hızlı gezinme olarak bfcache geri yükleme deneyimi yaşadığından Core Web Vitals metriklerinin bunu yansıtması önemlidir. Sonuçta kullanıcı bfcache'in etkinleştirilip etkinleştirilmediğini umursamıyor, sadece gezinmenin hızlı olmasını önemsiyorlar!

Chrome Kullanıcı Deneyimi Raporu gibi Core Web Vitals metriklerini toplayan ve raporlayan araçlar, bfcache geri yüklemelerini veri kümelerinde ayrı sayfa ziyaretleri olarak ele alır. bfcache geri yüklendikten sonra bu metrikleri ölçmek için özel bir web performansı API'si bulunmasa da mevcut web API'lerini kullanarak bunların değerlerini tahmin edebilirsiniz:

• Çerçevedeki tüm öğeler aynı anda boyanacağından, Largest Contentful Paint (LCP) için pageshow etkinliğinin zaman damgası ile bir 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 geçerli INP değerini 0 olarak sıfırlayın.
• Cumulative Layout Shift (CLS) için mevcut Performance Observer'ı kullanmaya devam edin ancak mevcut CLS değerini 0 olarak sıfırlayın.

bfcache'nin her metriği nasıl etkilediği hakkında daha fazla bilgi için her bir Core Web Vitals metrik kılavuzu sayfalarına bakın. Bu metriklerin bfcache sürümlerinin nasıl uygulanacağına dair belirli bir örnek için bfcache sürümlerini web-vitals JS kitaplığına ekleme başlıklı makaleyi inceleyin.

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

Ek Kaynaklar

• Firefox Önbelleğe Alma (Firefox'ta bfcache)
• Sayfa Önbelleği (Safari'de bfcache)
• Geri-ileri önbellek: Web'de açığa çıkan davranış (tarayıcılar arasındaki bfcache farklılıkları)
• bfcache test kullanıcısı (farklı API'lerin ve etkinliklerin tarayıcılarda bfcache'yi nasıl etkilediğini test edin)
• Performans İçin Oyun Değiştirici: Tarayıcı Geri/İleri Önbelleği (Smashing Magazine'in bfcache'yi etkinleştirerek Core Web Vitals'da önemli iyileşmeleri gösterdiği bir örnek olay)