Bộ nhớ đệm Back/Forward (bfcache)

Tóm tắt — Back/forward cache (bfcache) là tính năng trình duyệt đóng băng toàn bộ trang trong bộ nhớ khi bạn rời đi, nhờ đó nút Back hoặc Forward có thể khôi phục trang gần như tức thì mà không tải lại, miễn là trình duyệt chưa loại ảnh chụp đóng băng đó. Đây là tính năng trình duyệt, không phải yếu tố xếp hạng của Google. Tuy nhiên, vì trang được khôi phục tải gần như tức thì, bfcache cải thiện chỉ số Core Web Vitals trên những lượt điều hướng Back/Forward thực sự được khôi phục; vì vậy kiểm tra hiệu suất có thể yêu cầu bạn “khắc phục điều kiện sử dụng bfcache”.

Bfcache là gì

Khi bạn nhấp nút Back của trình duyệt, một trong hai việc xảy ra. Trình duyệt dựng lại trang trước từ đầu — tải lại tệp, chạy lại JavaScript và bố trí lại toàn bộ trang — hoặc khôi phục trang gần như tức thì, đúng trạng thái bạn đã rời đi. Cách khôi phục tức thì đó là back/forward cache, hay bfcache.

Cơ chế nằm ở chỗ: thay vì loại bỏ trang cũ khi bạn điều hướng khỏi trang, trình duyệt đóng băng toàn bộ trang trong bộ nhớ — gồm cả JavaScript đang chạy — và giữ nguyên trạng thái. Nếu bạn sớm quay lại và ảnh chụp đóng băng vẫn còn, trình duyệt sẽ kích hoạt lại rồi hiển thị đúng trang đó, không gửi request mạng và không phải chờ. Việc khôi phục chỉ là khả năng, không phải bảo đảm: trình duyệt có thể loại trang khỏi bộ nhớ trước khi bạn nhấn Back do thiếu bộ nhớ, hết thời gian hoặc một hoạt động nhất định; khi đó trang sẽ tải lại bình thường.

Mô tả một dòng của Google nói rõ: bfcache là “a browser optimization that enables instant back and forward navigation.” (bản dịch) “một cơ chế tối ưu hóa trình duyệt cho phép điều hướng quay lại và tiến tới tức thì.”

Vì sao đây không phải “bộ nhớ đệm” bạn vốn biết

Đây là điểm thường bị nhầm lẫn. Khi nghe “cache”, bạn có thể nghĩ tới browser cache hoặc HTTP cache — các tệp như hình ảnh, script và stylesheet được trình duyệt lưu để không phải tải lại. Bfcache không phải cơ chế đó. Những cache kia lưu tệp; bfcache lưu ảnh chụp của toàn bộ trang đang hoạt động, gồm cả trạng thái JavaScript. Tài liệu Chrome nói rõ bfcache “differs from browser cache and HTTP cache.” (bản dịch) “khác với browser cache và HTTP cache.”

Bfcache cũng không phải hai cơ chế đôi khi bị gộp chung: resource cache trong bộ nhớ của trình duyệt — nơi giữ script đã biên dịch và hình ảnh đã giải mã trong phiên hiện tại — hay Cache Storage của service worker — các cặp request/response mà website chủ động quản lý bằng caches.open(). Cả hai có thể hoạt động trên cùng trang với bfcache, nhưng là cơ chế riêng biệt chứ không phải chính bfcache.

Bfcache cũng không phải tính năng “cached page” hay “cached snapshot” cũ mà Google và Bing từng cung cấp trong kết quả tìm kiếm — menu nhỏ hiển thị phiên bản trang được lưu. Tính năng tìm kiếm đó đã ngừng hoạt động. Bfcache là tính năng trực tiếp của trình duyệt, không liên quan tới kết quả tìm kiếm.

Bfcache có giúp SEO không?

Không trực tiếp. Bfcache không phải yếu tố xếp hạng của Google — tài liệu xếp hạng Core Web Vitals của Google không hề nhắc tới nó. Bfcache giúp lượt điều hướng Back/Forward tải gần như tức thì đối với khách truy cập thực sự nhận được lượt khôi phục, và trình duyệt đo đó như một lần “tải trang” rất tốt. Vì vậy, nếu nhiều khách truy cập dùng Back và Forward — khi mua sắm, duyệt kết quả tìm kiếm hoặc đọc từ bài này sang bài khác — bfcache có thể cải thiện số liệu thực tế Core Web Vitals tổng thể. Đây chỉ là mối quan hệ gián tiếp, cách hai bước so với tuyên bố “bfcache tăng thứ hạng”; nó không bảo đảm tỷ lệ khôi phục, đánh giá Core Web Vitals tổng thể hay thứ hạng, nhưng tác động có thật và đo được.

Muốn xem đầy đủ yếu tố nào chặn bfcache, cách kiểm thử và mối liên hệ chính xác — không phóng đại — với Core Web Vitals? Hãy chuyển sang tab Advanced.

Tóm tắt — Bfcache là ảnh chụp toàn trang trong bộ nhớ — DOM + JS heap + trạng thái đang chạy — không phải phản hồi HTTP có thể tải lại, resource cache trong bộ nhớ hay Cache Storage của service worker. Khi điều hướng khỏi trang, trình duyệt tạm dừng JS và đóng băng trang; khi Back/Forward, nếu ảnh chụp vẫn còn, trình duyệt kích hoạt và hiển thị lại tức thì mà không gửi request mạng. Tuy nhiên, ảnh chụp luôn có thể bị loại, nên khôi phục là khả năng chứ không phải bảo đảm. Bfcache không phải yếu tố xếp hạng Google Search được ghi nhận; liên quan SEO chỉ gián tiếp qua số liệu CWV thực tế — chủ yếu LCP và CLS — trên lượt điều hướng thực sự được khôi phục, không bảo đảm tỷ lệ khôi phục, CWV tổng hợp, thứ hạng hay chuyển đổi. Trình xử lý unload là rào cản điều kiện lớn nhất — làm giảm khoảng 18 điểm phần trăm tỷ lệ hit trên Chrome. Cache-Control: no-store từng là nguyên nhân lịch sử lớn nhất — chặn khoảng 17% lượt điều hướng lịch sử trên mobile và 7% trên desktop — nhưng sau đợt triển khai năm 2025, Chrome cho phép có điều kiện nhiều trang no-store: trang bị loại khi trạng thái xác thực/cookie thay đổi và vẫn bị chặn bởi các API kết nối mở. Hãy đóng hoặc tạm dừng kết nối, timer và observer tại pagehide/freeze, rồi thiết lập lại tại pageshow/resume. window.opener, permissions policy và frame cũng có thể chặn; hãy xem lý do theo từng frame trong DevTools hoặc notRestoredReasons. Kiểm thử riêng lẻ bằng Chrome DevTools; chẩn đoán thực tế bằng API notRestoredReasons chỉ có trên Chrome — giá trị null không chứng minh đã khôi phục và văn bản lý do không ổn định. Mỗi trình duyệt có quy tắc riêng, còn soft navigation của SPA không được xử lý tương tự.

