Tải trang nhanh hơn nhờ thời gian suy nghĩ của máy chủ nhờ tính năng Gợi ý sớm

Tìm hiểu cách máy chủ của bạn có thể gửi gợi ý cho trình duyệt về các tài nguyên phụ quan trọng.

Gợi ý ban đầu là gì?

Các trang web trở nên tinh vi hơn theo thời gian. Do đó, không có gì lạ khi máy chủ cần thực hiện các công việc không quan trọng (ví dụ: quyền truy cập vào cơ sở dữ liệu hoặc CDN truy cập vào máy chủ gốc) để tạo HTML cho trang được yêu cầu. Rất tiếc, "thời gian suy nghĩ của máy chủ" này sẽ khiến trình duyệt có thêm độ trễ trước khi có thể bắt đầu hiển thị trang. Trên thực tế, kết nối sẽ không hoạt động một cách hiệu quả miễn là máy chủ cần chuẩn bị phản hồi.

Gợi ý sớm là một mã trạng thái HTTP (103 Early Hints) dùng để gửi phản hồi HTTP sơ bộ trước khi có phản hồi cuối cùng. Điều này cho phép máy chủ gửi gợi ý đến trình duyệt về các tài nguyên phụ quan trọng (ví dụ: biểu định kiểu cho trang, JavaScript quan trọng) hoặc nguồn gốc có thể được trang sử dụng, trong khi máy chủ đang bận tạo tài nguyên chính. Trình duyệt có thể sử dụng các gợi ý đó để khởi động kết nối và yêu cầu tài nguyên phụ trong khi chờ tài nguyên chính. Nói cách khác, Gợi ý sớm giúp trình duyệt tận dụng "thời gian suy nghĩ của máy chủ" bằng cách thực hiện trước một số công việc, nhờ đó tăng tốc độ tải trang.

Trong một số trường hợp, hiệu suất cải thiện đối với Thời gian hiển thị nội dung lớn nhất có thể kéo dài từ vài trăm mili giây (theo quan sát của Shopify và Cloudflare) và nhanh hơn tới một giây như trong bảng so sánh trước/sau:

Triển khai Gợi ý sớm

Trước khi đi sâu vào chủ đề, xin lưu ý rằng tính năng Gợi ý sớm sẽ không hữu ích nếu máy chủ của bạn có thể gửi ngay 200 phản hồi (hoặc các phản hồi cuối cùng khác). Thay vào đó, hãy cân nhắc sử dụng link rel=preload hoặc link rel=preconnect thông thường trên phản hồi chính (Tiêu đề HTTP liên kết rel) hoặc trong phản hồi chính (các phần tử <link>) trong những trường hợp như vậy. Đối với những trường hợp máy chủ của bạn cần một ít thời gian để tạo phản hồi chính, hãy đọc tiếp!

Bước đầu tiên để tận dụng tính năng Gợi ý sớm bao gồm việc xác định các trang đích hàng đầu, tức là các trang mà người dùng thường bắt đầu khi họ truy cập vào trang web của bạn. Đây có thể là trang chủ hoặc các trang danh sách sản phẩm phổ biến nếu bạn có nhiều người dùng đến từ các trang web khác. Lý do các điểm truy cập này quan trọng hơn các trang khác là vì tính hữu ích của Gợi ý sớm giảm khi người dùng di chuyển trong trang web của bạn (nghĩa là trình duyệt có nhiều khả năng có tất cả các tài nguyên phụ cần thiết trong lần điều hướng thứ hai hoặc thứ ba tiếp theo). Tạo ấn tượng ban đầu thật tốt cũng luôn là một ý hay!

