Trong bài viết trước, tôi đã đề xuất sử dụng API SaveData để mang lại trải nghiệm khác biệt, hiệu quả hơn cho những người dùng đã bày tỏ mong muốn đó. Hy vọng điều này sẽ mang lại trải nghiệm tuyệt vời hơn cho tất cả người dùng. Trong bài viết này, tôi muốn dành nhiều thời gian hơn cho vấn đề này và cũng xem xét các tín hiệu khác mà chúng ta có thể sử dụng tương tự để giúp chúng ta đưa ra quyết định về nội dung cần tải trên trang web của mình.
Điều đó không có nghĩa là nội dung không cần thiết là vô nghĩa — thiết kế nâng cao và giao diện người dùng có thể có tác động quan trọng đến thương hiệu của trang web và những nội dung bổ sung nhỏ thú vị thực sự có thể tác động đến mối quan hệ của người dùng với trang web của bạn. Khi chi phí cho những "nội dung bổ sung" đó bắt đầu tác động tiêu cực đến trải nghiệm của người dùng trên trang web, thì bạn nên cân nhắc xem chúng cần thiết như thế nào và liệu chúng có thể bị tắt đối với một số người dùng hay không.
Có lẽ hơi khó hiểu, iOS có chế độ Dữ liệu thấp, mặc dù chế độ này được chính iOS sử dụng để giảm các tác vụ nền sử dụng dữ liệu và không được trình duyệt hiển thị để cho phép các trang web tận dụng chế độ đó (ngay cả đối với Chrome trên iOS, chế độ này giống một giao diện trên Safari hơn là trình duyệt Chrome đầy đủ).
Các trang web có thể hoạt động theo tùy chọn Lưu dữ liệu để cung cấp một trang web nhẹ hơn nhằm... . . lưu dữ liệu của người dùng! Điều này hữu ích cho những người dùng sử dụng mạng kém hoặc đắt tiền, do đó, họ không phải trả chi phí cắt cổ chỉ để truy cập trang web của bạn. Cài đặt này được sử dụng bởi người dùng ở các quốc gia nghèo hơn nhưng cũng được sử dụng bởi những người có gói dữ liệu giới hạn có thể sắp hết ngay trước khi gia hạn giới hạn hàng tháng của bạn hoặc những người đi du lịch nơi phí chuyển vùng có thể đắt hơn nhiều so với ở nhà.
< tr>[TD]Nigeria[/TD][TD]55%[/TD]Bây giờ, có một vài điều cần lưu ý về điều này. Trước hết, có lẽ không có gì ngạc nhiên khi thấy mức sử dụng cao của cài đặt này đối với những quốc gia thường được coi là "nghèo" — hơn 50% người dùng thiết bị di động có cài đặt này có vẻ phổ biến. Có lẽ điều đáng ngạc nhiên hơn là mức sử dụng tương đối cao của một phần ba người dùng sử dụng cài đặt này ở những quốc gia như Vương quốc Anh, Đức và Pháp. Tóm lại, đây không phải là một cài đặt thích hợp.
Tôi rất muốn biết lý do tại sao Trung Quốc lại miễn cưỡng sử dụng cài đặt này nếu bất kỳ độc giả nào biết. Thật kỳ lạ, họ báo cáo là một loạt các trình duyệt trong phân tích của chúng tôi bao gồm Android WebView, Chrome và Safari (mặc dù nó không hỗ trợ điều này!). Có lẽ, đây là những chiếc điện thoại nhái hoặc các bản dựng tùy chỉnh khác không hiển thị cài đặt này cho người dùng cuối để bật tính năng này. Nếu bạn có bất kỳ lý thuyết hoặc thông tin nào khác về điều này — Tôi rất muốn biết, vì vậy hãy để lại tin nhắn trong phần bình luận bên dưới.
Tuy nhiên, bảng trên không thực sự đại diện cho tổng lưu lượng truy cập và đó là một điểm khác cần lưu ý về dữ liệu này. Nếu chúng ta so sánh 10 quốc gia truy cập SmashingMagazine.com nhiều nhất theo số lượng người dùng trên bốn phân khúc khác nhau, chúng ta sẽ thấy như sau:
Tất cả người dùng và người dùng di động không quá khác biệt. Mặc dù một số quốc gia "nghèo" hơn như Philippines và Nigeria đứng cao hơn trong bảng xếp hạng trên thiết bị di động (hỗ trợ máy tính để bàn của trang web này có vẻ cao hơn ở các nước phương Tây).
Tuy nhiên, khi xem xét những quốc gia có hỗ trợ Save Data (giống như bảng đầu tiên tôi đã trình bày), thì lại là một góc nhìn hoàn toàn khác; Ấn Độ đã vượt qua Hoa Kỳ ở vị trí đầu bảng và Philippines vươn lên vị trí thứ ba. Và cuối cùng, khi xem xét những quốc gia thực sự bật Save Data, thì thứ tự không thể nhận ra được so với cột đầu tiên.
Ngoài ra, như tôi đã đề cập trong bài viết trước, sáng kiến Core Web Vitals chỉ được đo lường trong trình duyệt Chrome (và không phải các trình duyệt Chromium khác như Edge hoặc Opera) đang tập trung vào những người dùng này, trong khi đồng thời đó là những người dùng hỗ trợ API này và các API khác để cho phép bạn giải quyết vấn đề của họ.
Vì vậy, mặc dù tôi ước rằng không có sự bất bình đẳng này trên thế giới này và mặc dù tôi ước rằng tất cả các trình duyệt sẽ hỗ trợ các tùy chọn này tốt hơn, tôi vẫn tin rằng việc sử dụng các tùy chọn này để tùy chỉnh việc phân phối tốt hơn là điều đúng đắn cần làm và thực tế là chúng chỉ khả dụng trong các trình duyệt dựa trên Chromium tại thời điểm này không phải là lý do để bỏ qua các tùy chọn này.
Các trang web vẫn phải cung cấp trải nghiệm cốt lõi của trang web, nhưng loại bỏ các tính năng bổ sung tùy chọn. Đối với Smashing Magazine, điều đó liên quan đến việc loại bỏ một số phông chữ web của chúng tôi. Đối với những trang khác, có thể liên quan đến việc sử dụng hình ảnh nhỏ hơn hoặc không tải video theo mặc định. Tất nhiên, vì lý do hiệu suất web, bạn nên luôn sử dụng hình ảnh nhỏ nhất có thể, nhưng trong thời đại màn hình di động mật độ cao như ngày nay, nhiều người thích cung cấp hình ảnh chất lượng cao để tận dụng những màn hình đẹp đó. Nếu người dùng đã chỉ ra rằng họ thích lưu dữ liệu, bạn có thể sử dụng điều đó làm tín hiệu để giảm xuống một cấp độ ở đó, ngay cả khi nó không đẹp bằng hình ảnh, nhưng vẫn truyền tải được thông điệp.
Tim Vereecke đã có một bài nói chuyện tuyệt vời về một số Chiến lược Data S(h)aver mà anh ấy sử dụng trên trang web của mình cho những người dùng có tùy chọn Save Data này, bao gồm hiển thị ít bài viết hơn theo mặc định, tải ít hơn trên các trang cuộn vô hạn khi đến cuối trang, xóa phông chữ biểu tượng hoặc giảm số lượng quảng cáo, không tự động phát video và tải thêm nhiều mẹo và thủ thuật, một số trong số đó đã được anh ấy tóm tắt trong một bài viết đi kèm.
Một điểm quan trọng mà Tim lưu ý là sử dụng Lưu dữ liệu không phải lúc nào cũng cải thiện hiệu suất. Một số kỹ thuật mà anh ấy sử dụng như tải ít hơn hoặc tắt tính năng tải trước các trang có khả năng sẽ tiết kiệm dữ liệu, nhưng nhược điểm là tải lâu hơn một chút nếu người dùng muốn xem nội dung đó. Tuy nhiên, nhìn chung, việc giảm dữ liệu thường giúp tăng hiệu suất web.
Tuy nhiên, nhược điểm của Lưu dữ liệu là người dùng phải biết để bật tùy chọn này. Trong khi nhiều độc giả của Smashing Magazine có thể am hiểu kỹ thuật hơn và có thể biết về tùy chọn này hoặc có thể thoải mái tìm hiểu về cài đặt trình duyệt của họ, thì những người khác có thể không. Ngoài ra, với thay đổi đã đề cập ở trên của Chrome khi loại bỏ tùy chọn trình duyệt Lưu dữ liệu và có lẽ chuyển sang sử dụng tùy chọn cấp hệ điều hành, chúng ta có thể thấy một số thay đổi trong cách sử dụng tùy chọn này (tốt hơn hoặc tệ hơn!).
Vậy, chúng ta có thể làm gì để cố gắng giúp những người dùng không có tùy chọn này? Vâng, có một số tín hiệu khác mà chúng ta có thể sử dụng, vì chúng cũng có thể chỉ ra những người dùng có thể gặp khó khăn với trải nghiệm đầy đủ của trang web. Tuy nhiên, vì chúng ta đang đưa ra quyết định đó cho họ (không giống như Lưu dữ liệu là lựa chọn rõ ràng của người dùng), chúng ta nên cẩn thận với bất kỳ giả định nào mà chúng ta đưa ra. Chúng ta thậm chí có thể muốn nhấn mạnh với người dùng rằng họ đang có trải nghiệm khác và cung cấp cho họ cách từ chối điều này. Có lẽ đây là cách thực hành tốt nhất ngay cả đối với những người sử dụng Lưu dữ liệu, vì có thể họ không biết hoặc quên rằng mình đã bật cài đặt này, do đó có trải nghiệm khác.
Tương tự như vậy, bạn cũng có thể cung cấp trải nghiệm giống như Lưu dữ liệu cho tất cả người dùng (ngay cả trong các trình duyệt và hệ điều hành không hỗ trợ) bằng cài đặt giao diện người dùng, sau đó có thể lưu giá trị này vào cookie và thực hiện theo (một mẹo khác mà Tim đã đề cập trong bài nói chuyện của mình).
Trong phần còn lại của bài viết này, tôi muốn xem xét các giải pháp thay thế cho Lưu dữ liệu mà bạn cũng có thể thực hiện để tùy chỉnh trang web của mình. Theo tôi, chúng ta nên sử dụng các giải pháp này ngoài Lưu dữ liệu để có thể thêm một chút tùy chọn.
Sau đó, điều này trả về một trong bốn giá trị chuỗi (
Quay lại với người dùng thiết bị di động Ấn Độ, những người mà chúng tôi thấy trong bài viết trước đang có trải nghiệm tệ hơn nhiều, 84,2% được báo cáo là
Có các tùy chọn khác có sẵn trong API
Lưu ý: Vì lý do riêng tư, các tùy chọn này trả về một số được làm tròn, thay vì một số chính xác, để tránh chúng được sử dụng làm vectơ dấu vân tay. Đây là lý do tại sao chúng ta không thể có những thứ tốt đẹp. Tuy nhiên, vì mục đích không theo dõi, chúng ta chỉ cần một con số không chính xác.
Nhược điểm khác của các API này là chúng chỉ khả dụng dưới dạng API JavaScript (may mắn là rất dễ sử dụng) hoặc dưới dạng Client Hint HTTP Header (không dễ sử dụng).
Client Hints là một cách để giải quyết những hạn chế đó, bằng cách không gửi bất kỳ thông tin bổ sung nào theo mặc định và thay vì để các trang web "chọn tham gia" vào thông tin này khi họ sẽ sử dụng thông tin này. Họ thực hiện điều này bằng cách cho trình duyệt biết, với
Điều này cũng có thể được bao gồm trong phần tử meta trong nội dung trang:
Điều này có nghĩa là bất kỳ yêu cầu nào trong tương lai đối với trang web này sẽ bao gồm các Tiêu đề HTTP Gợi ý của Khách hàng đó, cũng như các Tiêu đề HTTP thông thường:
Quan trọng! Nếu sử dụng Gợi ý của Khách hàng và trả về các kết quả khác nhau cho cùng một URL dựa trên những điều này, hãy nhớ bao gồm các tiêu đề gợi ý của khách hàng mà bạn đang thay đổi nội dung dựa trên, trong Tiêu đề
Bạn có thể xem tất cả các gợi ý máy khách có sẵn cho trình duyệt của mình tại https://browserleaks.com/client-hints (gợi ý: hãy sử dụng trình duyệt dựa trên Chromium để xem trang web này hoặc bạn sẽ không thấy nhiều!). Trang web này chọn tham gia tất cả các Gợi ý máy khách đã biết để hiển thị thông tin tiềm ẩn bị rò rỉ bởi trình duyệt của bạn nhưng mỗi trang web chỉ nên bật các gợi ý mà họ sẽ sử dụng. Client Hints cũng theo mặc định chỉ được gửi theo yêu cầu đến nguồn gốc ban đầu chứ không phải yêu cầu của bên thứ ba được trang tải (mặc dù có thể bật tính năng này thông qua tiêu đề Chính sách cấp phép).
Nhược điểm chính của quy trình hai bước này, mà tôi đồng ý là hoàn toàn cần thiết vì những lý do nêu trên, là yêu cầu đầu tiên đến trang web không nhận được những gợi ý của khách hàng này và đây rất có thể là yêu cầu sẽ được hưởng lợi nhiều nhất từ việc tiết kiệm dựa trên những gợi ý của khách hàng này.
Bản demo BrowserLeaks ở trên thực sự gian lận bằng cách tải dữ liệu đó trong một khung iframe thay vì trong tài liệu chính để giải quyết vấn đề này. Tôi không khuyên bạn nên sử dụng tùy chọn đó cho hầu hết các trang web, nghĩa là bạn chỉ còn cách sử dụng API JavaScript, chỉ tối ưu hóa cho các lượt truy cập không phải trang đầu tiên hoặc sử dụng các yêu cầu độc lập với thông tin Client Hint (tệp Phương tiện, CSS hoặc JavaScript). Điều đó không có nghĩa là việc sử dụng các yêu cầu độc lập này không mạnh mẽ và đặc biệt hữu ích cho CDN hình ảnh, nhưng trang web nhanh nhất là trang web có thể bắt đầu hiển thị tất cả nội dung quan trọng ngay từ phản hồi đầu tiên.
Tôi không hoàn toàn tin rằng cái đầu tiên hữu ích vì hầu như mọi thiết bị hiện nay đều có nhiều bộ xử lý, nhưng thường thì sức mạnh của những lõi đó quan trọng hơn số lượng, tuy nhiên, hai cái tiếp theo có nhiều tiềm năng để tối ưu hóa.
DPR từ lâu đã được sử dụng để phục vụ hình ảnh phản hồi - thường thông qua
Tôi nghĩ rằng chỉ số thực sự có thể được sử dụng làm chỉ số hiệu suất là Bộ nhớ thiết bị. Không giống như số lượng bộ xử lý hoặc DPR, dung lượng RAM của thiết bị thường là chỉ số tuyệt vời để biết liệu đó có phải là thiết bị "cao cấp" hay là thiết bị rẻ hơn, hạn chế hơn. Tôi được khuyến khích tìm hiểu cách thức điều này tương quan với Core Web Vitals của Gilberto Cocchi sau bài viết cuối cùng của tôi và kết quả rất thú vị như được hiển thị trong biểu đồ bên dưới. Những báo cáo này được tạo bằng phiên bản tùy chỉnh của Báo cáo Web Vitals, được thay đổi để cho phép báo cáo trên 4 chiều.
LCP (Largest Contentful Paint) lớn nhất cho thấy mối tương quan rõ ràng giữa LCP kém và RAM, với điểm p75 của RAM 1 GB và 2 GB có màu đỏ và hổ phách, nhưng mặc dù cả RAM cao hơn đều có điểm màu xanh lá cây, vẫn có sự khác biệt rõ ràng và đáng chú ý, đặc biệt là thể hiện trên biểu đồ.
Liệu điều này là do thiếu RAM hoặc RAM chỉ là thước đo proxy của các yếu tố khác (thiết bị cao cấp so với thiết bị thấp cấp, tuổi thiết bị, mạng mà các thiết bị đó chạy trên…v.v.), thực sự không quan trọng vào cuối ngày. Nếu đó là một thước đo proxy tốt cho thấy trải nghiệm có thể kém hơn đối với những người dùng đó, thì chúng ta có thể sử dụng nó như một tín hiệu để tối ưu hóa trang web của mình cho họ.
Chuyển đổi bố cục tích lũy (CLS) có một số mối tương quan, nhưng ngay cả ở bộ nhớ thấp nhất vẫn hiển thị màu xanh lá cây:
Điều này có lẽ không quá ngạc nhiên vì CLS thực sự không thể bị chống lại bởi sức mạnh của các thiết bị hoặc mạng. Nếu có sự thay đổi nào đó xảy ra, trình duyệt sẽ nhận thấy — ngay cả khi nó xảy ra quá nhanh, đến mức người dùng hầu như không nhận thấy.
Điều thú vị là có ít tương quan hơn nhiều đối với Độ trễ đầu vào đầu tiên (FID). Xin lưu ý rằng FID thường không được đo lường, do đó có thể dẫn đến sự gián đoạn trong biểu đồ khi có ít người dùng trong danh mục đó — như thể hiện trong loạt thiết bị 1GB có ít điểm dữ liệu.
Thành thật mà nói, tôi mong đợi Bộ nhớ thiết bị có tác động lớn hơn nhiều đến FID (dù trực tiếp hay gián tiếp vì những lý do đã thảo luận trong phần LCP ở trên) và một lần nữa có lẽ phản ánh rằng số liệu này thực sự không khó để vượt qua đối với nhiều trang web, một điều mà nhóm Chrome rất hiểu rõ và đang nỗ lực thực hiện.
Đối với lý do riêng tư, bộ nhớ thiết bị về cơ bản chỉ được báo cáo là một trong một tập hợp cố định, có giới hạn các số dấu phẩy động: 0,25, 0,5, 1, 2, 4, 8, vì vậy ngay cả khi bạn có 32 GB RAM thì nó cũng sẽ được báo cáo là 8. Nhưng một lần nữa, sự thiếu chính xác đó là ổn vì chúng ta có lẽ chỉ quan tâm đến các thiết bị có 2 GB RAM trở xuống, dựa trên các số liệu thống kê ở trên — mặc dù lời khuyên tốt nhất là hãy đo lượng khách truy cập trang web của riêng bạn và dựa thông tin của bạn vào đó. Tôi chỉ hy vọng theo thời gian, khi công nghệ tiến bộ, chúng ta sẽ không rơi vào tình huống tương tự như ECT khi mọi thứ di chuyển lên danh mục hàng đầu, khiến tín hiệu trở nên kém hữu ích hơn. Về mặt tích cực, điều này sẽ dễ thay đổi hơn chỉ bằng cách tăng số lượng giới hạn trên.
Điều này có thể đơn giản như ghi lại các giá trị cho các tùy chọn này trong Google Analytics Custom Dimension. Đó là những gì chúng tôi đã làm tại Smashing cho một số tùy chọn trong số đó và cách chúng tôi có thể tạo các biểu đồ ở trên để xem mối tương quan khi chúng tôi có thể cắt và phân tích các biện pháp này so với dữ liệu khác trong Google Analytics (bao gồm cả Core Web Vitals, chúng tôi đã ghi vào Google Analytics bằng thư viện web-vitals).
Ngoài ra, nếu bạn đã sử dụng một trong nhiều giải pháp RUM hiện có, một số hoặc tất cả các giải pháp này có thể đã được đo lường và bạn có thể đã có dữ liệu để giúp bắt đầu đưa ra quyết định về việc có nên sử dụng các tùy chọn này hay không. Và nếu thư viện RUM bạn chọn không theo dõi các số liệu này, thì có thể đề xuất họ theo dõi để mang lại lợi ích cho bạn và những người dùng khác của họ.
Tôi đã đề cập rằng trang web này, smashingmagazine.com sử dụng API Lưu dữ liệu để tránh tải phông chữ web. Ngoài ra, trang web này sử dụng thư viện instant.page để tải trước các bài viết khi di chuột qua — ngoại trừ các ECT chậm hoặc khi người dùng đã chỉ định tùy chọn Lưu dữ liệu.
Web Almanac (một trang web khác mà tôi làm việc), là một trang web bài viết có vẻ đơn giản khác, trong đó mỗi chương sử dụng nhiều biểu đồ và hình ảnh khác. Ban đầu, chúng được tải dưới dạng hình ảnh tải chậm và sau đó được nâng cấp thành nhúng Google Trang tính, có hiệu ứng di chuột tiện dụng để xem các điểm dữ liệu. Các nhúng của Google Trang tính thực sự hơi chậm và tốn nhiều tài nguyên, vì vậy nâng cấp này chỉ dành cho những người dùng có khả năng được hưởng lợi từ nó: những người dùng có chiều rộng khung nhìn Desktop, khi Lưu dữ liệu không bị tắt, khi chúng tôi sử dụng kết nối nhanh bằng ECT và khi hỗ trợ canvas có độ phân giải cao (không được đề cập trong bài viết này, nhưng iPad cũ không hỗ trợ tính năng này nhưng đã tuyên bố là có).
Tôi khuyến khích bạn cân nhắc xem những phần nào trên trang web của mình mà bạn nên cân nhắc giới hạn cho một số người dùng. Hãy cho chúng tôi biết trong phần bình luận về cách bạn sử dụng chúng.
Điều đó không có nghĩa là nội dung không cần thiết là vô nghĩa — thiết kế nâng cao và giao diện người dùng có thể có tác động quan trọng đến thương hiệu của trang web và những nội dung bổ sung nhỏ thú vị thực sự có thể tác động đến mối quan hệ của người dùng với trang web của bạn. Khi chi phí cho những "nội dung bổ sung" đó bắt đầu tác động tiêu cực đến trải nghiệm của người dùng trên trang web, thì bạn nên cân nhắc xem chúng cần thiết như thế nào và liệu chúng có thể bị tắt đối với một số người dùng hay không.
API Lưu dữ liệu
Chúng ta hãy cùng tóm tắt nhanh về API Lưu dữ liệu. Tùy chọn người dùng đó khả dụng theo hai cách (hy vọng sẽ sớm có ba cách!):- Tiêu đề
Save-Datađược gửi trên mỗi yêu cầu HTTP.
Điều này cho phép các backend động thay đổi HTML được trả về. - API JavaScript
NetworkInformation.saveData.
Điều này cho phép JavaScript phía máy khách kiểm tra điều này và hành động phù hợp. - Truy vấn phương tiện
prefers-reduced-datasắp tới, cho phép CSS đặt các tùy chọn khác nhau tùy thuộc vào cài đặt này.
Điều này khả dụng sau một cờ trong Chrome, nhưng chưa được bật theo mặc định trong khi hoàn tất chuẩn hóa.
Có lẽ hơi khó hiểu, iOS có chế độ Dữ liệu thấp, mặc dù chế độ này được chính iOS sử dụng để giảm các tác vụ nền sử dụng dữ liệu và không được trình duyệt hiển thị để cho phép các trang web tận dụng chế độ đó (ngay cả đối với Chrome trên iOS, chế độ này giống một giao diện trên Safari hơn là trình duyệt Chrome đầy đủ).
Các trang web có thể hoạt động theo tùy chọn Lưu dữ liệu để cung cấp một trang web nhẹ hơn nhằm... . . lưu dữ liệu của người dùng! Điều này hữu ích cho những người dùng sử dụng mạng kém hoặc đắt tiền, do đó, họ không phải trả chi phí cắt cổ chỉ để truy cập trang web của bạn. Cài đặt này được sử dụng bởi người dùng ở các quốc gia nghèo hơn nhưng cũng được sử dụng bởi những người có gói dữ liệu giới hạn có thể sắp hết ngay trước khi gia hạn giới hạn hàng tháng của bạn hoặc những người đi du lịch nơi phí chuyển vùng có thể đắt hơn nhiều so với ở nhà.
Và nó có được sử dụng không?
Một lần nữa, tôi đã nói về điều này trong bài viết trước và câu trả lời là có! Ví dụ, khoảng hai phần ba người dùng Chrome di động Ấn Độ của Tạp chí Smashing đã bật cài đặt này. Mở rộng điều đó để xem xét 10 người dùng di động hàng đầu hỗ trợ Lưu dữ liệu, theo khối lượng cho trang web này, chúng ta thấy như sau:| Quốc gia | % Dữ liệu Saver |
|---|---|
| Ấn Độ | 63% |
| Hoa Kỳ | 10% |
| Philippines | 49% |
| Trung Quốc | 0% |
| Anh | 35% |
| Nga | 55% |
| Canada | 38% |
| Đức | 35% |
| Pakistan | 51% |
Tôi rất muốn biết lý do tại sao Trung Quốc lại miễn cưỡng sử dụng cài đặt này nếu bất kỳ độc giả nào biết. Thật kỳ lạ, họ báo cáo là một loạt các trình duyệt trong phân tích của chúng tôi bao gồm Android WebView, Chrome và Safari (mặc dù nó không hỗ trợ điều này!). Có lẽ, đây là những chiếc điện thoại nhái hoặc các bản dựng tùy chỉnh khác không hiển thị cài đặt này cho người dùng cuối để bật tính năng này. Nếu bạn có bất kỳ lý thuyết hoặc thông tin nào khác về điều này — Tôi rất muốn biết, vì vậy hãy để lại tin nhắn trong phần bình luận bên dưới.
Tuy nhiên, bảng trên không thực sự đại diện cho tổng lưu lượng truy cập và đó là một điểm khác cần lưu ý về dữ liệu này. Nếu chúng ta so sánh 10 quốc gia truy cập SmashingMagazine.com nhiều nhất theo số lượng người dùng trên bốn phân khúc khác nhau, chúng ta sẽ thấy như sau:
| Tất cả người dùng | Người dùng thiết bị di động | Hỗ trợ Mobile SaveData | Mobile SaveData trên | |
|---|---|---|---|---|
| 1 | Hoa Kỳ | Hoa Kỳ | Ấn Độ | Ấn Độ |
| 2 | Ấn Độ | Ấn Độ | Hoa Kỳ | Philippines |
| 3 | Vương quốc Anh | Vương quốc Anh | Philippines | Nigeria |
| 4 | Canada | Đức | Trung Quốc | Vương quốc Anh |
| 5 | Đức | Philippines | Vương quốc Anh | Nga |
| 6 | Pháp | Canada | Nigeria | Hoa Kỳ |
| 7 | Nga | Trung Quốc | Nga | Indonesia |
| 8 | Úc | Pháp | Canada | Pakistan |
| 9 | Philippines | Nigeria | Đức | Brazil |
| 10 | Hà Lan | Nga | Pakistan | Canada |
Tuy nhiên, khi xem xét những quốc gia có hỗ trợ Save Data (giống như bảng đầu tiên tôi đã trình bày), thì lại là một góc nhìn hoàn toàn khác; Ấn Độ đã vượt qua Hoa Kỳ ở vị trí đầu bảng và Philippines vươn lên vị trí thứ ba. Và cuối cùng, khi xem xét những quốc gia thực sự bật Save Data, thì thứ tự không thể nhận ra được so với cột đầu tiên.
Tôi đã đề cập trước đó rằng Save Data chỉ khả dụng trên các trình duyệt dựa trên Chromium, nghĩa là chúng tôi đang bỏ qua người dùng Safari (một tỷ lệ đáng kể người dùng thiết bị di động) và Firefox. Tuy nhiên, vô số nghiên cứu (bao gồm cả số liệu thống kê cho trang web của chúng tôi tại đây và các nghiên cứu khác của những người như Alex Russell) đã chỉ ra rằng thiết bị Android là nền tảng được lựa chọn cho các quốc gia nghèo hơn có mạng chậm hơn. Điều này không có gì đáng ngạc nhiên khi xét đến sự chênh lệch về chi phí giữa các thiết bị Android và iOS, nhưng việc chỉ sử dụng các tín hiệu được cung cấp cho những thiết bị đó không có nghĩa là bỏ qua một nửa cơ sở người dùng của bạn, mà thay vào đó là tập trung vào những người dùng cần trợ giúp nhiều nhất.
Ngoài ra, như tôi đã đề cập trong bài viết trước, sáng kiến Core Web Vitals chỉ được đo lường trong trình duyệt Chrome (và không phải các trình duyệt Chromium khác như Edge hoặc Opera) đang tập trung vào những người dùng này, trong khi đồng thời đó là những người dùng hỗ trợ API này và các API khác để cho phép bạn giải quyết vấn đề của họ.
Vì vậy, mặc dù tôi ước rằng không có sự bất bình đẳng này trên thế giới này và mặc dù tôi ước rằng tất cả các trình duyệt sẽ hỗ trợ các tùy chọn này tốt hơn, tôi vẫn tin rằng việc sử dụng các tùy chọn này để tùy chỉnh việc phân phối tốt hơn là điều đúng đắn cần làm và thực tế là chúng chỉ khả dụng trong các trình duyệt dựa trên Chromium tại thời điểm này không phải là lý do để bỏ qua các tùy chọn này.
Cách hành động sau khi lưu Dữ liệu
Cách thức chính xác các trang web sử dụng thông tin này hoàn toàn phụ thuộc vào trang web. Trước đây, Chrome thường thực hiện các thay đổi đối với trang web bằng cách ủy quyền các yêu cầu thông qua máy chủ của họ (tương tự như cách Opera Mini hoạt động), nhưng việc làm đó thường bị phản đối trong thời buổi ngày nay. Với sự gia tăng trong việc sử dụng HTTPS, nội dung trang web được bảo mật hơn một phần để tránh mọi sự can thiệp (Chrome không bao giờ thực hiện các tối ưu hóa tự động này trên các trang web HTTPS, mặc dù về mặt lý thuyết, trình duyệt có thể thực hiện). Chrome cũng sẽ sớm hủy bỏ việc tự động thay đổi nội dung này trên các trang web HTTP. Vì vậy, bây giờ các trang web phải thực hiện thay đổi theo ý muốn nếu họ muốn hành động theo tín hiệu người dùng này.Các trang web vẫn phải cung cấp trải nghiệm cốt lõi của trang web, nhưng loại bỏ các tính năng bổ sung tùy chọn. Đối với Smashing Magazine, điều đó liên quan đến việc loại bỏ một số phông chữ web của chúng tôi. Đối với những trang khác, có thể liên quan đến việc sử dụng hình ảnh nhỏ hơn hoặc không tải video theo mặc định. Tất nhiên, vì lý do hiệu suất web, bạn nên luôn sử dụng hình ảnh nhỏ nhất có thể, nhưng trong thời đại màn hình di động mật độ cao như ngày nay, nhiều người thích cung cấp hình ảnh chất lượng cao để tận dụng những màn hình đẹp đó. Nếu người dùng đã chỉ ra rằng họ thích lưu dữ liệu, bạn có thể sử dụng điều đó làm tín hiệu để giảm xuống một cấp độ ở đó, ngay cả khi nó không đẹp bằng hình ảnh, nhưng vẫn truyền tải được thông điệp.
Tim Vereecke đã có một bài nói chuyện tuyệt vời về một số Chiến lược Data S(h)aver mà anh ấy sử dụng trên trang web của mình cho những người dùng có tùy chọn Save Data này, bao gồm hiển thị ít bài viết hơn theo mặc định, tải ít hơn trên các trang cuộn vô hạn khi đến cuối trang, xóa phông chữ biểu tượng hoặc giảm số lượng quảng cáo, không tự động phát video và tải thêm nhiều mẹo và thủ thuật, một số trong số đó đã được anh ấy tóm tắt trong một bài viết đi kèm.
Một điểm quan trọng mà Tim lưu ý là sử dụng Lưu dữ liệu không phải lúc nào cũng cải thiện hiệu suất. Một số kỹ thuật mà anh ấy sử dụng như tải ít hơn hoặc tắt tính năng tải trước các trang có khả năng sẽ tiết kiệm dữ liệu, nhưng nhược điểm là tải lâu hơn một chút nếu người dùng muốn xem nội dung đó. Tuy nhiên, nhìn chung, việc giảm dữ liệu thường giúp tăng hiệu suất web.
Lưu dữ liệu có phải là lựa chọn duy nhất không?
Theo tôi, Lưu dữ liệu là một API tuyệt vời và tôi ước nhiều trang web hơn sử dụng API này và nhiều trình duyệt hơn hỗ trợ API này! Thực tế là người dùng đã yêu cầu các trang web gửi ít dữ liệu hơn có nghĩa là việc làm đó là hành động theo mong muốn của họ.Tuy nhiên, nhược điểm của Lưu dữ liệu là người dùng phải biết để bật tùy chọn này. Trong khi nhiều độc giả của Smashing Magazine có thể am hiểu kỹ thuật hơn và có thể biết về tùy chọn này hoặc có thể thoải mái tìm hiểu về cài đặt trình duyệt của họ, thì những người khác có thể không. Ngoài ra, với thay đổi đã đề cập ở trên của Chrome khi loại bỏ tùy chọn trình duyệt Lưu dữ liệu và có lẽ chuyển sang sử dụng tùy chọn cấp hệ điều hành, chúng ta có thể thấy một số thay đổi trong cách sử dụng tùy chọn này (tốt hơn hoặc tệ hơn!).
Vậy, chúng ta có thể làm gì để cố gắng giúp những người dùng không có tùy chọn này? Vâng, có một số tín hiệu khác mà chúng ta có thể sử dụng, vì chúng cũng có thể chỉ ra những người dùng có thể gặp khó khăn với trải nghiệm đầy đủ của trang web. Tuy nhiên, vì chúng ta đang đưa ra quyết định đó cho họ (không giống như Lưu dữ liệu là lựa chọn rõ ràng của người dùng), chúng ta nên cẩn thận với bất kỳ giả định nào mà chúng ta đưa ra. Chúng ta thậm chí có thể muốn nhấn mạnh với người dùng rằng họ đang có trải nghiệm khác và cung cấp cho họ cách từ chối điều này. Có lẽ đây là cách thực hành tốt nhất ngay cả đối với những người sử dụng Lưu dữ liệu, vì có thể họ không biết hoặc quên rằng mình đã bật cài đặt này, do đó có trải nghiệm khác.
Tương tự như vậy, bạn cũng có thể cung cấp trải nghiệm giống như Lưu dữ liệu cho tất cả người dùng (ngay cả trong các trình duyệt và hệ điều hành không hỗ trợ) bằng cài đặt giao diện người dùng, sau đó có thể lưu giá trị này vào cookie và thực hiện theo (một mẹo khác mà Tim đã đề cập trong bài nói chuyện của mình).
Trong phần còn lại của bài viết này, tôi muốn xem xét các giải pháp thay thế cho Lưu dữ liệu mà bạn cũng có thể thực hiện để tùy chỉnh trang web của mình. Theo tôi, chúng ta nên sử dụng các giải pháp này ngoài Lưu dữ liệu để có thể thêm một chút tùy chọn.
Các tín hiệu tùy chọn người dùng khác
Trước tiên, chúng ta sẽ xem xét các tùy chọn mà người dùng có thể bật và tắt, giống như Lưu dữ liệu. Một loại truy vấn phương tiện CSS theo sở thích của người dùng mới đã được ra mắt gần đây, đang được chuẩn hóa trong Bản thảo đặc tả truy vấn phương tiện Cấp độ 5 và nhiều loại đã có sẵn trong trình duyệt. Những loại này cho phép các nhà phát triển web thay đổi trang web của họ dựa trên các sở thích khác nhau của người dùng:-
prefers-reduced-motion
Điều này cho thấy người dùng muốn ít chuyển động hơn, có thể là do rối loạn chuyển động tiền đình. Adam Argyle đã nhấn mạnh rằng chuyển động giảm != không chuyển động. Chỉ cần giảm bớt một chút. Nếu bạn đang thực hiện tùy chọn lưu dữ liệu, bạn sẽ không giữ lại tất cả dữ liệu! -
prefers-reduced-transparency
Để hỗ trợ khả năng đọc cho những người thấy khó phân biệt nội dung có nền trong mờ. -
prefers-contrast
Tương tự như trên, tùy chọn này có thể được sử dụng như một yêu cầu để tăng độ tương phản giữa các thành phần. -
forced-colors
Điều này cho biết tác nhân người dùng đang sử dụng bảng màu giảm, thường là vì lý do trợ năng, chẳng hạn như chế độ Tương phản cao của Windows. -
prefers-color-scheme
Tùy chọn này có thể được đặt thànhlighthoặcdarkđể chỉ ra phối màu ưa thích của người dùng. -
prefers-reduced-data
Phiên bản truy vấn phương tiện CSS của Save Data đã đề cập ở trên.
Tín hiệu mạng
Trở về nhiều mục hơn để tối ưu hóa hiệu suất web, API Loại kết nối hiệu quả là một thuộc tính của API Thông tin mạng và có thể được truy vấn trong JavaScript bằng mã sau (hiện tại chỉ có trong trình duyệt Chromium):
Mã:
navigator.connection.effectiveType;4g, 3g, 2g hoặc slow-2g) — lý thuyết cho rằng bạn có thể giảm nhu cầu mạng khi kết nối chậm hơn và do đó mang lại trải nghiệm nhanh hơn ngay cả đối với những người dùng mạng chậm hơn. ECT có một số nhược điểm. Nhược điểm chính là định nghĩa của 4 loại đều cố định và dựa trên dữ liệu mạng khá cũ. Kết quả là hầu như tất cả người dùng hiện nay đều thuộc danh mục 4g, một số ít thuộc danh mục 3g và rất ít người thuộc danh mục 2g hoặc slow-2g.Quay lại với người dùng thiết bị di động Ấn Độ, những người mà chúng tôi thấy trong bài viết trước đang có trải nghiệm tệ hơn nhiều, 84,2% được báo cáo là
4g, 15,1% 3g, 0,4% 2g và 0,3% slow-2g. Thật tuyệt khi công nghệ đã tiến bộ đến mức này, nhưng sự phụ thuộc của chúng ta vào nó cũng tăng lên, và điều đó có nghĩa là việc sử dụng nó như một công cụ phân biệt người dùng "chậm hơn" đã bị hạn chế và ngày càng trở nên hạn chế hơn theo thời gian. Có thể xác định 16% người dùng chậm nhất không phải là điều đáng khinh, nhưng vẫn còn kém xa so với 63% người dùng yêu cầu chúng ta Lưu dữ liệu trong khu vực đó!Có các tùy chọn khác có sẵn trong API
navigator.connection, nhưng không có sự đơn giản của một số ít danh mục:
Mã:
navigator.connection.rtt;navigator.connection.downlink;Nhược điểm khác của các API này là chúng chỉ khả dụng dưới dạng API JavaScript (may mắn là rất dễ sử dụng) hoặc dưới dạng Client Hint HTTP Header (không dễ sử dụng).
Client Hints HTTP Header
Tiêu đề HTTPSave-Data là Tiêu đề HTTP đơn giản được gửi cho tất cả các yêu cầu khi người dùng bật tính năng này. Điều này giúp các chương trình phụ trợ dễ dàng sử dụng. Tuy nhiên, chúng ta không thể lấy thông tin khác như ECT trong các tiêu đề HTTP tương tự mà không làm tăng đáng kể tất cả các yêu cầu duyệt web khi phần lớn các trang web sẽ không sử dụng tính năng này. Nó cũng gây ra rủi ro về quyền riêng tư bằng cách cung cấp nhiều thông tin hơn mức chúng ta thực sự cần về người dùng của mình.Client Hints là một cách để giải quyết những hạn chế đó, bằng cách không gửi bất kỳ thông tin bổ sung nào theo mặc định và thay vì để các trang web "chọn tham gia" vào thông tin này khi họ sẽ sử dụng thông tin này. Họ thực hiện điều này bằng cách cho trình duyệt biết, với
Accept CH HTTP Header, những tiêu đề Client Hint nào mà trang sẽ sử dụng. Ví dụ, trong phản hồi cho yêu cầu ban đầu, chúng ta có thể bao gồm Tiêu đề HTTP này:
Mã:
accept-ch: ect, rtt, downlink
Mã:
Mã:
downlink: 10ect: 4grtt: 50Vary, do đó bất kỳ bộ đệm nào cũng nhận biết được điều này và sẽ không phục vụ trang được lưu trong bộ đệm cho các lần truy cập trong tương lai trừ khi chúng cũng có cùng tiêu đề gợi ý máy khách được đặt.Bạn có thể xem tất cả các gợi ý máy khách có sẵn cho trình duyệt của mình tại https://browserleaks.com/client-hints (gợi ý: hãy sử dụng trình duyệt dựa trên Chromium để xem trang web này hoặc bạn sẽ không thấy nhiều!). Trang web này chọn tham gia tất cả các Gợi ý máy khách đã biết để hiển thị thông tin tiềm ẩn bị rò rỉ bởi trình duyệt của bạn nhưng mỗi trang web chỉ nên bật các gợi ý mà họ sẽ sử dụng. Client Hints cũng theo mặc định chỉ được gửi theo yêu cầu đến nguồn gốc ban đầu chứ không phải yêu cầu của bên thứ ba được trang tải (mặc dù có thể bật tính năng này thông qua tiêu đề Chính sách cấp phép).
Nhược điểm chính của quy trình hai bước này, mà tôi đồng ý là hoàn toàn cần thiết vì những lý do nêu trên, là yêu cầu đầu tiên đến trang web không nhận được những gợi ý của khách hàng này và đây rất có thể là yêu cầu sẽ được hưởng lợi nhiều nhất từ việc tiết kiệm dựa trên những gợi ý của khách hàng này.
Bản demo BrowserLeaks ở trên thực sự gian lận bằng cách tải dữ liệu đó trong một khung iframe thay vì trong tài liệu chính để giải quyết vấn đề này. Tôi không khuyên bạn nên sử dụng tùy chọn đó cho hầu hết các trang web, nghĩa là bạn chỉ còn cách sử dụng API JavaScript, chỉ tối ưu hóa cho các lượt truy cập không phải trang đầu tiên hoặc sử dụng các yêu cầu độc lập với thông tin Client Hint (tệp Phương tiện, CSS hoặc JavaScript). Điều đó không có nghĩa là việc sử dụng các yêu cầu độc lập này không mạnh mẽ và đặc biệt hữu ích cho CDN hình ảnh, nhưng trang web nhanh nhất là trang web có thể bắt đầu hiển thị tất cả nội dung quan trọng ngay từ phản hồi đầu tiên.
Tín hiệu khả năng thiết bị
Tiếp theo từ tín hiệu Người dùng và Mạng, chúng ta có danh mục cuối cùng là tín hiệu thiết bị. Các API này giải thích về khả năng của thiết bị, thay vì kết nối, bao gồm:| API | JavaScript API | Client Hint | Example Output |
|---|---|---|---|
| Số bộ xử lý | navigator.hardwareConcurrency | N/A | 4 |
| Tỷ lệ điểm ảnh của thiết bị | devicePixelRatio | Sec-CH-DPR, DPR | 3 |
| Bộ nhớ thiết bị | navigator.deviceMemory | Sec-CH-Device-Memory, Device-Memory | 8 |
DPR từ lâu đã được sử dụng để phục vụ hình ảnh phản hồi - thường thông qua
srcset hoặc truy vấn phương tiện hơn là các API trên, nhưng các tùy chọn tiêu đề JavaScript và Client Hint ít được các trang web sử dụng hơn (mặc dù nhiều CDN hình ảnh hỗ trợ gửi các hình ảnh khác nhau dựa trên Client Hints). Sử dụng chúng nhiều hơn có thể dẫn đến các tối ưu hóa có giá trị cho các trang web — ngoài các trường hợp sử dụng phương tiện tĩnh mà chúng ta thường thấy cho đến bây giờ.Tôi nghĩ rằng chỉ số thực sự có thể được sử dụng làm chỉ số hiệu suất là Bộ nhớ thiết bị. Không giống như số lượng bộ xử lý hoặc DPR, dung lượng RAM của thiết bị thường là chỉ số tuyệt vời để biết liệu đó có phải là thiết bị "cao cấp" hay là thiết bị rẻ hơn, hạn chế hơn. Tôi được khuyến khích tìm hiểu cách thức điều này tương quan với Core Web Vitals của Gilberto Cocchi sau bài viết cuối cùng của tôi và kết quả rất thú vị như được hiển thị trong biểu đồ bên dưới. Những báo cáo này được tạo bằng phiên bản tùy chỉnh của Báo cáo Web Vitals, được thay đổi để cho phép báo cáo trên 4 chiều.
LCP (Largest Contentful Paint) lớn nhất cho thấy mối tương quan rõ ràng giữa LCP kém và RAM, với điểm p75 của RAM 1 GB và 2 GB có màu đỏ và hổ phách, nhưng mặc dù cả RAM cao hơn đều có điểm màu xanh lá cây, vẫn có sự khác biệt rõ ràng và đáng chú ý, đặc biệt là thể hiện trên biểu đồ.
Liệu điều này là do thiếu RAM hoặc RAM chỉ là thước đo proxy của các yếu tố khác (thiết bị cao cấp so với thiết bị thấp cấp, tuổi thiết bị, mạng mà các thiết bị đó chạy trên…v.v.), thực sự không quan trọng vào cuối ngày. Nếu đó là một thước đo proxy tốt cho thấy trải nghiệm có thể kém hơn đối với những người dùng đó, thì chúng ta có thể sử dụng nó như một tín hiệu để tối ưu hóa trang web của mình cho họ.
Chuyển đổi bố cục tích lũy (CLS) có một số mối tương quan, nhưng ngay cả ở bộ nhớ thấp nhất vẫn hiển thị màu xanh lá cây:
Điều này có lẽ không quá ngạc nhiên vì CLS thực sự không thể bị chống lại bởi sức mạnh của các thiết bị hoặc mạng. Nếu có sự thay đổi nào đó xảy ra, trình duyệt sẽ nhận thấy — ngay cả khi nó xảy ra quá nhanh, đến mức người dùng hầu như không nhận thấy.
Điều thú vị là có ít tương quan hơn nhiều đối với Độ trễ đầu vào đầu tiên (FID). Xin lưu ý rằng FID thường không được đo lường, do đó có thể dẫn đến sự gián đoạn trong biểu đồ khi có ít người dùng trong danh mục đó — như thể hiện trong loạt thiết bị 1GB có ít điểm dữ liệu.
Thành thật mà nói, tôi mong đợi Bộ nhớ thiết bị có tác động lớn hơn nhiều đến FID (dù trực tiếp hay gián tiếp vì những lý do đã thảo luận trong phần LCP ở trên) và một lần nữa có lẽ phản ánh rằng số liệu này thực sự không khó để vượt qua đối với nhiều trang web, một điều mà nhóm Chrome rất hiểu rõ và đang nỗ lực thực hiện.
Đối với lý do riêng tư, bộ nhớ thiết bị về cơ bản chỉ được báo cáo là một trong một tập hợp cố định, có giới hạn các số dấu phẩy động: 0,25, 0,5, 1, 2, 4, 8, vì vậy ngay cả khi bạn có 32 GB RAM thì nó cũng sẽ được báo cáo là 8. Nhưng một lần nữa, sự thiếu chính xác đó là ổn vì chúng ta có lẽ chỉ quan tâm đến các thiết bị có 2 GB RAM trở xuống, dựa trên các số liệu thống kê ở trên — mặc dù lời khuyên tốt nhất là hãy đo lượng khách truy cập trang web của riêng bạn và dựa thông tin của bạn vào đó. Tôi chỉ hy vọng theo thời gian, khi công nghệ tiến bộ, chúng ta sẽ không rơi vào tình huống tương tự như ECT khi mọi thứ di chuyển lên danh mục hàng đầu, khiến tín hiệu trở nên kém hữu ích hơn. Về mặt tích cực, điều này sẽ dễ thay đổi hơn chỉ bằng cách tăng số lượng giới hạn trên.
Đo lường người dùng của bạn
Phần cuối cùng, về việc liên hệ Bộ nhớ thiết bị với Core Web Vitals, đưa ra một chủ đề quan trọng: đừng chỉ coi bất kỳ tùy chọn nào trong số này là hiển nhiên sẽ hữu ích cho trang web của bạn. Thay vào đó, hãy đo lường số lượng người dùng để xem tùy chọn nào trong số này sẽ hữu ích cho người dùng của bạn.Điều này có thể đơn giản như ghi lại các giá trị cho các tùy chọn này trong Google Analytics Custom Dimension. Đó là những gì chúng tôi đã làm tại Smashing cho một số tùy chọn trong số đó và cách chúng tôi có thể tạo các biểu đồ ở trên để xem mối tương quan khi chúng tôi có thể cắt và phân tích các biện pháp này so với dữ liệu khác trong Google Analytics (bao gồm cả Core Web Vitals, chúng tôi đã ghi vào Google Analytics bằng thư viện web-vitals).
Ngoài ra, nếu bạn đã sử dụng một trong nhiều giải pháp RUM hiện có, một số hoặc tất cả các giải pháp này có thể đã được đo lường và bạn có thể đã có dữ liệu để giúp bắt đầu đưa ra quyết định về việc có nên sử dụng các tùy chọn này hay không. Và nếu thư viện RUM bạn chọn không theo dõi các số liệu này, thì có thể đề xuất họ theo dõi để mang lại lợi ích cho bạn và những người dùng khác của họ.
Kết luận
Tôi hy vọng bài viết này sẽ thuyết phục bạn cân nhắc các tùy chọn này cho trang web của riêng bạn. Nhiều tùy chọn trong số này rất dễ sử dụng nếu bạn biết về chúng và có thể tạo ra sự khác biệt thực sự đối với những người dùng đang gặp khó khăn nhất. Chúng không chỉ dành cho các ứng dụng web phức tạp mà còn có thể được sử dụng ngay cả trên các trang web bài viết tĩnh.Tôi đã đề cập rằng trang web này, smashingmagazine.com sử dụng API Lưu dữ liệu để tránh tải phông chữ web. Ngoài ra, trang web này sử dụng thư viện instant.page để tải trước các bài viết khi di chuột qua — ngoại trừ các ECT chậm hoặc khi người dùng đã chỉ định tùy chọn Lưu dữ liệu.
Web Almanac (một trang web khác mà tôi làm việc), là một trang web bài viết có vẻ đơn giản khác, trong đó mỗi chương sử dụng nhiều biểu đồ và hình ảnh khác. Ban đầu, chúng được tải dưới dạng hình ảnh tải chậm và sau đó được nâng cấp thành nhúng Google Trang tính, có hiệu ứng di chuột tiện dụng để xem các điểm dữ liệu. Các nhúng của Google Trang tính thực sự hơi chậm và tốn nhiều tài nguyên, vì vậy nâng cấp này chỉ dành cho những người dùng có khả năng được hưởng lợi từ nó: những người dùng có chiều rộng khung nhìn Desktop, khi Lưu dữ liệu không bị tắt, khi chúng tôi sử dụng kết nối nhanh bằng ECT và khi hỗ trợ canvas có độ phân giải cao (không được đề cập trong bài viết này, nhưng iPad cũ không hỗ trợ tính năng này nhưng đã tuyên bố là có).
Tôi khuyến khích bạn cân nhắc xem những phần nào trên trang web của mình mà bạn nên cân nhắc giới hạn cho một số người dùng. Hãy cho chúng tôi biết trong phần bình luận về cách bạn sử dụng chúng.
Đọc thêm
- Thời gian đến byte đầu tiên: Ngoài thời gian phản hồi của máy chủ
- Tạo biểu mẫu nhiều bước hiệu quả để có trải nghiệm người dùng tốt hơn
- Thời gian đến byte đầu tiên: Ngoài thời gian phản hồi của máy chủ
- Tại sao tối ưu hóa điểm Lighthouse của bạn là không đủ cho một trang web nhanh