Bfcache thực chất là gì — trục chính về độ chính xác

Điểm quan trọng nhất: bfcache là ảnh chụp toàn trang trong bộ nhớ, không phải phản hồi HTTP được lưu đệm. Khi bạn điều hướng khỏi trang, thay vì hủy trang, trình duyệt tạm dừng JavaScript và đóng băng toàn bộ trạng thái — DOM, JS heap, timer đang chạy và mọi phần còn lại — trong bộ nhớ. Nếu bạn nhấn Back hoặc Forward khi ảnh chụp vẫn còn, trình duyệt kích hoạt lại và hiển thị đúng trang đã rời đi, với không request mạng và không kết xuất lại. Đây là khả năng khôi phục, không phải bảo đảm: trình duyệt có thể loại ảnh chụp do áp lực bộ nhớ, hết thời gian hay sự kiện nhất định; quy tắc riêng của trình duyệt cũng có thể buộc tải mới. Google mô tả bfcache là “a browser optimization that enables instant back and forward navigation.” (bản dịch) “một cơ chế tối ưu hóa trình duyệt cho phép điều hướng quay lại và tiến tới tức thì.”

Đây là lý do việc đánh đồng bfcache với HTTP/browser cache là lỗi lặp lại trong nội dung đối thủ. HTTP cache lưu phản hồi của các request trước — các tệp có thể phục vụ lại. Bfcache lưu trang đang hoạt động. Tài liệu Chrome DevTools phân biệt rõ: bfcache “differs from browser cache and HTTP cache.” (bản dịch) “khác với browser cache và HTTP cache.” Bạn không “bật” bfcache bằng cache header như khi cấu hình HTTP caching; header chỉ liên quan vì Cache-Control: no-store từng khiến trang không đủ điều kiện — xem phần dưới.

Sự phân biệt tương tự áp dụng với hai cache khác thường bị nhầm với bfcache: resource cache trong bộ nhớ của trình duyệt — script đã biên dịch và hình ảnh đã giải mã trong phiên hiện tại — và Cache Storage của service worker — các cặp request/response mà website tự quản lý qua caches.open(). Cả hai có thể cùng hoạt động với bfcache trên một trang, nhưng không cơ chế nào là bfcache; bfcache chính là phiên bản trang đóng băng, không phải asset được cache hay phản hồi bị chặn.

Cần phân biệt thêm vì vẫn thường gây nhầm: bfcache không liên quan tới tính năng “cached page” cũ trong tìm kiếm mà Google và Bing từng hiển thị trong kết quả. Đó là ảnh chụp trang được lưu trong chỉ mục tìm kiếm và đã ngừng hoạt động. Bfcache là tính năng phía client của rendering engine.

Lượt điều hướng Back/Forward phổ biến đến mức nào?

Đây không phải trường hợp hiếm. Theo web.dev, “1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward.” (bản dịch) “cứ 10 lượt điều hướng trên desktop có 1 lượt và cứ 5 lượt trên mobile có 1 lượt là quay lại hoặc tiến tới.” Với website có luồng lặp lại — từ danh mục thương mại điện tử tới sản phẩm rồi quay lại, kết quả tìm kiếm, nội dung phân trang hoặc đọc liên tiếp nhiều bài — đây là tỷ lệ lớn các lượt điều hướng thực có thể trở nên gần như tức thì.

Hỗ trợ trình duyệt

“All major browsers include a bfcache, including Chrome since version 96, Firefox and Safari.” (bản dịch) “Mọi trình duyệt lớn đều có bfcache, gồm Chrome từ phiên bản 96, Firefox và Safari.” Firefox và Safari đã có triển khai bfcache riêng lâu hơn; mọi trình duyệt dựa trên Chromium — Edge, Brave, Opera, Arc — thừa hưởng triển khai của Chrome. Tài liệu policy của Microsoft Edge mô tả cùng tính năng: khi rời trang, trạng thái hiện tại — cây tài liệu, script và các phần khác — có thể được giữ trong back-forward cache; nếu quay lại, trang có thể được khôi phục và hiển thị ở trạng thái trước khi cache. Edge bật mặc định; chỉ quản trị viên CNTT mới có thể tắt bằng enterprise policy, không phải chủ website.

Lưu ý quan trọng: bfcache của mỗi trình duyệt có quy tắc đủ điều kiện riêng. Trang vượt qua “Test back/forward cache” trong Chrome DevTools không được bảo đảm đủ điều kiện trên Firefox hoặc Safari. Hãy coi việc pass trên Chrome là cần thiết, chưa phải đầy đủ.

Những yếu tố chặn điều kiện bfcache

Sự kiện unload — rào cản lớn nhất

Nếu chỉ nhớ một điều từ bài này: hãy ngừng dùng sự kiện unload. web.dev nhấn mạnh hiếm thấy trong tài liệu Google: “Never use the unload event. Ever!” (bản dịch) “Đừng bao giờ dùng sự kiện unload.” Trên Chrome, trình xử lý unload làm giảm khoảng 18 điểm phần trăm tỷ lệ hit bfcache — rào cản do chính website gây ra lớn nhất.

Chrome đang chủ động ngừng hỗ trợ vì hai lý do. Thứ nhất, đây là rào cản bfcache lớn nhất. Thứ hai, bản thân unload cực kỳ thiếu tin cậy: trên mobile, sự kiện thường hoàn toàn không kích hoạt vì tab chuyển nền rồi bị đóng và trình duyệt ưu tiên bfcache hơn kích hoạt unload. Vì vậy sự kiện được dựa vào để “dọn dẹp” thường không chạy, đồng thời chặn một cải thiện hiệu suất thật.

Cách khắc phục:

