Trang này được dịch bởi Cloud Translation API.

Trình kết xuất trước trang trong Chrome để di chuyển trang tức thì

Barry Pollard

Hỗ trợ trình duyệt

Nhóm Chrome đã khôi phục lại việc hiển thị trước đầy đủ các trang trong tương lai mà người dùng có thể sẽ truy cập vào.

Nhật ký ngắn gọn về quá trình kết xuất trước

Trước đây, Chrome hỗ trợ gợi ý về tài nguyên <link rel="prerender" href="/next-page">, tuy nhiên, ngoài Chrome thì gợi ý này không được hỗ trợ rộng rãi và đây không phải là một API có tính biểu đạt cao.

Tính năng kết xuất trước cũ bằng đường liên kết rel=prerender đã ngừng hoạt động và thay vào đó là Tìm nạp trước NoState. Phương thức 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 hoàn toàn trang cũng như không thực thi JavaScript. Quá trình 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 khả năng tải tài nguyên nhưng sẽ không phân phối lượt tải trang tức thì như quá trình kết xuất trước đầy đủ.

Nhóm Chrome hiện đã giới thiệu lại tính năng kết xuất trước đầy đủ vào Chrome. Để tránh các sự cố xảy ra với việc sử dụng hiện tại cũng như cho phép mở rộng quá trình 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"...> (vẫn được giữ nguyên đối với quá trình Tìm nạp trước NoState) với mục đích gỡ bỏ cơ chế này vào thời điểm nào đó trong tương lai.

Trang được kết xuất trước như thế nào?

Trang có thể được kết xuất trước theo một trong bốn cách, tất cả đều nhằm mục đích làm cho điều hướng nhanh hơn:

Khi bạn nhập URL vào thanh địa chỉ của Chrome (còn được gọi là "thanh địa chỉ"), Chrome có thể tự động kết xuất trước trang cho bạn nếu tin tưởng rằng bạn sẽ truy cập trang đó dựa trên nhật ký duyệt web trước đó 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 bằng cách 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 theo hướng dẫn của công cụ tìm kiếm.
Các trang web có thể sử dụng API Quy tắc suy đoán để cho Chrome biết trang nào cần kết xuất trước theo phương thức lập trình. Tính năng này thay thế những việc <link rel="prerender"...> đã 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 văn bản này có thể tồn tại tĩnh trên các trang hoặc được JavaScript tự động chèn vào khi chủ sở hữu trang thấy phù hợp.

Trong mỗi trường hợp như vậy, quá trình kết xuất trước sẽ hoạt động như thể trang đã được mở trong một thẻ nền ẩn rồi "kích hoạt" bằng cách thay thế thẻ nền trước bằng trang được kết xuất trước đó. Nếu một trang được kích hoạt trước khi được kết xuất 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, nghĩa là bạn vẫn có thể có được khởi đầu thuận lợi.

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 nhập (ví dụ: lời nhắc) không được kích hoạt ở trạng thái này mà sẽ bị trì hoãn cho đến khi trang được kích hoạt. Trong một số ít trường hợp, quá trình kết xuất trước sẽ bị huỷ. Nhóm Chrome đang nghiên cứu để tìm ra các lý do huỷ quá trình kết xuất trước dưới dạng API, đồng thời cải thiện các chức năng của Công cụ cho nhà phát triển để giúp xác định các trường hợp hiếm gặp đó dễ dàng hơn.

Lưu ý: Bạn nên coi các trang được kết xuất trước là một gợi ý và một tính năng nâng cao tăng dần. Không giống như preload, quá trình kết xuất trước là một gợi ý suy đoán và trình duyệt có thể chọn không hành động theo gợi ý 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 suy đoán khác.

Tác động của việc kết xuất trước

Quá trình kết xuất trước cho phép tải trang gần như ngay lập tức như trong video sau đây:

Ví dụ về tác động của việc kết xuất trước.

