Nhóm Chrome đã và đang nỗ lực để cập nhật một số tính năng thú vị cho API Quy tắc dự đoán 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í là kết xuất trước các thao tác điều hướng trong tương lai. Tất cả các điểm cải tiến bổ sung này hiện đều có trong Chrome 122 (một số tính năng có trong các phiên bản trước đó).
Những thay đổi này giúp việc triển khai tính năng tìm nạp trước và kết xuất trước trang trở nên 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 sử dụng rộng rãi hơn.
Các tính năng khác
Trước tiên, chúng tôi sẽ giải thích về những nội dung bổ sung mới mà chúng tôi đã thêm vào Speculation Rules API và cách sử dụng các nội dung đó. Sau đó, chúng tôi sẽ cho bạn xem một bản minh hoạ để bạn có thể thấy các thành phần này hoạt động như thế nào.
Quy tắc về tài liệu
Trước đây, API Quy tắc suy đoán hoạt động bằng cách chỉ định danh sách URL để tải 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 có tính chất bán động ở chỗ bạn có thể thêm tập lệnh quy tắc suy đoán mới và xoá các tập lệnh cũ để loại bỏ các suy đoán đó (lưu ý rằng việc cập nhật danh sách urls
của 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, việc lựa chọn URL vẫn tuỳ thuộc vào trang web, bằng cách gửi URL từ máy chủ tại thời điểm yêu cầu trang hoặc bằng cách tạo động 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 hơn (trong đó thao tác điều hướng tiếp theo là từ một nhóm nhỏ các thao tác điều hướng 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 linh độ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, sau đó được chèn vào trang).
Thay vào đó, chúng tôi rất vui được cung cấp một lựa chọn mới để tự động tìm đường liên kết bằng cách sử dụng quy tắc tài liệu. Thao tác này hoạt động bằng cách lấy 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 đường 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 các kết quả khớp href để tìm đườ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 trên toàn trang web, thay vì có các bộ quy tắc cụ thể cho mỗi trang, giúp các trang web triển khai các quy tắc suy đoán dễ dàng hơn nhiều.
Tất nhiên, việc kết xuất trước tất 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 đã giới thiệu một chế độ cài đặt eagerness
.
Sự háo hức
Với mọi loại dự đoán, bạn phải đánh đổi giữa độ chính xác và khả năng gợi nhắc cũng như 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 trên cùng một trang) và với thời gian chờ nhiều nhất có thể, nhưng có thể lãng phí rất nhiều băng thông.
Mặt khác, việc chỉ kết xuất trước 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 thời gian dẫn đầu sẽ bị giảm đi đáng kể. Điều này có nghĩa là quá trình kết xuất trước có thể chưa hoàn tất 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 dự đoán, phân tách thời điểm dự đoán với URL thực hiện dự đoán. Chế độ cài đặt eagerness
có sẵn cho cả quy tắc nguồn list
và document
, đồng thời có 4 chế độ cài đặt, trong đó Chrome có các phương pháp phỏng đoán sau:
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ế độ này hiện 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 di chuột lê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 rất đơn giản, 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 suy đoán đơn giản sau đây. Quy tắc này sẽ kết xuất trước tất cả các đường liên kết khi di chuột hoặc khi con trỏ di chuyển xuống 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 suy đoán:
<script type="speculationrules">
{
"prerender": [{
"source": "document",
"where": {
"href_matches": "/*"
},
"eagerness": "moderate"
}]
}
</script>
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 chặn việc sử dụng quá mức 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) hoạt động theo phương thức Vào trước, ra trước (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ớ.
Việc người dùng kích hoạt các dự đoán moderate
và conservative
cho phép chúng ta sử dụng ngưỡng 2 khiêm tốn hơn để tiết kiệm bộ nhớ. Chế độ cài đặt immediate
và eager
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 cần chế độ nào và khi nào cần chế độ đó.
Bạn có thể kích hoạt lại một dự đoán bị huỷ bằng cách đẩy ra khỏi hàng đợi FIFO (ví dụ: bằng cách di chuột qua đường liên kết đó một lần nữa). Điều này sẽ khiến URL đó được dự đoán lại. Trong trường hợp đó, dự đoán trước đó có thể đã khiến trình duyệt lưu một số tài nguyên vào bộ nhớ đệm HTTP cho URL đó. Vì vậy, việc lặp lại dự đoán sẽ làm giảm đáng kể chi phí mạng và thời gian.
Giới hạn immediate
và eager
cũng là động. Việc xoá một phần tử tập lệnh quy tắc suy đoán bằng các cấp độ háo hức này sẽ tạo ra dung lượng bằng cách huỷ các suy đoán đã xoá đó. Bạn cũng có thể dự đoán lại các URL này nếu chúng nằm trong tập lệnh URL mới và chưa đạt đến giới hạn.
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.
- 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.
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.
source
không bắt buộc
Chrome 122 đặt khoá source
là không bắt buộc vì bạn có thể suy ra khoá này từ sự hiện diện của 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 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.
Tái sử dụng bộ nhớ đệm hiệu quả hơn
Chúng tôi đã cải tiến một số tính năng lưu vào bộ nhớ đệm trong Chrome để việc tải trước (hoặc thậm chí là 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à việc suy đoán vẫn có thể mang lại lợi ích trong tương lai, ngay cả khi thông tin suy đoán đó không được sử dụng.
Điều này cũng giúp giảm đáng kể chi phí dự đ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 độ ưu tiên moderate
) 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 việc sử dụng lại bộ nhớ đệm.
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. Lưu ý: tính năng này hiện chỉ đượ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.
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.
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ể sử dụng bản minh hoạ này để xem các quy tắc tài liệu với chế độ cài đặt moderate
eagerness (tính năng tìm nạp trước) đang hoạt động:
Mở DevTools, nhấp vào bảng điều khiển Application (Ứng dụng). Sau đó, trong mục Dịch vụ nền, hãy nhấp vào Tải suy đoán, rồi nhấp vào ngăn Suy đoán và 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 được kết xuất trước. Khi nhấp vào các công thức này, 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ề cách gỡ lỗi quy tắc suy đoán trước đó để biết thêm thông tin về cách sử dụng Công cụ của Chrome cho nhà phát triển để gỡ lỗi quy tắc suy đoán.
Hỗ trợ nền tảng cho quy tắc suy đoán
Mặc dù quy tắc suy đoán tương đối đơn giản để triển khai bằng cách chèn các quy tắc vào phần tử <script type="speculationrules">
, nhưng tính năng hỗ trợ nền tảng có thể giúp bạn thực hiện việc này chỉ bằng một lần nhấp. Chúng tôi đã làm việc với nhiều nền tảng và đối tác để triển khai các quy tắc về hành vi đầu cơ một cách dễ dàng hơn.
Chúng tôi cũng đang nỗ lực để chuẩn hoá API thông qua Nhóm cộng đồng ươm tạo web (WICG) để cho phép các trình duyệt khác cũng triển khai API thú vị này nếu họ muốn.
WordPress
Nhóm Hiệu suất cốt lõi của WordPress (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 dự đoán. Trình bổ trợ này cho phép bạn thêm tính năng hỗ trợ quy tắc tài liệu vào bất kỳ trang web WordPress nào chỉ bằng một lần nhấp chuột. 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 việc cài đặt trình bổ trợ này vì nó sẽ giúp bạn nắm bắt thông tin mới nhất về các trình bổ trợ hiệu suất có liên quan của nhóm.
Có hai nhóm chế độ cài đặt: Chế độ suy đoán và chế độ cài đặt Mức độ háo hức:
Để biết 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 việc tìm nạp trước hoặc kết xuất trước), hãy đọc tài liệu này.
Akamai
Akamai là một trong những nhà cung cấp CDN hàng đầu thế giới và họ đã tích cực thử nghiệm API Quy tắc dự đoán trong một thời gian. Akamai đã phát hành tài liệu về cách khách hàng có thể bật API này trong phần cài đặt CDN. Trước đây, họ cũng đã chia sẻ những kết quả ấn tượng có thể đạt được với 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. Mục đích của giải pháp này là cung cấp thời gian chờ lâu hơn so với khi di chuột qua một đường liên kết, nhưng không lãng phí thời gian suy đoán không cần thiết trên tất cả các đường liên kết được quan sát. Hãy xem tài liệu về API Quy tắc đầu cơ của Nitropack để biết thêm thông tin. Giải pháp sáng tạo này cho thấy các quy tắc danh sách cũ vẫn có nhiều điều để cung cấp khi kết hợp với thông tin chi tiết dành riêng cho trang web.
Nhóm Chrome cũng đã hợp tác với NitroPack để tổ chức một hội thảo trên web về Speculation Rules API dành cho những người muốn biết thêm thông tin, bao gồm cả một cuộc thảo luận hiệu quả về những điều cần cân nhắc giữa việc dự đoán sớm và thường xuyên, cũng như dự đoán muộn và ít thường xuyên hơn.
Astro
Astro đã thêm tính năng hiển thị trướ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 tính năng tải trước chuẩn cho các trình duyệt không hỗ trợ Speculation Rules API. Hãy đọc tài liệu về tính năng kết xuất trước của ứng dụng để biết thêm thông tin.
Kết luận
Những nội dung bổ sung này cho Speculation Rules API giúp bạn sử dụng tính năng hiệu suất mới và thú vị này cho các trang web một cách đơn giản hơn nhiều, đồng thời giảm nguy cơ lãng phí tài nguyên với các dự đoán không sử dụng. Thật thú vị khi thấy các nền tảng đã dựa vào API này. Chúng tôi hy vọng sẽ thấy API này được sử dụng rộng rãi hơn trong năm 2024 và cuối cùng mang lại hiệu suất tốt hơn cho người dùng cuối.
Ngoài những lợi ích về hiệu suất mà Speculation Rules API mang lại, chúng tôi cũng rất hào hứng khi thấy những cơ hội mới mà API này mang lại. Chuyển đổi khung hiển thị là một API mới cho phép nhà phát triển chỉ định các chuyển đổi giữa các thao tác điều hướng dễ dàng hơn. Tính năng này hiện có sẵn cho Ứng dụng một trang (SPA), nhưng phiên bản nhiều trang đang trong quá trình phát triển (và có sẵn sau một cờ trong Chrome). Trình 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ễ, nếu không, việc này sẽ ngăn cản việc cải thiện trải nghiệm người dùng mà quá trình chuyển đổi dự kiến sẽ mang lại. Chúng tôi đã thấy các trang web thử nghiệm cách kết hợp này.
Chúng tôi mong muốn tiếp tục áp dụng API Quy tắc đầu cơ trong suốt năm 2024 và sẽ cập nhật cho bạn mọi điểm cải tiến khác mà chúng tôi thực hiện đối với API này.
Lời cảm ơn
Hình thu nhỏ của Robbie Down trên Unsplash