• Thay unload bằng pagehide. Sự kiện pagehide kích hoạt trong mọi trường hợp unload kích hoạt, và cả khi trang đi vào bfcache, nên đây là nâng cấp rõ ràng. Dùng visibilitychange để dọn dẹp đáng tin cậy khi “người dùng rời đi”.
• Phát hiện lượt khôi phục bfcache bằng pageshow. Lắng nghe pageshow và kiểm tra event.persisted; nếu là true, trang đã được khôi phục từ bfcache — lúc đó hãy làm mới dữ liệu cũ hoặc đếm lại pageview.
• Chủ động chặn listener unload bằng response header Permissions-Policy: unload=(), ngăn mọi trình xử lý unload được đăng ký. Chrome đang dần chuyển policy mặc định sang từ chối — Permissions-Policy cho unload có từ Chrome 115.

Cache-Control: no-store — lớn nhất trong lịch sử, nay cần hiểu có điều kiện

Đây là điểm về độ mới mà phần lớn nội dung đối thủ diễn đạt sai. Trong lịch sử, Cache-Control: no-store là nguyên nhân đơn lẻ lớn nhất khiến trang bị loại khỏi bfcache — số liệu của Chrome ước tính khoảng 17% lượt điều hướng lịch sử trên mobile và 7% trên desktop. Nhiều website đặt no-store để tránh phục vụ trang cũ, nhưng Google lập luận lý do này yếu hơn với bfcache: lượt khôi phục bfcache không tải một phản hồi cũ được cache, mà hiển thị lại đúng trang đang hoạt động gần như thể tab vẫn mở.

Vì vậy Chrome đã thay đổi hành vi — có điều kiện, không phải phổ quát. Thử nghiệm bắt đầu ở Chrome 116 và triển khai hoàn tất cho 100% người dùng trong tháng 3 và tháng 4/2025. Chrome nay cho phép bfcache với nhiều trang no-store theo các điều kiện an toàn cụ thể, không phải ngoại lệ chung. Theo tài liệu Chrome, trang bị loại khỏi bfcache nếu trạng thái xác thực hoặc cookie thay đổi khi đang đóng băng; một khách đã đăng xuất hoặc xóa cookie sẽ không thấy ảnh chụp đăng nhập cũ. Danh sách API cố định — gồm các API kết nối mở như IndexedDB, WebSocket, WebRTC và những API dưới đây — vẫn loại trang no-store khỏi bfcache. Đây là hành vi riêng của Chrome trên một dải phiên bản cụ thể, không thể mặc định áp dụng cho trình duyệt khác hay Chrome cũ. Hãy lấy báo cáo DevTools/notRestoredReasons hiện tại trên đúng trình duyệt và phiên bản đang kiểm thử. Kết luận thực tế: hướng dẫn coi no-store là rào cản bfcache vô điều kiện và vĩnh viễn đã lỗi thời; coi vấn đề đã giải quyết hoàn toàn cũng sai. Nếu độ mới thực sự quan trọng, tài liệu Chrome đề xuất no-cache hoặc max-age ngắn — ví dụ max-age=60 — thay cho no-store.

Kết nối mở, observer và các rào cản khác

Tại thời điểm điều hướng, một số tài nguyên đang mở vẫn có thể chặn điều kiện — nhưng chính xác tài nguyên nào chặn hoàn toàn hay chỉ bị đóng rồi có thể kết nối lại phụ thuộc trình duyệt và phiên bản. Hãy coi danh sách dưới đây là ví dụ về một mô hình, không phải danh sách rào cản cố định, vĩnh viễn:

• Request fetch() / XMLHttpRequest đang thực hiện.
• Transaction IndexedDB đang mở.
• Kết nối WebSocket / WebRTC, timer và observer đang mở — MutationObserver, IntersectionObserver và tương tự. Lĩnh vực này tiếp tục cải thiện: ghi chú phát hành Microsoft Edge gần đây cho biết WebSocket mở nay bị đóng khi trang đi vào bfcache — thay vì chặn cache hoàn toàn — và khuyến nghị kết nối lại qua kiểm tra event.persisted của pageshow. Điều này phản ánh xu hướng rộng hơn của Chrome là giảm rào cản thay vì loại trang.

Mô hình tổng quát nên triển khai thay vì ghi nhớ danh sách cố định: đóng hoặc tạm dừng kết nối, timer và observer trong xử lý pagehide/freeze, rồi thiết lập lại trong xử lý pageshow/resume khi event.persisted là true. Mô hình này vẫn đúng khi trình duyệt thay đổi API nào chặn hoàn toàn và API nào chỉ bị tạm dừng rồi cho phép kết nối lại.

window.opener, permissions policy và frame. Tham chiếu window.opener, một số permissions policy và iframe nhúng — cùng origin hoặc khác origin — cũng có thể ảnh hưởng điều kiện; đây là mục trong checklist tôi đúc kết ở hướng dẫn CLS của Ahrefs và tài liệu Chrome. Đừng đoán nguyên nhân từ checklist chung: panel DevTools và API notRestoredReasons đều báo lý do chặn theo từng frame — top frame và từng iframe riêng — vì frame gây chặn không phải lúc nào cũng là trang cấp cao nhất. Hãy lấy lý do thật từ báo cáo theo frame trên trình duyệt đang kiểm thử.

Hiểu đúng chuỗi sự kiện và trạng thái vòng đời

Nhầm lẫn giữa điều mỗi sự kiện vòng đời thật sự chứng minh và điều nó chỉ gợi ý là lỗi chính xác phổ biến thứ hai, sau các lỗi về điều kiện ở trên:

Quy tắc thực tế: coi pagehide.persisted là ý định, không phải bằng chứng — trang vẫn có thể bị loại trước khi được khôi phục. Chỉ pageshow.persisted === true mới chứng minh lượt khôi phục đã xảy ra. Luôn dọn dẹp tại pagehide/freeze — việc này rẻ và an toàn cả trên lượt điều hướng bình thường — và chỉ chạy tác vụ dành riêng cho khôi phục tại pageshow/resume, với điều kiện event.persisted, để không làm mới dữ liệu hay đếm analytics view hai lần khi tải mới thông thường.

Cách kiểm thử và chẩn đoán bfcache

Lab / kiểm tra một lần: Chrome DevTools

Mở DevTools → Application → Background services → Back/forward cache, rồi nhấp “Test back/forward cache.” Chrome tự điều hướng tới chrome://terms/ rồi quay lại, sau đó báo thành công hoặc danh sách lý do chặn cụ thể. Cách này phù hợp để kiểm tra từng URL.

Dữ liệu thực tế / production: API notRestoredReasons