Trang web ví dụ đã là một trang web nhanh, nhưng ngay cả với trang web này, bạn vẫn có thể thấy việc kết xuất trước cải thiện trải nghiệm người dùng như thế nào. 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, CLS (Mức thay đổi bố cục tích luỹ) giảm (vì CLS tải xảy ra trước chế độ xem ban đầu) và INP được cải thiện (vì phải hoàn tất lượt tải trước khi người dùng tương tác).

Ngay cả khi trang được kích hoạt trước khi được tải hoàn toàn, bắt đầu tải trang từ đầu, bạn vẫn có thể cải thiện trải nghiệm tải. Khi một đường liên kết được kích hoạt trong lúc 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, việc 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á mức vì phải tốn tài nguyên người dùng. Chỉ kết xuất trước khi có nhiều khả năng trang đó đang được điều hướng.

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 các đề xuất 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 dự đoán của Chrome về các URL trên trang chrome://predictors:

Trang Dự đoán Chrome được lọc để hiển thị các dự đoán thấp (xám), trung bình (hổ phách) và cao (xanh lục) dựa trên văn bản được nhập. — Trang Dự đoán của Chrome.

Đường màu xanh lục cho biết đủ tin cậy để kích hoạt kết xuất trước. Trong ví dụ này, việc nhập "s" mang lại độ tin cậy hợp lý (màu hổ phách). Tuy nhiên, sau khi bạn nhập "sh", Chrome sẽ có đủ tin tưởng để bạn gần như luôn chuyển đến https://sheets.google.com.

Ảnh chụp màn hình này được chụp trong một bản cài đặt Chrome tương đối mới và lọc ra các dự đoán không tin cậy, nhưng nếu xem các dự đoán của riêng mình, bạn có thể sẽ 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.

Các công cụ dự đoán này cũng là yếu tố thúc đẩy các tuỳ chọn đề xuất của thanh địa chỉ mà bạn có thể thấy:

Tính năng 'Typeahead' trên thanh địa chỉ của Chrome — Tính năng "Typeahead" trên thanh địa chỉ.

Chrome sẽ liên tục cập nhật công cụ dự đoán dựa trên nội dung bạn nhập và các lựa chọn của bạn.

Khi có mức độ tin cậy lớn hơn 50% (hiển thị bằng màu hổ phách), Chrome sẽ chủ động kết nối trước với miền nhưng không kết xuất trước trang.
Nếu có 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 kết xuất 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 trang của họ để thông báo cho trình duyệt về URL cần kết xuất trước:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["next.html", "next2.html"]
    }
  ]
}
</script>

Hoặc theo các quy tắc tài liệu (có trên Chrome 121) để 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 API mẫu URL) 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ị 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.

Háo hức

Hỗ trợ trình duyệt

Chế độ cài đặt eagerness dùng để cho biết thời điểm kích hoạt dự đoán, điều này đặc biệt hữu ích đối với các quy tắc trong tài liệu:

immediate: Thuộc tính này dùng để suy đoán càng sớm càng tốt, tức là ngay khi quan sát được các quy tắc suy đoán.
eager: Phương thức này hoạt động giống hệt với chế độ cài đặt immediate, nhưng trong tương lai, chúng ta sẽ tìm cách đặt thuộc tính này ở đâu đó trong khoảng từ immediate đến moderate.
moderate: Thao tác này sẽ thực hiện 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 trên sự kiện pointerdown nếu thời gian đó sớm hơn và trên thiết bị di động không có sự kiện hover).
conservative: Tham số này suy đoán bằng 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 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ể. 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. Do một tài liệu có thể chứa nhiều URL, bạn nê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).

Chế độ cài đặt eagerness mà bạ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, gọn nhẹ, việc suy đoán háo hức 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 từ người dùng để hạn chế lãng phí.

Tuỳ chọn moderate là trung gian và nhiều trang web có thể hưởng lợi từ quy tắc suy đoán sau. 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 trong sự kiện con trỏ dưới dạng cách triển khai cơ bản nhưng mạnh mẽ các quy tắc suy đ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 đầy đủ. Đây thường có thể là bước đầu tiên phù hợp trên con đường kết xuất trước:

