Việc phát triển các trang web với tốc độ nhanh ở mọi nơi có thể là một khách hàng tiềm năng khó khăn. Sự đa dạng về tính năng của thiết bị (và chất lượng mạng mà các thiết bị kết nối) có thể khiến đây là một nhiệm vụ không thể vượt qua được. Mặc dù chúng ta có thể tận dụng các tính năng của trình duyệt để cải thiện hiệu suất tải, nhưng làm cách nào để biết thiết bị của người dùng có khả năng hoạt động như thế nào hoặc chất lượng kết nối mạng của họ? Giải pháp là gợi ý của ứng dụng!
Gợi ý ứng dụng là một tập hợp các tiêu đề của yêu cầu HTTP chọn tham gia, cung cấp cho chúng ta thông tin chi tiết về các khía cạnh này trên thiết bị của người dùng và mạng mà họ kết nối. Bằng cách nhấn vào phía máy chủ thông tin này, chúng ta có thể thay đổi cách phân phối nội dung dựa trên điều kiện thiết bị và/hoặc mạng. Điều này có thể giúp chúng tôi tạo ra trải nghiệm người dùng hoà nhập hơn.
Tất cả đều là về thương lượng nội dung
Gợi ý ứng dụng là một phương thức khác để thương lượng nội dung, có nghĩa là thay đổi phản hồi nội dung dựa trên tiêu đề yêu cầu của trình duyệt.
Một ví dụ về quy trình thương lượng nội dung có liên quan đến tiêu đề yêu cầu Accept. Phương thức này mô tả loại nội dung mà trình duyệt hiểu được, mà máy chủ có thể sử dụng để thương lượng phản hồi. Đối với các yêu cầu về hình ảnh, nội dung
tiêu đề Accept của Chrome là:
Accept: image/webp,image/apng,image/*,*/*;q=0.8
Mặc dù tất cả các trình duyệt đều hỗ trợ các định dạng hình ảnh như JPEG, PNG và GIF, nhưng trong trường hợp này, Accept (Chấp nhận) cho biết trình duyệt cũng hỗ trợ WebP và APNG. Nhờ thông tin này, chúng ta có thể thương lượng các loại hình ảnh tốt nhất cho mỗi trình duyệt:
<?php
// Check Accept for an "image/webp" substring.
$webp = stristr($_SERVER["HTTP_ACCEPT"], "image/webp") !== false ? true : false;
// Set the image URL based on the browser's WebP support status.
$imageFile = $webp ? "whats-up.webp" : "whats-up.jpg";
?>
<img src="<?php echo($imageFile); ?>" alt="I'm an image!">
Giống như Accept, gợi ý ứng dụng là một cách khác để thương lượng nội dung, nhưng trong bối cảnh các chức năng của thiết bị và điều kiện mạng. Với gợi ý của ứng dụng, chúng ta có thể đưa ra quyết định về hiệu suất phía máy chủ dựa trên trải nghiệm cá nhân của người dùng, chẳng hạn như quyết định xem có nên phân phát các tài nguyên không quan trọng cho người dùng có điều kiện mạng kém hay không. Trong hướng dẫn này, chúng tôi sẽ mô tả tất cả các gợi ý hiện có và một số cách bạn có thể sử dụng để giúp việc phân phối nội dung phù hợp hơn với người dùng.
Chọn tham gia
Không giống như tiêu đề Accept, gợi ý của ứng dụng không chỉ xuất hiện một cách kỳ diệu (ngoại trừ Save-Data mà chúng ta sẽ thảo luận sau). Để duy trì ở mức tối thiểu các tiêu đề của yêu cầu, bạn cần chọn sử dụng gợi ý của ứng dụng mà bạn muốn nhận được bằng cách gửi tiêu đề Accept-CH khi người dùng yêu cầu một tài nguyên:
Accept-CH: Viewport-Width, Downlink
Giá trị của Accept-CH là một danh sách các gợi ý được yêu cầu được phân tách bằng dấu phẩy mà trang web sẽ sử dụng để xác định kết quả cho yêu cầu tài nguyên tiếp theo. Khi ứng dụng đọc tiêu đề này, ứng dụng sẽ nhận được thông báo là "trang web này muốn nhận gợi ý của ứng dụng Viewport-Width và Downlink". Đừng lo lắng về các gợi ý cụ thể.
Chúng ta sẽ giải quyết vấn đề đó trong giây lát.
Bạn có thể đặt các tiêu đề chọn tham gia này bằng bất kỳ ngôn ngữ phụ trợ nào. Ví dụ: bạn có thể sử dụng hàm header của PHP.
Thậm chí, bạn có thể đặt các tiêu đề chọn tham gia này bằng thuộc tính http-equiv
trong thẻ <meta>:
<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink" />
Tất cả các gợi ý của khách hàng!
Gợi ý ứng dụng mô tả một trong hai điều: thiết bị của người dùng, cách sử dụng và mạng mà họ sử dụng để truy cập trang web của bạn. Hãy xem qua tất cả các gợi ý có sẵn.
Gợi ý về thiết bị
Một số gợi ý ứng dụng mô tả các đặc điểm thiết bị của người dùng, thường là các đặc điểm trên màn hình. Một vài trong số các thành phần này có thể giúp bạn chọn tài nguyên nội dung nghe nhìn tối ưu cho màn hình của người dùng nhất định, nhưng không phải tất cả các thành phần này đều tập trung vào nội dung nghe nhìn.
Trước khi tìm hiểu về danh sách này, bạn nên tìm hiểu một số thuật ngữ chính dùng để mô tả màn hình và độ phân giải nội dung nghe nhìn:
Kích thước nội tại: kích thước thực tế của một tài nguyên nội dung đa phương tiện. Ví dụ: nếu bạn mở một hình ảnh trong Photoshop, thì kích thước hiển thị trong hộp thoại kích thước hình ảnh mô tả kích thước nội tại của hình ảnh đó.
Kích thước hàm nội tại được điều chỉnh theo mật độ: kích thước của một tài nguyên nội dung đa phương tiện sau khi được hiệu chỉnh theo mật độ pixel. Đó là kích thước nội tại của hình ảnh chia cho tỷ lệ pixel của thiết bị. Ví dụ: hãy cùng sử dụng mã đánh dấu này:
<img
src="whats-up-1x.png"
srcset="whats-up-2x.png 2x, whats-up-1x.png 1x"
alt="I'm that image you wanted."
/>
Giả sử kích thước nội tại của hình ảnh 1x trong trường hợp này là 320x240 và kích thước nội tại của hình ảnh 2x là 640x480. Nếu mã đánh dấu này được phân tích cú pháp bằng một ứng dụng cài đặt trên thiết bị có tỷ lệ pixel của thiết bị màn hình là 2 (ví dụ: màn hình Retina), thì hình ảnh 2x sẽ được yêu cầu. Kích thước hàm nội tại được điều chỉnh theo mật độ của hình ảnh 2x là 320x240, vì 640x480 chia cho 2 là 320x240.
Kích thước bên ngoài: kích thước của một tài nguyên nội dung đa phương tiện sau khi áp dụng CSS và các yếu tố bố cục khác (chẳng hạn như các thuộc tính width và height). Giả sử bạn có một phần tử <img> tải một hình ảnh có kích thước nội tại được chỉnh sửa theo mật độ là 320x240, nhưng phần tử này cũng có các thuộc tính CSS width và height với giá trị 256px và 192px được áp dụng tương ứng. Trong ví dụ này, kích thước bên ngoài của phần tử <img> đó sẽ trở thành 256x192.
width: 256px;
và height: 192px; sẽ chuyển đổi hình ảnh có kích thước nội tại 320x240
thành hình ảnh có kích thước bên ngoài 256x192.Với một số thuật ngữ, hãy cùng đi vào danh sách các gợi ý ứng dụng dành riêng cho thiết bị mà bạn có.
Chiều rộng khung nhìn
Viewport-Width là chiều rộng của khung nhìn của người dùng tính bằng pixel CSS:
Viewport-Width: 320
Bạn có thể sử dụng gợi ý này với các gợi ý khác cho từng màn hình để cung cấp các phương pháp xử lý khác nhau (tức là cắt) của một hình ảnh tối ưu cho các kích thước màn hình cụ thể (tức là hướng nghệ thuật) hoặc để bỏ qua các tài nguyên không cần thiết cho chiều rộng màn hình hiện tại.
DPR
DPR là từ viết tắt của tỷ lệ pixel của thiết bị, báo cáo tỷ lệ pixel vật lý trên pixel CSS trên màn hình của người dùng:
DPR: 2
Gợi ý này sẽ hữu ích khi chọn nguồn hình ảnh tương ứng với mật độ pixel của màn hình (như bộ mô tả x có trong thuộc tính srcset).
Chiều rộng
Gợi ý Width xuất hiện trong các yêu cầu về tài nguyên hình ảnh do thẻ <img> hoặc <source> kích hoạt bằng thuộc tính sizes.
sizes cho trình duyệt biết kích thước bên ngoài của tài nguyên sẽ là bao nhiêu; Width sử dụng kích thước bên ngoài đó để yêu cầu một hình ảnh có kích thước nội tại tối ưu cho bố cục hiện tại.
Ví dụ: giả sử người dùng yêu cầu một trang có màn hình rộng 320 pixel CSS với DPR là 2. Thiết bị tải tài liệu có phần tử <img> chứa giá trị thuộc tính sizes là 85vw (tức là 85% chiều rộng khung nhìn cho tất cả kích thước màn hình). Nếu đã chọn sử dụng gợi ý Width, ứng dụng sẽ gửi gợi ý Width này đến máy chủ cùng với yêu cầu về src của <img>:
Width: 544
Trong trường hợp này, ứng dụng sẽ gợi ý cho máy chủ rằng chiều rộng hàm nội tại tối ưu cho hình ảnh được yêu cầu sẽ bằng 85% chiều rộng khung nhìn (272 pixel) nhân với DPR của màn hình (2), bằng 544 pixel.
Gợi ý này đặc biệt hiệu quả vì nó không chỉ tính đến chiều rộng đã được điều chỉnh theo mật độ của màn hình, mà còn điều chỉnh thông tin quan trọng này với kích thước bên ngoài của hình ảnh trong bố cục. Điều này giúp máy chủ có cơ hội thương lượng các phản hồi hình ảnh tối ưu cho cả màn hình và bố cục.
Nội dung-DPR
Mặc dù bạn đã biết rằng màn hình có tỷ lệ pixel của thiết bị, nhưng các tài nguyên cũng có tỷ lệ pixel riêng. Trong các trường hợp sử dụng lựa chọn tài nguyên đơn giản nhất, tỷ lệ pixel giữa các thiết bị và tài nguyên có thể giống nhau. Tuy nhiên! Trong trường hợp cả tiêu đề DPR và Width đều đang hoạt động, kích thước bên ngoài của một tài nguyên có thể tạo ra các tình huống khác nhau. Đây là khi gợi ý Content-DPR phát huy tác dụng.
Không giống như các gợi ý khác của ứng dụng, Content-DPR không phải là tiêu đề yêu cầu để máy chủ sử dụng, mà là máy chủ tiêu đề phản hồi phải gửi bất cứ khi nào gợi ý DPR và Width được dùng để chọn tài nguyên. Giá trị của Content-DPR phải là kết quả của phương trình sau:
Content-DPR = [Kích thước tài nguyên hình ảnh đã chọn] / ([Width] / [DPR])
Khi tiêu đề của yêu cầu Content-DPR được gửi, trình duyệt sẽ biết cách điều chỉnh tỷ lệ hình ảnh đã cho cho tỷ lệ pixel của thiết bị trên màn hình và bố cục. Nếu không, hình ảnh có thể không điều chỉnh được tỷ lệ đúng cách.
Bộ nhớ thiết bị
Về mặt kỹ thuật, là một phần của API Bộ nhớ thiết bị, Device-Memory cho thấy lượng bộ nhớ ước tính mà thiết bị hiện có trong GiB:
Device-Memory: 2
Có thể sử dụng gợi ý này để giảm lượng JavaScript được gửi đến các trình duyệt trên các thiết bị có bộ nhớ hạn chế, vì JavaScript là loại nội dung tốn nhiều tài nguyên nhất mà các trình duyệt thường tải. Hoặc bạn có thể gửi hình ảnh DPR thấp hơn vì những hình ảnh này sử dụng ít bộ nhớ hơn để giải mã.
Gợi ý mạng
API Thông tin mạng cung cấp một danh mục khác của gợi ý ứng dụng, mô tả hiệu suất kết nối mạng của người dùng. Theo tôi, đây là những gợi ý hữu ích nhất. Nhờ những công cụ này, chúng tôi có thể điều chỉnh trải nghiệm cho phù hợp với người dùng bằng cách thay đổi cách chúng tôi phân phối tài nguyên cho ứng dụng trên các kết nối chậm.
Tin nhắn theo thời gian thực
Gợi ý RTT cung cấp Thời gian trọn vòng ước tính, tính bằng mili giây, trên lớp ứng dụng. Gợi ý RTT, không giống như lớp truyền tải RTT, bao gồm cả thời gian xử lý của máy chủ.
RTT: 125
Gợi ý này hữu ích do độ trễ có vai trò quan trọng trong hiệu suất tải.
Khi sử dụng gợi ý RTT, chúng ta có thể đưa ra quyết định dựa trên khả năng phản hồi của mạng. Việc này có thể giúp tăng tốc độ phân phối toàn bộ trải nghiệm (ví dụ: thông qua việc bỏ qua một số yêu cầu).
Đường xuống
Mặc dù độ trễ rất quan trọng đối với hiệu suất tải, nhưng băng thông cũng ảnh hưởng đến. Gợi ý Downlink, được biểu thị bằng megabit/giây (Mb/giây), cho thấy tốc độ hạ nguồn ước chừng của kết nối của người dùng:
Downlink: 2.5
Cùng với RTT, Downlink có thể hữu ích trong việc thay đổi cách phân phối nội dung đến người dùng dựa trên chất lượng kết nối mạng.
ECT
Gợi ý ECT là viết tắt của Hiệu ứng kết nối. Giá trị của kiểu kết nối này là một trong danh sách liệt kê các loại kết nối, mỗi kiểu kết nối mô tả một kết nối trong phạm vi được chỉ định của cả giá trị RTT và Downlink.
Tiêu đề này không giải thích loại kết nối thực tế là gì. Ví dụ: tiêu đề không báo cáo liệu cổng vào của bạn là trạm phát sóng hay điểm truy cập Wi-Fi. Thay vào đó, công cụ này phân tích độ trễ và băng thông của kết nối hiện tại, đồng thời xác định cấu hình mạng giống với kết nối đó nhất. Ví dụ: nếu bạn kết nối qua Wi-Fi với một mạng chậm, thì ECT có thể được điền giá trị 2g. Đây là giá trị gần đúng nhất của kết nối hiệu quả:
ECT: 2g
Giá trị hợp lệ cho ECT là 4g, 3g, 2g và slow-2g. Gợi ý này có thể được dùng làm điểm xuất phát để đánh giá chất lượng kết nối, sau đó tinh chỉnh bằng cách sử dụng các gợi ý RTT và Downlink.
Lưu dữ liệu
Save-Data không phải là gợi ý mô tả tình trạng mạng vì đây là lựa chọn ưu tiên của người dùng cho biết rằng các trang nên gửi ít dữ liệu hơn.
Tôi muốn phân loại Save-Data là gợi ý mạng vì nhiều thao tác bạn sẽ thực hiện với gợi ý mạng này cũng tương tự như các gợi ý mạng khác. Người dùng cũng có thể bật tính năng này trong môi trường có độ trễ cao/băng thông thấp. Gợi ý này, khi có, luôn có dạng như sau:
Save-Data: on
Tại Google, chúng tôi đã thảo luận về những việc bạn có thể làm với Save-Data.
Tác động mà giải pháp này có thể tác động đến hiệu suất có thể rất sâu sắc. Đó là tín hiệu cho thấy người dùng
thực sự yêu cầu bạn gửi ít nội dung hơn! Nếu bạn lắng nghe và hành động dựa vào tín hiệu đó, người dùng sẽ đánh giá cao tín hiệu đó.
Cùng nhau hợp tác
Những việc bạn làm với gợi ý của ứng dụng phụ thuộc vào bạn. Vì họ cung cấp rất nhiều thông tin, nên bạn có nhiều lựa chọn. Để có được một số ý tưởng, hãy xem gợi ý về khách hàng có thể làm gì cho Sconnie Timber, một công ty gỗ hư cấu nằm ở vùng nông thôn Trung Tây Trung Bộ. Như thường lệ ở các khu vực từ xa, kết nối mạng có thể không ổn định. Đây là khi mà một công nghệ như gợi ý của ứng dụng khách có thể thực sự tạo ra sự khác biệt cho người dùng.
Hình ảnh thích ứng
Tất cả trừ các trường hợp sử dụng hình ảnh thích ứng đơn giản nhất có thể trở nên phức tạp. Nếu bạn có nhiều phương pháp xử lý và biến thể của cùng một hình ảnh cho các kích thước màn hình khác nhau và các định dạng khác nhau thì sao? Mã đánh dấu đó rất phức tạp rất nhanh chóng.
Thông tin này rất dễ hiểu nhầm và dễ quên hoặc hiểu sai các khái niệm quan trọng (chẳng hạn như sizes).
Mặc dù chắc chắn <picture> và srcset là các công cụ tuyệt vời, nhưng việc phát triển và duy trì cho các trường hợp sử dụng phức tạp có thể tốn nhiều thời gian. Chúng tôi có thể tự động hoá việc tạo mã đánh dấu, nhưng việc này cũng khó khăn vì chức năng mà <picture> và srcset cung cấp đủ phức tạp để bạn cần thực hiện quy trình tự động hoá sao cho duy trì tính linh hoạt.
Gợi ý của ứng dụng có thể giúp đơn giản hoá việc này. Việc thương lượng phản hồi bằng hình ảnh bằng gợi ý của ứng dụng có thể có dạng như sau:
- Nếu phù hợp với quy trình công việc của bạn, trước tiên, hãy chọn cách xử lý hình ảnh (tức là hình ảnh hướng đến nghệ thuật) bằng cách chọn gợi ý
Viewport-Width. - Chọn độ phân giải hình ảnh bằng cách kiểm tra gợi ý
Widthvà gợi ýDPR, đồng thời chọn một nguồn phù hợp với kích thước bố cục và mật độ màn hình của hình ảnh (tương tự như cách hoạt động của bộ mô tảxvàwtrongsrcset). - Chọn định dạng tệp tối ưu nhất mà trình duyệt hỗ trợ (một định dạng
Acceptgiúp chúng tôi làm trong hầu hết các trình duyệt).
Khi có lo ngại với khách hàng của một công ty gỗ giả định, tôi đã phát triển một quy trình lựa chọn hình ảnh phản hồi ngây thơ trong PHP, trong đó sử dụng gợi ý của khách hàng. Điều này có nghĩa là thay vì gửi mã đánh dấu này cho tất cả người dùng, hãy làm như sau:
<picture>
<source
srcset="
company-photo-256w.webp 256w,
company-photo-512w.webp 512w,
company-photo-768w.webp 768w,
company-photo-1024w.webp 1024w,
company-photo-1280w.webp 1280w
"
type="image/webp"
/>
<img
srcset="
company-photo-256w.jpg 256w,
company-photo-512w.jpg 512w,
company-photo-768w.jpg 768w,
company-photo-1024w.jpg 1024w,
company-photo-1280w.jpg 1280w
"
src="company-photo-256w.jpg"
sizes="(min-width: 560px) 251px, 88.43vw"
alt="The Sconnie Timber Staff!"
/>
</picture>
Tôi có thể giảm xuống mức sau dựa trên hỗ trợ trình duyệt cá nhân:
<img
src="/image/sizes:true/company-photo.jpg"
sizes="(min-width: 560px) 251px, 88.43vw"
alt="SAY CHEESY PICKLES."
/>
Trong ví dụ này, URL /image là một tập lệnh PHP, theo sau là các tham số được viết lại bởi
mod_rewrite. Chiến lược này sử dụng tên tệp hình ảnh và các tham số bổ sung để giúp tập lệnh phụ trợ chọn hình ảnh phù hợp nhất trong các điều kiện cho trước.
Tôi thấy “Nhưng đây không phải chỉ là đang triển khai lại <picture> và srcset trên phần phụ trợ?” là câu hỏi đầu tiên của bạn.
Có một điểm khác biệt quan trọng: khi một ứng dụng dùng gợi ý của ứng dụng để tạo phản hồi cho nội dung đa phương tiện, hầu hết (nếu không phải là tất cả) công việc đều dễ tự động hoá hơn nhiều, trong đó có thể bao gồm một dịch vụ (như CDN) có thể thay mặt bạn thực hiện việc này. Trong khi với các giải pháp HTML, bạn cần viết mã đánh dấu mới để cung cấp cho mọi trường hợp sử dụng. Chắc chắn rồi, bạn có thể tự động tạo mã đánh dấu. Tuy nhiên, nếu thiết kế hoặc yêu cầu của bạn thay đổi, thì có khả năng bạn sẽ cần xem lại chiến lược tự động hoá của mình trong tương lai.
Gợi ý của ứng dụng giúp bạn có thể bắt đầu với một hình ảnh không tổn hao, có độ phân giải cao, sau đó có thể được đổi kích thước linh hoạt để tối ưu cho bất kỳ tổ hợp màn hình và bố cục nào. Không giống như srcset (yêu cầu bạn liệt kê một danh sách cố định gồm các hình ảnh đề xuất để trình duyệt lựa chọn), phương pháp này có thể linh hoạt hơn. Mặc dù srcset buộc bạn phải cung cấp cho trình duyệt một tập hợp thô các biến thể (ví dụ: 256w, 512w, 768w và 1024w), nhưng một giải pháp do ứng dụng gợi ý có thể phân phát tất cả các chiều rộng mà không có một loạt mã đánh dấu khổng lồ.
Tất nhiên, bạn không phải tự viết logic lựa chọn hình ảnh. Cloudinary sử dụng các gợi ý của ứng dụng để tạo phản hồi hình ảnh khi bạn sử dụng tham số w_auto và quan sát thấy rằng người dùng trung bình tải ít hơn 42% byte xuống khi sử dụng các trình duyệt hỗ trợ gợi ý ứng dụng.
Nhưng hãy thận trọng! Các thay đổi trong phiên bản Chrome 67 dành cho máy tính đã ngừng hỗ trợ các gợi ý của ứng dụng trên nhiều nguồn gốc. Rất may là những hạn chế này không ảnh hưởng đến các phiên bản Chrome dành cho thiết bị di động và sẽ được gỡ bỏ hoàn toàn cho tất cả nền tảng khi hoàn tất Chính sách về tính năng.
Trợ giúp người dùng trên mạng chậm
Hiệu suất thích ứng là ý tưởng giúp chúng ta điều chỉnh cách phân phối tài nguyên dựa trên thông tin mà ứng dụng khách cung cấp cho chúng ta; cụ thể là thông tin liên quan đến trạng thái hiện tại của kết nối mạng của người dùng.
Khi lo ngại về trang web của Sconnie Timber, chúng tôi đã thực hiện các bước để giảm tải khi mạng chậm, với các tiêu đề Save-Data, ECT, RTT và Downlink sẽ được kiểm tra trong mã phụ trợ. Khi việc này hoàn tất, chúng tôi sẽ tạo điểm chất lượng mạng mà chúng tôi có thể dùng để xác định xem có nên can thiệp để mang lại trải nghiệm người dùng tốt hơn hay không. Điểm mạng này nằm trong khoảng từ 0 đến 1, trong đó 0 là chất lượng mạng kém nhất có thể, còn 1 là chất lượng mạng tốt nhất.
Ban đầu, chúng tôi sẽ kiểm tra xem Save-Data có xuất hiện hay không. Nếu có, điểm số sẽ được đặt thành 0, vì chúng tôi giả định người dùng muốn chúng tôi làm bất cứ điều gì cần thiết để giúp trải nghiệm nhẹ hơn và nhanh hơn.
Tuy nhiên, nếu không có Save-Data, chúng ta sẽ chuyển sang và cân nhắc các giá trị của gợi ý ECT, RTT và Downlink để tính điểm số mô tả chất lượng kết nối mạng. Mã nguồn tạo điểm mạng có trên GitHub. Điểm cần lưu ý là nếu sử dụng các gợi ý liên quan đến mạng theo một số gợi ý, chúng ta có thể cải thiện trải nghiệm cho những người sử dụng mạng chậm.
Khi các trang web thích ứng với thông tin mà ứng dụng khách gợi ý, chúng ta không nhất thiết phải áp dụng phương pháp "tất cả hoặc không có gì". Chúng ta có thể quyết định một cách thông minh tài nguyên nào cần gửi. Chúng ta có thể sửa đổi logic lựa chọn hình ảnh thích ứng để gửi hình ảnh có chất lượng thấp hơn cho một màn hình nhất định, nhằm tăng tốc hiệu suất tải khi chất lượng mạng kém.
Trong ví dụ này, chúng ta có thể thấy tác động của các gợi ý ứng dụng khi cải thiện hiệu suất của các trang web trên các mạng chậm hơn. Dưới đây là thác nước WebPagetest của một trang web trên mạng chậm và không thể thích ứng với gợi ý của ứng dụng:
Và giờ đây là thác nước cho cùng một trang web trên cùng một kết nối chậm, ngoại trừ lần này, trang web sử dụng gợi ý của ứng dụng để loại bỏ các tài nguyên trang không quan trọng:
Gợi ý của ứng dụng giúp giảm thời gian tải trang từ hơn 45 giây xuống chưa đến 1/10 thời gian đó. Trong trường hợp này, các gợi ý của ứng dụng chưa được nhấn mạnh đầy đủ và có thể mang lại lợi ích nghiêm trọng cho những người dùng đang tìm kiếm thông tin quan trọng qua các mạng chậm.
Hơn nữa, bạn có thể sử dụng gợi ý của ứng dụng mà không gây ảnh hưởng đến trải nghiệm của các trình duyệt không hỗ trợ gợi ý. Ví dụ: nếu muốn điều chỉnh việc phân phối tài nguyên có kiện giá trị của gợi ý ECT trong khi vẫn cung cấp trải nghiệm đầy đủ cho các trình duyệt không hỗ trợ, chúng ta có thể đặt lại về giá trị mặc định như sau:
// Set the ECT value to "4g" by default.
$ect = isset($_SERVER["HTTP_ECT"]) ? $_SERVER["HTTP_ECT"] : "4g";
Ở đây, "4g" đại diện cho kết nối mạng chất lượng cao nhất mà tiêu đề ECT mô tả. Nếu chúng ta khởi chạy $ect đến "4g", các trình duyệt không hỗ trợ gợi ý của ứng dụng sẽ không bị ảnh hưởng. Chọn tham gia FTW!
Hãy chú ý đến những bộ nhớ đệm này!
Bất cứ khi nào thay đổi phản hồi dựa trên tiêu đề HTTP, bạn cần lưu ý cách bộ nhớ đệm sẽ xử lý các lần tìm nạp sau này cho tài nguyên đó. Tiêu đề Vary là không thể thiếu ở đây, vì tiêu đề này khoá các mục nhập bộ nhớ đệm vào giá trị của các tiêu đề yêu cầu được cung cấp cho nó. Nói một cách đơn giản, nếu sửa đổi bất kỳ phản hồi nào dựa trên một tiêu đề của yêu cầu HTTP nhất định, hầu như lúc nào bạn cũng nên đưa yêu cầu đó vào tiêu đề đó trong Vary như sau:
Vary: DPR, Width
Tuy nhiên, bạn cần lưu ý lớn về điều này: Bạn không bao giờ muốn Vary các phản hồi có thể lưu vào bộ nhớ đệm trên một tiêu đề thay đổi thường xuyên (như Cookie) vì các tài nguyên đó sẽ không thể lưu vào bộ nhớ đệm được. Biết được điều này, bạn có thể cần tránh Vary trên các tiêu đề gợi ý của ứng dụng, chẳng hạn như RTT hoặc Downlink, vì đó là các yếu tố kết nối có thể thay đổi khá thường xuyên. Nếu bạn muốn sửa đổi phản hồi trên các tiêu đề đó, hãy cân nhắc chỉ nhập tiêu đề ECT để giảm thiểu tình trạng bỏ lỡ bộ nhớ đệm.
Tất nhiên, điều này chỉ áp dụng nếu bạn lưu một câu trả lời vào bộ nhớ đệm ngay từ đầu.
Ví dụ: bạn sẽ không lưu các thành phần HTML vào bộ nhớ đệm nếu nội dung của chúng là động, vì điều đó có thể phá vỡ trải nghiệm người dùng khi truy cập nhiều lần. Trong những trường hợp như vậy, vui lòng sửa đổi các phản hồi đó bất cứ khi nào bạn cảm thấy cần thiết và không liên quan đến Vary.
Gợi ý của ứng dụng trong trình chạy dịch vụ
Thương lượng nội dung không còn chỉ dành cho máy chủ nữa! Vì trình chạy dịch vụ đóng vai trò là proxy giữa ứng dụng và máy chủ, nên bạn có quyền kiểm soát cách phân phối tài nguyên qua JavaScript. Quy định này áp dụng cho cả các gợi ý của ứng dụng. Trong sự kiện fetch của trình chạy dịch vụ, bạn có thể sử dụng phương thức request.headers.get của đối tượng event để đọc tiêu đề yêu cầu của một tài nguyên như sau:
self.addEventListener('fetch', (event) => {
let dpr = event.request.headers.get('DPR');
let viewportWidth = event.request.headers.get('Viewport-Width');
let width = event.request.headers.get('Width');
event.respondWith(
(async function () {
// Do what you will with these hints!
})(),
);
});
Bạn có thể đọc mọi tiêu đề gợi ý ứng dụng mà bạn chọn sử dụng theo cách này. Mặc dù đó không phải
là cách duy nhất bạn có thể có được một số thông tin này. Bạn có thể đọc gợi ý dành riêng cho mạng trong các thuộc tính JavaScript tương đương sau đây ở đối tượng navigator:
| Gợi ý ứng dụng | JS tương đương |
|---|---|
| "ECT" | `navigator.connection.effectiveType` |
| "RTT" | "navigation.connection.rtt" |
| "Lưu dữ liệu" | `navigator.connection.saveData` |
| "Đường liên kết xuống" | `navigator.connection.downlink` |
| "Bộ nhớ thiết bị" | "navigation.deviceMemory" |
Vì các API này không có sẵn ở những nơi bạn cần kiểm tra tính năng bằng toán tử in:
if ('connection' in navigator) {
// Work with netinfo API properties in JavaScript!
}
Từ đây, bạn có thể sử dụng logic tương tự như logic bạn sẽ sử dụng trên máy chủ, ngoại trừ việc bạn không cần một máy chủ để thương lượng nội dung bằng các gợi ý của ứng dụng. Chỉ riêng trình chạy dịch vụ mới có thể mang lại trải nghiệm nhanh hơn và phục hồi tốt hơn nhờ khả năng phân phát nội dung bổ sung khi người dùng không kết nối mạng.
Kết thúc
Với các gợi ý của ứng dụng, chúng tôi có thể mang đến trải nghiệm nhanh hơn cho người dùng theo cách tiến bộ hoàn toàn. Chúng tôi có thể phân phát nội dung nghe nhìn dựa trên khả năng thiết bị của người dùng theo cách giúp việc phân phát hình ảnh thích ứng trở nên dễ dàng hơn so với việc dựa vào <picture> và srcset, đặc biệt là đối với các trường hợp sử dụng phức tạp. Điều này cho phép chúng tôi không chỉ giảm thời gian và công sức về mặt phát triển, mà còn tối ưu hoá tài nguyên (đặc biệt là hình ảnh) theo cách nhắm mục tiêu chính xác hơn đến màn hình của người dùng so với
Có lẽ quan trọng hơn, chúng ta có thể loại bỏ kết nối mạng kém và thu hẹp khoảng cách cho người dùng bằng cách sửa đổi nội dung chúng ta gửi và cách chúng ta gửi nội dung đó. Điều này có thể giúp cải thiện tính năng giúp người dùng truy cập vào trang web dễ dàng hơn trên các mạng yếu. Kết hợp với trình chạy dịch vụ, chúng tôi có thể tạo các trang web có tốc độ cực nhanh, có thể sử dụng khi không có mạng.
Mặc dù gợi ý ứng dụng chỉ có trong Chrome và các trình duyệt dựa trên Chromium, nhưng bạn có thể sử dụng gợi ý theo cách không gây trở ngại cho những trình duyệt không hỗ trợ. Hãy cân nhắc sử dụng các gợi ý của ứng dụng khách để tạo ra trải nghiệm thực sự bao quát và dễ điều chỉnh, đồng thời biết được khả năng của mọi thiết bị của người dùng và mạng mà họ kết nối. Hy vọng rằng các nhà cung cấp trình duyệt khác sẽ thấy được giá trị của họ và cho thấy ý định triển khai.
Tài nguyên
- Hình ảnh thích ứng tự động có tính năng Gợi ý của ứng dụng
- Gợi ý ứng dụng và hình ảnh thích ứng – Những thay đổi trong Chrome 67
- Đưa ra Gợi ý (Khách hàng)! (Trang trình bày)
- Cung cấp các ứng dụng nhanh và nhẹ bằng
Save-Data
Cảm ơn Ilya Grigorik, Eric Portis, Jeff Posnick, Yoav Weiss và estelle Weyl về những ý kiến phản hồi và nội dung chỉnh sửa hữu ích trong bài viết này.