Trước đây, cách duy nhất để kiểm tra điều kiện là bài test DevTools thủ công từng URL; không thể biết vì sao lượt điều hướng của người dùng thật bị chặn. Thuộc tính notRestoredReasons trên PerformanceNavigationTiming — có từ Chrome 123+ — lấp khoảng trống đó bằng cách báo lý do chặn cụ thể cho top frame và iframe cùng origin trong dữ liệu thực tế.

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

Một số điểm cần hiểu đúng theo hướng dẫn API của Chrome:

• Chỉ có trên Chrome 123+. Firefox và Safari không cung cấp API thực tế tương đương, nên vẫn phải kiểm tra thủ công trên các trình duyệt đó để biết tỷ lệ khôi phục.
• Kết quả null mơ hồ, không phải tín hiệu xanh. Nó có thể nghĩa là trang được khôi phục, hoặc trình duyệt không thu thập lý do; tài liệu Chrome nói không được coi null là bằng chứng khôi phục thành công.
• Văn bản lý do không phải hợp đồng ổn định. Đừng hard-code so khớp chuỗi; hãy nhóm và theo dõi xu hướng theo lý do vì cách diễn đạt có thể đổi giữa các phiên bản Chrome.

Trong thực tế, hãy thu thập notRestoredReasons cùng tỷ lệ khôi phục pageshow.persisted trước và sau khi phát hành bản sửa, so sánh xu hướng thay vì một ảnh chụp, đồng thời kiểm tra lab thủ công trên Firefox và Safari. Đây là công cụ chẩn đoán bfcache ở quy mô RUM/production thay vì kiểm từng URL, nhưng không đại diện toàn bộ bức tranh.

Bfcache và Core Web Vitals — mối quan hệ chính xác

Đây là sắc thái phần lớn nội dung đối thủ làm mờ và là góc đáng trình bày rõ.

Cách đo lượt khôi phục bfcache. Trình duyệt — và do đó dữ liệu thực tế CrUX — tính một lượt điều hướng được khôi phục từ bfcache như lần “tải trang” cực nhanh: LCP gần như tức thì và, khi trang được triển khai đúng — không phải bố trí lại — gần như không có CLS bổ sung, vì không kết xuất lại. Trong so sánh thực tế của DebugBear, trang khôi phục từ bfcache có LCP khoảng 100ms so với ~427ms khi tải không cache. Đây là lý do bfcache xuất hiện như đòn bẩy CLS và LCP trong checklist CLS của Ahrefs, nơi tôi viết: “Make sure your pages are eligible for bfcache. The back/forward cache keeps pages in the browser cache. It allows for instant loading of a page that was already loaded, meaning no layout shifts will happen.” (bản dịch) “Hãy bảo đảm trang đủ điều kiện dùng bfcache. Back/forward cache giữ trang trong cache trình duyệt, cho phép tải tức thì trang đã tải trước đó, nên không xảy ra dịch chuyển bố cục.”

Có hai giới hạn phạm vi cần nói chính xác. Thứ nhất, tác động chỉ áp dụng cho lượt điều hướng CrUX phân loại là back/forward — chiều navigation-type — không nói gì về lượt truy cập đầu hay tải lại, vốn chiếm phần lớn lưu lượng trên nhiều website. Thứ hai, cải thiện trải nghiệm được đo cho người nhận lượt khôi phục không phải bảo đảm: người dùng có trang bị loại khỏi bfcache vẫn nhận lần tải bình thường. Vì vậy công việc về điều kiện bfcache thay đổi tỷ lệ khôi phục trong các lượt Back/Forward, không phải tỷ lệ cố định của tổng lưu lượng; nó cũng không bảo đảm Core Web Vitals thực tế tổng hợp, thứ hạng hay tỷ lệ chuyển đổi. Đây là đòn bẩy thật, đo được nhưng có phạm vi cụ thể, không phải bản sửa hiệu suất hoặc SEO chung.

Bfcache có phải yếu tố xếp hạng không? Không. Đây là tuyên bố có thể bảo vệ và tạo khác biệt. Tài liệu xếp hạng Core Web Vitals của Google không nhắc bfcache. Chuỗi ảnh hưởng trung thực là: điều kiện bfcache → số liệu CWV thực tế tốt hơn — chủ yếu LCP/CLS — trên lượt Back/Forward → Core Web Vitals là một trong nhiều tín hiệu “trải nghiệm trang” mà Google nói phù hợp với điều hệ thống xếp hạng vốn tưởng thưởng. Tuyên bố này yếu hơn và chính xác hơn nhiều so với “bfcache tăng thứ hạng”. Bfcache cũng là tính năng rendering engine, không phải tính năng crawler; nó không liên quan cách Googlebot hay Bingbot crawl trang, nên không có “quan điểm của Bing về bfcache cho SEO” như với robots.txt hoặc sitemap.

SPA và soft navigation. Bfcache hoạt động trên điều hướng trình duyệt và sự kiện lịch sử thật. Thay đổi route “mềm” phía client của single-page app — hoán đổi view bằng JS mà không kích hoạt điều hướng trình duyệt thật — không phải sự kiện bfcache và không được xử lý tương tự. Việc một số công cụ RUM cố gán Core Web Vitals cho soft navigation có thể tạo sai khác giữa CrUX và RUM; đây là điểm cần lưu ý khi kiểm tra website dùng framework JS.

Rào cản bfcache phổ biến ngoài thực tế đến đâu?

Web Almanac của HTTP Archive theo dõi vấn đề này; đây là lĩnh vực đang thay đổi, không phải chuyện cũ đã ổn định. Bản 2022 cho biết ít nhất khoảng 22% trang mobile không đủ điều kiện bfcache chỉ theo hai tiêu chí unload và no-store. Từ đó, việc dùng trình xử lý unload giảm trên các nhóm website và thiết bị, nhưng Cache-Control: no-store lại tăng — chương 2025 ước tính khoảng 23% website, tăng từ khoảng 21% năm 2024, một phần do trải nghiệm xác thực/cá nhân hóa nhiều hơn và yêu cầu tuân thủ nghiêm ngặt hơn.

Phát hiện trái trực giác đáng trích dẫn: website lớn, lưu lượng cao có khả năng tự chặn bfcache cao hơn rõ rệt. Trong 1 000 website hàng đầu, khoảng 28% trang desktop và 20% trang mobile vẫn dùng trình xử lý unload, so với chỉ khoảng 11% desktop và 10% mobile trên toàn bộ website — thường vì website lớn mang nhiều analytics cũ và mã phụ thuộc unload. Những website có nhiều lưu lượng Back/Forward nhất để mất lại thường đang tự cản trở.

Vị trí của chủ đề này