<script type="speculationrules">
{
  "prefetch": [
    {
      "urls": ["next.html", "next2.html"]
    }
  ]
}
</script>

Lưu ý: Không giống như gợi ý về tài nguyên <link rel="prefetch"> cũ vừa được tìm nạp trước vào bộ nhớ đệm HTTP, các tài liệu được tải bằng các quy tắc suy đoán được xử lý giống như các thao tác điều hướng (nhưng sau đó không được hiển thị) và được lưu giữ trong bộ nhớ nên sẽ được cung cấp cho trình duyệt nhanh hơn khi cần. Thao tác này cũng cho phép tìm nạp trước các tài liệu không thể lưu vào bộ nhớ đệm trong bộ nhớ đệm HTTP. Do vấn đề khi tìm nạp trước tài liệu bằng <link rel="prefetch">, bạn nên sử dụng các quy tắc suy đoán cho những tài liệu này từ giờ trở đi (<link rel="prefetch"> chỉ dùng để tìm nạp trước các tài nguyên phụ).

Giới hạn của Chrome

Chrome có các giới hạn để ngăn việc sử dụng quá mức API Quy tắc suy đoán:

sự háo hức	Tìm nạp trước	Trình kết xuất trước
`immediate`/`eager`	50	10
`moderate`/`conservative`	2 (FIFO)	2 (FIFO)

Giới hạn suy đoán trong Chrome.

Các chế độ cài đặt moderate và conservative (tuỳ thuộc vào tương tác của người dùng) hoạt động theo cách vào trước, ra trước (FIFO): sau khi đạt đến giới hạn, một 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 nhất để tiết kiệm bộ nhớ. Một suy đoán đã bị huỷ có thể được kích hoạt lại – ví dụ như bằng cách di chuột qua liên kết đó một lần nữa – điều này sẽ dẫn đến việc URL đó được suy đoán lại, loại bỏ suy đoán cũ nhất. Trong trường hợp này, suy đoán trước đó sẽ lưu mọi tài nguyên có thể lưu vào bộ nhớ đệm trong Bộ nhớ đệm HTTP của URL đó. Vì vậy, việc suy đoán thêm thời gian sẽ giúp giảm chi phí. Đây là lý do tại sao giới hạn này đượ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ởi 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 những gì cần thiết và khi nào chúng cần.

Giới hạn immediate và eager cũng thay đổi, vì vậy việc xoá phần tử tập lệnh URL list sẽ tạo ra dung lượng bằng cách huỷ những suy đoán đã bị loại bỏ đó.

Chrome cũng sẽ ngăn chặn hoạt động suy đoán được sử dụng 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 pin khi bật và ở chế độ pin yếu.
Các hạn chế về bộ nhớ.
Khi cài đặt "Tải trước các trang" bị tắt (chế độ 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).
Các trang được mở trong thẻ nền.

Chrome cũng không hiển thị iframe nhiều nguồn gốc trên các trang được kết xuất trước cho đến khi được kích hoạt.

Tất cả những điều kiện này đều nhằm giảm tác động của việc suy đoán quá mức có thể gây bất lợi cho người dùng.

Cách bao gồm các quy tắc suy đoán trên một trang

Các quy tắc suy đoán có thể được đưa vào HTML của trang theo cách tĩnh hoặc được chèn động vào trang bằng JavaScript:

Quy tắc suy đoán được bao gồm cố định: Ví dụ: trang web tin tức hoặc blog có thể kết xuất trước bài viết mới nhất nếu đó thường là điều hướng tiếp theo cho nhiều 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ặc conservative để suy đoán khi người dùng tương tác với các đường liên kết.
Các 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 suy đoán khác.

Những người ưu tiên chèn động dựa trên các thao tác như di chuột qua hoặc nhấp vào đường liên kết (như nhiều thư viện đã làm trước đây với <link rel=prefetch>) được đề xuất 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 các quy tắc suy đoán vào <head> hoặc <body> trong khung chính. Các quy tắc suy đoán trong khung phụ sẽ 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 hiện sau khi trang đó được kích hoạt.

