Việc phát triển các trang web có tốc độ nhanh ở mọi nơi có thể là một khách hàng tiềm năng khó nhằn. Vô vàn khả năng của thiết bị—và chất lượng của mạng mà chúng kết nối có thể khiến công việc này dường như là một nhiệm vụ không thể vượt qua. Mặc dù chúng tôi có thể thực hiện 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, làm cách nào để chúng ta biết khả năng của thiết bị của người dùng hoặc chất lượng mạng của họ kết nối không? Giải pháp là khách hàng gợi ý!
Gợi ý ứng dụng khách là một tập hợp các tiêu đề yêu cầu HTTP lựa chọn tham gia nhằm cung cấp cho chúng tôi thông tin chi tiết về những khía cạnh này của thiết bị của người dùng và mạng mà họ kết nối. Theo khi khai thác phía máy chủ thông tin này, chúng ta có thể thay đổi cách phân phối 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.
Thương lượng nội dung
Gợi ý ứng dụng là một phương pháp khác để thương lượng nội dung, tức là thay đổi phản hồi nội dung dựa trên tiêu đề của yêu cầu của trình duyệt.
Một ví dụ về thương lượng nội dung bao gồm
Accept
tiêu đề của yêu cầu. Tài liệu 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 yêu cầu về hình ảnh, nội dung
trong 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 nút Chấp nhận cho biết Trong trường hợp này, trình duyệt cũng hỗ trợ WebP và APNG. Nhờ thông tin này, chúng tôi có thể thương lượng các loại hình ảnh tốt 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 ý khách hàng là một cách khác để thương lượng nội dung, nhưng trong
bối cảnh về khả năng của thiết bị và điều kiện mạng. Với gợi ý từ khách hàng, 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 cá nhân
trải nghiệm 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. Trong hướng dẫn này, chúng tôi sẽ mô tả tất cả
các gợi ý có sẵn và một số cách sử dụng chúng để giúp nội dung được phân phối hiệu quả hơn
phù hợp với người dùng.
Chọn tham gia
Không giống như tiêu đề Accept, gợi ý ứng dụng không chỉ xuất hiện một cách kỳ diệu (với
ngoại lệ của Save-Data mà chúng ta sẽ thảo luận sau). Nhằm duy trì
của yêu cầu ở mức tối thiểu, bạn sẽ cần chọn sử dụng gợi ý ứng dụng khách nào
muốn nhận bằng cách gửi tiêu đề Accept-CH khi người dùng yêu cầu
tài nguyên:
Accept-CH: Viewport-Width, Downlink
Giá trị của Accept-CH là danh sách các gợi ý được yêu cầu được phân tách bằng dấu phẩy trên trang web
sẽ sử dụng trong việc xác định kết quả cho yêu cầu tài nguyên tiếp theo. Khi
khách hàng đọc tiêu đề này, tức là có thông báo "trang web này muốn có Viewport-Width
và Downlink gợi ý ứng dụng khách." Đừng lo lắng về các gợi ý cụ thể.
Chúng tôi sẽ trả lời các câu hỏi đó sau 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ụ: PHP
Bạn có thể sử dụng hàm header.
Bạn thậm chí có thể đặt các tiêu đề chọn tham gia này bằng http-equiv
thuộc tính
trên thẻ <meta>:
<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink" />
Tất cả gợi ý của khách hàng!
Gợi ý về ứng dụng mô tả một trong hai nội dung: thiết bị mà người dùng sử dụng, cách 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 nhanh tất cả các gợi ý có sẵn.
Gợi ý về thiết bị
Một số gợi ý của ứng dụng mô tả các đặc điểm về thiết bị của người dùng, thường là màn hình đặc điểm. Một vài công cụ trong số đó 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ả màn hình đều tập trung vào phương tiện truyền thông.
Trước khi chúng ta tìm hiểu danh sách này, có thể bạn nên tìm hiểu một vài thuật ngữ chính thường dùng để mô tả màn hình và độ phân giải của nội dung nghe nhìn:
Kích thước nội tại: Kích thước thực tế của tài nguyên nội dung nghe nhìn. Ví dụ: nếu bạn mở một hình ảnh trong Photoshop, kích thước đượ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 nó.
Kích thước nội tại được điều chỉnh theo mật độ: các kích thước của tài nguyên nội dung đa phương tiện sau nó đã được sửa cho mật độ pixel. Đó là kích thước nội tại của hình ảnh chia cho pixel thiết bị . Ví dụ: chúng ta hãy cùng xem 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 khách hàng phân tích cú pháp
được cài đặt trên một 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
màn hình), hình ảnh 2x sẽ được yêu cầu. Kích thước 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 tài nguyên đa phương tiện sau CSS và bố cục khác
các yếu tố (chẳng hạn như các thuộc tính width và height) đã được áp dụng cho yếu tố đó. Hãy
giả sử bạn có một phần tử <img> tải một hình ảnh có mật độ đã được chỉnh sửa
kích thước nội tại là 320x240, nhưng cũng có các thuộc tính CSS width và height
có 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> đó trở thành 256x192.
width: 256px;
và height: 192px; biến đổi hình ảnh có kích thước sẵn có 320x240
thành hình ảnh có kích thước cực lớn 256x192.Chúng ta hãy xem qua một số thuật ngữ, hãy đi vào danh sách gợi ý khách hàng có sẵn cho bạn.
Chiều rộng khung nhìn
Viewport-Width là chiều rộng 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 dành riêng cho từng màn hình để đưa ra những gợi ý khác nhau phương pháp xử lý (tức là cắt ảnh) của một hình ảnh tối ưu cho các kích thước màn hình cụ thể (ví dụ: nghệ thuật chỉ đường), 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 (viết tắt của từ viết tắt tỷ lệ pixel của thiết bị) báo cáo tỷ lệ pixel vật lý so với CSS
pixel trên màn hình của người dùng:
DPR: 2
Gợi ý này rất hữu ích khi chọn các nguồn hình ảnh tương ứng với
mật độ pixel (như phần mô tả x thực hiện trong 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 được <img> kích hoạt hoặc
Thẻ <source> sử dụng sizes
.
sizes cho trình duyệt biết kích thước bên ngoài của tài nguyên đó;
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
là 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 (ví dụ: 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, khách hàng sẽ gửi
Width này sẽ gợi ý đến máy chủ cùng với yêu cầu cho src của <img>:
Width: 544
Trong trường hợp này, máy khách đang gợi ý cho máy chủ rằng một hàm nội tại tối ưu chiều rộng của hình ảnh được yêu cầu sẽ là 85% chiều rộng của 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 mạnh mẽ vì không chỉ tính đến chiều rộng được điều chỉnh theo mật độ của màn hình, nhưng cũng điều chỉnh phần quan trọng này thông tin với kích thước bên ngoài của hình ảnh trong bố cục. Điều này mang lại cho các máy chủ cơ hội thương lượng phản hồi hình ảnh tối ưu cho cả hai màn hình và bố cục.
DPR nội dung
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ó
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, pixel
tỷ lệ giữa thiết bị và tài nguyên có thể giống nhau. Tuy nhiên! Trong trường hợp cả hai
các tiêu đề DPR và Width đang hoạt động, kích thước bên ngoài của tài nguyên có thể
tạo ra các tình huống trong đó hai yếu tố khác nhau. Đây là nơi gợi ý Content-DPR
bắt đầu 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 để sử dụng
mà là máy chủ tiêu đề phản hồi phải gửi bất cứ khi nào DPR và
Gợi ý Width 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 này:
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 mở rộng quy mô
hình ảnh đã cho cho bố cục và tỷ lệ pixel của thiết bị trên màn hình. Nếu không có dịch vụ này,
hình ảnh có thể không điều chỉnh được theo tỷ lệ.
Bộ nhớ thiết bị
Về mặt kỹ thuật, đây là một phần của Bộ nhớ thiết bị
API, Device-Memory cho biết các
số tiền gần đúng
kỷ niệm
thiết bị hiện tại có trong GiB:
Device-Memory: 2
Trường hợp có thể sử dụng gợi ý này là giảm lượng JavaScript được gửi đến các trình duyệt trên những thiết bị có bộ nhớ hạn chế, vì JavaScript là các trình duyệt loại nội dung chuyên sâu về tài nguyên thường tải. Hoặc bạn có thể gửi hình ảnh 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 cung cấp một danh mục gợi ý về ứng dụng mô tả hiệu suất mạng của người dùng kết nối. Theo tôi, đây là bộ gợi ý hữu ích nhất. Với họ, 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 cung cấp cho máy khách trên các kết nối chậm.
RTT
Gợi ý RTT cung cấp Thời gian trọn vòng gần đúng, tính bằng mili giây, bật
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
thời gian xử lý của máy chủ.
RTT: 125
Gợi ý này 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,
giúp tăng tốc độ phân phối toàn bộ trải nghiệm (ví dụ: thông qua
bỏ qua một số yêu cầu).
Đường liên kết xuống
Mặc dù độ trễ là yếu tố quan trọng trong việc tải hiệu suất nhưng băng thông cũng có ảnh hưởng,
của Google. Gợi ý Downlink, được biểu thị bằng megabit/giây (Mb/giây), cho biết
Tốc độ kết nối của người dùng ước chừng về sau:
Downlink: 2.5
Cùng với RTT, Downlink có thể hữu ích trong việc thay đổi cách thức nội dung
được phân phối cho người dùng dựa trên chất lượng của kết nối mạng.
ECT
Gợi ý ECT là viết tắt của effective Connection Type (Loại kết nối hiệu quả). Giá trị của nó là một trong những
danh sách liệt kê 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ả RTT và Downlink
giá trị.
Tiêu đề này không giải thích loại kết nối thực tế là gì—đối với
ví dụ: cổng vào không báo cáo liệu cổng vào của bạn là trạm phát sóng hay là quyền truy cập Wi-Fi
điểm. Thay vào đó, công cụ này phân tích độ trễ, băng thông của kết nối hiện tại và
sẽ xác định hồ sơ mạng giống với hồ sơ đó nhất. Ví dụ: nếu bạn kết nối
qua Wi-Fi đến một mạng chậm, ECT có thể được điền sẵn giá trị là 2g,
đây là kết nối 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. Gợi ý này có thể là
được sử dụng làm điểm bắt đầu để đánh giá chất lượng kết nối, sau đó
được tinh chỉnh bằng các gợi ý RTT và Downlink.
Tiết kiệm dữ liệu
Save-Data không phải là gợi ý mô tả tình trạng mạng vì đó là người dùng
lựa chọn ưu tiên nêu rõ rằng các trang sẽ gửi ít dữ liệu hơn.
Tôi muốn phân loại Save-Data là gợi ý mạng vì có nhiều điều
bạn sẽ thực hiện tương tự như các gợi ý mạng khác. Người dùng cũng có thể
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, khi
hiện tại, 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 hệ thống đối với hiệu suất có thể rất lớn. Đó là tín hiệu cho biết người dùng
theo đúng nghĩa đen là 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 điều đó
của Google, người dùng sẽ đánh giá cao điều đó.
Cùng nhau hợp tác
Những việc bạn làm với gợi ý về ứng dụng phụ thuộc vào bạn. Vì chúng cung cấp rất nhiều thông tin, bạn có nhiều lựa chọn. Để có một số ý tưởng tuôn trào, hãy cùng tìm hiểu gợi ý ứng dụng khách có thể làm cho Sconnie Gỗ, một loại gỗ hư cấu đặt tại vùng nông thôn miền Trung Trung Tây. Như thường lệ trong các trường hợp , kết nối mạng có thể yếu. Đây là nơi công nghệ như gợi ý của ứ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ả trừ những 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 cách xử lý và các biến thể của cùng một hình ảnh cho các màn hình khác nhau
kích thước—và định dạng khác nhau không? Mã đánh dấu đó rất phức tạp rất
.
Rất dễ bị nhầm lẫn, và cũng dễ quên hoặc hiểu lầm là quan trọng
các khái niệm khác (chẳng hạn như sizes).
Mặc dù <picture> và srcset không thể phủ nhận là những công cụ tuyệt vời, nhưng chú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 tôi có thể tự động hoá
bạn có thể tạo mã đánh dấu, nhưng việc này cũng khó khăn do chức năng
<picture> và srcset cung cấp đủ phức tạp để đáp ứng nhu cầu tự động hoá
được thực hiện theo cách duy trì tính linh hoạt mà chúng mang lại.
Gợi ý ứng dụng có thể giúp đơn giản hoá việc này. Đang thương lượng về phản hồi bằng hình ảnh với khách hàng gợi ý sẽ có dạ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 hình ảnh xử lý (tức là
hình ảnh định hướng 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, và chọn 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ự về cách hoạt động của trình mô tảxvàwtrongsrcset). - Chọn định dạng tệp tối ưu nhất mà trình duyệt hỗ trợ (định dạng
Acceptgiúp chúng tôi làm được trong hầu hết các trình duyệt).
Khi nghĩ rằng khách hàng của công ty gỗ hư cấu của tôi, tôi đã ngây thơ quy trình chọn hình ảnh thích ứng trong PHP sử dụng gợi ý ứng dụ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:
<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 sự 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ố
viết lại bởi
mod_rewrite. Nó
lấy 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 tốt nhất trong điều kiện đã cho.
Tôi hiểu "Nhưng không chỉ là triển khai lại <picture> và srcset trên
không?" là câu hỏi đầu tiên của bạn.
Có, nhưng có một điểm khác biệt quan trọng là: khi một ứng dụng sử dụng gợi ý của khách hàng để tạo ra câu trả lờ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 là dễ tự động hoá hơn. Bạn có thể sử dụng một dịch vụ (chẳng hạn như CDN) để thực hiện việc này thay mặt bạn. Trái lại, với giải pháp HTML, bạn cần ghi mã đánh dấu mới vào cung cấp cho mọi trường hợp sử dụng. Chắc chắn là bạn có thể tự động tạo mã đánh dấu. Nếu thiết kế hoặc yêu cầu thay đổi, có thể bạn vẫn cần xem lại chiến lược tự động hoá của mình trong tương lai.
Gợi ý khách hàng giúp bạn có thể bắt đầu với hình ảnh không tổn hao, độ phân giải cao
hình ảnh sau đó có thể được đổi kích thước linh động để tối ưu cho bất kỳ cách kết hợp nào
màn hình và bố cục. Không giống như srcset, đòi hỏi bạn phải liệt kê một giá trị cố định
danh sách hình ảnh có thể dùng để trình duyệt chọn, phương pháp này
có thể linh hoạt hơn. Trong khi srcset buộc bạn cung cấp cho trình duyệt một tập hợp tương đối
gồm nhiều biến thể, chẳng hạn như 256w, 512w, 768w và 1024w – một gợi ý của ứng dụng
có thể phân phát ở mọi chiều rộng mà không cần phải có quá nhiều mã đánh dấu.
Tất nhiên, bạn không phải tự viết logic lựa chọn hình ảnh. Đám mây
sử dụng gợi ý của ứng dụng để tạo phản hồi bằng hình ảnh khi bạn sử dụng w_auto
tham số,
và quan sát thấy rằng trung bình số người dùng tải xuống số byte ít hơn 42% khi sử dụng trình duyệt
hỗ trợ gợi ý ứng dụng.
Nhưng hãy cẩn thận! Những thay đổi trong phiên bản Chrome 67 dành cho máy tính đã ngừng hỗ trợ cho ứng dụng trên nhiều nguồn gốc gợi ý. 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à chúng sẽ được gỡ bỏ hoàn toàn cho tất cả các nền tảng khi hoạt động trên Tính năng Chính sách đã hoàn tất.
Hỗ trợ 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à khách hàng cung cấp cho chúng tôi; cụ thể thông tin về trạng thái hiện tại kết nối mạng của người dùng.
Trong trường hợp có liên quan đến 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 là
mà chúng tôi đã xem xét trong mã phụ trợ. Khi quá trình này hoàn tất, chúng tôi sẽ tạo ra chất lượng mạng
điểm số chúng tôi có thể dùng để xác định xem có nên can thiệp để mang lại người dùng tốt hơn không
của bạn. Điểm số mạng này nằm trong khoảng từ 0 đến 1, trong đó 0 là thấp nhất
chất lượng mạng tốt nhất và 1 là tốt nhất.
Ban đầu, chúng tôi kiểm tra xem Save-Data có xuất hiện hay không. Nếu đúng như vậy, điểm số sẽ được đặt thành
0, vì chúng ta giả định người dùng muốn chúng ta làm bất cứ điều gì cần thiết để khiến
nhẹ hơn và nhanh hơn.
Tuy nhiên, nếu không có Save-Data, chúng ta sẽ tiếp tục và cân các giá trị của ECT,
RTT và Downlink gợi ý để tính điểm mô tả mạng
chất lượng kết nối. Nguồn tạo điểm số mạng
mã
có trên GitHub. Bài học rút ra là nếu chúng ta sử dụng các gợi ý liên quan đến mạng trong
một số nội dung thời trang, chúng tôi có thể cải thiện trải nghiệm cho những người
chạy chậm
mạng.
Khi các trang web thích ứng với thông tin do khách hàng cung cấp, chúng tôi không cần phải áp dụng á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 những tài nguyên gửi. Chúng tôi có thể sửa đổi logic lựa chọn hình ảnh thích ứng để gửi chất lượng thấp hơn hình ảnh cho một màn hình cụ thể để tăng 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 gợi ý của khách hàng tác động như thế nào đến cải thiện hiệu suất của trang web trên các mạng chậm hơn. Dưới đây là một WebPagetest thác nước của một trang web trên mạng chậm không thích ứng với gợi ý của ứng dụng:
Giờ đây, bạn sẽ thấy 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ừ thời gian, trang web sẽ sử dụng gợi ý ứng dụng khách để loại bỏ các tài nguyên trang không quan trọng:
Gợi ý ứng dụng giúp giảm thời gian tải trang từ hơn 45 giây xuống ít hơn . Lợi ích của gợi ý về ứng dụng trong tình huống này không thể được nhấn mạnh đủ 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 qua các mạng chậm.
Hơn nữa, bạn có thể sử dụng gợi ý ứng dụng mà không làm hỏng trải nghiệm
cho các trình duyệt không hỗ trợ các tuỳ chọn này. Ví dụ: nếu chúng ta muốn điều chỉnh tài nguyên
phân phối dựa trên giá trị của gợi ý ECT mà vẫn phân phối đầy đủ
đối với các trình duyệt không hỗ trợ, chúng tôi có thể đặt lại về giá trị mặc định
như thế:
// 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, tiêu đề ECT
mô tả. Nếu chúng ta khởi chạy $ect đến "4g", thì các trình duyệt không hỗ trợ ứng dụng
các gợi ý sẽ không bị ảnh hưởng. Chọn sử dụng FTW!
Lưu ý đến những bộ nhớ đệm!
Mỗi khi 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 trong tương lai cho tài nguyên đó. Vary
tiêu đề là
không thể thiếu ở đây, vì khoá này khoá các mục nhập trong bộ nhớ đệm thành giá trị của tiêu đề yêu cầu
được cung cấp cho nó. Nói một cách đơn giản, nếu bạn sửa đổi bất kỳ phản hồi nào dựa trên một HTTP nhất định
tiêu đề của yêu cầu, hầu như lúc nào bạn cũng nên đưa yêu cầu đó vào tiêu đề Vary
như thế:
Vary: DPR, Width
Tuy nhiên, có một cảnh báo lớn về điều này: Bạn không bao giờ muốn Vary có thể lưu vào bộ nhớ đệm
nội dung phản hồi trên tiêu đề thay đổi thường xuyên (như Cookie) vì những tiêu đề đó
không thể lưu vào bộ nhớ đệm một cách hiệu quả. Khi biết được điều này, bạn nên tránh
Vary trên các tiêu đề gợi ý ứng dụng 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. Điều này sẽ
giảm thiểu số lần thiếu 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 ngay từ đầu.
Ví dụ: bạn sẽ không lưu nội dung HTML vào bộ nhớ đệm nếu nội dung của nội dung đó là động, vì
có thể làm hỏng trải nghiệm người dùng trong các lượt truy cập lặp lại. Trong những trường hợp như thế này, hãy cảm thấy
tự do sửa đổi các phản hồi đó trên bất kỳ cơ sở nào bạn cảm thấy cần thiết và không
lo lắng về Vary.
Thông tin về ứng dụng trong trình chạy dịch vụ
Thương lượng nội dung không chỉ dành cho máy chủ nữa! Vì nhân viên dịch vụ hành động
dưới dạng proxy giữa máy khách và máy chủ, bạn có quyền kiểm soát cách các tài nguyên
đều được phân phối qua JavaScript. Quy tắc này bao gồm cả gợi ý của ứng dụng. Trong trình chạy dịch vụ
fetch, bạn có thể sử dụng mã của đối tượng event
request.headers.get
để đọc tiêu đề của 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. Tuy vậy
không phải là cách duy nhất để tìm hiểu một số thông tin này. Gợi ý dành riêng cho mạng
có thể được đọc trong các thuộc tính JavaScript tương đương trong đối tượng navigator:
| Gợi ý khách hàng | Hàm JS tương đương |
|---|---|
| "ECT" | `navigator.connection.effectiveType` |
| "RTT" | `navigator.connection.rtt` |
| "Save-Data" (Lưu dữ liệu) | `navigator.connection.saveData` |
| "Đường liên kết xuống" | `navigator.connection.downlink` |
| "Bộ nhớ thiết bị" | `navigator.deviceMemory` |
Vì các API này không có sẵn ở mọi nơi mà bạn cần kiểm tra tính năng bằng
in
toán tử:
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ừ bạn không cần máy chủ để thương lượng nội dung dựa trên gợi ý của ứng dụng. Dịch vụ chỉ mình nhân viên mới có khả năng tạo ra trải nghiệm nhanh hơn và bền bỉ hơn vào khả năng phân phát nội dung khi người dùng không có kết nối mạng.
Kết thúc
Nhờ có gợi ý từ khách hàng, chúng tôi có thể mang đến trải nghiệm nhanh hơn cho người dùng
một cách hoàn toàn tiến bộ. Chúng tôi có thể phân phát nội dung nghe nhìn dựa trên thiết bị của người dùng
giúp phân phát hình ảnh thích ứng dễ dàng hơn so với việc dựa vào
trên <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 ở khía cạnh 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 đến màn hình của người dùng
tốt hơn
Có lẽ quan trọng hơn, chúng ta có thể phát hiện được các kết nối mạng kém và cầu nối khoảng cách cho người dùng bằng cách sửa đổi những gì chúng tôi gửi—và cách chúng tôi gửi nó. Điều này có thể nỗ lực dài để 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 ớt. Khi kết hợp với trình chạy dịch vụ, chúng tôi có thể tạo ra các trang web cực kỳ 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à dựa trên Chromium các trình duyệt—có thể sử dụng chúng theo cách không gây cản trở các trình duyệt không hỗ trợ chúng. Cân nhắc sử dụng gợi ý của khách hàng để sáng tạo thật sự trải nghiệm dành cho tất cả mọi người và có thể điều chỉnh cho phù hợp với từng thiết bị của người dùng và mạng mà các thiết bị này kết nối. Hy vọng rằng, các nhà cung cấp trình duyệt khác sẽ thấy giá trị của chúng và cho thấy ý định triển khai.
Tài nguyên
- Hình ảnh thích ứng tự động với ứng dụng Gợi ý
- Gợi ý về ứng dụng và hình ảnh thích ứng – Những thay đổi của Chrome 67
- Nhận gợi ý (Ứng dụ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 ý kiến phản hồi và nội dung chỉnh sửa hữu ích cho bài viết này.