Bfcache là một trong nhiều đòn bẩy hiệu suất trong cụm này. Lợi ích xuất hiện trong dữ liệu thực tế Core Web Vitals — cụ thể Cumulative Layout Shift và Largest Contentful Paint — vì trang được khôi phục hiển thị tức thì mà không bố trí lại. Cơ chế này khác caching, vốn lưu tệp thay vì ảnh chụp trang đang hoạt động, dù cả hai cùng có điểm liên quan là header Cache-Control. Không có liên hệ trực tiếp với Interaction to Next Paint, nên tôi không gượng ép kết nối.

Tóm tắt AI

Bản tóm lược của nội dung Advanced:

• Bfcache = ảnh chụp toàn trang trong bộ nhớ — DOM + JS heap + trạng thái đang chạy — không phải phản hồi HTTP có thể tải lại, resource cache trong bộ nhớ hay Cache Storage của service worker. Khi rời trang, trình duyệt tạm dừng JS và đóng băng trang; khi Back/Forward, nếu ảnh chụp vẫn còn, trang được kích hoạt và hiển thị tức thì, không gửi request mạng. Trang luôn có thể bị loại, nên khôi phục không được bảo đảm. Tài liệu Chrome nói cơ chế này “khác browser cache và HTTP cache”; nó cũng không phải tính năng “cached page” cũ trong tìm kiếm.
• Không phải yếu tố xếp hạng và có phạm vi giới hạn. Tài liệu xếp hạng Core Web Vitals của Google không nhắc bfcache. Chuỗi ảnh hưởng gián tiếp là điều kiện bfcache → số liệu CWV thực tế tốt hơn — chủ yếu LCP/CLS — trên lượt Back/Forward được khôi phục → CWV là một đầu vào trải nghiệm trang. Nó không bảo đảm tỷ lệ khôi phục, CWV tổng hợp, thứ hạng hay chuyển đổi và chỉ ảnh hưởng lượt CrUX phân loại back/forward.
• Quy mô: “cứ 10 lượt desktop có 1 và cứ 5 lượt mobile có 1 là back hoặc forward.” Hỗ trợ gồm Chrome từ v96, Firefox và Safari, nhưng mỗi trình duyệt có quy tắc riêng.
• Rào cản lớn nhất là sự kiện unload — web.dev nhấn mạnh rằng không bao giờ nên dùng sự kiện này — làm giảm khoảng 18 điểm phần trăm tỷ lệ hit Chrome. Thay bằng pagehide + visibilitychange; phát hiện khôi phục qua pageshow/event.persisted; chặn unload bằng Permissions-Policy: unload=().
• Cache-Control: no-store từng là rào cản lớn nhất — khoảng 17% mobile / 7% desktop. Sau đợt triển khai tháng 3–4/2025, Chrome cho phép có điều kiện nhiều trang no-store: loại khi auth/cookie đổi, vẫn bị API kết nối mở chặn và chỉ áp dụng Chrome. Cả cách coi no-store là rào cản tuyệt đối lẫn coi vấn đề đã giải quyết đều lỗi thời.
• Rào cản khác: fetch/XHR đang chạy, timer, observer, IndexedDB, WebSocket/WebRTC, window.opener, permissions policy và frame. Đóng/tạm dừng tại pagehide/freeze, kết nối lại tại pageshow/resume, và lấy lý do theo frame từ DevTools/notRestoredReasons.
• Đúng vòng đời: pagehide.persisted là ý định, không phải bằng chứng; chỉ pageshow.persisted === true xác nhận khôi phục. Luôn dọn dẹp tại pagehide/freeze; chỉ làm tác vụ khôi phục tại pageshow/resume.
• Kiểm thử: “Test back/forward cache” trong Chrome DevTools cho lab; API notRestoredReasons chỉ có trên Chrome 123+ cho dữ liệu thực tế — null không chứng minh khôi phục, văn bản lý do không ổn định, còn Firefox/Safari cần kiểm tra thủ công. So sánh trước/sau với tỷ lệ pageshow.persisted.
• SPA: soft navigation phía client không phải sự kiện bfcache và có thể gây sai khác CrUX/RUM.
• Mức sử dụng: Web Almanac cho thấy no-store tăng khoảng 21%→23%, còn unload cao hơn trên website lớn — khoảng 28% desktop trong top 1 000 — nên website lớn thường tự chặn bfcache.

Tài liệu chính thức

Tài liệu nguồn sơ cấp về bfcache. Lưu ý nguồn được tách: bfcache nằm trong tài liệu Chrome / rendering engine — tiếng nói thể chế của Google về chủ đề — không phải Google Search Central; chính sự tách biệt này là điểm quan trọng.

Google / Chrome

• Back/forward cache — tài liệu chuẩn: định nghĩa, cơ chế, số liệu 1/10 và 1/5 cùng hướng dẫn về unload.
• Kiểm thử back/forward cache — các bước DevTools, rào cản chính và câu rõ ràng “khác browser cache và HTTP cache”.
• Bật bfcache cho Cache-Control: no-store — thay đổi policy năm 2025, số liệu 17% / 7% và lịch triển khai.
• Ngừng hỗ trợ sự kiện unload — lý do unload bị loại dần và lộ trình Permissions-Policy.
• API notRestoredReasons cho back/forward cache — chẩn đoán thực tế trên PerformanceNavigationTiming — Chrome 123+.
• Tìm hiểu Core Web Vitals và kết quả Google Search — tài liệu xếp hạng của Google Search Central; được dẫn làm bằng chứng rằng tài liệu không nhắc bfcache.

Microsoft / Edge

• Policy Microsoft Edge: BackForwardCacheEnabled — định nghĩa của Edge, cùng lưu ý unload và công tắc enterprise policy.

MDN / tiêu chuẩn web

• bfcache — MDN Glossary — định nghĩa web-dev tổng quát và phân biệt với HTTP cache.
• Theo dõi lý do chặn bfcache — MDN — cách dùng notRestoredReasons trong thực tế.

Trích dẫn từ nguồn

Các tuyên bố công khai trong tài liệu nguồn. Mỗi liên kết sâu dẫn thẳng tới đoạn được trích trên trang nguồn.

Google / Chrome — bfcache là gì và vì sao quan trọng