Tiêu đề HTTP `Speculation-Rules`

Hỗ trợ trình duyệt

Nguồn

Bạn cũng có thể gửi 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 này vào HTML của tài liệu. Nhờ vậy, các CDN có thể 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 một 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. 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 quy tắc suy đoán của mình. Nếu không, các 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ả) đường liên kết có cùng nguồn gốc.

Các quy tắc suy đoán và SPA

Quy tắc suy đ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 các trang Ứng dụng trang đơn (SPA) hoặc giao diện ứng dụng. Những cấu trúc này không sử dụng phương thức tìm nạp tài liệu, mà thay vào đó sẽ tìm nạp qua API hoặc một phần dữ liệu/trang, sau đó được xử lý và trình bày trên 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 phần này được gọi là "điều hướng mềm" ngoài các quy tắc suy đoán, nhưng không thể được 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ừ trang trước. Điều này có thể giúp bù lại một số chi phí phát sinh thêm ban đầu mà một số SPA phải chịu. Tuy nhiên, không thể kết xuất trước các thay đổi về tuyến trong ứng dụng.

Gỡ lỗi quy tắc suy đoán

Hãy xem bài đăng chuyên đề về các quy tắc suy đoán gỡ lỗi để biết các tính năng mới trong Công cụ của Chrome cho nhà phát triển nhằm 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 đó sẽ bổ sung vào các quy tắc hiện có. Do đó, những cách khác nhau sau đây đều dẫn đến việc kết xuất trướ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 nhóm speculationrules

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    },
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

Hỗ trợ của `No-Vary-Search`

Hỗ trợ trình duyệt

Nguồn

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à thông 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ụ: Google Analytics sử dụng thông số UTM để đo lường chiến dịch, nhưng thường không dẫn đến 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, có thể sử dụng lại chính trang đó từ bộ nhớ đệm.

Tương tự, ứ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 đối với tài nguyên được phân phối, từ đó cho phép trình duyệt sử dụng lại các phiên bản tài liệu được lưu vào bộ nhớ đệm trước đó, vốn chỉ khác 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) cho các suy đoán điều hướng tìm nạp 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 quá trình kết xuất trước).

Hỗ trợ các quy tắc suy đoán bằng cách 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 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 giống nhau cho cả mã sản phẩm 123 và 124. Tuy nhiên, nội dung trang rồi sẽ khác nhau tuỳ theo chế độ 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 tham số tìm kiếm id. Vì vậy, chúng ta nhanh chóng tìm nạp trước URL đó và URL đó sẽ trả về tiêu đề HTTP No-Vary-Search cho thấy trang có thể được dùng cho bất kỳ thông 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ì 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 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 hay chờ quá trình tìm nạp trước hoàn tất để xem liệu trình duyệ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 dự kiến phản hồi trang 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 hạn chế đối với quy tắc suy đoán và các cải tiến trong tương lai

Quy tắc suy đoán chỉ áp dụng cho những trang mở trong cùng một thẻ, nhưng chúng tôi đang nỗ lực giảm thiểu hạn chế đó.

