API bộ nhớ đệm cho thao tác tiến/lùi không được khôi phục

Tìm hiểu thao tác nào bị chặn sử dụng bfcache và lý do.

Thuộc tính notRestoredReasons, được thêm vào lớp PerformanceNavigationTiming, báo cáo thông tin về việc liệu các khung hình trong tài liệu có bị chặn sử dụng bfcache khi điều hướng hay không và lý do. Nhà phát triển có thể sử dụng thông tin này để xác định những trang cần cập nhật nhằm đảm bảo các trang đó tương thích với bộ nhớ đệm, nhờ đó cải thiện hiệu suất của trang web.

Trạng thái hiện tại

API notRestoredReasons đã được chuyển từ Chrome 123 và đang được triển khai dần.

Khái niệm và cách sử dụng

Các trình duyệt hiện đại cung cấp một tính năng tối ưu hoá để điều hướng nhật ký được gọi là bộ nhớ đệm cho thao tác tiến/lùi (bfcache). Điều này mang lại trải nghiệm tải tức thì khi người dùng quay lại trang họ đã truy cập. Các trang có thể bị chặn không cho vào bfcache hoặc bị loại khi đang ở trong bfcache vì nhiều lý do, một số trang theo yêu cầu của thông số kỹ thuật và một số nguyên nhân cụ thể cho việc triển khai trình duyệt.

Trước đây, các nhà phát triển không có cách nào để tìm hiểu lý do tại sao các trang của họ bị chặn sử dụng bfcache trong trường này, mặc dù đã có thử nghiệm trong công cụ cho nhà phát triển của Chrome. Để bật tính năng giám sát trong trường, lớp PerformanceNavigationTiming đã được mở rộng để bao gồm một thuộc tính notRestoredReasons. Thao tác này trả về một đối tượng chứa thông tin liên quan ở khung trên cùng và tất cả các iframe có trong tài liệu:

  • Lý do khiến họ bị chặn sử dụng bfcache.
  • Các chi tiết như khung idname để giúp xác định iframe trong HTML.

    Điều này cho phép các nhà phát triển hành động để làm cho những trang đó tương thích với bộ nhớ đệm, nhờ đó cải thiện hiệu suất của trang web.

Ví dụ

Bạn có thể lấy thực thể PerformanceNavigationTiming từ các tính năng như Performance.getEntriesByType()PerformanceObserver.

Ví dụ: bạn có thể gọi hàm sau để trả về tất cả đối tượng PerformanceNavigationTiming có trong tiến trình hiệu suất và ghi lại notRestoredReasons của các đối tượng đó:

function returnNRR() {
  const navEntries = performance.getEntriesByType("navigation");
  for (let i = 0; i < navEntries.length; i++) {
    console.log(`Navigation entry ${i}`);
    let navEntry = navEntries[i];
    console.log(navEntry.notRestoredReasons);
  }
}

Đối với các thao tác điều hướng nhật ký, thuộc tính PerformanceNavigationTiming.notRestoredReasons trả về một đối tượng có cấu trúc sau, thể hiện trạng thái bị chặn của khung cấp cao nhất:

{
  children: [],
  id: null,
  name: null,
  reasons: [
    {"reason", "unload-listener"}
  ],
  src: null,
  url: "https://www.example.com/page/"
}

Các thuộc tính này bao gồm như sau:

children
Một mảng đối tượng thể hiện trạng thái bị chặn của mọi khung có cùng nguồn gốc được nhúng trong khung cấp cao nhất. Mỗi đối tượng có cùng cấu trúc với đối tượng mẹ. Bằng cách này, mọi cấp độ của khung nhúng đều có thể được biểu thị theo cách đệ quy bên trong đối tượng đó. Nếu khung không có phần tử con, thì mảng sẽ trống.
id
Một chuỗi biểu thị giá trị thuộc tính id của khung (ví dụ: <iframe id="foo" src="...">). Nếu khung không có id, thì giá trị sẽ là null. Đối với trang cấp cao nhất, đây là null.
name
Một chuỗi đại diện cho giá trị thuộc tính name của khung (ví dụ: <iframe name="bar" src="...">). Nếu khung không có name, thì giá trị đó sẽ là một chuỗi trống. Đối với trang cấp cao nhất, đây là null.
reasons
Một mảng chuỗi biểu thị lý do trang đã điều hướng bị chặn sử dụng bfcache. Có nhiều lý do khác nhau khiến việc chặn có thể xảy ra. Hãy xem phần Lý do chặn để biết thêm thông tin.
src
Một chuỗi biểu thị đường dẫn đến nguồn của khung (ví dụ: <iframe src="b.html">). Nếu khung không có src, thì giá trị đó sẽ là một chuỗi trống. Đối với trang cấp cao nhất, đây là null.
url
Một chuỗi đại diện cho URL của trang/iframe đã điều hướng.

Đối với các đối tượng PerformanceNavigationTiming không biểu thị điều hướng nhật ký, thuộc tính notRestoredReasons sẽ trả về null.