• “Back/forward cache (or bfcache) is a browser optimization that enables instant back and forward navigation.” (bản dịch) “Back/forward cache — hay bfcache — là cơ chế tối ưu hóa trình duyệt cho phép điều hướng quay lại và tiến tới tức thì.” Đi tới trích dẫn
• “1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward. With bfcache enabled, browsers could eliminate the data transfer and time spent loading for billions of web pages every single day!” (bản dịch) “Cứ 10 lượt điều hướng desktop có 1 lượt và cứ 5 lượt mobile có 1 lượt là quay lại hoặc tiến tới. Khi bật bfcache, trình duyệt có thể loại bỏ việc truyền dữ liệu và thời gian tải cho hàng tỷ trang web mỗi ngày.” Đi tới trích dẫn
• “All major browsers include a bfcache, including Chrome since version 96, Firefox and Safari.” (bản dịch) “Mọi trình duyệt lớn đều có bfcache, gồm Chrome từ phiên bản 96, Firefox và Safari.” Đi tới trích dẫn

Google / Chrome — quy tắc tối ưu hóa số một

• “Never use the unload event. Ever!” (bản dịch) “Đừng bao giờ dùng sự kiện unload.” — web.dev. Đi tới trích dẫn

Chrome DevTools — bfcache không phải HTTP cache

• “Back/forward cache differs from browser cache and HTTP cache.” (bản dịch) “Back/forward cache khác browser cache và HTTP cache.” — tài liệu Chrome DevTools. Đi tới trích dẫn

Microsoft Edge — cùng tính năng, cùng lưu ý

• “When navigating away from a page, its current state (document tree, script, and so on) may be preserved in the back-forward cache. If the browser navigates back to the page, the page may be restored from the back-forward cache and displayed in the state it was in before being cached.” (bản dịch) “Khi điều hướng khỏi trang, trạng thái hiện tại — cây tài liệu, script và các phần khác — có thể được giữ trong back-forward cache. Nếu trình duyệt quay lại trang, trang có thể được khôi phục từ back-forward cache và hiển thị ở trạng thái trước khi được cache.” — tài liệu policy Microsoft Edge. Đi tới trích dẫn

Patrick Stox — tôi — về bfcache như một đòn bẩy CLS

• “Make sure your pages are eligible for bfcache. The back/forward cache keeps pages in the browser cache. It allows for instant loading of a page that was already loaded, meaning no layout shifts will happen.” (bản dịch) “Hãy đảm bảo các trang có thể dùng bfcache. Back/forward cache giữ nguyên trang trong bộ nhớ trình duyệt, nhờ đó trang đã tải có thể xuất hiện tức thì mà không gây dịch chuyển bố cục.” — hướng dẫn CLS của tôi trên Ahrefs. Đọc bài

Checklist điều kiện bfcache

Một lượt kiểm tra để xác nhận trang có thể vào back/forward cache:

• Không có listener sự kiện unload ở bất kỳ đâu trên trang — của bạn hoặc bên thứ ba. Đây là rào cản lớn nhất.
• Chuyển mã dọn dẹp/analytics từ unload sang pagehide và visibilitychange.
• Listener pageshow kiểm tra event.persisted để làm mới dữ liệu cũ và đếm lại pageview chính xác sau lượt khôi phục bfcache.
• Cân nhắc response header Permissions-Policy: unload=() để chặn đăng ký mọi listener unload.
• Rà soát Cache-Control: no-store; nếu đặt phòng ngừa, xác nhận vẫn cần. Chrome 2025+ cho phép có điều kiện nhiều trang no-store — loại khi auth/cookie đổi và vẫn bị API kết nối mở chặn; đừng mặc định trình duyệt hoặc phiên bản khác giống vậy. Nếu độ mới quan trọng, ưu tiên no-cache hoặc max-age ngắn.
• Không để kết nối, timer hoặc observer mở khi điều hướng — fetch/XHR đang chạy, transaction IndexedDB, WebSocket/WebRTC, MutationObserver/IntersectionObserver. Đóng/tạm dừng tại pagehide/freeze; thiết lập lại tại pageshow/resume khi event.persisted là true.
• Không có tham chiếu window.opener, permissions policy hạn chế hay frame bị chặn làm trang mất điều kiện; xem lý do theo từng frame trong DevTools/notRestoredReasons thay vì đoán.
• Kiểm thử lab trong Chrome DevTools → Application → Back/forward cache → “Test back/forward cache”.
• Chẩn đoán dữ liệu thực tế ở quy mô lớn bằng notRestoredReasons trong RUM — chỉ Chrome; null không chứng minh khôi phục và văn bản lý do không ổn định, nên theo dõi xu hướng thay vì hard-code chuỗi.
• Đừng mặc định pass Chrome nghĩa là đủ điều kiện mọi nơi; kiểm tra nhanh Firefox và Safari, vì mỗi trình duyệt có quy tắc riêng.

Bảng tra nhanh bfcache

Yếu tố chặn và cách sửa

Các sự kiện cần biết

Kiểm thử

Dữ kiện nhanh

• Bfcache = toàn bộ trang đang hoạt động trong bộ nhớ, không phải tệp, resource cache hay Cache Storage của service worker. Chrome nói cơ chế này “differs from browser cache and HTTP cache.” (bản dịch) “khác browser cache và HTTP cache.”
• Không phải yếu tố xếp hạng Google — tài liệu CWV của Search Central không nhắc tới. Khôi phục cải thiện LCP/CLS được đo cho người nhận lượt đó; không bảo đảm tỷ lệ khôi phục, CWV tổng hợp, thứ hạng hay chuyển đổi.
• Hỗ trợ: Chrome 96+, Firefox, Safari — mỗi trình duyệt có quy tắc riêng.
• 1/10 lượt desktop và 1/5 lượt mobile là Back/Forward.

Anti-pattern bfcache — và các quan niệm sai phía sau

“Bfcache chỉ là HTTP/browser cache của tôi — tôi cấu hình bằng Cache-Control.” Không. Bfcache là ảnh chụp toàn trang riêng biệt trong bộ nhớ; tài liệu Chrome nói nó “differs from browser cache and HTTP cache.” (bản dịch) “khác browser cache và HTTP cache.” Cache header chỉ liên quan ở chỗ no-store từng khiến trang mất điều kiện. Bạn không “bật bfcache” bằng cache header.

“Bfcache là yếu tố xếp hạng Google, nên sửa nó sẽ tăng thứ hạng.” Không có nguồn chính thức nào của Google Search xác lập điều này. Tài liệu xếp hạng Core Web Vitals không nhắc bfcache. Mối quan hệ thật là gián tiếp — LCP/CLS thực tế tốt hơn trên lượt Back/Forward — một tuyên bố yếu hơn nhưng chính xác hơn.