Giờ đây, khi đã có danh sách các trang đích được ưu tiên này, bạn cần thực hiện bước tiếp theo là xác định những nguồn gốc hoặc tài nguyên phụ phù hợp để sử dụng gợi ý kết nối trước hoặc tải trước dưới dạng phép ước tính đầu tiên. Thông thường, đó sẽ là những nguồn gốc và tài nguyên phụ đóng góp nhiều nhất vào các chỉ số người dùng chính, chẳng hạn như Thời gian hiển thị nội dung lớn nhất hoặc Thời gian hiển thị nội dung đầu tiên. Cụ thể hơn, hãy tìm các tài nguyên phụ chặn hiển thị, chẳng hạn như JavaScript đồng bộ, biểu định kiểu hoặc thậm chí là phông chữ web. Tương tự, hãy tìm những nguồn gốc lưu trữ tài nguyên phụ đóng góp nhiều vào các chỉ số người dùng chính. Lưu ý: nếu tài nguyên chính của bạn đang sử dụng <link rel=preconnect> hoặc <link rel=preload>, thì bạn có thể xem xét các nguồn gốc hoặc tài nguyên này trong số các đề xuất cho Gợi ý sớm. Hãy xem bài viết này để biết thêm thông tin chi tiết.

Bước thứ hai bao gồm giảm thiểu nguy cơ sử dụng tính năng Gợi ý sớm đối với các tài nguyên hoặc nguồn gốc có thể đã lỗi thời hoặc không còn được tài nguyên chính sử dụng. Ví dụ: những tài nguyên được cập nhật và tạo phiên bản thường xuyên (ví dụ: example.com/css/main.fa231e9c.css) có thể không phải là lựa chọn tốt nhất. Xin lưu ý rằng mối lo ngại này không chỉ dành riêng cho tính năng Gợi ý sớm mà áp dụng cho mọi đường liên kết rel=preload hoặc rel=preconnect, bất kể đường liên kết nào có thể xuất hiện. Đây là loại chi tiết được xử lý tốt nhất trong quy trình tự động hoá hoặc tạo mẫu (ví dụ: một quy trình thủ công có nhiều khả năng dẫn đến hàm băm hoặc URL phiên bản không khớp giữa link rel=preload và thẻ HTML thực tế đang sử dụng tài nguyên).

Ví dụ: hãy xem xét quy trình sau đây:

GET /main.html
Host: example.com
User-Agent: [....] Chrome/103.0.0.0 [...]

Máy chủ dự đoán rằng sẽ cần đến main.abcd100.css và đề xuất tải trước đối tượng này thông qua tính năng Gợi ý sớm:

103 Early Hints
Link: </main.abcd100.css>; rel=preload; as=style
[...]

Một lúc sau, trang web (bao gồm cả CSS đã liên kết) được phân phát. Rất tiếc, tài nguyên CSS này thường xuyên được cập nhật và tài nguyên chính đã vượt quá 5 phiên bản trước (abcd105) so với tài nguyên CSS được dự đoán (abcd100).

200 OK
[...]
<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.abcd105.css">

Nhìn chung, hãy nhắm đến các tài nguyên và nguồn gốc khá ổn định và phần lớn độc lập với kết quả của tài nguyên chính. Nếu cần, bạn có thể cân nhắc chia các tài nguyên chính của mình thành hai phần: một phần ổn định được thiết kế để sử dụng với Gợi ý ban đầu và một phần linh động hơn sẽ được tìm nạp sau khi trình duyệt nhận được tài nguyên chính:

<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.css">
   <link rel="stylesheet" href="/experimental.3eab3290.css">

Cuối cùng, ở phía máy chủ, hãy tìm các yêu cầu về tài nguyên chính được gửi bởi các trình duyệt được xác định là có hỗ trợ Gợi ý sớm và phản hồi ngay lập tức bằng 103 Gợi ý sớm. Trong phản hồi 103, hãy thêm các gợi ý kết nối trước và tải trước có liên quan. Khi tài nguyên chính đã sẵn sàng, hãy phản hồi như thông thường (ví dụ: 200 OK nếu thành công). Để có khả năng tương thích ngược, bạn cũng nên đưa tiêu đề HTTP Link vào phản hồi cuối cùng. Thậm chí, việc bổ sung các tài nguyên quan trọng đã trở nên rõ ràng trong quá trình tạo tài nguyên chính (ví dụ: phần động của tài nguyên chính nếu bạn làm theo đề xuất "chia làm hai"). Đoạn mã này sẽ có dạng như sau:

GET /main.html
Host: example.com
User-Agent: [....] Chrome/103.0.0.0 [...]
103 Early Hints
Link: <https://fonts.google.com>; rel=preconnect
Link: </main.css>; rel=preload; as=style
Link: </common.js>; rel=preload; as=script

Một lúc sau:

200 OK
Content-Length: 7531
Content-Type: text/html; charset=UTF-8
Content-encoding: br
Link: <https://fonts.google.com>; rel=preconnect
Link: </main.css>; rel=preload; as=style
Link: </common.js>; rel=preload; as=script
Link: </experimental.3eab3290.css>; rel=preload; as=style
<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.css">
   <link rel="stylesheet" href="/experimental.3eab3290.css">
   <script src="/common.js"></script>
   <link rel="preconnect" href="https://fonts.googleapis.com">

Hỗ trợ trình duyệt

Mặc dù tất cả các trình duyệt chính đều hỗ trợ 103 Gợi ý sớm, nhưng tuỳ theo trình duyệt, các lệnh có thể gửi được Gợi ý sớm sẽ khác nhau:

Hỗ trợ kết nối trước:

Hỗ trợ tải trước:

Hỗ trợ máy chủ

Dưới đây là thông tin tóm tắt ngắn gọn về mức độ hỗ trợ tính năng Gợi ý sớm trong số phần mềm máy chủ OSS HTTP phổ biến:

• Apache: được hỗ trợ qua mod_http2.
• H2O: được hỗ trợ.
• NGINX: mô-đun thử nghiệm.
• Nút: được hỗ trợ kể từ 18.11.0 cho http và http2

Bật tính năng Gợi ý sớm, một cách dễ dàng

Nếu đang sử dụng một trong các CDN hoặc nền tảng sau đây, bạn có thể không cần triển khai tính năng Gợi ý sớm theo cách thủ công. Hãy tham khảo tài liệu trực tuyến của nhà cung cấp giải pháp để tìm hiểu xem tài liệu đó có hỗ trợ tính năng Gợi ý sớm hay không, hoặc tham khảo danh sách chưa đầy đủ tại đây:

• Gợi ý sớm tại Cloudflare
• Gợi ý sớm tại Nhanh.
• Gợi ý sớm tại Akamai.

Tránh các vấn đề đối với khách hàng không hỗ trợ tính năng Gợi ý sớm

Phản hồi HTTP thông tin trong phạm vi 100 là một phần của tiêu chuẩn HTTP, nhưng một số ứng dụng hoặc bot cũ có thể gặp khó khăn với những phản hồi này bởi vì trước khi ra mắt 103 Gợi ý sớm, chúng hiếm khi được sử dụng để duyệt web nói chung.

Chỉ đưa ra 103 Gợi ý sớm để phản hồi các ứng dụng khách gửi tiêu đề yêu cầu HTTP sec-fetch-mode: navigate phải đảm bảo các gợi ý đó chỉ được gửi cho những ứng dụng khách mới hơn hiểu để chờ phản hồi tiếp theo. Ngoài ra, vì tính năng Gợi ý sớm chỉ được hỗ trợ trong các yêu cầu điều hướng (xem các giới hạn hiện tại), nên tính năng này mang lại lợi ích bổ sung là tránh được việc gửi một cách không cần thiết những yêu cầu này trên các yêu cầu khác.

Ngoài ra, Gợi ý sớm chỉ nên được gửi qua kết nối HTTP/2 hoặc HTTP/3.

Mẫu nâng cao

Nếu đã áp dụng đầy đủ Gợi ý sớm cho trang đích chính của mình và nhận thấy mình đang tìm kiếm thêm cơ hội, bạn có thể sẽ quan tâm đến các mẫu nâng cao sau đây.