Xin lưu ý rằng notRestoredReasons cũng trả về null khi không có lý do chặn. Vì vậy, việc này không phải là null để cho biết bfcache đã được hay chưa được sử dụng. Để làm được việc đó, bạn phải sử dụng thuộc tính event.persisted.

Báo cáo việc chặn bfcache trong khung cùng nguồn gốc

Khi một trang nhúng các khung có cùng nguồn gốc, giá trị notRestoredReasons được trả về sẽ chứa một đối tượng bên trong thuộc tính children, thể hiện trạng thái bị chặn của từng khung được nhúng.

Ví dụ:

{
  children: [
    {
      children: [],
      id: "iframe-id",
      name: "iframe-name",
      reasons: [],
      src: "./index.html",
      url: "https://www.example.com/"
    },
    {
      children: [],
      id: "iframe-id2",
      name: "iframe-name2",
      reasons: [
        {"reason": "unload-listener"}
      ],
      src: "./unload-examples.html",
      url: "https://www.example.com/unload-examples.html"
    },
  ],
  id: null,
  name: null,
  reasons: [],
  src: null,
  url:"https://www.example.com"
}

Báo cáo chặn bfcache trong các khung trên nhiều nguồn gốc

Khi một trang nhúng các khung trên nhiều nguồn gốc, chúng tôi sẽ giới hạn lượng thông tin được chia sẻ về các khung đó để tránh rò rỉ thông tin trên nhiều nguồn gốc. Chúng tôi chỉ đưa vào thông tin mà trang ngoài đã biết và liệu cây con trên nhiều nguồn gốc có chặn bfcache hay không. Chúng tôi không cung cấp lý do chặn hoặc thông tin nào về cấp thấp của cây con (ngay cả khi một số cấp phụ có cùng nguồn gốc).

Ví dụ:

{
  children: [
    {
      children: [],
      id: "iframe-id",
      name: "iframe-name",
      reasons: [],
      src: "./index.html",
      url: "https://www.example2.com/"
    }
  ],
  id: null,
  name: null,
  reasons: [
        {"reason": "masked"}
  ],
  src: null,
  url:"https://www.example.com"
}

Đối với tất cả iframe trên nhiều nguồn gốc, chúng tôi báo cáo null đối với giá trị reasons của khung, còn khung cấp cao nhất sẽ cho biết lý do của "masked". Xin lưu ý rằng "masked" cũng có thể được dùng cho các tác nhân người dùng cụ thể nên không phải lúc nào cũng chỉ ra vấn đề trong iframe.

Hãy xem phần Bảo mật và quyền riêng tư trong nội dung giải thích để biết thêm thông tin chi tiết về những điều cần cân nhắc về bảo mật và quyền riêng tư.

Lý do chặn

Như chúng tôi đã đề cập trước đó, có nhiều lý do khác nhau có thể khiến việc chặn xảy ra:

Sau đây là ví dụ về một số lý do phổ biến nhất khiến bfcache không thể sử dụng được:

  • unload-listener: trang đăng ký một trình xử lý unload, giúp ngăn chặn việc sử dụng bfcache trong một số trình duyệt nhất định. Hãy xem bài viết Huỷ bỏ sự kiện huỷ tải để biết thêm thông tin.
  • response-cache-control-no-store: Trang sử dụng no-store làm giá trị cache-control.
  • related-active-contents: Trang đã được mở từ một trang khác (sử dụng "thẻ trùng lặp") vẫn còn tham chiếu đến trang này.

Ý kiến phản hồi

Nhóm Chromium muốn tìm hiểu về trải nghiệm của bạn với API notRestoredReasons bfcache.

Cho chúng tôi biết về thiết kế API

Có điều gì về API không hoạt động như bạn mong đợi không? Hay có phương thức hoặc thuộc tính nào bị thiếu để triển khai ý tưởng không? Bạn có câu hỏi hoặc nhận xét về mô hình bảo mật này? Báo cáo vấn đề về thông số kỹ thuật trên kho lưu trữ GitHub tương ứng hoặc thêm ý kiến của bạn về vấn đề hiện có.

Báo cáo sự cố về triển khai

Bạn có phát hiện lỗi trong quá trình triển khai Chromium không? Hay cách triển khai có khác với thông số kỹ thuật không? Báo cáo lỗi trên công cụ theo dõi lỗi của chúng tôi. Hãy nhớ cung cấp càng nhiều chi tiết càng tốt, các hướng dẫn đơn giản để tái tạo và chỉ định thành phần là UI > Browser > Navigation > BFCache. Glitch rất hữu ích khi chia sẻ các bản dựng lại nhanh chóng và dễ dàng.

Hiện thông tin hỗ trợ về API này

Bạn có định dùng API notRestoredReasons bfcache không? Sự hỗ trợ công khai của bạn giúp nhóm Chromium ưu tiên các tính năng, đồng thời cho các nhà cung cấp trình duyệt khác thấy được tầm quan trọng của việc hỗ trợ các tính năng đó.

Gửi một bài đăng đến @ChromiumDev kèm theo hashtag #NotRestoredReasons và cho chúng tôi biết bạn đang sử dụng hashtag này ở đâu và bằng cách nào.

Các đường liên kết hữu ích