Hỗ trợ trình duyệt
Nhóm Chrome đã khôi phục tính năng kết xuất trước toàn bộ các trang trong tương lai mà người dùng có thể chuyển đến.
Lịch sử ngắn gọn về tính năng kết xuất trước
Trước đây, Chrome hỗ trợ gợi ý tài nguyên <link rel="prerender" href="/next-page">
, tuy nhiên, tính năng này không được hỗ trợ rộng rãi ngoài Chrome và không phải là một API rõ ràng.
Tính năng kết xuất trước cũ này sử dụng gợi ý rel=prerender
liên kết đã ngừng hoạt động và thay vào đó là tính năng Tìm nạp trước NoState. Tính năng này tìm nạp các tài nguyên mà trang trong tương lai cần, nhưng không kết xuất trước trang đầy đủ cũng như không thực thi JavaScript. Tính năng Tìm nạp trước NoState giúp cải thiện hiệu suất trang bằng cách cải thiện quá trình tải tài nguyên, nhưng sẽ không tải trang ngay lập tức như tính năng kết xuất trước đầy đủ.
Nhóm Chrome hiện đã đưa tính năng kết xuất trước toàn bộ trở lại Chrome. Để tránh các vấn đề phức tạp với cách sử dụng hiện tại và để cho phép mở rộng tính năng kết xuất trước trong tương lai, cơ chế kết xuất trước mới này sẽ không sử dụng cú pháp <link rel="prerender"...>
. Cú pháp này vẫn được giữ nguyên cho tính năng Tìm nạp trước NoState, với mục đích ngừng sử dụng cú pháp này vào một thời điểm nào đó trong tương lai.
Trang được kết xuất trước như thế nào?
Bạn có thể kết xuất trước một trang theo một trong 4 cách, tất cả đều nhằm mục đích giúp thao tác điều hướng nhanh hơn:
- Khi bạn nhập một URL vào thanh địa chỉ của Chrome (còn gọi là "omnibox"), Chrome có thể tự động kết xuất trước trang cho bạn nếu có độ tin cậy cao rằng bạn sẽ truy cập vào trang đó, dựa trên nhật ký duyệt web trước đây của bạn.
- Khi bạn sử dụng thanh dấu trang, Chrome có thể tự động kết xuất trước trang cho bạn khi bạn giữ con trỏ trên một trong các nút dấu trang.
- Khi bạn nhập một cụm từ tìm kiếm vào thanh địa chỉ của Chrome, Chrome có thể tự động kết xuất trước trang kết quả tìm kiếm khi được công cụ tìm kiếm hướng dẫn.
- Các trang web có thể sử dụng API Quy tắc dự đoán để cho Chrome biết những trang cần kết xuất trước theo phương thức lập trình. Phương thức này thay thế những gì
<link rel="prerender"...>
từng làm và cho phép các trang web chủ động kết xuất trước một trang dựa trên các quy tắc suy đoán trên trang. Các thẻ này có thể tồn tại tĩnh trên các trang hoặc được JavaScript chèn động khi chủ sở hữu trang thấy phù hợp.
Trong mỗi trường hợp này, tính năng kết xuất trước sẽ hoạt động như thể trang đã được mở trong một thẻ nền không hiển thị, sau đó được "kích hoạt" bằng cách thay thế thẻ nền trước bằng trang đã kết xuất trước đó. Nếu một trang được kích hoạt trước khi hiển thị trước hoàn toàn, thì trạng thái hiện tại của trang đó là "nền trước" và tiếp tục tải, tức là bạn vẫn có thể bắt đầu tốt.
Khi trang được kết xuất trước được mở ở trạng thái ẩn, một số API gây ra hành vi xâm phạm (ví dụ: lời nhắc) sẽ không được kích hoạt ở trạng thái này mà bị trì hoãn cho đến khi trang được kích hoạt. Trong một số ít trường hợp chưa thể thực hiện việc này, tính năng kết xuất trước sẽ bị huỷ. Nhóm Chrome đang nỗ lực cung cấp các lý do huỷ kết xuất trước dưới dạng API, đồng thời cải thiện các tính năng của DevTools để giúp xác định các trường hợp hiếm gặp đó dễ dàng hơn.
Tác động của tính năng kết xuất trước
Tính năng kết xuất trước cho phép tải trang gần như tức thì như trong video sau:
Trang web mẫu đã là một trang web nhanh, nhưng ngay cả với trang web này, bạn vẫn có thể thấy cách tính năng kết xuất trước cải thiện trải nghiệm người dùng. Do đó, điều này cũng có thể tác động trực tiếp đến Chỉ số quan trọng chính của trang web của trang web, với LCP gần bằng 0, giảm CLS (vì mọi CLS tải đều xảy ra trước chế độ xem ban đầu) và cải thiện INP (vì quá trình tải phải hoàn tất trước khi người dùng tương tác).
Ngay cả khi một trang kích hoạt trước khi tải xong, việc bắt đầu tải trang trước sẽ cải thiện trải nghiệm tải. Khi một đường liên kết được kích hoạt trong khi quá trình kết xuất trước vẫn đang diễn ra, trang kết xuất trước sẽ chuyển sang khung chính và tiếp tục tải.
Tuy nhiên, tính năng kết xuất trước sẽ sử dụng thêm bộ nhớ và băng thông mạng. Hãy cẩn thận để không kết xuất trước quá nhiều, gây tốn tài nguyên của người dùng. Chỉ kết xuất trước khi có nhiều khả năng người dùng sẽ chuyển đến trang đó.
Hãy xem phần Đo lường hiệu suất để biết thêm thông tin về cách đo lường tác động thực tế đến hiệu suất trong số liệu phân tích của bạn.
Xem nội dung gợi ý trên thanh địa chỉ của Chrome
Đối với trường hợp sử dụng đầu tiên, bạn có thể xem nội dung dự đoán của Chrome về URL trong trang chrome://predictors
:
Đường màu xanh lục cho biết có đủ độ tin cậy để kích hoạt tính năng kết xuất trước. Trong ví dụ này, việc nhập "s" sẽ mang lại độ tin cậy hợp lý (màu hổ phách), nhưng sau khi bạn nhập "sh", Chrome sẽ có đủ độ tin cậy để cho rằng bạn gần như luôn điều hướng đến https://sheets.google.com
.
Ảnh chụp màn hình này được chụp trong một phiên bản Chrome tương đối mới và lọc ra các dự đoán có độ tin cậy bằng 0. Tuy nhiên, nếu xem các trình dự đoán của riêng mình, bạn có thể thấy nhiều mục hơn đáng kể và có thể cần nhiều ký tự hơn để đạt được mức độ tin cậy đủ cao.
Những yếu tố dự đoán này cũng là yếu tố tạo ra các lựa chọn đề xuất trên thanh địa chỉ mà bạn có thể đã nhận thấy:
Chrome sẽ liên tục cập nhật các thuật toán dự đoán dựa trên nội dung bạn nhập và lựa chọn.
- Đối với mức độ tin cậy lớn hơn 50% (hiển thị bằng màu hổ phách), Chrome chủ động kết nối trước với miền nhưng không hiển thị trước trang.
- Nếu mức độ tin cậy lớn hơn 80% (hiển thị bằng màu xanh lục), Chrome sẽ kết xuất trước URL.
Speculation Rules API
Đối với tuỳ chọn hiển thị trước API Quy tắc suy đoán, nhà phát triển web có thể chèn hướng dẫn JSON vào các trang của họ để thông báo cho trình duyệt về những URL cần hiển thị trước:
<script type="speculationrules">
{
"prerender": [
{
"urls": ["next.html", "next2.html"]
}
]
}
</script>
Hoặc theo quy tắc tài liệu (có trong Chrome 121). Quy tắc này sẽ kết xuất trước các đường liên kết có trong tài liệu dựa trên bộ chọn href
(dựa trên URL Pattern API) hoặc bộ chọn CSS:
<script type="speculationrules">
{
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/wp-admin"}},
{ "not": {"href_matches": "/*\\?*(^|&)add-to-cart=*"}},
{ "not": {"selector_matches": ".do-not-prerender"}},
{ "not": {"selector_matches": "[rel~=nofollow]"}}
]
}
}]
}
</script>
Nhóm Chrome đã chuẩn bị một Lớp học lập trình về Quy tắc suy đoán để hướng dẫn bạn cách thêm Quy tắc suy đoán vào một trang web.
Sự háo hức
Hỗ trợ trình duyệt
Chế độ cài đặt eagerness
được dùng để cho biết thời điểm kích hoạt các thông tin suy đoán, điều này đặc biệt hữu ích cho các quy tắc tài liệu:
immediate
: Chế độ cài đặt này dùng để suy đoán càng sớm càng tốt – tức là ngay khi các quy tắc suy đoán được tuân thủ.eager
: Chế độ cài đặt này hoạt động giống hệt chế độ cài đặtimmediate
, nhưng trong tương lai, chúng tôi sẽ tìm cách bố trí chế độ này vào khoảng giữaimmediate
vàmoderate
.moderate
: Chế độ cài đặt này tiến hành suy đoán nếu bạn giữ con trỏ trên một đường liên kết trong 200 mili giây (hoặc trong sự kiệnpointerdown
nếu sự kiện đó xảy ra sớm hơn và trên thiết bị di động không có sự kiệnhover
).conservative
: Chế độ cài đặt này suy đoán dựa trên sự kiện con trỏ hoặc sự kiện chạm.
eagerness
mặc định cho các quy tắc list
là immediate
. Bạn có thể sử dụng các tuỳ chọn moderate
và conservative
để giới hạn các quy tắc list
cho những URL mà người dùng tương tác với một danh sách cụ thể. Tuy nhiên, trong nhiều trường hợp, quy tắc document
có điều kiện where
thích hợp có thể phù hợp hơn.
eagerness
mặc định cho các quy tắc document
là conservative
. Vì một tài liệu có thể bao gồm nhiều URL, nên bạn cần thận trọng khi sử dụng immediate
hoặc eager
cho các quy tắc document
(xem thêm phần Giới hạn của Chrome ở phần tiếp theo).
Bạn nên sử dụng chế độ cài đặt eagerness
nào tuỳ thuộc vào trang web của bạn. Đối với một trang web tĩnh, nhẹ, việc dự đoán nhiều hơn có thể không tốn kém nhiều và có lợi cho người dùng. Các trang web có cấu trúc phức tạp hơn và tải trọng trang nặng hơn có thể muốn giảm lãng phí bằng cách dự đoán ít thường xuyên hơn cho đến khi bạn nhận được tín hiệu tích cực hơn về ý định của người dùng để hạn chế lãng phí.
Tuỳ chọn moderate
là một điểm trung gian và nhiều trang web có thể hưởng lợi từ quy tắc dự đoán sau đây. Quy tắc này sẽ kết xuất trước một đường liên kết khi giữ con trỏ trên đường liên kết trong 200 mili giây hoặc trên sự kiện pointerdown dưới dạng một cách triển khai cơ bản nhưng mạnh mẽ của các quy tắc dự đoán:
<script type="speculationrules">
{
"prerender": [{
"where": {
"href_matches": "/*"
},
"eagerness": "moderate"
}]
}
</script>
Tìm nạp trước
Bạn cũng có thể sử dụng quy tắc suy đoán để chỉ tìm nạp trước các trang mà không cần kết xuất trước toàn bộ. Đây thường là bước đầu tiên tốt trên con đường kết xuất trước:
<script type="speculationrules">
{
"prefetch": [
{
"urls": ["next.html", "next2.html"]
}
]
}
</script>
Giới hạn của Chrome
Chrome có các giới hạn để ngăn chặn việc sử dụng quá mức Speculation Rules API:
háo hức | Tìm nạp trước | Kết xuất trước |
---|---|---|
immediate /eager |
50 | 10 |
moderate /conservative |
2 (FIFO) | 2 (FIFO) |
Các chế độ cài đặt moderate
và conservative
(tuỳ thuộc vào hoạt động tương tác của người dùng) hoạt động theo cách thức Phân loại theo thứ tự đến (FIFO): sau khi đạt đến giới hạn, một dự đoán mới sẽ khiến dự đoán cũ nhất bị huỷ và thay thế bằng dự đoán mới hơn để tiết kiệm bộ nhớ. Bạn có thể kích hoạt lại một dự đoán đã bị huỷ (ví dụ: bằng cách di chuột qua đường liên kết đó một lần nữa). Thao tác này sẽ khiến URL đó được dự đoán lại, đẩy dự đoán cũ nhất ra ngoài. Trong trường hợp này, dự đoán trước đó sẽ lưu vào bộ nhớ đệm mọi tài nguyên có thể lưu vào bộ nhớ đệm trong Bộ nhớ đệm HTTP cho URL đó, vì vậy, việc dự đoán thêm một lần nữa sẽ giảm chi phí. Đó là lý do giới hạn được đặt ở ngưỡng khiêm tốn là 2. Quy tắc danh sách tĩnh không được kích hoạt bằng hành động của người dùng và do đó có giới hạn cao hơn vì trình duyệt không thể biết quy tắc nào cần thiết và khi nào cần thiết.
Giới hạn immediate
và eager
cũng là động, vì vậy, việc xoá phần tử tập lệnh URL list
sẽ tạo dung lượng bằng cách huỷ các dự đoán đã xoá đó.
Chrome cũng sẽ ngăn việc sử dụng thông tin suy đoán trong một số điều kiện nhất định, bao gồm:
- Save-Data (Tiết kiệm dữ liệu).
- Trình tiết kiệm pin khi bật và pin yếu.
- Hạn chế về bộ nhớ.
- Khi bạn tắt chế độ cài đặt "Tải trước trang" (chế độ này cũng bị các tiện ích Chrome như uBlock Origin tắt một cách rõ ràng).
- Các trang được mở trong thẻ nền.
Chrome cũng không hiển thị iframe trên các trang được kết xuất trước cho đến khi kích hoạt.
Tất cả các điều kiện này đều nhằm giảm tác động của việc suy đoán quá mức khi điều này gây bất lợi cho người dùng.
Cách đưa quy tắc suy đoán vào một trang
Bạn có thể đưa các quy tắc suy đoán vào HTML của trang theo cách tĩnh hoặc chèn động vào trang bằng JavaScript:
- Tự động đưa các quy tắc suy đoán vào: Ví dụ: một trang web tin tức hoặc blog có thể hiển thị trước bài viết mới nhất nếu đó thường là thao tác điều hướng tiếp theo của phần lớn người dùng. Ngoài ra, bạn có thể sử dụng các quy tắc tài liệu có
moderate
hoặcconservative
để suy đoán khi người dùng tương tác với các đường liên kết. - Quy tắc suy đoán được chèn động: Quy tắc này có thể dựa trên logic ứng dụng, được cá nhân hoá cho người dùng hoặc dựa trên các phương pháp phỏng đoán khác.
Những người ưu tiên chèn động dựa trên các hành động như di chuột qua hoặc nhấp vào đường liên kết (như nhiều thư viện đã thực hiện trước đây với <link rel=prefetch>
) nên xem xét các quy tắc tài liệu, vì các quy tắc này cho phép trình duyệt xử lý nhiều trường hợp sử dụng của bạn.
Bạn có thể thêm quy tắc suy đoán trong <head>
hoặc <body>
trong khung chính. Quy tắc suy đoán trong khung con không được thực thi và quy tắc suy đoán trong các trang được kết xuất trước chỉ được thực thi sau khi trang đó được kích hoạt.
Tiêu đề HTTP Speculation-Rules
Bạn cũng có thể phân phối các quy tắc suy đoán bằng cách sử dụng tiêu đề HTTP Speculation-Rules
, thay vì đưa trực tiếp các quy tắc đó vào HTML của tài liệu. Điều này cho phép CDN triển khai dễ dàng hơn mà không cần tự thay đổi nội dung tài liệu.
Tiêu đề HTTP Speculation-Rules
được trả về cùng với tài liệu và trỏ đến vị trí của tệp JSON chứa các quy tắc suy đoán:
Speculation-Rules: "/speculationrules.json"
Tài nguyên này phải sử dụng đúng loại MIME và nếu là tài nguyên đa nguồn gốc, thì phải vượt qua quy trình kiểm tra CORS.
Content-Type: application/speculationrules+json
Access-Control-Allow-Origin: *
Nếu muốn sử dụng URL tương đối, bạn nên đưa khoá "relative_to": "document"
vào quy tắc dự đoán. Nếu không, URL tương đối sẽ tương ứng với URL của tệp JSON chứa quy tắc suy đoán. Điều này có thể đặc biệt hữu ích nếu bạn cần chọn một số hoặc tất cả các đường liên kết cùng nguồn gốc.
Quy tắc suy đoán và SPA
Quy tắc dự đoán chỉ được hỗ trợ cho các thao tác điều hướng toàn trang do trình duyệt quản lý, chứ không hỗ trợ cho Ứng dụng trang đơn (SPA) hoặc trang vỏ ứng dụng. Các cấu trúc này không sử dụng tính năng tìm nạp tài liệu, mà thay vào đó tạo API hoặc tìm nạp một phần dữ liệu hoặc trang. Sau đó, các dữ liệu hoặc trang này được xử lý và hiển thị trong trang hiện tại. Ứng dụng có thể tìm nạp trước dữ liệu cần thiết cho những lượt "chuyển hướng mềm" này bên ngoài các quy tắc dự đoán, nhưng không thể kết xuất trước.
Bạn có thể sử dụng Quy tắc suy đoán để kết xuất trước chính ứng dụng từ một trang trước đó. Điều này có thể giúp bù đắp một số chi phí tải ban đầu bổ sung mà một số SPA có. Tuy nhiên, bạn không thể kết xuất trước các thay đổi về tuyến đường trong ứng dụng.
Gỡ lỗi quy tắc suy đoán
Hãy xem bài đăng chuyên sâu về cách gỡ lỗi quy tắc suy đoán để biết các tính năng mới của Chrome DevTools hỗ trợ xem và gỡ lỗi API mới này.
Nhiều quy tắc suy đoán
Bạn cũng có thể thêm nhiều quy tắc suy đoán vào cùng một trang và các quy tắc này sẽ được thêm vào các quy tắc hiện có. Do đó, tất cả các cách sau đây đều dẫn đến việc kết xuất trước cả one.html
và two.html
:
Danh sách URL:
<script type="speculationrules">
{
"prerender": [
{
"urls": ["one.html", "two.html"]
}
]
}
</script>
Nhiều tập lệnh speculationrules
:
<script type="speculationrules">
{
"prerender": [
{
"urls": ["one.html"]
}
]
}
</script>
<script type="speculationrules">
{
"prerender": [
{
"urls": ["two.html"]
}
]
}
</script>
Nhiều danh sách trong một tập hợp speculationrules
<script type="speculationrules">
{
"prerender": [
{
"urls": ["one.html"]
},
{
"urls": ["two.html"]
}
]
}
</script>
Hỗ trợ của No-Vary-Search
Khi tải trước hoặc kết xuất trước một trang, một số tham số URL nhất định (về mặt kỹ thuật được gọi là tham số tìm kiếm) có thể không quan trọng đối với trang mà máy chủ thực sự phân phối và chỉ được JavaScript phía máy khách sử dụng.
Ví dụ: tham số UTM được Google Analytics sử dụng để đo lường chiến dịch, nhưng thường không dẫn đến việc các trang khác nhau được phân phối từ máy chủ. Điều này có nghĩa là page1.html?utm_content=123
và page1.html?utm_content=456
sẽ phân phối cùng một trang từ máy chủ, vì vậy, bạn có thể sử dụng lại cùng một trang từ bộ nhớ đệm.
Tương tự, các ứng dụng có thể sử dụng các tham số URL khác chỉ được xử lý phía máy khách.
Đề xuất No-Vary-Search (Không thay đổi nội dung tìm kiếm) cho phép máy chủ chỉ định các tham số không làm thay đổi tài nguyên được phân phối, do đó cho phép trình duyệt sử dụng lại các phiên bản đã lưu vào bộ nhớ đệm trước đó của một tài liệu chỉ khác nhau về các tham số này. Tính năng này được hỗ trợ trong Chrome (và các trình duyệt dựa trên Chromium) để dự đoán điều hướng tải trước (mặc dù chúng tôi cũng đang tìm cách hỗ trợ tính năng này cho tính năng kết xuất trước).
Quy tắc suy đoán hỗ trợ việc sử dụng expects_no_vary_search
để cho biết vị trí dự kiến sẽ trả về tiêu đề HTTP No-Vary-Search
. Việc này có thể giúp tránh được các lượt tải xuống không cần thiết.
<script type="speculationrules">
{
"prefetch": [{
"urls": ["/products*"],
"expects_no_vary_search": "params=(\"id\")"
}]
}
</script>
<a href="/products?id=123">Product 123</a>
<a href="/products?id=124">Product 124</a>
Trong ví dụ này, HTML trang ban đầu /products
giống nhau cho cả mã sản phẩm 123
và 124
. Tuy nhiên, nội dung trang cuối cùng sẽ khác nhau dựa trên hoạt động kết xuất phía máy khách bằng JavaScript để tìm nạp dữ liệu sản phẩm bằng tham số tìm kiếm id
. Vì vậy, chúng ta sẽ tìm nạp trước URL đó và URL đó sẽ trả về một tiêu đề HTTP No-Vary-Search
cho biết trang có thể được dùng cho bất kỳ tham số tìm kiếm id
nào.
Tuy nhiên, nếu người dùng nhấp vào bất kỳ đường liên kết nào trước khi quá trình tải trước hoàn tất, thì trình duyệt có thể chưa nhận được trang /products
. Trong trường hợp này, trình duyệt không biết liệu yêu cầu có chứa tiêu đề HTTP No-Vary-Search
hay không. Sau đó, trình duyệt sẽ có lựa chọn tìm nạp lại đường liên kết hoặc đợi quá trình tìm nạp trước hoàn tất để xem đường liên kết đó có chứa tiêu đề HTTP No-Vary-Search
hay không. Chế độ cài đặt expects_no_vary_search
cho phép trình duyệt biết rằng phản hồi trang dự kiến sẽ chứa tiêu đề HTTP No-Vary-Search
và chờ quá trình tìm nạp trước đó hoàn tất.
Các quy định hạn chế về quy tắc suy đoán và các tính năng nâng cao trong tương lai
Quy tắc về hành vi phỏng đoán chỉ áp dụng cho các trang được mở trong cùng một thẻ, nhưng chúng tôi đang nỗ lực để giảm bớt quy tắc hạn chế đó.
Theo mặc định, các dự đoán chỉ được giới hạn ở các trang cùng nguồn gốc. Trang dự đoán trên cùng một trang web, trên nhiều nguồn gốc (ví dụ: https://a.example.com
có thể hiển thị trước một trang trên https://b.example.com
). Để sử dụng tính năng này, trang được dự đoán (https://b.example.com
trong ví dụ này) cần chọn sử dụng bằng cách thêm tiêu đề HTTP Supports-Loading-Mode: credentialed-prerender
, nếu không Chrome sẽ huỷ tính năng dự đoán.
Các phiên bản trong tương lai cũng có thể cho phép kết xuất trước cho các trang không phải cùng trang web, nhiều nguồn gốc miễn là không có cookie cho trang được kết xuất trước và trang được kết xuất trước chọn sử dụng tiêu đề HTTP Supports-Loading-Mode: uncredentialed-prerender
tương tự.
Các quy tắc dự đoán đã hỗ trợ tính năng tải trước trên nhiều nguồn gốc, nhưng xin nhắc lại là chỉ khi không có cookie cho miền trên nhiều nguồn gốc. Nếu người dùng đã từng truy cập vào trang web đó và có cookie, thì hoạt động suy đoán sẽ không được kích hoạt và sẽ hiển thị lỗi trong DevTools.
Do những hạn chế hiện tại đó, một mẫu có thể cải thiện trải nghiệm người dùng cho cả đường liên kết nội bộ và đường liên kết bên ngoài (nếu có thể) là kết xuất trước URL cùng nguồn gốc và cố gắng tải trước URL có nguồn gốc khác:
<script type="speculationrules">
{
"prerender": [
{
"where": { "href_matches": "/*" },
"eagerness": "moderate"
}
],
"prefetch": [
{
"where": { "not": { "href_matches": "/*" } },
"eagerness": "moderate"
}
]
}
</script>
Theo mặc định, quy tắc hạn chế để ngăn chặn hành vi suy đoán trên nhiều nguồn gốc đối với các đường liên kết trên nhiều nguồn gốc là cần thiết để bảo mật. Đây là điểm cải tiến so với <link rel="prefetch">
cho các đích đến nhiều nguồn gốc. Các đích đến này cũng sẽ không gửi cookie nhưng vẫn cố gắng tải trước. Điều này sẽ dẫn đến việc tải trước bị lãng phí và cần được gửi lại hoặc tệ hơn là tải trang không chính xác.
Quy tắc dự đoán không được hỗ trợ cho tính năng tải trước cho các trang do worker dịch vụ kiểm soát. Chúng tôi đang nỗ lực để hỗ trợ tính năng này. Hãy theo dõi bài viết Hỗ trợ vấn đề về worker để biết thông tin cập nhật. Tính năng kết xuất trước được hỗ trợ cho các trang do trình chạy dịch vụ kiểm soát.
Phát hiện tính năng hỗ trợ API Quy tắc suy đoán
Bạn có thể phát hiện tính năng hỗ trợ Speculation Rules API bằng các bước kiểm tra HTML tiêu chuẩn:
if (HTMLScriptElement.supports && HTMLScriptElement.supports('speculationrules')) {
console.log('Your browser supports the Speculation Rules API.');
}
Thêm linh động các quy tắc suy đoán thông qua JavaScript
Đây là ví dụ về cách thêm quy tắc đầu cơ prerender
bằng JavaScript:
if (HTMLScriptElement.supports &&
HTMLScriptElement.supports('speculationrules')) {
const specScript = document.createElement('script');
specScript.type = 'speculationrules';
specRules = {
prerender: [
{
urls: ['/next.html'],
},
],
};
specScript.textContent = JSON.stringify(specRules);
console.log('added speculation rules to: next.html');
document.body.append(specScript);
}
Bạn có thể xem bản minh hoạ về tính năng kết xuất trước của Speculation Rules API, sử dụng tính năng chèn JavaScript, trên trang minh hoạ kết xuất trước này.
Việc chèn trực tiếp phần tử <script type = "speculationrules">
vào DOM bằng innerHTML
sẽ không đăng ký các quy tắc suy đoán vì lý do bảo mật và bạn phải thêm phần tử này như đã trình bày trước đó. Tuy nhiên, nội dung được chèn động bằng innerHTML
chứa các đường liên kết mới sẽ được các quy tắc hiện có trên trang chọn.
Tương tự, việc chỉnh sửa trực tiếp bảng điều khiển Elements (Phần tử) trong Công cụ cho nhà phát triển của Chrome để thêm phần tử <script type = "speculationrules">
sẽ không đăng ký các quy tắc suy đoán. Thay vào đó, bạn phải chạy tập lệnh để thêm phần tử này vào DOM một cách linh động từ Console để chèn các quy tắc.
Thêm quy tắc suy đoán thông qua trình quản lý thẻ
Để thêm các quy tắc suy đoán bằng trình quản lý thẻ như Trình quản lý thẻ của Google (GTM), bạn phải chèn các quy tắc này thông qua JavaScript, thay vì thêm trực tiếp phần tử <script type = "speculationrules">
thông qua GTM vì những lý do tương tự như đã đề cập trước đó:
Xin lưu ý rằng ví dụ này sử dụng var
vì GTM không hỗ trợ const
.
Huỷ quy tắc suy đoán
Việc xoá các quy tắc suy đoán sẽ dẫn đến việc huỷ kết xuất trước, nhưng tại thời điểm này, tài nguyên có thể đã được sử dụng để bắt đầu kết xuất trước. Vì vậy, bạn không nên kết xuất trước nếu có khả năng cần huỷ kết xuất trước.
Quy tắc về thông tin suy đoán và Chính sách bảo mật nội dung
Vì các quy tắc suy đoán sử dụng phần tử <script>
, mặc dù chỉ chứa JSON, nhưng các quy tắc này cần được đưa vào script-src
Content-Security-Policy nếu trang web sử dụng quy tắc này – bằng cách sử dụng hàm băm hoặc số chỉ dùng một lần.
Bạn có thể thêm một inline-speculation-rules
mới vào script-src
để cho phép các phần tử <script type="speculationrules">
được chèn từ tập lệnh băm hoặc số chỉ dùng một lần được hỗ trợ. Phương thức này không hỗ trợ các quy tắc có trong HTML ban đầu, vì vậy, các quy tắc cần được JavaScript chèn vào cho những trang web sử dụng CSP nghiêm ngặt.
Phát hiện và tắt tính năng kết xuất trước
Tính năng kết xuất trước thường mang lại trải nghiệm tích cực cho người dùng vì cho phép kết xuất trang nhanh chóng, thường là ngay lập tức. Điều này mang lại lợi ích cho cả người dùng và chủ sở hữu trang web, vì các trang được kết xuất trước mang lại trải nghiệm người dùng tốt hơn mà nếu không thì khó có thể đạt được.
Tuy nhiên, có thể có trường hợp bạn không muốn hiển thị trước trang, chẳng hạn như khi các trang thay đổi trạng thái – dựa trên yêu cầu ban đầu hoặc dựa trên JavaScript thực thi trên trang.
Bật và tắt tính năng kết xuất trước trong Chrome
Tính năng kết xuất trước chỉ được bật cho những người dùng Chrome có chế độ cài đặt "Tải trước trang" trong chrome://settings/performance/
. Ngoài ra, tính năng kết xuất trước cũng bị tắt trên các thiết bị có dung lượng bộ nhớ thấp hoặc nếu hệ điều hành đang ở chế độ Tiết kiệm dữ liệu hoặc Trình tiết kiệm pin. Hãy xem phần Giới hạn của Chrome.
Phát hiện và tắt tính năng kết xuất trước phía máy chủ
Các trang được kết xuất trước sẽ được gửi bằng tiêu đề HTTP Sec-Purpose
:
Sec-Purpose: prefetch;prerender
Các trang được tìm nạp trước bằng Speculation Rules API sẽ chỉ đặt tiêu đề này thành prefetch
:
Sec-Purpose: prefetch
Máy chủ có thể phản hồi dựa trên tiêu đề này để ghi lại các yêu cầu dự đoán, trả về nội dung khác hoặc ngăn quá trình kết xuất trước. Nếu hệ thống trả về mã phản hồi cuối cùng không thành công (tức là không nằm trong phạm vi 200-299 sau khi chuyển hướng), thì trang sẽ không được kết xuất trước và mọi trang tìm nạp trước sẽ bị loại bỏ. Ngoài ra, xin lưu ý rằng các phản hồi 204 và 205 cũng không hợp lệ để kết xuất trước, nhưng hợp lệ để tải trước.
Nếu bạn không muốn một trang cụ thể được kết xuất trước, thì cách tốt nhất để đảm bảo điều này không xảy ra là trả về mã phản hồi không phải 2XX (chẳng hạn như 503). Tuy nhiên, để mang lại trải nghiệm tốt nhất, bạn nên cho phép kết xuất trước, nhưng trì hoãn mọi hành động chỉ nên xảy ra sau khi trang thực sự được xem, bằng cách sử dụng JavaScript.
Phát hiện tính năng kết xuất trước trong JavaScript
API document.prerendering
sẽ trả về true
trong khi trang đang kết xuất trước. Các trang có thể sử dụng thuộc tính này để ngăn chặn hoặc trì hoãn một số hoạt động nhất định trong quá trình kết xuất trước cho đến khi trang thực sự được kích hoạt.
Sau khi tài liệu được kết xuất trước được kích hoạt, activationStart
của PerformanceNavigationTiming
cũng sẽ được đặt thành một thời gian khác 0, đại diện cho khoảng thời gian giữa thời điểm bắt đầu kết xuất trước và thời điểm tài liệu thực sự được kích hoạt.
Bạn có thể có một hàm để kiểm tra các trang hiển thị trước và đã hiển thị trước như sau:
function pagePrerendered() {
return (
document.prerendering ||
self.performance?.getEntriesByType?.('navigation')[0]?.activationStart > 0
);
}
Cách dễ nhất để xem liệu một trang đã được kết xuất trước (một phần hoặc toàn bộ) hay chưa là mở DevTools sau khi trang được kích hoạt và nhập performance.getEntriesByType('navigation')[0].activationStart
vào bảng điều khiển. Nếu hệ thống trả về một giá trị khác 0, thì bạn biết rằng trang đã được kết xuất trước:
Khi người dùng xem trang, trang sẽ được kích hoạt và sự kiện prerenderingchange
sẽ được gửi trên document
. Sau đó, bạn có thể sử dụng sự kiện này để bật các hoạt động trước đây sẽ được bắt đầu theo mặc định khi tải trang nhưng bạn muốn trì hoãn cho đến khi người dùng thực sự xem trang.
Khi sử dụng các API này, JavaScript ở phía giao diện người dùng có thể phát hiện và hành động phù hợp với các trang được kết xuất trước.
Tác động đến số liệu phân tích
Analytics được dùng để đo lường mức sử dụng trang web, chẳng hạn như sử dụng Google Analytics để đo lường lượt xem trang và sự kiện. Hoặc bằng cách đo lường các chỉ số hiệu suất của trang bằng tính năng Giám sát người dùng thực (RUM).
Bạn chỉ nên kết xuất trước các trang khi có nhiều khả năng người dùng sẽ tải trang đó. Đó là lý do các tuỳ chọn kết xuất trước của thanh địa chỉ Chrome chỉ xảy ra khi có xác suất cao như vậy (trên 80% thời gian).
Tuy nhiên, đặc biệt là khi sử dụng API Quy tắc suy đoán, các trang được kết xuất trước có thể ảnh hưởng đến số liệu phân tích và chủ sở hữu trang web có thể cần thêm mã bổ sung để chỉ bật số liệu phân tích cho các trang được kết xuất trước khi kích hoạt, vì không phải nhà cung cấp dịch vụ phân tích nào cũng có thể làm việc này theo mặc định.
Bạn có thể thực hiện việc này bằng cách sử dụng Promise
để chờ sự kiện prerenderingchange
nếu tài liệu đang hiển thị trước hoặc phân giải ngay lập tức nếu tài liệu hiện đang:
// Set up a promise for when the page is activated,
// which is needed for prerendered pages.
const whenActivated = new Promise((resolve) => {
if (document.prerendering) {
document.addEventListener('prerenderingchange', resolve, {once: true});
} else {
resolve();
}
});
async function initAnalytics() {
await whenActivated;
// Initialise your analytics
}
initAnalytics();
Một phương pháp thay thế là trì hoãn các hoạt động phân tích cho đến khi trang hiển thị lần đầu tiên. Phương pháp này sẽ áp dụng cho cả trường hợp kết xuất trước và khi các thẻ được mở ở chế độ nền (ví dụ: bằng cách nhấp chuột phải và mở trong thẻ mới):
// Set up a promise for when the page is first made visible
const whenFirstVisible = new Promise((resolve) => {
if (document.hidden) {
document.addEventListener('visibilitychange', resolve, {once: true});
} else {
resolve();
}
});
async function initAnalytics() {
await whenFirstVisible;
// Initialise your analytics
}
initAnalytics();
Mặc dù điều này có thể phù hợp với các trường hợp sử dụng phân tích và tương tự, nhưng trong các trường hợp khác, bạn có thể muốn tải thêm nội dung cho các trường hợp đó. Do đó, bạn có thể muốn sử dụng document.prerendering
và prerenderingchange
để nhắm mục tiêu cụ thể đến các trang hiển thị trước.
Giữ lại nội dung khác trong quá trình kết xuất trước
Bạn có thể sử dụng các API đã thảo luận trước đó để giữ lại nội dung khác trong giai đoạn kết xuất trước. Đây có thể là các phần cụ thể của JavaScript hoặc toàn bộ phần tử tập lệnh mà bạn không muốn chạy trong giai đoạn kết xuất trước.
Ví dụ: với tập lệnh sau:
<script src="https://example.com/app/script.js" async></script>
Bạn có thể thay đổi thành phần này thành một phần tử tập lệnh được chèn động chỉ chèn dựa trên hàm whenActivated
trước đó:
async function addScript(scriptUrl) {
await whenActivated;
const script = document.createElement('script');
script.src = 'scriptUrl';
document.body.appendChild(script);
}
addScript('https://example.com/app/script.js');
Điều này có thể hữu ích để giữ lại các tập lệnh riêng biệt có chứa số liệu phân tích hoặc hiển thị nội dung dựa trên trạng thái hoặc các biến khác có thể thay đổi trong khoảng thời gian của một lượt truy cập. Ví dụ: các đề xuất, trạng thái đăng nhập hoặc biểu tượng giỏ hàng đều có thể bị giữ lại để đảm bảo thông tin mới nhất được trình bày.
Mặc dù điều này có thể xảy ra thường xuyên hơn khi sử dụng tính năng kết xuất trước, nhưng các điều kiện này cũng đúng đối với các trang được tải trong các thẻ nền đã đề cập trước đó (vì vậy, bạn có thể sử dụng hàm whenFirstVisible
thay vì whenActivated
).
Trong nhiều trường hợp, trạng thái cũng nên được kiểm tra trên các thay đổi chung của visibilitychange
– ví dụ: khi quay lại một trang đã ở chế độ nền, mọi bộ đếm giỏ hàng đều phải được cập nhật bằng số lượng mặt hàng mới nhất trong giỏ hàng. Vì vậy, đây không phải là vấn đề cụ thể về tính năng kết xuất trước, mà tính năng này chỉ làm cho vấn đề hiện có trở nên rõ ràng hơn.
Một cách mà Chrome giảm thiểu một số nhu cầu gói tập lệnh hoặc hàm theo cách thủ công là một số API nhất định bị giữ lại như đã đề cập trước đó và các iframe của bên thứ ba không được hiển thị, vì vậy, chỉ nội dung ở trên cùng mới cần được giữ lại theo cách thủ công.
Đo lường hiệu suất
Để đo lường các chỉ số hiệu suất, công cụ phân tích nên xem xét liệu có nên đo lường các chỉ số này dựa trên thời gian kích hoạt thay vì thời gian tải trang mà API trình duyệt sẽ báo cáo hay không.
Đối với Chỉ số quan trọng chính của trang web do Chrome đo lường thông qua Báo cáo trải nghiệm người dùng của Chrome, các chỉ số này nhằm đo lường trải nghiệm người dùng. Vì vậy, các chỉ số này được đo lường dựa trên thời gian kích hoạt. Ví dụ: điều này thường dẫn đến LCP là 0 giây, cho thấy đây là cách hiệu quả để cải thiện Các chỉ số quan trọng về trang web.
Kể từ phiên bản 3.1.0, thư viện web-vitals
đã được cập nhật để xử lý các thao tác điều hướng được kết xuất trước theo cách tương tự như cách Chrome đo lường Các chỉ số quan trọng về trang web. Phiên bản này cũng gắn cờ các thao tác điều hướng được kết xuất trước cho các chỉ số đó trong thuộc tính Metric.navigationType
nếu trang được kết xuất trước toàn bộ hoặc một phần.
Đo lường lượt kết xuất trước
Bạn có thể biết liệu một trang có được kết xuất trước hay không bằng cách xem mục activationStart
khác 0 của PerformanceNavigationTiming
. Sau đó, bạn có thể ghi lại thông tin này bằng Phương diện tuỳ chỉnh hoặc phương thức tương tự khi ghi lại số lượt xem trang, ví dụ: sử dụng hàm pagePrerendered
được mô tả trước đó:
// Set Custom Dimension for Prerender status
gtag('set', { 'dimension1': pagePrerendered() });
// Initialise GA - including sending page view by default
gtag('config', 'G-12345678-1');
Điều này sẽ cho phép số liệu phân tích của bạn cho biết số lượng thành phần điều hướng được kết xuất trước so với các loại thành phần điều hướng khác, đồng thời cho phép bạn liên kết mọi chỉ số hiệu suất hoặc chỉ số kinh doanh với các loại thành phần điều hướng này. Trang tải nhanh hơn đồng nghĩa với việc người dùng hài lòng hơn, điều này thường có thể tác động thực sự đến các chỉ số kinh doanh như các nghiên cứu điển hình của chúng tôi cho thấy.
Khi đo lường tác động của việc kết xuất trước trang đối với hoạt động kinh doanh của bạn đối với các thao tác điều hướng tức thì, bạn có thể quyết định xem có nên đầu tư nhiều hơn vào việc sử dụng công nghệ này để cho phép kết xuất trước nhiều thao tác điều hướng hơn hay không, hoặc để điều tra lý do các trang không được kết xuất trước.
Đo lường tỷ lệ truy cập
Ngoài việc đo lường tác động của những trang được truy cập sau khi kết thúc quá trình kết xuất trước, bạn cũng cần đo lường những trang được kết xuất trước và không được truy cập sau đó. Điều này có thể cho thấy bạn đang kết xuất trước quá nhiều và sử dụng tài nguyên có giá trị của người dùng mà không mang lại nhiều lợi ích.
Bạn có thể đo lường điều này bằng cách kích hoạt một sự kiện phân tích khi chèn các quy tắc dự đoán (sau khi kiểm tra xem trình duyệt có hỗ trợ tính năng kết xuất trước bằng HTMLScriptElement.supports('speculationrules')
hay không) để cho biết rằng tính năng kết xuất trước đã được yêu cầu. (Xin lưu ý rằng việc yêu cầu kết xuất trước không có nghĩa là quá trình kết xuất trước đã bắt đầu hoặc hoàn tất, như đã lưu ý trước đó, kết xuất trước là một gợi ý cho trình duyệt và trình duyệt có thể chọn không kết xuất trước các trang dựa trên chế độ cài đặt của người dùng, mức sử dụng bộ nhớ hiện tại hoặc các phương pháp phỏng đoán khác.)
Sau đó, bạn có thể so sánh số lượng sự kiện này với số lượt xem trang thực tế được kết xuất trước. Hoặc bạn có thể kích hoạt một sự kiện khác khi kích hoạt nếu điều đó giúp bạn dễ dàng so sánh hơn.
Sau đó, bạn có thể ước tính "tỷ lệ thành công của lượt truy cập" bằng cách xem sự khác biệt giữa hai con số này. Đối với các trang mà bạn đang sử dụng Speculation Rules API để kết xuất trước, bạn có thể điều chỉnh các quy tắc cho phù hợp để đảm bảo tỷ lệ truy cập cao nhằm duy trì sự cân bằng giữa việc sử dụng tài nguyên của người dùng để giúp họ và việc sử dụng tài nguyên một cách không cần thiết.
Xin lưu ý rằng một số hoạt động kết xuất trước có thể đang diễn ra do thanh địa chỉ kết xuất trước chứ không chỉ do các quy tắc dự đoán của bạn. Bạn có thể kiểm tra document.referrer
(sẽ để trống cho thao tác điều hướng trên thanh địa chỉ, bao gồm cả thao tác điều hướng trên thanh địa chỉ được kết xuất trước) nếu muốn phân biệt các thao tác này.
Hãy nhớ xem xét cả những trang không có bản xem trước, vì điều đó có thể cho thấy rằng các trang này không đủ điều kiện để xem trước, ngay cả từ thanh địa chỉ. Điều đó có thể có nghĩa là bạn không được hưởng lợi từ tính năng nâng cao hiệu suất này. Nhóm Chrome đang tìm cách bổ sung công cụ để kiểm tra điều kiện sử dụng tính năng Tạo trước, có thể tương tự như công cụ kiểm thử bfcache, đồng thời có thể thêm một API để cho biết lý do tính năng tạo trước không thành công.
Tác động đến tiện ích
Hãy xem bài đăng chuyên sâu về Tiện ích Chrome: Mở rộng API để hỗ trợ tính năng Điều hướng tức thì. Bài đăng này trình bày chi tiết một số điểm cần cân nhắc khác mà tác giả tiện ích có thể cần phải xem xét đối với các trang được kết xuất trước.
Phản hồi
Nhóm Chrome đang tích cực phát triển tính năng kết xuất trước và có nhiều kế hoạch mở rộng phạm vi của những tính năng đã có trong bản phát hành Chrome 108. Chúng tôi hoan nghênh mọi ý kiến phản hồi trên kho lưu trữ GitHub hoặc thông qua công cụ theo dõi lỗi của chúng tôi. Chúng tôi rất mong được nghe và chia sẻ các nghiên cứu điển hình về API mới thú vị này.
Đường liên kết có liên quan
- Lớp học lập trình về quy tắc suy đoán
- Gỡ lỗi các quy tắc suy đoán
- Giới thiệu tính năng Tìm nạp trước NoState
- Quy cách của Speculation Rules API
- Kho lưu trữ GitHub về suy đoán điều hướng
- Tiện ích Chrome: Mở rộng API để hỗ trợ tính năng Điều hướng tức thì
Lời cảm ơn
Hình thu nhỏ của Marc-Olivier Jodoin trên Unsplash