Đối với những khách truy cập đang yêu cầu trang thứ n trong hành trình của người dùng thông thường, bạn nên điều chỉnh phản hồi Gợi ý sớm cho phù hợp với nội dung thấp hơn và sâu hơn trên trang, nói cách khác là sử dụng Gợi ý sớm trên các tài nguyên có mức độ ưu tiên thấp hơn. Điều này nghe có vẻ khác thường vì chúng tôi khuyên bạn nên tập trung vào các tài nguyên phụ hoặc nguồn gốc có mức độ ưu tiên cao và chặn hiển thị. Tuy nhiên, vào thời điểm khách truy cập đã điều hướng trong một thời gian, rất có thể trình duyệt của họ đã có tất cả các tài nguyên quan trọng. Từ đó trở đi, bạn nên chuyển sang sử dụng các tài nguyên có mức độ ưu tiên thấp hơn. Ví dụ: điều này có nghĩa là bạn có thể sử dụng Gợi ý ban đầu để tải hình ảnh sản phẩm hoặc JS/CSS bổ sung chỉ cần thiết cho các tương tác ít phổ biến của người dùng.

Các hạn chế hiện tại

Dưới đây là các hạn chế của tính năng Gợi ý sớm khi được triển khai trong Chrome:

• Chỉ dành cho các yêu cầu điều hướng (tức là tài nguyên chính của tài liệu cấp cao nhất).
• Chỉ hỗ trợ preconnect và preload (tức là prefetch không được hỗ trợ).
• Gợi ý sớm, theo sau là lệnh chuyển hướng nhiều nguồn gốc trong phản hồi cuối cùng sẽ khiến Chrome bỏ các tài nguyên và kết nối nhận được thông qua tính năng Gợi ý sớm.

Các trình duyệt khác có các giới hạn tương tự và hơn nữa giới hạn hơn nữa 103 gợi ý ban đầu chỉ cho preconnect.

Tiếp theo là gì?

Tuỳ thuộc vào sự quan tâm của cộng đồng, chúng tôi có thể tăng cường việc triển khai Gợi ý sớm với các khả năng sau:

• Gợi ý ban đầu được gửi trên các yêu cầu về tài nguyên phụ.
• Thông tin gợi ý ban đầu được gửi trên các yêu cầu về tài nguyên chính của iframe.
• Hỗ trợ tìm nạp trước trong tính năng Gợi ý sớm.

Chúng tôi hoan nghênh ý kiến đóng góp của bạn về những khía cạnh cần ưu tiên và cách cải thiện tính năng Gợi ý sớm.

Mối quan hệ với H2/Đẩy

Nếu đã quen thuộc với tính năng Đẩy/HTTP2 không dùng nữa, có thể bạn sẽ thắc mắc về sự khác biệt của tính năng Gợi ý sớm. Mặc dù tính năng Gợi ý sớm yêu cầu trình duyệt phải đi vòng quanh để bắt đầu tìm nạp các tài nguyên phụ quan trọng, nhưng với HTTP2/Đẩy máy chủ, máy chủ có thể bắt đầu đẩy các tài nguyên phụ cùng với phản hồi. Mặc dù điều này nghe có vẻ tuyệt vời, nhưng điều này dẫn đến một nhược điểm chính về cấu trúc: với HTTP2/Push, rất khó để tránh đẩy các tài nguyên phụ mà trình duyệt đã có. Hiệu ứng "đẩy quá" này dẫn đến việc sử dụng băng thông mạng kém hiệu quả, gây cản trở đáng kể đến lợi ích hiệu suất. Nhìn chung, dữ liệu của Chrome cho thấy HTTP2/Đẩy thực tế có tác động tiêu cực đối với hiệu suất trên web.

Ngược lại, tính năng Gợi ý sớm hoạt động tốt hơn trong thực tế vì nó kết hợp khả năng gửi phản hồi sơ bộ với các gợi ý cho phép trình duyệt chịu trách nhiệm tìm nạp hoặc kết nối với những gì thực sự cần. Mặc dù tính năng Gợi ý sớm không bao gồm tất cả các trường hợp sử dụng mà HTTP2/Đẩy có thể giải quyết trên lý thuyết, nhưng chúng tôi tin rằng Gợi ý sớm là một giải pháp thiết thực hơn để tăng tốc độ điều hướng.

Hình thu nhỏ của Pierre Bamin.