“Cache-Control: no-store luôn chặn bfcache, vĩnh viễn.” Đúng trong lịch sử — và vẫn là nguyên nhân lịch sử lớn nhất — nhưng không còn luôn đúng sau khi Chrome triển khai đầy đủ bfcache an toàn với no-store năm 2025. Hướng dẫn trước thay đổi đã lỗi thời, nhưng coi vấn đề đã giải quyết hoàn toàn cũng sai: ngoại lệ Chrome có điều kiện — loại khi auth/cookie đổi, vẫn bị API kết nối mở chặn — và chỉ áp dụng Chrome, không phải tín hiệu xanh phổ quát.

“Trang kích hoạt pagehide với persisted: true chắc chắn đã được cache.” Không — đó là ý định, không phải bằng chứng. Trình duyệt vẫn có thể loại trang trước khi khôi phục. Chỉ pageshow.persisted === true xác nhận lượt khôi phục thật sự xảy ra.

“Nếu trang pass bài test bfcache trong Chrome DevTools thì đủ điều kiện mọi nơi.” Sai. Chrome, Firefox và Safari áp dụng hạn chế riêng; pass trên một trình duyệt không bảo đảm đủ điều kiện trên trình duyệt khác.

“unload là cách ổn để chạy mã thoát/dọn dẹp, nên tôi sẽ giữ.” Không — Chrome gọi sự kiện này cực kỳ thiếu tin cậy, thường không kích hoạt trên mobile, và đang chủ động loại dần bằng Permissions-Policy vì đây là rào cản bfcache lớn nhất. Dùng pagehide + visibilitychange.

“Bfcache giúp SPA giống như giúp website nhiều trang.” Cần giới hạn tuyên bố. Bfcache gắn với điều hướng trình duyệt thật; thay đổi route “mềm” phía client không phải cùng sự kiện và không được xử lý tương tự, đồng thời có thể gây sai khác CrUX/RUM trên website phụ thuộc SPA.

“Bfcache đã được giải quyết / là tin cũ, không đáng kiểm tra.” Dữ liệu Web Almanac bác bỏ: mức dùng no-store đang tăng, còn unload vẫn cao hơn rõ rệt trên website lớn, lưu lượng cao — chính những website có nhiều lưu lượng Back/Forward nhất để mất.

Công cụ kiểm thử và chẩn đoán bfcache

• Panel Back/forward cache trong Chrome DevTools. Application → Background services → Back/forward cache → “Test back/forward cache.” Công cụ tự điều hướng tới chrome://terms/ rồi quay lại, sau đó báo thành công hoặc lý do chặn chính xác. Phù hợp kiểm tra lab từng URL.
• API notRestoredReasons — Chrome 123+. Đọc performance.getEntriesByType('navigation')[0].notRestoredReasons trong RUM để xem ở quy mô lớn lý do chặn của người dùng thật, gồm iframe cùng origin, thay vì chỉ kiểm tra lab thủ công.
• PageSpeed Insights / Lighthouse / CrUX. Nơi khuyến nghị hoặc cờ “back/forward cache” thường xuất hiện đầu tiên trong audit và nơi lợi ích CWV thực tế của website đủ điều kiện bfcache được thể hiện.
• Header Permissions-Policy: unload=(). Không phải công cụ kiểm thử mà là biện pháp thực thi: đặt header để chủ động ngăn mọi listener unload, gồm cả bên thứ ba, được đăng ký.
• Chương Performance của Web Almanac — HTTP Archive. Dùng để so chuẩn mức phổ biến của rào cản bfcache theo thiết bị và nhóm thứ hạng website.

DevTools cho biết trình xử lý unload đã chặn khôi phục

Triệu chứng: bài test Back/forward cache nêu unload. Nguyên nhân có thể: mã bên thứ nhất hoặc bên thứ ba đã đăng ký listener unload. Cách sửa: thay tác vụ dọn dẹp bằng pagehide/visibilitychange, thêm Permissions-Policy: unload=() khi phù hợp và chạy lại bài test sau mỗi thay đổi ở script bị ảnh hưởng.

Trang được khôi phục hiển thị dữ liệu người dùng cũ

Triệu chứng: Back quay lại tức thì nhưng trạng thái tài khoản, tồn kho hoặc giá trị động khác đã cũ. Nguyên nhân có thể: trang tiếp tục trạng thái đóng băng mà không làm mới dữ liệu nhạy cảm theo thời gian. Cách sửa: lắng nghe pageshow, kiểm tra event.persisted và chỉ làm mới dữ liệu cần thiết. Xác nhận cả tải thông thường lẫn khôi phục đều hoạt động đúng.

Analytics bỏ sót hoặc đếm đôi lượt xem Back/Forward

Triệu chứng: pageview khác số lượt điều hướng lịch sử thực tế. Nguyên nhân có thể: analytics chỉ chạy ở lần tải đầu hoặc chạy hai lần mà không phân biệt khôi phục. Cách sửa: xử lý pageshow rõ ràng và dùng event.persisted để đếm đúng một lần điều hướng được khôi phục.

Lab pass nhưng tỷ lệ khôi phục thực tế vẫn thấp

Triệu chứng: URL mẫu pass DevTools nhưng RUM báo nhiều lượt không khôi phục. Nguyên nhân có thể: template, trình duyệt, trạng thái người dùng thật khác hoặc kết nối mở không liên tục tạo thêm rào cản. Cách sửa: thu thập notRestoredReasons, nhóm theo lý do và template, rồi tái hiện trường hợp thực tế chiếm ưu thế thay vì ngoại suy từ một lần pass.

Chứng minh bản sửa bfcache đã có hiệu lực

Kiểm thử điều kiện

Bài test: DevTools → Application → Back/forward cache → Test back/forward cache. Kết quả mong đợi: trang khôi phục thành công mà không có lý do chặn. Diễn giải thất bại: còn ít nhất một rào cản điều kiện. Khoảng theo dõi: ngay lập tức trên Chrome với trạng thái đã test. Điều kiện rollback: bản sửa làm hỏng dọn dẹp, bảo mật hoặc hành vi ứng dụng bắt buộc.

Kiểm thử hành vi khôi phục

Bài test: điều hướng khỏi trang rồi Back, sau đó xác minh pageshow nhận event.persisted === true và dữ liệu nhạy cảm theo thời gian được làm mới. Kết quả mong đợi: một lượt khôi phục tức thì, dữ liệu đúng và một analytics view. Diễn giải thất bại: trang không được cache hoặc xử lý khôi phục chưa hoàn chỉnh. Khoảng theo dõi: ngay lập tức trên các trạng thái đăng nhập/đăng xuất đại diện. Điều kiện rollback: dữ liệu nhạy cảm cũ hoặc hành động bị lặp sau khôi phục.