Theo mặc định, suy đoán bị giới hạn ở các trang cùng nguồn gốc. Các trang có nguồn gốc khác theo suy đoán (ví dụ: https://a.example.com có thể kết xuất trước một trang trên https://b.example.com). Để sử dụng trang được suy đoán này (trong ví dụ này là https://b.example.com) 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ỷ hoạt động suy đ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 đối với các trang không phải là cùng một trang web và có nhiều nguồn gốc, miễn là cookie không tồn tại 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 suy đoán vốn đã hỗ trợ việc tìm nạp trước trên nhiều nguồn gốc, nhưng chỉ hỗ trợ khi cookie cho miền nhiều nguồn gốc không tồn tại. Nếu cookie tồn tại từ việc người dùng đã truy cập trang web đó trước đó thì quá trình suy đoán sẽ không được kích hoạt và sẽ hiển thị lỗi trong Công cụ cho nhà phát triển.

Với các 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 của bạn cho cả đường liên kết nội bộ lẫn đường liên kết ngoài (nếu có thể) là kết xuất trước URL có cùng nguồn gốc và tìm nạp trước các URL có nhiều nguồn gốc:

<script type="speculationrules">
  {
    "prerender": [
      {
        "where": { "href_matches": "/*" },
        "eagerness": "moderate"
      }
    ],
    "prefetch": [
      {
        "where": { "not": { "href_matches": "/*" } },
        "eagerness": "moderate"
      }
    ]
  }
</script>

Vì lý do bảo mật, việc hạn chế nhằm ngăn chặn tình trạng suy đoán trên nhiều nguồn gốc đối với các đường liên kết nhiều nguồn gốc theo mặc định là cần thiết. Đây là một điểm cải tiến so với <link rel="prefetch"> đối với các đích đến trên nhiều nguồn gốc. Các đích này cũng sẽ không gửi cookie nhưng vẫn cố tìm nạp trước. Điều này sẽ dẫn đến việc tìm nạp trước lãng phí cần phải được gửi lại hoặc tệ hơn là tải trang không chính xác.

Không hỗ trợ quy tắc suy đoán cho việc tìm nạp trước đối với các trang do trình chạy dịch vụ kiểm soát. Chúng tôi đang nỗ lực bổ sung tính năng hỗ trợ này. Theo dõi vấn đề về Trình chạy dịch vụ hỗ trợ này để biết thông tin cập nhật. Hỗ trợ trình kết xuất trước cho các trang do trình chạy dịch vụ kiểm soát.

Hỗ trợ Phát hiện quy tắc suy đoán

Bạn có thể phát hiện tính năng hỗ trợ Speculation Rules API (API Quy tắc suy đoán) 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 một cách 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 suy đoán 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ề quá trình kết xuất trước API Quy tắc suy đoán bằ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 một phần tử <script type = "speculationrules"> trực tiếp 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à phần tử này phải được thêm vào như minh hoạ trước đó. Tuy nhiên, nội dung được chèn động bằng cách sử dụng innerHTML chứa đường liên kết mới sẽ được chọn theo các quy tắc hiện hành trên trang.

Tương tự, việc chỉnh sửa trực tiếp bảng điều khiển Phần tử trong Công cụ của Chrome cho nhà phát triển để thêm phần tử <script type = "speculationrules"> sẽ không đăng ký các quy tắc suy đoán và thay vào đó, tập lệnh để thêm phần tử này vào DOM phải được chạy từ Bảng điều khiển để chèn 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 một trình quản lý thẻ như Trình quản lý thẻ của Google (GTM), các quy tắc này phải được chèn thông qua JavaScript, thay vì thêm trực tiếp phần tử <script type = "speculationrules"> qua GTM vì những lý do tương tự như đã đề cập trước đó:

Cấu hình thẻ HTML tuỳ chỉnh trong Trình quản lý thẻ của Google — Thêm Quy tắc suy đoán thông qua Trình quản lý thẻ của Google.

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á quy tắc suy đoán sẽ khiến quá trình kết xuất trước bị huỷ. Tuy nhiên, vào thời điểm quá trình này xảy ra, các tài nguyên có thể đã được dùng để bắt đầu quá trình 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 phải huỷ quá trình kết xuất trước.

Quy tắc 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ù các quy tắc này chỉ chứa JSON, nhưng các quy tắc đó cần phải được đưa vào Content-Security-Policy của script-src nếu trang web sử dụng phần tử 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 inline-speculation-rules mới vào script-src để cho phép hỗ trợ các phần tử <script type="speculationrules"> được chèn từ các tập lệnh hàm băm hoặc tập lệnh chưa được nhập. Tệp 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à vô hiệu hoá kết xuất trước

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ì nó cho phép kết xuất trang nhanh — thường là tức thì. Đ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 cho phép trải nghiệm người dùng tốt hơn nhưng có thể khó có được nếu không có.

Tuy nhiên, có thể có những trường hợp bạn không muốn quá trình kết xuất trước trang diễn ra, 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

Chỉ bật trình kết xuất trước cho những người dùng Chrome có cài đặt "Tải trước cá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ó bộ nhớ thấp hoặc nếu hệ điều hành đang ở chế độ Tiết kiệm dữ liệu hoặc Tiết kiệm năng lượng. Xem mục 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 với tiêu đề HTTP Sec-Purpose:

Sec-Purpose: prefetch;prerender

Những trang được tìm nạp trước bằng API Quy tắc suy đoán sẽ có tiêu đề này chỉ được đặt thành prefetch:

Sec-Purpose: prefetch

Các máy chủ có thể phản hồi dựa trên tiêu đề này để ghi nhật ký các yêu cầu suy đoán, trả về nhiều nội dung hoặc ngăn quá trình kết xuất trước. Nếu mã phản hồi không thành công được trả về (không phải mã 200 hoặc 304) 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ỏ.

Nếu bạn không muốn một trang cụ thể được kết xuất trước, đây là cách tốt nhất để đảm bảo việc đó sẽ không xảy ra. Tuy nhiên, để mang lại trải nghiệm tốt nhất, bạn nên cho phép hiển thị trước, nhưng trì hoãn mọi hành động chỉ nên xảy ra khi đó trang thực sự được xem, bằng cách sử dụng JavaScript.

Phát hiện quá trình 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 tính năng 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 kích hoạt tài liệu được kết xuất trước, activationStart của PerformanceNavigationTiming cũng sẽ được đặt thành thời gian khác 0, thể hiện khoảng thời gian tính từ khi quá trình kết xuất trước bắt đầu đến khi tài liệu thực sự được kích hoạt.

Bạn có thể có chức năng kiểm tra các trang kết xuất trước và kết xuất 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 (toàn bộ hay một phần) là mở Công cụ cho nhà phát triển sau khi trang được kích hoạt rồi nhập performance.getEntriesByType('navigation')[0].activationStart vào bảng điều khiển. Nếu một giá trị khác 0 được trả về, tức là bạn biết trang đó đã được kết xuất trước:

Bảng điều khiển trong Công cụ của Chrome cho nhà phát triển hiển thị một ActiveStart dương cho biết trang đã được kết xuất trước — Thử nghiệm quá trình kết xuất trước trong bảng điều khiển.

Khi người dùng xem trang kích hoạt trang, sự kiện prerenderingchange sẽ được gửi đi trên document. Sau đó, bạn có thể dùng sự kiện này để kích hoạt các hoạt động mà trước đó đã đượ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.

Bằng cách sử dụng các API này, JavaScript giao diện người dùng có thể phát hiện và hành động theo các trang được kết xuất trước một cách thích hợp.

Cảnh báo: PerformanceNavigationTiming.type không sử dụng giá trị prerender dành cho loại điều hướng <link rel="prerender"...> cũ, ban đầu. Điều này có thể thay đổi trong tương lai nhưng hiện tại, khách hàng nên sử dụng API document.prerendering để xác định các trang kết xuất trước và một trường PerformanceNavigationTiming.activationStart khác 0 để xác định các trang kết xuất trước đã được kích hoạt.

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 chỉ số hiệu suất của trang sử dụng Giám sát người dùng thực (RUM).

Chỉ nên kết xuất trước trang khi có nhiều khả năng người dùng sẽ tải trang. Đây là lý do tại sao các tuỳ chọn hiển thị trước trên thanh địa chỉ của Chrome chỉ xảy ra khi có xác suất cao như vậy (hơ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 phải thêm mã bổ sung để chỉ bật tính năng 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 tất cả các nhà cung cấp dịch vụ phân tích đều 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 kết xuất trước hoặc phân giải ngay lập tức nếu tài liệu đó được kết xuất trước:

// 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 được hiển thị lần đầu tiên, việc này sẽ bao gồm cả trường hợp kết xuất trước cũng như khi thẻ được mở trong nền (ví dụ: khi 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 Analytics và các trường hợp sử dụng 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 trong các trường hợp đó. Vì vậy, bạn nê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 khi kết xuất trước

Bạn có thể dùng chính 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ử của 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 này:

<script src="https://example.com/app/script.js" async></script>

Bạn có thể thay đổi lựa chọn này thành phần tử tập lệnh được chèn động và 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 bao gồm 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 truy cập. Ví dụ: Google có thể giữ lại các đề xuất, trạng thái đăng nhập hoặc biểu tượng giỏ hàng để đảm bảo trình bày thông tin mới nhất.

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 những điều kiện này cũng đúng với các trang được tải trong các thẻ nền được đề cập trước đó (vì vậy, hàm whenFirstVisible có thể được dùng thay cho whenActivated).

Trong nhiều trường hợp, tốt nhất là bạn cũng nên kiểm tra các thay đổi chung của visibilitychange đối với trạng thái. Ví dụ: khi quay lại một trang có nền trước, mọi bộ đếm giỏ hàng đều phải được cập nhật 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 đề dành riêng cho việc kết xuất trước mà chỉ làm cho vấn đề hiện tại trở nên rõ ràng hơn.

Một cách để Chrome giảm thiểu một số nhu cầu gói các tập lệnh hoặc hàm theo cách thủ công là một số API nhất định được giữ lại như đã đề cập trước đó và các iframe của bên thứ ba cũng không được hiển thị, do đó chỉ có nội dung bên cạnh đó mới được yêu cầu giữ lại theo cách thủ công.

Đo lường hiệu suất

Để đo lường chỉ số hiệu suất, Analytics nên cân nhắc xem 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 Các chỉ số quan trọng về trang web (được Chrome đo lường thông qua Báo cáo trải nghiệm người dùng trên Chrome) thì các chỉ số này được dùng để đo lường trải nghiệm người dùng. Vì vậy, những chỉ số này được tính 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. Điều này cho thấy đây là một cách rất hiệu quả để cải thiện Core Web Vitals.

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 giống như cách Chrome đo lường Chỉ số quan trọng chính của 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 những chỉ số đó trong thuộc tính Metric.navigationType nếu trang đã được kết xuất trước hoàn toàn hoặc một phần.

Đo lường quá trình kết xuất trước

Bạn có thể xem một trang được kết xuất trước bằng một mục activationStart khác 0 là PerformanceNavigationTiming hay không. Sau đó, dữ liệu này có thể được ghi lại bằng một Phương diện tuỳ chỉnh hoặc tương tự khi ghi lại các lượt xem trang, chẳng hạn như 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 phân tích của bạn cho biết số lượng điều hướng được kết xuất trước so với các loại điều hướng khác, và cũng cho phép bạn liên hệ bất kỳ chỉ số hiệu suất hoặc chỉ số kinh doanh nào với các loại điều hướng khác nhau 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ó tác động thực tế đến các biện pháp kinh doanh như 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 hiển thị trước các trang đối với hoạt động điều hướng tức thì đối với hoạt động kinh doanh, bạn có thể quyết định xem có nên đầu tư thêm nỗ lực vào việc sử dụng công nghệ này để cho phép hiển thị 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 các trang được truy cập sau khi kết xuất trước, bạn cũng cần phải đo lường các 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 hết tài nguyên có giá trị của người dùng mà không mang lại lợi ích gì.

Bạn có thể đo lường việc này bằng cách kích hoạt một sự kiện phân tích khi các quy tắc suy đoán được chèn vào (sau khi kiểm tra, trình duyệt có hỗ trợ kết xuất trước bằng HTMLScriptElement.supports('speculationrules')) để cho biết rằng đã yêu cầu kết xuất trước. (Lưu ý rằng chỉ vì 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 đã được bắt đầu hoặc hoàn tất vì như đã lưu ý trước đó, quá trình kết xuất trước là một gợi ý cho trình duyệt và có thể chọn không kết xuất trước các trang trong 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 đoán khác.)

Sau đó, bạn có thể so sánh số lượng những sự kiện này với số lượt xem trang kết xuất trước thực tế. Hoặc bạn có thể kích hoạt một sự kiện khác khi kích hoạt nếu việc đó giúp bạn so sánh dễ dàng hơn.

Sau đó, "tỷ lệ truy cập thành công" có thể được ước chừng bằng cách xem xét sự khác biệt giữa hai số liệu này. Đối với các trang mà bạn đang sử dụng API Quy tắc suy đoán để kết xuất trước các trang, bạn có thể điều chỉnh các quy tắc một cách thích hợp nhằm đảm bảo giữ được tỷ lệ truy cập cao nhằm duy trì sự cân bằng giữa việc sử dụng hết tài nguyên của người dùng để giúp họ so với việc sử dụng tài nguyên đó không cần thiết.

Xin lưu ý rằng một số quá trình kết xuất trước có thể diễn ra do quá trình kết xuất trước trên thanh địa chỉ chứ không chỉ do các quy tắc suy đoán của bạn. Bạn có thể kiểm tra document.referrer (sẽ trống đối với thao tác trên thanh địa chỉ, bao gồm cả thao tác trên thanh địa chỉ được kết xuất trước) nếu muốn phân biệt những thao tác này.

Hãy nhớ cũng xem xét các trang không có kết xuất trước, vì điều đó có thể cho biết các trang này không đủ điều kiện để kết xuất 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 thêm công cụ bổ sung để kiểm tra điều kiện kết xuất trước, có thể tương tự như công cụ kiểm tra bfcache và cũng có thể thêm một API để biết lý do quá trình kết xuất trước không thành công.

Tác động đối với tiện ích

Xem bài đăng chuyên đề về Tiện ích của Chrome: Mở rộng API để hỗ trợ Điều hướng tức thì, trong đó trình bày chi tiết một số yếu tố khác mà tác giả tiện ích cần cân nhắc đối với các trang được kết xuất trước.

Ý kiến 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à họ 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 về kho lưu trữ GitHub hoặc về việc sử dụng 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

Xác nhận

Hình thu nhỏ của Marc-Olivier Jodoin trên Unsplash

Trình kết xuất trước trang trong Chrome để di chuyển trang tức thì

Nhật ký ngắn gọn về quá trình kết xuất trước

Trang được kết xuất trước như thế nào?

Tác động của việc kết xuất trước

Xem các đề xuất trên thanh địa chỉ của Chrome

Speculation Rules API

Háo hức

Tìm nạp trước

Giới hạn của Chrome

Cách bao gồm các quy tắc suy đoán trên một trang

Tiêu đề HTTP Speculation-Rules

Các quy tắc suy đoán và SPA

Gỡ lỗi quy tắc suy đoán

Nhiều quy tắc suy đoán

Hỗ trợ của No-Vary-Search

Các hạn chế đối với quy tắc suy đoán và các cải tiến trong tương lai

Hỗ trợ Phát hiện quy tắc suy đoán

Thêm một cách linh động các quy tắc suy đoán thông qua JavaScript

Thêm quy tắc suy đoán thông qua trình quản lý thẻ

Huỷ quy tắc suy đoán

Quy tắc suy đoán và Chính sách bảo mật nội dung

Phát hiện và vô hiệu hoá kết xuất trước

Bật và tắt tính năng kết xuất trước trong Chrome

Phát hiện và tắt tính năng kết xuất trước ở phía máy chủ

Phát hiện quá trình kết xuất trước trong JavaScript

Tác động đến số liệu phân tích

Giữ lại nội dung khác trong khi kết xuất trước

Đo lường hiệu suất

Đo lường quá trình kết xuất trước

Đo lường tỷ lệ truy cập

Tác động đối với tiện ích

Ý kiến phản hồi

Đường liên kết có liên quan

Xác nhận

Tiêu đề HTTP `Speculation-Rules`

Hỗ trợ của `No-Vary-Search`