Tóm tắt: API Extensions đã được cập nhật để hỗ trợ bộ nhớ đệm cho thao tác tiến/lùi, tải trước điều hướng. Xem bên dưới để biết chi tiết.
Chrome đang nỗ lực để giúp điều hướng trở nên nhanh chóng. Điều hướng tức thì các công nghệ như Bộ nhớ đệm cho thao tác tiến/lùi (đã giao trên máy tính theo Chrome 96) và Quy tắc suy đoán (đã vận chuyển trong Chrome 103) cải thiện cả hoạt động diễn ra trong tương lai và sau này của bạn. Trong bài đăng này, chúng ta sẽ khám phá các bản cập nhật đối với trình duyệt các API tiện ích để phù hợp với các quy trình mới này.
Tìm hiểu các loại trang
Trước khi giới thiệu về Bộ nhớ đệm cho thao tác tiến/lùi và kết xuất trước, riêng chỉ có một trang đang hoạt động. Đây luôn là mục người dùng nhìn thấy. Nếu một người dùng quay lại trang trước, trang đang hoạt động sẽ bị huỷ bỏ (Trang B) và trang trước đó trong lịch sử sẽ được tạo lại hoàn toàn (Trang A). Các tiện ích không cần phải lo lắng về việc trang nào thuộc vòng đời vì chỉ có một mục cho thẻ, trạng thái hoạt động/hiển thị.
Với bộ nhớ đệm cho thao tác tiến/lùi và kết xuất trước, bạn sẽ không còn gặp phải một đối tác mối quan hệ giữa thẻ và trang. Giờ đây, mỗi thẻ lại lưu trữ nhiều trang và các trang chuyển đổi giữa các trạng thái thay vì bị huỷ và tạo lại.
Ví dụ: một trang có thể bắt đầu hoạt động dưới dạng một trang được kết xuất trước (không hiển thị), chuyển sang một trang đang hoạt động (hiển thị) khi người dùng nhấp vào một liên kết, sau đó được lưu trữ trong Bộ nhớ đệm cho thao tác tiến/lùi (không hiển thị) khi người dùng chuyển đến một trang khác, tất cả đều không bao giờ bị huỷ. Phần sau của bài viết này chúng ta sẽ xem xét các thuộc tính mới được hiển thị để giúp tiện ích hiểu rõ đang đặt trang trạng thái nào.
Lưu ý rằng một thẻ có thể có một loạt trang được kết xuất trước (không chỉ một trang), một trang duy nhất đang hoạt động (hiển thị) và một loạt các trang được lưu vào bộ nhớ đệm cho thao tác tiến/lùi.
Có gì thay đổi đối với các nhà phát triển tiện ích?
Mã khung hình == 0
Trong Chromium, chúng tôi gọi khung trên cùng/chính là khung ngoài cùng.
Tác giả tiện ích giả định frameId
của khung ngoài cùng là 0 (phương pháp hay nhất trước đây) có thể có vấn đề.
Vì một thẻ hiện có thể có nhiều khung ngoài cùng (được kết xuất trước và lưu vào bộ nhớ đệm
trang), giả định rằng có duy nhất một lớp ngoài cùng
khung cho một thẻ là không chính xác. frameId == 0 sẽ vẫn tiếp tục đại diện
khung ngoài cùng của trang hoạt động, nhưng các khung ngoài cùng của
Các trang other trong cùng một thẻ sẽ khác 0. Một trường mới frameType có
để khắc phục sự cố này. Hãy xem phần "Làm cách nào để xác định một khung hình có phải là khung ngoài cùng không?"
của bài đăng này.
Vòng đời của khung so với tài liệu
Một khái niệm khác gây rắc rối với tiện ích là vòng đời của khung. Khung lưu trữ một tài liệu (được liên kết với một URL đã cam kết). Tài liệu có thể thay đổi (giả sử bằng cách điều hướng) nhưng frameId thì không, vì vậy tài liệu rất khó để liên tưởng một điều gì đó đã xảy ra trong một tài liệu cụ thể với chỉ frameIds. Chúng tôi sẽ ra mắt khái niệm về documentId là giá trị nhận dạng duy nhất cho từng tài liệu. Nếu một khung được điều hướng và mở ra một tài liệu mới mà giá trị nhận dạng sẽ thay đổi. Trường này hữu ích cho xác định thời điểm các trang thay đổi trạng thái vòng đời (giữa kết xuất trước/đang hoạt động/được lưu vào bộ nhớ đệm) vì nó vẫn không thay đổi.
Sự kiện điều hướng trên web
Các sự kiện trong không gian tên chrome.webNavigation
có thể kích hoạt nhiều lần trên
cùng một trang tuỳ thuộc vào vòng đời của trang đó. Xem
"Làm cách nào để biết trang này đang ở trong vòng đời nào?"
và "Làm cách nào để xác định thời điểm một trang chuyển đổi?".
Làm cách nào để biết trang này đang ở trong vòng đời nào?
DocumentLifecycle
đã được thêm vào một số API tiện ích trong đó frameId
trước đây. Nếu loại DocumentLifecycle xuất hiện trong một sự kiện
(chẳng hạn như onCommitted),
giá trị của nó là trạng thái mà sự kiện được tạo. Bạn luôn có thể truy vấn
thông tin từ WebNavigation getFrame()
và getAllFrames()
nhưng sử dụng giá trị từ sự kiện luôn được ưu tiên. Nếu bạn sử dụng
một trong hai phương thức sẽ nhận biết được trạng thái của khung hình có thể thay đổi giữa thời điểm sự kiện
được tạo và khi các hứa hẹn trả về bằng cả hai phương pháp được giải quyết.
DocumentLifecycle
có các giá trị sau:
"prerenderinch : Hiện không được hiển thị cho người dùng nhưng đang chuẩn bị để có thể hiển thị cho người dùng."active": Hiển thị cho người dùng."cached": Được lưu trữ trong bộ nhớ đệm cho thao tác tiến/lùi."pending_deletion": Tài liệu đang bị huỷ.
Làm cách nào để xác định một khung hình có phải là khung ngoài cùng không?
Các tiện ích trước đây có thể đã kiểm tra xem frameId == 0 có xác định hay không
liệu sự kiện xảy ra có phải là từ khung ngoài cùng hay không. Có nhiều trang
trong một thẻ, chúng ta hiện có nhiều khung hình ngoài cùng, do đó, định nghĩa frameId
là vấn đề. Bạn sẽ không bao giờ nhận được các sự kiện về thao tác tiến/lùi được lưu vào bộ nhớ đệm
khung. Tuy nhiên, đối với các khung được kết xuất trước, frameId sẽ là
khác 0 đối với khung ngoài cùng. Vì vậy, việc sử dụng frameId == 0 làm tín hiệu cho
việc xác định đó có phải là khung ngoài cùng hay không là không chính xác.
Để giúp giải quyết vấn đề này, chúng tôi đã giới thiệu một loại mới có tên là
FrameType
vì vậy, giờ đây bạn có thể dễ dàng xác định khung hình có thực sự là khung ngoài cùng hay không.
FrameType có các giá trị sau:
"outermost_frame": Thường được gọi là khung trên cùng. Lưu ý rằng có rất nhiều yếu tố. Ví dụ: nếu bạn có một kết xuất trước và lưu vào bộ nhớ đệm mỗi trang có một khung ngoài cùng có thể được gọi là khung trên cùng."fenced_frame": Được dành riêng để sử dụng trong tương lai."sub_frame": Thường là iframe.
Chúng ta có thể kết hợp DocumentLifecycle với FrameType và xác định xem một khung có phải là
khung ngoài cùng hoạt động. Ví dụ: tab.documentLifecycle === “active” && frameType === “outermost_frame”
Làm thế nào để khắc phục vấn đề về thời gian sử dụng liên quan đến khung hình?
Như chúng ta đã nói ở trên, khung lưu trữ tài liệu và khung đó có thể điều hướng đến một
tài liệu nhưng frameId sẽ không thay đổi. Điều này sẽ gây ra vấn đề khi bạn
nhận một sự kiện chỉ với frameId. Nếu bạn Tra cứu URL
của khung, nó có thể khác với khi sự kiện xảy ra, điều này được gọi là
thời gian sử dụng.
Để giải quyết vấn đề này, chúng tôi đã ra mắt documentId
(và parentDocumentId).
Phương thức webNavigation.getFrame()
phương thức hiện khiến frameId không bắt buộc nếu documentId được cung cấp. Chiến lược phát hành đĩa đơn
documentId sẽ thay đổi bất cứ khi nào một khung được điều hướng.
Làm cách nào để xác định thời điểm chuyển đổi một trang?
Có các tín hiệu rõ ràng để xác định thời điểm một trang chuyển đổi giữa các trạng thái.
Hãy cùng xem các sự kiện WebNavigation.
Trong lần điều hướng đầu tiên trên một trang bất kỳ, bạn sẽ thấy bốn sự kiện theo thứ tự
được liệt kê bên dưới. Lưu ý rằng bốn sự kiện này có thể xảy ra với
Trạng thái DocumentLifecycle là "prerender" hoặc "active".
onBeforeNavigate
onCommitted
onDOMContentLoaded
onCompleted
Điều này được minh hoạ trong sơ đồ dưới đây, cho thấy sự thay đổi của documentId
vào "xyz" khi trang được kết xuất trước trở thành trang đang hoạt động.
documentId thay đổi khi trang được kết xuất trước trở thành
trang đang hoạt động.Khi một trang chuyển đổi từ Bộ nhớ đệm cho thao tác tiến/lùi hoặc kết xuất trước sang
trạng thái đang hoạt động sẽ có thêm 3 sự kiện nữa (nhưng với DocumentLifecyle
là "active").
onBeforeNavigate
onCommitted
onCompleted
documentId sẽ giữ nguyên như trong các sự kiện gốc. Đây là
minh hoạ ở trên khi documentId == xyz kích hoạt. Lưu ý rằng
cùng một sự kiện điều hướng kích hoạt, ngoại trừ onDOMContentLoaded
vì trang đã được tải.
Nếu bạn có bất kỳ nhận xét hoặc câu hỏi nào, vui lòng đặt câu hỏi trên phần mở rộng về chromium nhóm.