Kiểm thử lý do trong dữ liệu thực tế

Bài test: theo dõi PerformanceNavigationTiming.notRestoredReasons trong RUM. Kết quả mong đợi: rào cản mục tiêu giảm trên template bị ảnh hưởng mà không có rào cản mới chiếm ưu thế. Diễn giải thất bại: mẫu lab không đại diện production hoặc dependency khác sở hữu vấn đề. Khoảng theo dõi: đủ lưu lượng Back/Forward thật để so cùng cơ cấu template. Điều kiện rollback: hồi quy đáng kể về ứng dụng hoặc tính toàn vẹn dữ liệu gắn với thay đổi.

Các chỉ số bfcache đáng duy trì

Tỷ lệ hit khôi phục

Chỉ số: lượt điều hướng Back/Forward đủ điều kiện được khôi phục từ bfcache. Ý nghĩa: tần suất người dùng nhận lợi ích điều hướng tức thì. Cách lấy: entry điều hướng RUM và pageshow.persisted, phân đoạn theo trình duyệt và template. Mốc / phạm vi thực tế: thiết lập baseline riêng vì quy tắc trình duyệt, trạng thái trang và cơ cấu điều hướng khác nhau. Tần suất: hằng tuần và sau thay đổi vòng đời.

Lý do không khôi phục

Chỉ số: lượt điều hướng lịch sử được nhóm theo notRestoredReasons. Ý nghĩa: rào cản nào làm mất nhiều lượt khôi phục thật nhất. Cách lấy: API PerformanceNavigationTiming trên trình duyệt hỗ trợ. Mốc / phạm vi thực tế: hướng tới không còn rào cản do mã của bạn kiểm soát, đồng thời ghi rõ độ phủ trình duyệt/API. Tần suất: phân loại hằng tuần.

Độ chính xác của lượt điều hướng được khôi phục

Chỉ số: lỗi, sự cố dữ liệu cũ và analytics/hành động bị lặp sau khôi phục. Ý nghĩa: điều kiện cao hơn có giữ đúng hành vi ứng dụng hay không. Cách lấy: sự kiện lỗi RUM, giám sát ứng dụng và QA analytics gắn với pageshow.persisted. Mốc / phạm vi thực tế: không có lỗi đã biết về độ chính xác hoặc quyền riêng tư. Tần suất: cảnh báo liên tục và QA khi phát hành.

Tài nguyên đáng đọc

Bài viết liên quan của tôi

• Cumulative Layout Shift — CLS — là gì và cách cải thiện — nơi tôi liệt kê điều kiện bfcache như chiến thuật cải thiện CLS, kèm checklist rào cản ngắn.
• Core Web Vitals — CWV — là gì và cách cải thiện — nhóm chỉ số cha, với bfcache là một trong nhiều đòn bẩy CLS.
• Hướng dẫn Technical SEO cho người mới — vị trí của hiệu suất web trong bức tranh lớn.

Bài thuyết trình của tôi

• How Search Works — SlideShare — phần trình bày của tôi về crawl, kết xuất, lập chỉ mục và xếp hạng, tạo bối cảnh vì sao tính năng rendering engine như bfcache nằm ngoài tín hiệu xếp hạng Search. Tuyên bố miễn trừ thường trực của tôi vẫn áp dụng: “This is my understanding of systems… not going to be 100% complete or accurate.” (bản dịch) “Đây là hiểu biết của tôi về các hệ thống… sẽ không đầy đủ hoặc chính xác 100%.”

Chính thức

• Back/forward cache — web.dev — tài liệu chuẩn.
• Bật bfcache cho Cache-Control: no-store và Ngừng hỗ trợ sự kiện unload — Chrome for Developers — hai thay đổi khiến hướng dẫn cũ lỗi thời.
• Tìm hiểu Core Web Vitals và kết quả Google Search — Google Search Central — tài liệu xếp hạng đáng chú ý là không hề nhắc bfcache.

Từ các nguồn trong ngành

• bfcache — MDN Glossary — định nghĩa chính xác, trung lập về engine và phân biệt với HTTP cache.
• Back/Forward Cache có ý nghĩa gì với tốc độ website? — DebugBear — bài dựa trên dữ liệu nhất trong nhóm, có log website thật và so sánh LCP cụ thể — ~100ms khi cache so với ~427ms khi không cache.
• Giải thích Back Forward Cache — SpeedVitals — cơ chế, điều kiện, kiểm thử và tác động CWV.
• Back/Forward Cache: là gì và cách triển khai — NitroPack — tập trung triển khai cho đối tượng CMS/hosting.
• Yếu tố thay đổi hiệu suất: Browser Back/Forward Cache — Smashing Magazine — phân tích kỹ thuật tốt, nhưng có trước thay đổi no-store năm 2025.
• Web Almanac — chương Performance 2025 — HTTP Archive — dữ liệu thực tế về mức dùng unload và no-store theo thiết bị và nhóm thứ hạng website.

Số liệu đáng trích dẫn

• Lượt Back/Forward phổ biến: “1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward” (bản dịch) “cứ 10 lượt desktop có 1 và cứ 5 lượt mobile có 1 là quay lại hoặc tiến tới” — quy mô cơ hội, không phải trường hợp hiếm. Nguồn
• unload làm giảm khoảng 18 điểm phần trăm tỷ lệ hit bfcache trên Chrome — vì vậy đây là rào cản số một và đang bị loại dần. Nguồn
• Cache-Control: no-store là rào cản lịch sử lớn nhất — khoảng 17% lượt điều hướng lịch sử trên mobile và 7% trên desktop — trước khi đợt triển khai tháng 3–4/2025 của Chrome cho phép bfcache với nhiều trang no-store. Nguồn
• Khôi phục bfcache gần như tức thì: DebugBear đo LCP khoảng 100ms cho trang được khôi phục so với ~427ms khi tải không cache. Nguồn
• Website lớn tự chặn nhiều nhất: trong 1 000 website hàng đầu, khoảng 28% trang desktop và 20% trang mobile vẫn dùng trình xử lý unload, so với khoảng 11% / 10% trên toàn bộ website; mức dùng no-store đang tăng khoảng 21%→23%. Nguồn

Tự kiểm tra: Back/Forward Cache — bfcache

Năm câu hỏi nhanh về bfcache là gì, yếu tố nào chặn và mối quan hệ với SEO. Chọn đáp án cho từng câu rồi kiểm tra.

Nhật ký thay đổi