Nhóm Chrome đang nỗ lực triển khai một số bản cập nhật thú vị cho API Quy tắc suy đoán. API này dùng để cải thiện hiệu suất điều hướng bằng cách tìm nạp trước hoặc thậm chí kết xuất trước các hoạt động điều hướng trong tương lai. Tất cả những điểm cải tiến bổ sung này hiện đều có trên Chrome 122 (cùng một số tính năng có từ các phiên bản trước).
Những thay đổi này giúp việc tìm nạp trước và kết xuất trước các trang dễ dàng hơn đáng kể và ít lãng phí hơn. Chúng tôi hy vọng điều này sẽ khuyến khích việc áp dụng thêm.
Các tính năng khác
Đầu tiên là phần giải thích về các phần bổ sung mới mà chúng tôi đã thêm vào Speculation Rules API và cách sử dụng những phần bổ sung đó. Sau đó, chúng tôi sẽ cho bạn thấy một bản minh hoạ để bạn có thể thấy các bước này hoạt động.
Quy tắc về tài liệu
Trước đây, Speculation Rules API (API Quy tắc suy đoán) hoạt động bằng cách chỉ định danh sách các URL cần tìm nạp trước hoặc kết xuất trước:
<script type="speculationrules">
{
"prerender": [
{
"source": "list",
"urls": ["next.html", "next2.html"]
}
]
}
</script>
Các quy tắc suy đoán mang tính bán động trong đó các tập lệnh quy tắc suy đoán mới có thể được thêm vào và các tập lệnh cũ sẽ bị xoá để loại bỏ những suy đoán đó (lưu ý rằng việc cập nhật danh sách urls của một tập lệnh quy tắc suy đoán hiện có sẽ không kích hoạt thay đổi trong các suy đoán). Tuy nhiên, công cụ này vẫn để quyền lựa chọn URL tại trang web, bằng cách gửi chúng từ máy chủ vào thời điểm yêu cầu trang hoặc bằng cách tự động tạo danh sách này thông qua JavaScript phía máy khách.
Quy tắc danh sách vẫn là một lựa chọn cho các trường hợp sử dụng đơn giản (trong đó điều hướng tiếp theo đến từ một tập hợp nhỏ các quy tắc rõ ràng) hoặc các trường hợp sử dụng nâng cao hơn (trong đó danh sách URL được tính toán động dựa trên bất kỳ phương pháp phỏng đoán nào mà chủ sở hữu trang web muốn sử dụng rồi chèn vào trang).
Thay vào đó, chúng tôi rất vui khi được cung cấp một lựa chọn mới giúp tự động tìm đường liên kết bằng cách sử dụng quy tắc tài liệu. Tính năng này hoạt động bằng cách tìm nguồn URL từ chính tài liệu dựa trên điều kiện where. Điều này có thể dựa trên chính các liên kết:
<script type="speculationrules">
{
"prerender": [{
"source": "document",
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout/*"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Bạn cũng có thể sử dụng bộ chọn CSS thay thế hoặc kết hợp với khớp href để tìm các đường liên kết trong trang hiện tại:
<script type="speculationrules">
{
"prerender": [{
"source": "document",
"where": {
"and": [
{ "selector_matches": ".prerender" },
{ "not": {"selector_matches": ".do-not-prerender"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Điều này cho phép sử dụng một bộ quy tắc suy đoán duy nhất trên toàn bộ trang web, thay vì có các quy tắc cụ thể trên mỗi trang, giúp các trang web dễ dàng triển khai các quy tắc suy đoán hơn.
Tất nhiên, việc kết xuất trước tất cả các đường liên kết trên một trang chắc chắn sẽ gây lãng phí, vì vậy, với khả năng mới này, chúng tôi đã ra mắt chế độ cài đặt eagerness.
Háo hức
Với bất kỳ loại suy đoán nào, cũng có sự đánh đổi giữa độ chính xác, độ ghi nhớ và thời gian thực hiện. Việc kết xuất trước tất cả các đường liên kết khi tải trang có nghĩa là bạn gần như chắc chắn sẽ kết xuất trước một đường liên kết mà người dùng nhấp vào (giả sử họ nhấp vào một đường liên kết cùng trang web trên trang) và sẽ mất nhiều thời gian thực hiện nhất có thể nhưng có khả năng lãng phí băng thông rất lớn.
Mặt khác, việc chỉ kết xuất trước sau khi người dùng nhấp vào một đường liên kết sẽ giúp tránh lãng phí, nhưng sẽ giúp giảm đáng kể thời gian thực hiện. Điều này có nghĩa là khó có khả năng đã hoàn tất quá trình kết xuất trước trước khi trình duyệt chuyển sang trang đó.
Chế độ cài đặt eagerness cho phép bạn xác định thời điểm chạy suy đoán, tách riêng when để suy đoán từ URL nào sẽ thực hiện suy đoán. Chế độ cài đặt eagerness áp dụng cho cả quy tắc nguồn list và document, đồng thời có 4 chế độ cài đặt mà Chrome có các thông tin phỏng đoán sau đây:
immediate: Giá trị này dùng để suy đoán sớm nhất có thể, tức là ngay khi quan sát được các quy tắc suy đoán.eager: Nút này hiện đang hoạt động giống hệt với chế độ cài đặtimmediate, nhưng trong tương lai, chúng tôi sẽ tìm cách đặt tuỳ chọn này ở đâu đó trong khoảng từimmediateđếnmoderate.moderate: Hành động này đưa ra suy đoán nếu bạn di chuột qua một đường liên kết trong 200 mili giây (hoặc trên sự kiệnpointerdownnếu sớm hơn và trên thiết bị di động không có sự kiệnhover).conservative: Thao tác này sẽ suy đoán con trỏ hoặc thao tác chạm xuống.
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 ở những URL mà người dùng tương tác với một danh sách cụ thể. Mặc dù trong nhiều trường hợp, các 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ể chứa nhiều URL, nên bạn nên thận trọng khi sử dụng immediate hoặc eager cho quy tắc document (xem thêm phần Giới hạn của Chrome tiếp theo).
Chế độ cài đặt eagerness nào cần sử dụng sẽ tuỳ thuộc vào trang web của bạn. Đối với một trang web tĩnh rất đơn giản, việc đầu tư háo hức hơn có thể tốn ít chi phí và có lợi cho người dùng. Các trang web có kiến trúc phức tạp hơn và tải trọng trang lớn hơn có thể muốn giảm lãng phí bằng cách suy đ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 nhằm hạn chế lãng phí.
Tuỳ chọn moderate là nền tảng trung gian và nhiều trang web có thể hưởng lợi từ quy tắc suy đoán đơn giản sau đây. Quy tắc này sẽ kết xuất trước tất cả đường liên kết khi di chuột hoặc con trỏ xuống dưới dạng cách triển khai các quy tắc suy đoán cơ bản nhưng vẫn hiệu quả:
<script type="speculationrules">
{
"prerender": [{
"source": "document",
"where": {
"href_matches": "/*"
},
"eagerness": "moderate"
}]
}
</script>
Các giới hạn của Chrome
Ngay cả khi bạn chọn eagerness, Chrome vẫn có các giới hạn để ngăn việc lạm dụng API này:
eagerness |
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) sẽ hoạt động theo Phương thức nhập trước, xuất trước (FIFO). Sau khi đạt đến giới hạn, suy đoán mới sẽ khiến suy đoán cũ nhất bị huỷ và được thay thế bằng suy đoán mới hơn để tiết kiệm bộ nhớ.
Trên thực tế, các suy đoán về moderate và conservative được người dùng kích hoạt cho phép chúng ta sử dụng ngưỡng khiêm tốn hơn là 2 để tiết kiệm bộ nhớ. Chế độ cài đặt immediate và eager không do người dùng kích hoạt, do đó sẽ có giới hạn cao hơn vì trình duyệt không thể biết được những chế độ cài đặt nào là cần thiết và khi nào cần đến.
Một suy đoán bị huỷ bỏ do bị đẩy ra khỏi hàng đợi FIFO có thể được kích hoạt lại (ví dụ: bằng cách di chuột qua đường liên kết đó một lần nữa), dẫn đến việc URL đó được suy đoán lại. Trong trường hợp đó, suy đoán trước đó có thể đã khiến trình duyệt lưu một số tài nguyên trong Bộ nhớ đệm HTTP cho URL đó, vì vậy, việc lặp lại suy đoán sẽ giúp giảm mạng nhiều và chi phí thời gian.
Các giới hạn immediate và eager cũng linh động. Việc xoá phần tử tập lệnh quy tắc suy đoán bằng cách sử dụng các mức độ mong muốn này sẽ tạo ra khả năng xử lý bằng cách huỷ những suy đoán đã bị xoá đó. Các URL này cũng có thể được suy đoán lại nếu chúng được đưa vào một tập lệnh URL mới và chưa đạt đến giới hạn.
Chrome cũng sẽ ngăn chặn việc sử dụng suy đoán trong một số điều kiện nhất định, bao gồm:
- Lưu-dữ liệu.
- Trình tiết kiệm năng lượng.
- Các hạn chế đối với bộ nhớ.
- Khi tắt chế độ cài đặt "Tải trước các trang" (tính năng này cũng bị các tiện ích của Chrome như uBlock Origin tắt một cách rõ ràng).
- Trang được mở trong thẻ nền.
Tất cả các điều kiện này đều nhằm mục đích giảm tác động của việc đầu cơ quá mức có thể gây bất lợi cho người dùng.
source không bắt buộc
Chrome 122 cung cấp khoá source ở chế độ không bắt buộc vì bạn có thể suy ra khoá này từ sự hiện diện của các khoá url hoặc where. Do đó, hai quy tắc suy đoán này giống hệt nhau:
<script type="speculationrules">
{
"prerender": [{
"source": "document",
"where": { "href_matches": "/*" },
"eagerness": "moderate"
}]
}
</script>
<script type="speculationrules">
{
"prerender": [{
"where": { "href_matches": "/*" },
"eagerness": "moderate"
}]
}
</script>
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 chúng vào HTML của tài liệu. Nhờ đó, các CDN triển khai dễ dàng hơn mà không cần phải 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 nhiều nguồn gốc, hãy 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 các quy tắc suy đoán của mình. Nếu không, URL tương đối sẽ tương đối với URL của tệp JSON củ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ó cùng nguồn gốc.
Sử dụng lại bộ nhớ đệm hiệu quả hơn
Chúng tôi đã thực hiện một số cải tiến đối với chức năng lưu vào bộ nhớ đệm trong Chrome để việc tìm nạp trước (hoặc thậm chí kết xuất trước) tài liệu sẽ lưu trữ và sử dụng lại tài nguyên trong bộ nhớ đệm HTTP. Điều này có nghĩa là hoạt động đầu cơ vẫn có thể mang lại các lợi ích trong tương lai, ngay cả khi không sử dụng suy đoán đó.
Điều này cũng giúp việc suy đoán lại (ví dụ: đối với các quy tắc tài liệu có chế độ cài đặt mức độ mong muốn là moderate) rẻ hơn đáng kể, vì Chrome sẽ sử dụng bộ nhớ đệm HTTP cho các tài nguyên có thể lưu vào bộ nhớ đệm.
Chúng tôi cũng hỗ trợ đề xuất No-Vary-Search mới để cải thiện hơn nữa việc sử dụng lại bộ nhớ đệm.
Hỗ trợ của No-Vary-Search
Khi tìm nạp trước hoặc hiển thị 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 thực sự do máy chủ 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 đang đượ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ủ, nê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 cho phép máy chủ chỉ định các tham số không dẫn đến sự khác biệt với tài nguyên được phân phối và 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 tài liệu, vốn chỉ khác nhau ở các tham số này. Lưu ý: hiện tại, tính năng này chỉ được hỗ trợ trong Chrome (và các trình duyệt dựa trên Chromium) đối với suy đoán điều hướng tìm nạp trước.
Cá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 tiêu đề HTTP No-Vary-Search sẽ được trả về. Việc này có thể giúp bạn tránh được những tệp 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 của trang ban đầu /products là giống nhau cho cả hai mã sản phẩm 123 và 124. Tuy nhiên, nội dung trang rốt cuộc sẽ khác nhau dựa trên việc hiển thị phía máy khách bằng JavaScript để tìm nạp dữ liệu sản phẩm bằng thông số tìm kiếm id. Vì vậy, chúng tôi đã tìm nạp trước URL đó một cách nghiêm ngặt và sẽ trả về một tiêu đề HTTP No-Vary-Search cho thấy trang có thể dùng được 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ìm nạp trước hoàn tất, thì có thể trình duyệt chưa nhận được trang /products. Trong trường hợp này, trình duyệt không biết liệu mình có chứa tiêu đề HTTP No-Vary-Search hay không. Sau đó, trình duyệt sẽ đưa ra lựa chọn tìm nạp lại đường liên kết hoặc đợi hoàn tất quá trình tìm nạp trước để 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 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.
Bản minh hoạ
Chúng tôi đã tạo một bản minh hoạ tại https://speculative-rules.glitch.me/common-fruits.html. Bạn có thể dùng bản này để xem các quy tắc tài liệu với chế độ cài đặt mức độ mong muốn moderate trong thực tế:
Mở Công cụ cho nhà phát triển, nhấp vào bảng Ứng dụng. Sau đó, trong phần Dịch vụ nền, hãy nhấp vào Tải theo suy đoán, sau đó nhấp vào ngăn Suy đoán rồi sắp xếp theo cột Trạng thái.
Khi di chuột qua các loại trái cây, bạn sẽ thấy các trang hiển thị trước. Khi nhấp vào các công thức đó, bạn sẽ thấy thời gian LCP nhanh hơn nhiều so với một trong các công thức không được kết xuất trước. Bản minh hoạ này cũng được giải thích trong video sau:
Bạn cũng có thể xem bài đăng trên blog về quy tắc gỡ lỗi về quy tắc suy đoán trước đây để biết thêm thông tin về cách sử dụng Công cụ cho nhà phát triển để gỡ lỗi các quy tắc suy đoán.
Hỗ trợ nền tảng cho các quy tắc suy đoán
Mặc dù việc triển khai các quy tắc suy đoán tương đối đơn giản bằng cách chèn các quy tắc vào phần tử <script type="speculationrules">, nhưng dịch vụ hỗ trợ trên nền tảng có thể khiến việc này chỉ bằng một lần nhấp. Chúng tôi đang làm việc với nhiều nền tảng và đối tác để giúp việc đưa ra các quy tắc suy đoán trở nên dễ dàng hơn.
Chúng tôi cũng đang nỗ lực để tiêu chuẩn hoá API này thông qua Nhóm cộng đồng vườn ươm web (WICG) để cho phép các trình duyệt khác cũng có thể triển khai API thú vị này nếu muốn.
WordPress
Nhóm hiệu suất WordPress Core (bao gồm cả các nhà phát triển của Google) đã tạo một trình bổ trợ Quy tắc suy đoán. Trình bổ trợ này cho phép thêm tính năng hỗ trợ quy tắc tài liệu chỉ bằng một cú nhấp chuột vào bất kỳ trang web WordPress nào. Bạn cũng có thể cài đặt trình bổ trợ này thông qua trình bổ trợ WordPress Performance Lab. Bạn cũng nên cân nhắc cài đặt trình bổ trợ này vì trình bổ trợ này sẽ giúp bạn nắm được các trình bổ trợ liên quan đến hiệu suất mà nhóm của chúng tôi cung cấp.
Có hai nhóm chế độ cài đặt: Chế độ suy đoán và chế độ cài đặt Mức độ quan tâm:
Đối với những cách thiết lập phức tạp hơn (ví dụ: để loại trừ một số URL nhất định khỏi hoạt động tìm nạp trước hoặc kết xuất trước), hãy đọc tài liệu.
Kết quả tìm kiếm
PayPal là một trong những nhà cung cấp CDN hàng đầu thế giới và hiện tại họ đã tích cực thử nghiệm với Speculation Rules API (API Quy tắc suy đoán). PayPal đã phát hành tài liệu về cách khách hàng có thể bật API này trong chế độ cài đặt CDN. Trước đây, họ cũng đã chia sẻ những kết quả ấn tượng có thể đạt được nhờ API mới này.
NitroPack
NitroPack là một giải pháp tối ưu hoá hiệu suất sử dụng AI điều hướng tuỳ chỉnh để dự đoán những trang cần thêm vào quy tắc suy đoán. Điều này giúp kéo dài thời gian thực hiện thay vì di chuột qua một đường liên kết, mà không lãng phí việc suy đoán một cách không cần thiết về tất cả các đường liên kết quan sát được. Hãy xem tài liệu về Nitropack Speculation Rules API để biết thêm thông tin. Giải pháp đổi mới này cho thấy vẫn còn nhiều điều để đáp ứng các quy tắc danh sách cũ hơn khi kết hợp với thông tin chi tiết theo trang web cụ thể.
Nhóm Chrome cũng hợp tác với NitroPack trong một hội thảo trên web về Speculation Rules API dành cho những người muốn tìm thêm thông tin, trong đó có một cuộc thảo luận tốt về những điểm cần cân nhắc giữa việc suy đoán sớm và thường xuyên, cũng như trễ và ít thường xuyên hơn.
Phi hành gia
Astro đã thêm kết xuất trước các trang bằng Speculation Rules API trong phiên bản 4.2 trên cơ sở thử nghiệm, cho phép các nhà phát triển sử dụng Astro dễ dàng bật tính năng này, đồng thời quay lại phương thức tìm nạp trước thông thường cho các trình duyệt không hỗ trợ Speculation Rules API. Hãy đọc tài liệu về kết xuất trước ứng dụng để biết thêm thông tin.
Kết luận
Những bổ sung này cho Speculation Rules API cho phép sử dụng tính năng hiệu suất mới thú vị này cho trang web một cách đơn giản hơn và ít có nguy cơ lãng phí tài nguyên do có các suy đoán không được sử dụng. Tôi rất vui khi thấy các nền tảng đã khai thác API này. Chúng tôi hy vọng có thể áp dụng API này nhiều hơn vào năm 2024, từ đó mang lại hiệu suất cao hơn cho người dùng cuối.
Ngoài việc đạt được hiệu suất mà Speculation Rules API mang lại, chúng tôi cũng rất hào hứng muốn xem những cơ hội mới này sẽ mở ra. Khung chuyển đổi khung hiển thị là một API mới cho phép nhà phát triển dễ dàng chỉ định hiệu ứng chuyển đổi giữa các thao tác. Tính năng này hiện được cung cấp cho Ứng dụng trang đơn (SPA), nhưng phiên bản nhiều trang đang được xử lý (và có sẵn sau một cờ trong Chrome). Kết xuất trước là một tiện ích bổ sung tự nhiên cho tính năng đó để đảm bảo không có độ trễ, điều này sẽ ngăn cản việc cải thiện trải nghiệm người dùng mà chuyển đổi này nhằm mục đích cung cấp. Chúng tôi đã thấy các trang web thử nghiệm với sự kết hợp này.
Chúng tôi rất mong được tiếp tục áp dụng Speculation Rules API trong suốt năm 2024. Đồng thời, chúng tôi sẽ thông báo cho bạn về mọi điểm cải tiến mà chúng tôi thực hiện đối với API này.
Xác nhận
Hình thu nhỏ của Robbie Down trên Unsplash