Việc phát triển các trang web có tốc độ tải nhanh ở mọi nơi có thể là một triển vọng khó khăn. Vô số chức năng của thiết bị và chất lượng của các mạng mà thiết bị kết nối có thể khiến bạn cảm thấy đây là một nhiệm vụ khó khăn. Mặc dù 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 khả năng của thiết bị người dùng hoặc chất lượng kết nối mạng của họ? Giải pháp là gợi ý cho ứng dụng!
Gợi ý về ứng dụng là một nhóm tiêu đề yêu cầu HTTP chọn sử dụng, giúp chúng tôi nắm được thông tin chi tiết về những khía cạnh này của thiết bị người dùng và mạng mà họ kết nối. Bằng cách khai thác thông tin này ở phía máy chủ, chúng tôi có thể thay đổi cách phân phối nội dung dựa trên điều kiện của 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 toàn diện hơn.
Tất cả là về thương lượng nội dung
Gợi ý cho ứng dụng là một phương thức khác để đàm phán nội dung, tức 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ề việc thương lượng nội dung liên quan đến tiêu đề của yêu cầu Accept. Nó mô tả những loại nội dung mà trình duyệt hiểu được, mà máy chủ có thể dùng để đàm phán phản hồi. Đối với các yêu cầu về hình ảnh, nội dung của tiêu đề Accept của Chrome là:
Accept: image/webp,image/apng,image/*,*/*;q=0.8
Mặc dù tất 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 cho biết trình duyệt cũng hỗ trợ WebP và APNG. Dựa vào thông tin này, chúng ta có thể thương lượng các loại hình ảnh phù hợp nhất cho từng 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 ý cho máy khách là một cách khác để thương lượng nội dung, nhưng trong bối cảnh khả năng của thiết bị và điều kiện mạng. Với gợi ý về ứng dụng khách, chúng tôi 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 riêng của người dùng, chẳng hạn như quyết định xem có nên phân phát 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 các gợi ý đó để cung cấp nội dung phù hợp hơn cho người dùng.
Chọn tham gia
Không giống như tiêu đề Accept, gợi ý về ứng dụng không chỉ xuất hiện một cách kỳ diệu (ngoại trừ Save-Data, chúng ta sẽ thảo luận về điều này sau). Để giữ cho tiêu đề yêu cầu ở mức tối thiểu, bạn sẽ cần chọn những gợi ý về ứng dụng mà bạn muốn nhận 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ị cho Accept-CH là một danh sách gồm nhiều gợi ý được yêu cầu, được phân tách bằng dấu phẩy mà trang web sẽ dùng để xác định kết quả cho yêu cầu tài nguyên tiếp theo. Khi đọc tiêu đề này, máy khách sẽ được thông báo rằng "trang web này muốn gợi ý cho máy khách Viewport-Width và Downlink". Bạn không cần lo lắng về chính các gợi ý cụ thể.
Chúng ta sẽ tìm hiểu về những điều đó ngay sau đây.
Bạn có thể đặt các tiêu đề chọn nhận này bằng bất kỳ ngôn ngữ nào ở phần phụ trợ. Ví dụ: bạn có thể sử dụng hàm header của PHP.
Bạn thậm chí có thể đặt các tiêu đề chọn nhận này bằng thuộc tính http-equiv trên thẻ <meta>:
<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink" />
Tất cả thông tin mô tả về ứng dụng!
Thông tin mô tả của ứng dụng cho biết một trong hai điều: thiết bị mà người dùng sử dụng và mạng mà họ đang dùng để truy cập vào trang web của bạn. Hãy cùng xem qua tất cả các gợi ý hiện có.
Gợi ý về thiết bị
Một số gợi ý về ứng dụng mô tả các đặc điểm của thiết bị người dùng, thường là đặc điểm màn hình. Một số trong số này có thể giúp bạn chọn tài nguyên đa phương tiện tối ưu cho màn hình của một người dùng nhất định, nhưng không phải tất cả đều nhất thiết phải tập trung vào nội dung nghe nhìn.
Trước khi xem danh sách này, bạn nên tìm hiểu một số thuật ngữ chính được dùng để mô tả độ phân giải màn hình và nội dung nghe nhìn:
Kích thước tự nhiên: kích thước thực tế của một tài nguyên đa phương tiện. Ví dụ: nếu bạn mở một hình ảnh trong Photoshop, thì kích thước xuất hiện trong hộp thoại kích thước hình ảnh sẽ mô tả kích thước nội tại của hình ảnh đó.
Kích thước nội tại đã điều chỉnh mật độ: kích thước của một tài nguyên đa phương tiện sau khi được điều chỉnh theo mật độ pixel. Đó là kích thước vốn có của hình ảnh chia cho tỷ lệ pixel trên thiết bị. Ví dụ: hãy xem xét 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 tự nhiên của hình ảnh 1x trong trường hợp này là 320x240 và kích thước tự nhiên của hình ảnh 2x là 640x480. Nếu mã đánh dấu này được một ứng dụng khách phân tích cú pháp (được cài đặt trên một thiết bị có tỷ lệ pixel 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 nội tại đã đ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 đa phương tiện sau khi CSS và các yếu tố bố cục khác (chẳng hạn như thuộc tính width và height) được áp dụng cho tài nguyên đó. 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 đã điều chỉnh 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 các giá trị lần lượt là 256px và 192px được áp dụng cho phần tử đó. Trong ví dụ này, kích thước bên ngoài của phần tử <img> đó sẽ là 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 ngoại tại 256x192.Sau khi nắm được một số thuật ngữ, hãy cùng xem danh sách các gợi ý về ứng dụng dành riêng cho thiết bị mà bạn có thể sử dụng.
Chiều rộng khung nhìn
Viewport-Width là chiều rộng khung hiển thị của người dùng tính bằng pixel CSS:
Viewport-Width: 320
Bạn có thể dùng gợi ý này với các gợi ý khác dành riêng cho màn hình để phân phối các cách xử lý (tức là cắt) khác nhau của một hình ảnh sao cho phù hợp nhất với các kích thước màn hình cụ thể (tức là hướng nghệ thuật) hoặc để bỏ qua những 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, viết tắt của tỷ lệ pixel của thiết bị, báo cáo tỷ lệ giữa pixel thực và pixel CSS trên màn hình của người dùng:
DPR: 2
Gợi ý này hữu ích khi chọn các nguồn hình ảnh tương ứng với mật độ điểm ảnh của màn hình (chẳng hạn như các bộ mô tả x trong thuộc tính srcset).
Chiều rộng
Gợi ý Width xuất hiện trên 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 cách sử dụ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 bên trong 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 một 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 mọi 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 đang gợi ý cho máy chủ rằng chiều rộng nội tại tối ưu cho hình ảnh được yêu cầu sẽ là 85% chiều rộng khung hiển thị (272 pixel) nhân với DPR (2) của màn hình, bằng 544 pixel.
Gợi ý này đặc biệt hữu ích vì không chỉ tính đến chiều rộng đã điều chỉnh mật độ của màn hình mà còn đối chiếu 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 các 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.
Content-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. Nhưng! 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 trường hợp mà hai tiêu đề này khác nhau. Đây là lúc gợi ý Content-DPR phát huy tác dụng.
Không giống như các gợi ý khác cho ứng dụng, Content-DPR không phải là tiêu đề yêu cầu mà máy chủ sẽ sử dụng, mà là tiêu đề phản hồi mà máy chủ phải gửi bất cứ khi nào các gợi ý DPR và Width được dùng để chọn một 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 chuyển tỉ lệ hình ảnh đã cho theo tỉ lệ pixel thiết bị và bố cục của màn hình. Nếu không có thuộc tính này, hình ảnh có thể không được điều chỉnh tỷ lệ đúng cách.
Bộ nhớ thiết bị
Về mặt kỹ thuật, Device-Memory là một phần của Device Memory API, cho biết dung lượng bộ nhớ gần đúng mà thiết bị hiện tại có theo GiB:
Device-Memory: 2
Một trường hợp sử dụng có thể cho gợi ý này là giảm lượng JavaScript được gửi đến 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 sử dụng nhiều tài nguyên nhất mà trình duyệt thường tải. Hoặc bạn có thể gửi hình ảnh có DPR thấp hơn vì chúng sử dụng ít bộ nhớ hơn để giải mã.
Gợi ý về mạng
Network Information API (API Thông tin mạng) cung cấp một danh mục khác về gợi ý cho ứng dụng khách, mô tả hiệu suất của kết nối mạng của người dùng. Theo tôi, đây là bộ gợi ý hữu ích nhất. Với các chỉ số này, chúng ta có thể điều chỉnh trải nghiệm cho người dùng bằng cách thay đổi cách phân phối tài nguyên cho các ứng dụng trên những kết nối chậm.
RTT
Gợi ý RTT cung cấp Thời gian khứ hồi (tính bằng mili giây) gần đúng trên lớp ứng dụng. Gợi ý RTT, không giống như RTT của lớp truyền tải, bao gồm cả thời gian xử lý của máy chủ.
RTT: 125
Gợi ý này rất hữu ích vì độ trễ đóng vai trò quan trọng trong hiệu suất tải.
Bằng cách 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, điều 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 có ảnh hưởng. Gợi ý Downlink (tính bằng megabit trên giây (Mbps)) cho biết tốc độ tải xuống gần đúng của kết nối người dùng:
Downlink: 2.5
Kết hợp với RTT, Downlink có thể hữu ích trong việc thay đổi cách phân phối nội dung cho 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 Loại kết nối hiệu quả. Giá trị của tham số này là một trong những giá trị trong danh sách được liệt kê về các loại kết nối, mỗi loạ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 đề này không báo cáo liệu cổng của bạn có phải là trạm phát sóng di động hay điểm truy cập Wi-Fi hay không. Thay vào đó, hệ thống sẽ 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 hồ sơ mạng mà kết nối đó giống nhất. Ví dụ: nếu bạn kết nối qua Wi-Fi với một mạng chậm, ECT có thể được điền sẵn giá trị 2g, đây là giá trị gần đúng nhất của kết nối hiệu quả:
ECT: 2g
Các giá trị hợp lệ cho ECT là 4g, 3g, 2g và slow-2g. Bạn có thể dùng gợi ý này 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.
Save-Data
Save-Data không phải là một gợi ý mô tả điều kiện mạng mà là một 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à một gợi ý về mạng vì nhiều việc bạn sẽ làm với gợi ý này tương tự như các gợi ý khác về mạng. Người dùng cũng có thể bật chế độ này trong môi trường có độ trễ cao/băng thông thấp. Gợi ý này (nếu 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 của việc này đến hiệu suất có thể rất lớn. Đây là một tín hiệu cho thấy người dùng đang yêu cầu bạn gửi cho họ ít nội dung hơn! Nếu bạn lắng nghe và hành động dựa trên tín hiệu đó, người dùng sẽ đánh giá cao điều này.
Cùng nhau hợp tác
Bạn làm gì với gợi ý về ứng dụng khách là tuỳ vào bạn. Vì các báo cáo này cung cấp rất nhiều thông tin, nên bạn có nhiều lựa chọn. Để có thêm ý tưởng, hãy xem gợi ý về ứng dụng khách có thể làm gì cho Sconnie Timber, một công ty gỗ hư cấu ở vùng Thượng Trung Tây nông thôn. Như thường thấy ở các khu vực vùng sâu vùng xa, kết nối mạng có thể không ổn định. Đây là nơi mà một công nghệ như gợi ý về ứng dụng 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ả các trường hợp sử dụng hình ảnh thích ứng (ngoại trừ trường hợp đơn giản nhất) đều có thể trở nên phức tạp. Điều gì xảy ra 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? Mã đánh dấu đó sẽ trở nên rất phức tạp rất
nhanh chóng.
Bạn có thể dễ dàng hiểu sai và dễ dàng quên hoặc hiểu lầm các khái niệm quan trọng (chẳng hạn như sizes).
Mặc dù <picture> và srcset là những công cụ tuyệt vời, nhưng có thể tốn thời gian để phát triển và duy trì cho các trường hợp sử dụng phức tạp. Chúng ta 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 <picture> và srcset cung cấp đủ phức tạp để quá trình tự động hoá cần được thực hiện theo cách duy trì tính linh hoạt mà chúng mang lại.
Thông tin mô tả của ứng dụng có thể đơn giản hoá quá trình này. Việc thương lượng các phản hồi hình ảnh với gợi ý của ứng dụng khách có thể trông như sau:
- Nếu phù hợp với quy trình làm việc của bạn, trước tiên, hãy chọn một phương pháp xử lý hình ảnh (tức là hình ảnh được định hướng nghệ thuật) bằng cách đánh dấu vào 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ợ (điều này giúp chúng tôi thực hiện trong hầu hết các trình duyệt).
Accept
Đối với khách hàng là công ty gỗ giả tưởng của tôi, tôi đã phát triển một quy trình chọn hình ảnh thích ứng đơn giản bằng PHP sử dụng gợi ý cho ứng dụng khách. Đ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:
<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 số lượng này xuống còn những trình duyệt sau đây dựa trên khả năng hỗ trợ của từng trình duyệt:
<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ằng mod_rewrite. Thành phần này lấy tên tệp hình ảnh và các tham số bổ sung để giúp một tập lệnh phụ trợ chọn hình ảnh phù hợp nhất trong các điều kiện nhất định.
Tôi đoán câu hỏi đầu tiên của bạn là "Nhưng chẳng phải đây chỉ là việc triển khai lại <picture> và srcset trên phần phụ trợ sao?"
Có thể nói là có, nhưng có một điểm khác biệt quan trọng: khi một ứng dụng sử dụng gợi ý cho ứng dụng để tạo phản hồi về nội dung nghe nhìn, hầu hết (nếu không phải tất cả) công việc đều dễ dàng tự động hoá hơn nhiều, bao gồm cả một dịch vụ (chẳng hạn như CDN) có thể thay 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 cho mọi trường hợp sử dụng. Chắc chắn rồi, bạn có thể tự động hoá việc 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 xét lại chiến lược tự động hoá trong tương lai.
Gợi ý về ứng dụng cho phép bắt đầu bằng một hình ảnh có độ phân giải cao, không bị mất dữ liệu, sau đó có thể đổi kích thước linh hoạt để phù hợp với mọi tổ hợp màn hình và bố cục. Không giống như srcset, yêu cầu bạn liệt kê một danh sách cố định các ứng cử viên hình ảnh có thể có để trình duyệt 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 nhóm biến thể thô (chẳng hạn như 256w, 512w, 768w và 1024w), nhưng một giải pháp dựa trên gợi ý của ứng dụng khách có thể phân phát tất cả các chiều rộng mà không cần một đống mã đánh dấu khổng lồ.
Dĩ nhiên, bạn không phải tự viết logic chọn hình ảnh. Cloudinary sử dụng gợi ý về ứng dụng để tạo câu trả lời bằng hình ảnh khi bạn sử dụng tham số w_auto và nhận thấy rằng người dùng trung bình đã tải xuống ít hơn 42% byte khi sử dụng các trình duyệt hỗ trợ gợi ý về ứng dụng.
Nhưng hãy cẩn thận! Các thay đổi trong phiên bản Chrome 67 dành cho máy tính đã loại bỏ tính năng hỗ trợ gợi ý của ứng dụng khách trên nhiều nguồn. Rất may là những hạn chế này không ảnh hưởng đến các phiên bản di động của Chrome và chúng sẽ được dỡ bỏ hoàn toàn cho tất cả các nền tảng khi quá trình triển khai Chính sách về tính năng hoàn tất.
Giúp người dùng trên mạng có tốc độ chậm
Hiệu suất thích ứng là ý tưởng rằng chúng ta có thể điều chỉnh cách phân phối tài nguyên dựa trên thông tin mà gợi ý về ứng dụng cung cấp cho chúng ta; cụ thể là thông tin xung quanh trạng thái hiện tại của kết nối mạng của người dùng.
Đối với 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 được kiểm tra trong mã phụ trợ của chúng tôi. Sau khi hoàn tất, chúng tôi sẽ tạo một đ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 tốt hơn cho người dùng 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ể và 1 là chất lượng mạng tốt nhất.
Ban đầu, chúng ta 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 rằng người dùng muốn chúng tôi làm mọi thứ cần thiết để mang lại trải nghiệm nhẹ nhàng và nhanh chóng hơn.
Tuy nhiên, nếu không có Save-Data, chúng tôi sẽ chuyển sang cân nhắc các giá trị của gợi ý ECT, RTT và Downlink để tính điểm mô tả chất lượng kết nối mạng. Mã nguồn tạo điểm số mạng có trên Github. Điểm mấu chốt là nếu sử dụng các gợi ý liên quan đến mạng theo một cách nào đó, chúng ta có thể cải thiện trải nghiệm cho những người dùng mạng chậm.
Khi các trang web điều chỉnh theo thông tin mà gợi ý về ứng dụng cung cấp, chúng ta không cần phải áp dụng phương pháp "được ăn cả, ngã về không". Chúng ta có thể quyết định một cách thông minh nên gửi tài nguyên nào. Chúng ta có thể sửa đổi logic 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 gợi ý về ứng dụng khi cải thiện hiệu suất của các trang web trên mạng chậm hơn. Dưới đây là biểu đồ thác nước WebPagetest của một trang web trên mạng chậm không thích ứng với gợi ý cho ứng dụng khách:
Và bây giờ là một 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 ý cho ứng dụng để loại bỏ các tài nguyên trang không quan trọng:
Gợi ý cho ứng dụng khách đã giảm thời gian tải trang từ hơn 45 giây xuống còn chưa đến một phần mười thời gian đó. Không thể nhấn mạnh đủ lợi ích của gợi ý về ứng dụng trong trường hợp này và đây có thể là một lợi ích lớn cho người dùng đang tìm kiếm thông tin quan trọng trên các mạng có tốc độ chậm.
Ngoài ra, bạn có thể sử dụng gợi ý về ứng dụng mà không làm gián đoạn trải nghiệm cho những trình duyệt không hỗ trợ gợi ý này. Ví dụ: nếu muốn điều chỉnh việc phân phối tài nguyên bằng cách sử dụng giá trị của gợi ý ECT trong khi vẫn mang đến trải nghiệm đầy đủ cho các trình duyệt không hỗ trợ, chúng ta có thể đặt giá trị dự phòng thành 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 có chất lượng cao nhất mà tiêu đề ECT mô tả. Nếu chúng ta khởi tạo $ect thành "4g", thì những trình duyệt không hỗ trợ gợi ý cho ứng dụng sẽ không bị ảnh hưởng. Chọn tham gia FTW!
Hãy chú ý đến những bộ nhớ đệm đó!
Bất cứ khi nào thay đổi một phản hồi dựa trên tiêu đề HTTP, bạn cần biết cách bộ nhớ đệm sẽ xử lý các lần tìm nạp tiếp theo cho tài nguyên đó. Tiêu đề Vary là không thể thiếu ở đây, vì tiêu đề này sẽ khoá các mục nhập trong bộ nhớ đệm theo giá trị của tiêu đề yêu cầu được cung cấp cho tiêu đề đó. 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, bạn gần như luôn phải đưa tiêu đề của yêu cầu đó vào Vary như sau:
Vary: DPR, Width
Tuy nhiên, có một lưu ý quan trọng cần lưu ý: Bạn không bao giờ muốn Vary phản hồi có thể lưu vào bộ nhớ đệm trên một tiêu đề thường xuyên thay đổi (chẳng hạn như Cookie) vì những tài nguyên đó sẽ không thể lưu vào bộ nhớ đệm một cách hiệu quả. Khi biết điều này, bạn có thể muốn tránh Varytrên các tiêu đề gợi ý cho ứng dụng khách như RTT hoặc Downlink, vì đây là những 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 các phản hồi trên những tiêu đề đó, hãy cân nhắc chỉ khoá tiêu đề ECT. Việc này sẽ giảm thiểu số lần không tìm thấy trong bộ nhớ đệm.
Tất nhiên, điều này chỉ áp dụng nếu bạn đang lưu phản hồi vào bộ nhớ đệm.
Ví dụ: bạn sẽ không lưu trữ 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ể làm hỏng trải nghiệm người dùng khi họ truy cập nhiều lần. Trong những trường hợp như thế này, bạn có thể thoải mái sửa đổi những câu trả lời như vậy dựa trên bất kỳ cơ sở nào mà bạn cảm thấy cần thiết và không cần lo lắng về Vary.
Thông tin mô tả của ứng dụng trong worker dịch vụ
Đàm phán nội dung không chỉ dành cho máy chủ nữa! Vì các worker 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 thông qua JavaScript. Trong đó có gợi ý về ứng dụng. Trong sự kiện fetch của worker 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 ý cho ứng dụng mà bạn chọn theo cách này. Mặc dù đó không phải là cách duy nhất để bạn có thể lấy một số thông tin này. Bạn có thể đọc các gợi ý dành riêng cho mạng trong các thuộc tính JavaScript tương đương sau đây trong đối tượng navigator:
| Thông tin mô tả về ứng dụng | Hàm tương đương trong JS |
|---|---|
| `ECT` | `navigator.connection.effectiveType` |
| `RTT` | `navigator.connection.rtt` |
| `Save-Data` | `navigator.connection.saveData` |
| `Downlink` | `navigator.connection.downlink` |
| `Device-Memory` | `navigator.deviceMemory` |
Vì các API này không có ở mọi nơi, nên 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 mà bạn sẽ sử dụng trên máy chủ, ngoại trừ việc bạn không cần máy chủ để thương lượng nội dung bằng gợi ý cho ứng dụng. Chỉ riêng các service worker đã có thể giúp trải nghiệm nhanh hơn và ổn định hơn nhờ khả năng bổ sung mà chúng có để phân phát nội dung khi người dùng không kết nối mạng.
Kết thúc
Với gợi ý về ứng dụng, chúng ta có thể mang đến trải nghiệm nhanh hơn cho người dùng theo cách hoàn toàn tiến bộ. Chúng ta có thể phân phát nội dung nghe nhìn dựa trên các chức năng của thiết bị 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 không chỉ giúp chúng tôi giảm thời gian và công sức phát triển mà còn tối ưu hoá các tài nguyên (đặc biệt là hình ảnh) theo cách nhắm đến màn hình của người dùng một cách chính xác hơn so với
Quan trọng hơn, chúng ta có thể phát hiện các 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 những gì chúng ta gửi và cách chúng ta gửi. Điều này có thể giúp người dùng dễ dàng truy cập vào các trang web trên mạng không ổn định. Kết hợp với các worker dịch vụ, chúng ta có thể tạo ra những trang web cực kỳ nhanh và có thể truy cập khi không có mạng.
Mặc dù 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 các gợi ý về ứng dụng theo cách không gây trở ngại cho những trình duyệt không hỗ trợ các gợi ý này. Hãy cân nhắc sử dụng gợi ý về ứng dụng để tạo ra trải nghiệm thực sự toàn diện và thích ứng, nhận biết được khả năng của thiết bị của mọi 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 các API này và thể hiện ý định triển khai.
Tài nguyên
- Hình ảnh thích ứng tự động bằng Gợi ý của ứng dụng
- Client Hints và hình ảnh thích ứng – Những thay đổi trong Chrome 67
- Hãy xem gợi ý (Client) này! (Trang trình bày)
- Phân phối các ứng dụng nhanh và gọn nhẹ bằng
Save-Data
Xin 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 có giá trị của họ đối với bài viết này.