Ngày phát hành: 7 tháng 3 năm 2025
Speculation Rules API giúp người dùng hưởng lợi từ việc tăng hiệu suất bằng cách tìm nạp trước hoặc kết xuất trước các thao tác điều hướng trang trong tương lai để mang lại các thao tác điều hướng trang nhanh hơn hoặc thậm chí là tức thì.
API này được thiết kế đặc biệt để dễ dàng triển khai, nhưng có một số điểm cần cân nhắc mà các trang web phức tạp cần xem xét trước khi sử dụng. Hướng dẫn này giúp chủ sở hữu trang web hiểu được những điều cần cân nhắc này.
Lập kế hoạch
Trước khi triển khai quy tắc suy đoán, bạn nên cân nhắc cách triển khai API (vì có một số lựa chọn) cũng như chi phí suy đoán (để hướng dẫn bạn về những trang cần suy đoán).
Quyết định cách triển khai quy tắc suy đoán
Một trong những quyết định đầu tiên bạn cần đưa ra là cách triển khai các quy tắc về hành vi đầu cơ trên trang web của mình, vì có nhiều phương pháp bạn có thể sử dụng:
- Trực tiếp trong HTML của trang
- Sử dụng JavaScript
- Sử dụng tiêu đề HTTP
Cuối cùng, mọi phương thức đều có cùng một hiệu quả, nhưng có thể có những ưu điểm về khả năng dễ triển khai và linh hoạt.
Các trang web nên chọn phương án phù hợp nhất với mình và thậm chí có thể kết hợp các phương án này nếu cần. Ngoài ra, bạn có thể triển khai các tính năng này bằng trình bổ trợ (chẳng hạn như trình bổ trợ Tải dữ liệu dự đoán cho WordPress) hoặc thư viện hoặc nền tảng có thể giúp bạn lựa chọn, nhưng bạn vẫn nên biết các lựa chọn có sẵn.
Thêm trực tiếp các quy tắc suy đoán vào HTML của trang
Bạn có thể triển khai Quy tắc về nội dung suy đoán ngay trên trang bằng cách thêm phần tử <script type="speculationrules"> vào HTML. Bạn có thể thêm thuộc tính này tại thời điểm tạo bản dựng cho các trang web tĩnh bằng cách sử dụng mẫu hoặc tại thời điểm chạy bằng máy chủ khi trang được yêu cầu. Các worker cạnh thậm chí có thể chèn các thẻ này vào HTML (mặc dù phương thức tiêu đề HTTP được thảo luận ở phần sau của hướng dẫn này có thể dễ dàng hơn).
Điều này cho phép bạn đưa các quy tắc tĩnh vào toàn bộ trang web, nhưng quy tắc tài liệu vẫn có thể linh động bằng cách cho phép bạn chọn URL để hiển thị từ trang bằng cách sử dụng các quy tắc được kích hoạt bởi các lớp CSS:
<script type="speculationrules">
{
"prerender": [{
"where": { "selector_matches": ".prerender" }
}],
"prefetch": [{
"where": { "selector_matches": ".prefetch" }
}]
}
</script>
Tập lệnh trước đó sẽ kết xuất trước các đường liên kết có lớp prerender và tương tự như vậy, hãy tải trước khi đường liên kết có lớp prefetch. Điều này cho phép nhà phát triển đưa các lớp này vào HTML để kích hoạt các dự đoán.
Ngoài việc đưa các đường liên kết của các lớp này vào HTML ban đầu của trang, các đường liên kết cũng sẽ được dự đoán nếu ứng dụng của bạn thêm các lớp đó một cách linh động, cho phép ứng dụng kích hoạt (và xoá) các dự đoán khi cần. Việc này có thể đơn giản hơn so với việc tạo hoặc xoá các quy tắc đầu cơ cụ thể hơn. Bạn cũng có thể thêm nhiều quy tắc suy đoán trên mỗi trang nếu muốn có một quy tắc cơ sở được áp dụng cho hầu hết trang web và(các) quy tắc dành riêng cho trang.
Ngoài ra, nếu bạn cần sử dụng các quy tắc suy đoán cụ thể hơn, thì các quy tắc dành riêng cho trang hoặc mẫu có thể cho phép các quy tắc khác nhau cho một số trang hoặc loại trang nhất định.
Cuối cùng, các trang được kết xuất phía máy chủ cũng có thể có các quy tắc linh động hơn dựa trên bất kỳ thông tin nào có sẵn cho máy chủ, chẳng hạn như thông tin phân tích cho trang đó hoặc hành trình phổ biến của người dùng đối với một số trang nhất định.
Thêm quy tắc suy đoán bằng JavaScript
Một cách thay thế để đưa các quy tắc vào tập lệnh trên trang là chèn các quy tắc đó bằng JavaScript. Điều này có thể giúp bạn ít phải cập nhật mẫu trang hơn. Ví dụ: việc trình quản lý thẻ chèn các quy tắc có thể là một cách nhanh chóng để triển khai các quy tắc về hành vi đầu cơ (và cũng cho phép tắt các quy tắc đó một cách nhanh chóng nếu cần).
Tuỳ chọn này cũng cho phép các quy tắc phía máy khách linh động dựa trên cách người dùng tương tác với trang. Ví dụ: nếu người dùng thêm một mặt hàng vào giỏ hàng, bạn có thể kết xuất trước trang thanh toán. Ngoài ra, bạn có thể sử dụng tính năng này để kích hoạt các dự đoán dựa trên một số điều kiện nhất định. Mặc dù API bao gồm chế độ cài đặt mức độ háo hức cho phép các quy tắc cơ bản dựa trên hoạt động tương tác, nhưng JavaScript cho phép nhà phát triển sử dụng logic của riêng họ để quyết định thời điểm và(các) trang để dự đoán.
Như đã đề cập trước đó, một phương pháp thay thế để chèn các quy tắc mới là có một quy tắc tài liệu cơ sở trên trang và có các quy tắc tài liệu kích hoạt JavaScript bằng cách thêm các lớp thích hợp vào các đường liên kết khiến chúng khớp với quy tắc.
Thêm quy tắc suy đoán bằng tiêu đề HTTP
Lựa chọn cuối cùng dành cho nhà phát triển là đưa các quy tắc vào bằng tiêu đề HTTP:
Speculation-Rules: "/speculationrules.json"
Có một số yêu cầu bổ sung về cách phân phối và sử dụng tài nguyên quy tắc (/speculationrules.json trong ví dụ này).
Tuỳ chọn này cho phép CDN triển khai dễ dàng hơn mà không cần thay đổi nội dung tài liệu. Điều này có nghĩa là bạn không thể thay đổi linh động các quy tắc suy đoán bằng JavaScript. Tuy nhiên, các quy tắc tài liệu có trình kích hoạt bộ chọn CSS vẫn có thể cho phép thay đổi linh động, ví dụ: bằng cách xoá lớp prerender khỏi một đường liên kết.
Tương tự như tuỳ chọn JavaScript, việc triển khai các quy tắc suy đoán bằng tiêu đề HTTP cho phép triển khai các quy tắc này độc lập với nội dung của trang web. Điều này có thể giúp bạn dễ dàng thêm và xoá các quy tắc mà không cần tạo lại toàn bộ trang web.
Cân nhắc các tác động về chi phí
Trước khi triển khai các quy tắc về hành vi đầu cơ, bạn nên dành chút thời gian để cân nhắc tác động của chi phí đối với cả người dùng và trang web của bạn thông qua API này. Chi phí bao gồm băng thông (chi phí cho cả người dùng và trang web!) và chi phí xử lý (ở cả phía máy khách và máy chủ).
Cân nhắc chi phí cho người dùng
Tải theo phỏng đoán có nghĩa là dự đoán một cách có căn cứ về nơi người dùng có thể chuyển đến nội dung mới. Tuy nhiên, nếu thao tác điều hướng đó không diễn ra, thì bạn có thể đã lãng phí tài nguyên. Đó là lý do bạn nên cân nhắc tác động đối với người dùng, cụ thể là:
- Băng thông bổ sung được dùng để tải các thao tác điều hướng trong tương lai xuống, đặc biệt là trên thiết bị di động, nơi băng thông có thể bị hạn chế hơn.
- Chi phí xử lý bổ sung để hiển thị các trang đó khi sử dụng tính năng kết xuất trước.
Khi dự đoán hoàn toàn chính xác, bạn sẽ không phải trả thêm chi phí vì khách truy cập sẽ truy cập vào các trang đó tiếp theo, chỉ khác là các chi phí đó được tính trước. Tuy nhiên, không thể dự đoán tương lai một cách chính xác tuyệt đối. Chiến lược đầu cơ càng mạnh thì nguy cơ lãng phí càng cao.
Chrome đã cân nhắc kỹ vấn đề này và API có một số tính năng có nghĩa là chi phí thấp hơn nhiều so với bạn nghĩ. Cụ thể, bằng cách sử dụng lại bộ nhớ đệm HTTP và không tải iframe trên nhiều nguồn gốc, chi phí kết xuất trước một thao tác điều hướng trên cùng một trang web thường nhỏ hơn đáng kể so với một trang đầy đủ không có tài nguyên được lưu vào bộ nhớ đệm, giúp giảm chi phí tải dự đoán so với dự kiến.
Tuy nhiên, ngay cả khi có các biện pháp bảo vệ này, các trang web vẫn nên cân nhắc kỹ những trang cần dự đoán và chi phí của người dùng đối với những dự đoán đó. Các đề xuất phù hợp để tải trước bao gồm những đề xuất có thể được dự đoán một cách hợp lý với độ tin cậy cao (có thể dựa trên số liệu phân tích hoặc hành trình phổ biến của người dùng) và khi chi phí thấp (ví dụ: các trang ít nội dung đa dạng thức hơn).
Bạn cũng nên cân nhắc việc trì hoãn JavaScript cho đến khi kích hoạt. Tương tự như việc tải nội dung từng phần cho đến khi cần, tính năng này có thể giúp giảm chi phí kết xuất trước, nhưng mang lại trải nghiệm người dùng tốt hơn nhiều. Với các giao dịch đầu cơ rẻ hơn, bạn có thể cảm thấy thoải mái hơn khi đầu cơ thường xuyên hoặc hào hứng hơn.
Nếu không thể, bạn nên sử dụng chiến lược ít hung hăng hơn bằng cách sử dụng các quy tắc về mức độ háo hức ở mức trung bình hoặc bảo thủ. Ngoài ra, bạn có thể sử dụng tính năng tải trước. Tính năng này có chi phí thấp hơn đáng kể so với tính năng kết xuất trước khi độ tin cậy thấp, sau đó nâng cấp lên tính năng kết xuất trước đầy đủ nếu độ tin cậy tăng lên (ví dụ: khi người dùng di chuột qua một đường liên kết hoặc thực sự nhấp vào đường liên kết đó).
Cân nhắc thêm tải phụ trợ
Ngoài việc xem xét chi phí phát sinh từ người dùng, chủ sở hữu trang web cũng nên xem xét chi phí cơ sở hạ tầng của riêng họ. Nếu mỗi trang dẫn đến 2, 3 hoặc thậm chí nhiều lượt tải trang hơn, thì chi phí phụ trợ có thể tăng lên khi sử dụng API này.
Việc đảm bảo các trang và tài nguyên của bạn có thể lưu vào bộ nhớ đệm sẽ làm giảm đáng kể lượng tải gốc và do đó giảm rủi ro tổng thể. Khi kết hợp với CDN, máy chủ gốc của bạn sẽ phải chịu tải bổ sung ở mức tối thiểu, mặc dù bạn cần cân nhắc mọi khoản chi phí tăng lên liên quan đến CDN.
Bạn cũng có thể dùng máy chủ hoặc CDN để kiểm soát kết quả suy đoán do tiêu đề HTTP có mục đích bảo mật xác định. Ví dụ: Sản phẩm Speed Brain của Cloudflare chỉ cho phép các nội dung dự đoán đã được lưu vào bộ nhớ đệm tại máy chủ biên của CDN và sẽ không gửi yêu cầu trở lại nguồn gốc.
Tuy nhiên, vì tải dự đoán thường được dùng để tải trang cùng nguồn gốc, nên người dùng sẽ đã chia sẻ tài nguyên trong bộ nhớ đệm của trình duyệt (giả sử chúng có thể lưu vào bộ nhớ đệm ngay từ đầu). Vì vậy, một lần tải dự đoán thường không tốn kém như một lần tải trang đầy đủ.
Tìm sự cân bằng giữa việc suy đoán quá nhiều hoặc quá ít
Để khai thác tối đa API Quy tắc suy đoán, bạn cần tìm sự cân bằng giữa việc suy đoán quá nhiều (tức là khi chi phí được trả không cần thiết và suy đoán không được sử dụng) và quá thận trọng (quá ít hoặc quá muộn để nhận được ít lợi ích).
Khi chi phí thấp (ví dụ: các trang nhỏ, được tạo tĩnh được lưu vào bộ nhớ đệm trên các nút cạnh CDN), bạn có thể áp dụng các dự đoán tích cực hơn.
Tuy nhiên, đối với các trang lớn hơn, phong phú hơn mà có thể không lưu được vào bộ nhớ đệm ở CDN biên, bạn cần phải cẩn thận hơn. Tương tự như vậy, các trang tốn nhiều tài nguyên có thể sử dụng hết băng thông mạng hoặc công suất xử lý, điều này có thể ảnh hưởng tiêu cực đến trang hiện tại. Mục đích của API là cải thiện hiệu suất, vì vậy, việc hồi quy hiệu suất chắc chắn không phải là điều chúng ta muốn! Đây là một lý do khác để giữ cho số trang được kết xuất trước không quá một hoặc hai trang (cũng lưu ý rằng Chrome giới hạn ở hai hoặc mười trang được kết xuất trước cùng một lúc tuỳ thuộc vào mức độ ưu tiên).
Các bước triển khai quy tắc suy đoán
Sau khi quyết định cách triển khai quy tắc suy đoán, bạn cần lên kế hoạch về nội dung suy đoán và cách triển khai nội dung này. Các trang web đơn giản hơn, chẳng hạn như blog cá nhân tĩnh, có thể chuyển thẳng đến chế độ kết xuất trước đầy đủ của một số trang nhất định, nhưng các trang web phức tạp hơn có thêm nhiều yếu tố phức tạp cần cân nhắc.
Bắt đầu với tính năng tải trước
Tính năng tìm nạp trước thường tương đối an toàn để triển khai cho hầu hết các trang web và đây là phương pháp ban đầu mà nhiều người sử dụng, bao gồm cả các bản phát hành trên quy mô lớn như Cloudflare và WordPress.
Các vấn đề chính cần lưu ý là liệu việc tải trước URL có gây ra bất kỳ thay đổi trạng thái và chi phí phía máy chủ nào hay không, đặc biệt là đối với các trang không thể lưu vào bộ nhớ đệm. Tốt nhất là các thay đổi về trạng thái (ví dụ: tải trước trang /logout) không được triển khai dưới dạng đường liên kết GET, nhưng đáng tiếc là điều này không hiếm trên web.
Bạn có thể loại trừ cụ thể các URL như vậy khỏi quy tắc:
<script type="speculationrules">
{
"prefetch": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Bạn có thể giới hạn tính năng tìm nạp trước ở các thao tác điều hướng phổ biến từ trang này sang trang khác hoặc cho tất cả các đường liên kết cùng nguồn gốc khi di chuột hoặc nhấp bằng cách sử dụng chế độ cài đặt eagerness của moderate hoặc conservative. Chế độ cài đặt conservative có rủi ro thấp nhất, nhưng cũng có phần thưởng tiềm năng thấp nhất. Nếu bắt đầu từ đó, hãy cố gắng nâng cấp lên ít nhất là moderate, nhưng tốt nhất là nâng cấp lên eager để có được nhiều lợi ích về hiệu suất hơn (rồi nâng cấp lên prerender nếu cần).
Hoạt động kết xuất trước có rủi ro thấp
Dữ liệu suy đoán tìm nạp trước dễ triển khai hơn, nhưng lợi ích hiệu suất tối đa cho API là tính năng kết xuất trước. Điều này có thể cần thêm một số cân nhắc khi trang không được truy cập ngay sau khi dự đoán (chúng ta sẽ đề cập đến vấn đề này trong phần tiếp theo), nhưng với tính năng kết xuất trước moderate hoặc conservative, trong đó thao tác điều hướng có thể xảy ra ngay sau đó, có thể là bước tiếp theo có mức độ rủi ro tương đối thấp.
<script type="speculationrules">
{
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Tải trước các trang phổ biến để cải thiện tính năng kết xuất trước không cần thiết
Một chiến thuật phổ biến là tải trước một số ít trang tiếp theo thường được truy cập khi tải bằng chế độ cài đặt eager (bằng cách chỉ định các trang đó trong danh sách URL hoặc sử dụng selector_matches), sau đó kết xuất trước bằng chế độ cài đặt moderate. Vì quá trình tải trước HTML có thể đã hoàn tất vào thời điểm di chuột lên đường liên kết, nên việc này sẽ giúp tăng hiệu suất so với việc chỉ kết xuất trước khi di chuột mà không tải trước.
<script type="speculationrules">
{
"prefetch": [{
"urls": ["next.html", "next2.html"],
"eagerness": "eager"
}],
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Kết xuất trước sớm hơn
Mặc dù các quy tắc tài liệu moderate cho phép sử dụng API với mức độ rủi ro tương đối thấp và dễ triển khai, nhưng thường thì thời gian này không đủ để kết xuất trước toàn bộ. Để đạt được tính năng điều hướng tức thì mà API này cho phép, bạn có thể cần phải làm nhiều hơn thế và hiển thị trước các trang một cách nhanh chóng hơn.
Bạn có thể thực hiện việc này bằng một danh sách URL tĩnh (như ví dụ về tải trước trước đó) hoặc bằng selector_matches xác định một số ít URL (tốt nhất là một hoặc hai trang), với các quy tắc tài liệu áp dụng cho các URL khác:
<script type="speculationrules">
{
"prerender": [
{
"where": {
"selector_matches": : ".prerender"
},
"eagerness": "eager",
},
{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}
]
}
</script>
Điều này có thể yêu cầu phân tích lưu lượng truy cập để có cơ hội tốt nhất dự đoán chính xác thao tác điều hướng tiếp theo. Việc hiểu rõ hành trình thông thường của khách hàng trên trang web cũng có thể giúp bạn xác định những nội dung phù hợp để tải trước.
Việc chuyển sang tính năng kết xuất trước háo hức hơn cũng có thể dẫn đến nhiều vấn đề cần cân nhắc hơn về phân tích, quảng cáo và JavaScript, cũng như nhu cầu cập nhật trang được kết xuất trước hoặc thậm chí là huỷ hoặc làm mới thông tin dự đoán về các thay đổi trạng thái.
Analytics, quảng cáo và JavaScript
Khi sử dụng tính năng kết xuất trước, các trang web phức tạp hơn cũng phải xem xét tác động đến số liệu phân tích. Bạn thường không muốn ghi lại lượt xem trang (hoặc quảng cáo) khi trang được dự đoán và chỉ khi dự đoán được kích hoạt.
Một số nhà cung cấp dịch vụ phân tích (chẳng hạn như Google Analytics) và nhà cung cấp quảng cáo (chẳng hạn như Thẻ nhà xuất bản của Google) đã hỗ trợ các quy tắc suy đoán và sẽ không ghi lại lượt xem cho đến khi trang được kích hoạt. Tuy nhiên, bạn có thể cần cân nhắc thêm về các nhà cung cấp khác hoặc các công cụ phân tích tuỳ chỉnh mà bạn đã triển khai.
Bạn có thể thêm các bước kiểm tra vào JavaScript để ngăn việc thực thi các đoạn mã cụ thể cho đến khi các trang được kích hoạt hoặc hiển thị, thậm chí gói toàn bộ phần tử <script> trong các bước kiểm tra như vậy. Khi các trang sử dụng trình quản lý thẻ để chèn các tập lệnh như vậy, bạn có thể giải quyết tất cả các tập lệnh này cùng một lúc bằng cách trì hoãn chính tập lệnh trình quản lý thẻ.
Tương tự, trình quản lý sự đồng ý là một cơ hội để trì hoãn các tập lệnh của bên thứ ba cho đến khi kích hoạt. Google đã làm việc với nhiều nền tảng trình quản lý sự đồng ý để giúp các nền tảng này nhận biết được tính năng hiển thị trước. Chúng tôi rất sẵn lòng hỗ trợ những người khác muốn làm như vậy. PubTech là một trong những công ty như vậy, cho phép nhà phát triển chọn chạy hoặc chặn JavaScript trong quá trình kết xuất trước.
Đối với mã ứng dụng, bạn cũng có thể thêm một thay đổi để trì hoãn việc thực thi mã cho đến khi kích hoạt, đặc biệt là khi trang không yêu cầu mã JavaScript để hiển thị. Đây là lựa chọn nhanh và an toàn hơn, nhưng đồng nghĩa với việc tất cả mã sẽ chạy cùng một lúc khi kích hoạt. Điều này có thể dẫn đến nhiều công việc tại thời điểm kích hoạt, từ đó ảnh hưởng đến INP, đặc biệt là khi trang có vẻ như đã tải đầy đủ và sẵn sàng để tương tác.
Ngoài ra, nếu có nội dung nào phụ thuộc vào JavaScript (ví dụ: nội dung hiển thị phía máy khách), thì việc trì hoãn việc này sẽ làm giảm tác động tích cực của tính năng kết xuất trước đối với LCP và CLS. Một phương pháp có mục tiêu hơn để cho phép nhiều JavaScript chạy hơn trong giai đoạn kết xuất trước sẽ mang lại trải nghiệm tốt hơn, nhưng có thể ít quan trọng hơn để triển khai.
Ban đầu, bạn có thể bắt đầu bằng cách trì hoãn hoàn toàn nhiều thẻ tập lệnh cho các trang web phức tạp hơn. Tuy nhiên, để khai thác tối đa API, mục tiêu cuối cùng là cho phép nhiều JavaScript chạy trong quá trình kết xuất trước.
Những trang web có vấn đề về số liệu phân tích hoặc quảng cáo cũng có thể muốn bắt đầu với tính năng tải trước, trong đó những vấn đề này ít đáng lo ngại hơn, trong khi họ cân nhắc những việc cần làm để hỗ trợ tính năng kết xuất trước.
Cập nhật thông tin dự đoán kết xuất trước
Khi kết xuất trước các trang trước khi điều hướng, có nguy cơ trang được kết xuất trước sẽ trở nên lỗi thời. Ví dụ: trang được kết xuất trước của một trang web thương mại điện tử có thể bao gồm một giỏ hàng thanh toán – một giỏ hàng đầy đủ các mặt hàng hoặc thậm chí chỉ là một bộ đếm cho biết số lượng mặt hàng trong giỏ hàng trên các trang khác. Nếu thêm nhiều mặt hàng vào giỏ hàng rồi chuyển đến một trang được kết xuất trước, người dùng sẽ thấy nhầm lẫn khi nhìn thấy trạng thái thanh toán cũ.
Đây không phải là vấn đề mới và khi người dùng mở nhiều thẻ trong trình duyệt, họ cũng gặp phải vấn đề tương tự. Tuy nhiên, với các trang được kết xuất trước, điều này có nhiều khả năng xảy ra và khó dự đoán hơn vì người dùng không chủ ý bắt đầu quá trình kết xuất trước.
Broadcast Channel API (API kênh truyền tin) là một cách để cho phép một trang trong trình duyệt truyền tin cập nhật như thế này đến các trang khác. Việc này cũng sẽ giải quyết vấn đề nhiều thẻ. Các trang được kết xuất trước có thể nghe thông báo truyền tin, mặc dù không thể gửi thông báo truyền tin của riêng mình cho đến khi được kích hoạt.
Ngoài ra, các trang được kết xuất trước có thể nhận thông tin cập nhật bằng máy chủ (sử dụng kết nối fetch() định kỳ hoặc kết nối WebSocket), nhưng có thể bị trễ trong quá trình cập nhật.
Huỷ hoặc làm mới thông tin suy đoán trước khi kết xuất
Bạn nên cập nhật trang được kết xuất trước để tiếp tục sử dụng trang được kết xuất trước mà không gây nhầm lẫn cho người dùng. Nếu không thể, bạn có thể huỷ các dự đoán.
Bạn cũng có thể sử dụng tính năng này để tuân thủ các giới hạn của Chrome nếu các trang web muốn kết xuất trước các trang khác có nhiều khả năng được truy cập hơn.
Để huỷ các dự đoán, bạn cần xoá các quy tắc dự đoán khỏi trang hoặc xoá các lớp hoặc tiêu chí so khớp khác nếu sử dụng phương pháp đó. Ngoài ra, trang được suy đoán có thể gọi window.close() nếu phát hiện trang đó không còn hiện tại. Tuy nhiên, nếu trang có thể phát hiện điều này, thì tốt hơn hết bạn nên cập nhật trạng thái của trang để cập nhật lại.
Bạn cũng có thể chèn lại các quy tắc này (hoặc tiêu chí so khớp) để các trang có thể được kết xuất trước lại (mặc dù một lần nữa, việc cập nhật trang hiện có thường là lựa chọn tốt hơn vì ít lãng phí hơn). Sau khi xoá các quy tắc suy đoán, bạn phải hoàn tất quá trình chèn lại trong một tác vụ vi mô mới trở đi để cho phép trình duyệt nhận thấy các lượt xoá và huỷ các lượt suy đoán. Một phương pháp để xoá và loại bỏ tất cả tập lệnh quy tắc đầu cơ được trình bày trong ví dụ sau:
async function refreshSpeculations() {
const speculationScripts = document.querySelectorAll('script[type="speculationrules"]');
for (const speculationScript of speculationScripts) {
// Get the current rules as JSON text
const ruleSet = speculationScript.textContent;
// Remove the existing script to reset prerendering
speculationScript.remove();
// Await for a microtask before re-inserting.
await Promise.resolve();
// Reinsert rule in a new speculation rules script
const newScript = document.createElement('script');
newScript.type = 'speculationrules';
newScript.textContent = ruleSet;
console.log(newScript);
// Append the new script back to the document
document.body.appendChild(newScript);
}
}
Việc xoá quy tắc sẽ huỷ các trình giả định (hoặc tải trước) hiện có, nhưng việc chèn lại quy tắc sẽ chỉ dự đoán các quy tắc tức thì hoặc vội vàng (bao gồm cả quy tắc danh sách URL sử dụng chế độ mặc định là tức thì). Tuy nhiên, các dự đoán ở mức độ trung bình hoặc thận trọng sẽ bị xoá nhưng không tự động được kích hoạt lại cho đến khi người dùng tương tác lại với đường liên kết.
Tuỳ chọn làm mới này không chỉ dành cho các quy tắc được chèn JavaScript. Bạn cũng có thể xoá hoặc thay đổi các quy tắc tĩnh có trong HTML theo cách tương tự, vì đây là một thay đổi DOM chuẩn. Bạn không thể xoá các quy tắc dự đoán HTTP, nhưng có thể xoá và thêm lại các tiêu chí so khớp (ví dụ: lớp prerender) bằng JavaScript.
Chrome cũng đang xem xét việc thêm tính năng hỗ trợ Clear-Site-Header để cho phép các phản hồi của máy chủ huỷ tính năng kết xuất trước (ví dụ: khi có yêu cầu cập nhật giỏ hàng).
Đo lường tác động
Sau khi triển khai các quy tắc dự đoán, bạn nên đo lường mức độ thành công chứ không chỉ giả định rằng tốc độ sẽ tự động nhanh hơn. Như đã đề cập trước đó, việc dự đoán quá mức thực sự có thể gây ra sự hồi quy về hiệu suất nếu ứng dụng hoặc máy chủ bị quá tải.
Khi triển khai bằng nhiều bước (tìm nạp trước, kết xuất trước có rủi ro thấp rồi kết xuất trước sớm), bạn nên đo lường từng bước.
Cách đo lường mức độ thành công
Các quy tắc dự đoán sẽ tác động tích cực đến các chỉ số hiệu suất chính như LCP (và có thể cả CLS và INP), nhưng những chỉ số này có thể không rõ ràng trong các chỉ số tổng thể ở cấp trang web. Điều này là do các trang web có thể chủ yếu bao gồm các loại điều hướng khác (ví dụ: trang đích) hoặc vì các thao tác điều hướng cùng nguồn đã đủ nhanh nên ngay cả khi cải thiện đáng kể các thao tác đó, điều này có thể không ảnh hưởng đến các chỉ số phân vị thứ 75 như được báo cáo trong Báo cáo trải nghiệm người dùng trên Chrome (CrUX).
Bạn có thể sử dụng các loại thao tác điều hướng trang trong CrUX để kiểm tra tỷ lệ phần trăm thao tác điều hướng là navigate_cache hoặc prerender và liệu tỷ lệ đó có tăng lên theo thời gian hay không. Tuy nhiên, để phân tích chi tiết, bạn có thể cần sử dụng tính năng Theo dõi người dùng thực để phân đoạn dữ liệu thành các thao tác điều hướng được suy đoán để xem các thao tác đó nhanh hơn bao nhiêu so với các thao tác điều hướng khác.
Cách đo lường mức sử dụng và mức lãng phí
Một yếu tố quan trọng khác cần cân nhắc là đo lường xem bạn có đang dự đoán chính xác các trang hay không. Điều này vừa giúp tránh lãng phí, vừa đảm bảo bạn đang nhắm đến những trang phù hợp nhất để hưởng lợi từ API này.
Rất tiếc, trang khởi tạo các nội dung suy đoán không thể trực tiếp xem trạng thái của các lượt thử suy đoán. Ngoài ra, không thể giả định rằng các lượt thử nghiệm đã được kích hoạt vì trình duyệt có thể giữ lại các dự đoán trong một số trường hợp nhất định. Do đó, bạn phải đo lường các chỉ số này trên chính trang. Điều này cũng yêu cầu kiểm tra hai API để xem trang có đang suy đoán hay đã suy đoán hay không:
if (document.prerendering) {
console.log("Page is prerendering");
} else if (performance.getEntriesByType("navigation")[0]?.activationStart > 0) {
console.log("Page has already prerendered");
} else {
console.log("This page load was not using prerendering");
}
Sau đó, trang này có thể ghi lại nỗ lực dự đoán vào máy chủ phụ trợ.
Một vấn đề phức tạp với số liệu phân tích là các nhà cung cấp (chẳng hạn như Google Analytics) nhận biết được tính năng kết xuất trước và bỏ qua các lệnh gọi số liệu phân tích cho đến khi trang được kích hoạt, ngay cả các lệnh gọi sự kiện riêng biệt. Do đó, người dùng Google Analytics phải sử dụng một tuỳ chọn ghi nhật ký phía máy chủ khác.
Bạn cũng có thể thực hiện việc này ở phía máy khách, trong đó mỗi trang kết xuất trước sẽ ghi lại quá trình kết xuất trước trong bộ nhớ dùng chung và trang gọi sẽ đọc nội dung này. localStorage hoạt động hiệu quả nhất vì bạn có thể đọc khi rời khỏi một trang (lưu ý rằng bạn không thể sử dụng sessionStorage vì có cách xử lý đặc biệt cho các trang được kết xuất trước). Tuy nhiên, hãy lưu ý rằng localStorage không an toàn về giao dịch và các trang khác có thể đang cập nhật thông tin này cùng một lúc nếu nhiều trang được kết xuất trước. Bản minh hoạ này sử dụng một hàm băm duy nhất và các mục riêng lẻ để tránh các vấn đề liên quan.
Kết luận
Các quy tắc dự đoán có thể giúp tăng hiệu suất đáng kể cho trang của bạn. Hướng dẫn này đưa ra lời khuyên về những điều cần cân nhắc khi triển khai API này để tránh mọi vấn đề tiềm ẩn, đồng thời khai thác tối đa API.
Việc lập kế hoạch trước khi triển khai sẽ giúp tránh phải làm lại. Đặc biệt đối với các trang web phức tạp hơn, bạn nên triển khai theo nhiều bước, bắt đầu bằng tính năng tải trước rồi chuyển sang tính năng kết xuất trước có rủi ro thấp và sau đó là tính năng kết xuất trước sớm. Cuối cùng, bạn cần đo lường những điểm cải tiến, cũng như mọi hoạt động sử dụng và lãng phí để đảm bảo bạn đang sử dụng API một cách tối ưu.