Tác động của web bloat đối với người dùng thiết bị chậm

 (danluu.com)
1 điểm bởi GN⁺ 2024-03-17 | 1 bình luận | Chia sẻ qua WhatsApp
  • Từ sau năm 2017, tăng trưởng băng thông phần nào đã vượt mức tăng kích thước truyền tải của các website thông thường, nhưng yêu cầu CPU của web app lại tăng nhanh hơn hiệu năng của thiết bị giá rẻ, khiến khả năng truy cập web kém đi ngay cả khi có Internet nhanh
  • Ngay cả với kết nối 1Gbps, Tecno Spark 8C vẫn bị crash trình duyệt trên diễn đàn Discourse, còn trên Itel P32 thì các site như Discourse, Reddit, Shopify, Substack, Wix, Mastodon, Bluesky rơi vào trạng thái FAIL hoặc gần như không thể sử dụng
  • Đo lường đã so sánh LCP* và thời gian CPU của luồng chính trên M3 Max, M1 Pro, Chrome throttling CPU 10x, Tecno Spark 8C, Itel P32; điểm PageSpeed Insights có tương quan yếu với tốc độ cảm nhận thực tế
  • Các site đơn giản hoặc cũ như MyBB, phpBB, WordPress đời cũ, HN, danluu.com hoạt động tương đối tốt ngay cả trên di động giá rẻ, trong khi các site có nhiều tải động như Discourse, Medium, Reddit, Substack nổi bật với độ trễ cuộn, tìm kiếm và chạm tab
  • Người dùng thiết bị giá rẻ ở các khu vực như Nigeria, India, Latin America là người dùng web thực sự; nếu xây web chỉ dựa trên iOS và Internet nhanh thì sẽ loại trừ cả người dùng kém khá giả lẫn người dùng desktop cấu hình thấp

Web nơi CPU trở thành nút thắt cổ chai thay vì băng thông

  • Năm 2017, web bloat làm tổn hại mạnh đến tính khả dụng trên kết nối chậm, và từ đó băng thông của các kết nối cao cấp tăng rất nhanh, khoảng 50% mỗi năm theo Nielsen
  • Người dùng Internet chậm vẫn còn rất nhiều và phần lớn web hiện đại vẫn khó dùng trên kết nối chậm, nhưng với các site thông thường thì tăng trưởng băng thông phần nào đã vượt mức tăng kích thước truyền tải
  • Ngược lại, yêu cầu hiệu năng CPU của web app không được cải thiện nhanh như băng thông, nên ngay cả khi có kết nối Internet tốt, việc dùng web trên thiết bị cấu hình thấp vẫn trở nên khó khăn
  • Các diễn đàn “hiện đại” dựa trên Discourse thậm chí có thể làm crash trình duyệt trên Tecno Spark 8C, và độ phản hồi giữa các lần crash còn được đo là tệ hơn cả việc dùng BBS với 8 MHz 286 và modem 1200 baud
  • Payload nén để tải tiêu đề tin nhắn trên Discourse là 2.6 MB, tức lượng truyền tải tăng khoảng 1000x so với trước kia, nhưng trên kết nối 1Gbps thì vẫn tương đối nhẹ
  • Ở góc độ CPU, ngay cả Tecno Spark 8C với 8-core (2 1.6 GHz Cortex-A75 / 6 1.6 GHz Cortex-A55) cũng không gánh nổi Discourse, dù CPU đó nhanh hơn 286 khoảng 100000x

Đối tượng đo và chỉ số

  • Thiết bị thử nghiệm gồm M3 Max Macbook (14-core), M1 Pro Macbook (8-core), M3 Max throttling 10x trong Chrome DevTools, Tecno Spark 8C, Itel P32
  • Mạng dùng 1Gbps Internet và router WiFi có độ trễ thấp khi tải nặng, để tạo điều kiện có lợi cho thiết bị
  • Đối tượng so sánh gồm blog/microblog, diễn đàn và nền tảng cho doanh nghiệp nhỏ
    • Blog/microblog: danluu.com, Substack, Medium, Ghost, Hugo, Tumblr, Mastodon, Twitter, Threads, Bluesky, Patreon
    • Diễn đàn: Discourse, Reddit, Quora, vBulletin, XenForo, phpBB, MyBB
    • Nền tảng cho doanh nghiệp nhỏ: Wix, Squarespace, Shopify, WordPress
  • Các chỉ số chính là kích thước nén khi truyền (wire), kích thước sau giải nén (raw), LCP*, và thời gian CPU của luồng chính
  • LCP* không phải Largest Contentful Paint do Chrome đo, mà lấy mốc thời điểm nội dung hữu ích thực sự xuất hiện khi các lần cập nhật màn hình lớn không hữu ích với người dùng
  • Thời gian CPU không phải Core Web Vital, nhưng được dùng như một chỉ số đơn giản có liên hệ mạnh với tính khả dụng mà người dùng cảm nhận trên thiết bị chậm

Khoảng cách về tính khả dụng thể hiện trong bảng

  • danluu.com và HN chạy nhanh trên mọi thiết bị thử nghiệm
    • danluu.com có 6kB wire / 18kB raw, trên Tecno Spark 8C đạt 0.4s LCP* / 0.3s CPU
    • HN có 11kB wire / 50kB raw, trên Tecno Spark 8C đạt 0.5s LCP* / 0.5s CPU
  • Các diễn đàn PHP cũ hoạt động tốt hơn rất nhiều trên thiết bị chậm so với diễn đàn hiện đại
    • MyBB trên Tecno Spark 8C đạt 0.8s LCP* / 0.8s CPU
    • phpBB đạt 1.7s LCP* / 1.5s CPU
    • vBulletin đạt 4.4s LCP* / 4.8s CPU
    • Discourse là 15s LCP* / 26s CPU và trên Itel P32 là FAIL
  • Ngay cả ở nền tảng blog, theme WordPress cũ cũng nhanh hơn rất nhiều trên thiết bị cấu hình thấp so với Medium và Substack
    • WordPress(old) trên Tecno Spark 8C đạt 0.7s LCP* / 1.7s CPU
    • Medium đạt 2.8s LCP* / 33s CPU
    • Substack đạt 14s LCP* / 14s CPU
  • Nhiều site hiện đại bị lỗi hoặc gần như không dùng được trên Itel P32
    • XenForo, Mastodon, Bluesky, Wix, Substack, Shopify, Discourse, Reddit là FAIL
    • Threads là 28s LCP* / 66s CPU, Twitter là 24s LCP* / 43s CPU, Medium là 3.2s LCP* / 63s CPU
  • Những trang dùng 10s+ CPU tạo ra trải nghiệm tệ ngay cả sau khi tải xong
    • Cuộn có thể tụt xuống chỉ còn vài FPS, và độ trễ chạm tab rất dài khiến người dùng khó biết thao tác đã được ghi nhận hay chưa
    • Nếu chạm lại, lần chạm đầu có thể được ghi nhận muộn rồi lần chạm thứ hai gây ra hành vi ngoài ý muốn

Khác biệt giữa thiết bị thực và CPU throttling

  • CPU throttling trong Chrome DevTools rất tiện, nhưng không thể xấp xỉ nhất quán kết quả trên thiết bị chậm thực tế
  • Khi so sánh M3/10 với Tecno Spark 8C, khác biệt giữa các site rất lớn
    • danluu.com và Ghost được xấp xỉ ở mức nào đó
    • Medium, Substack, Twitter chậm hơn khoảng 3x về thời gian CPU trên Tecno Spark 8C
    • Reddit và Discourse chậm hơn khoảng 4x
    • Shopify lại cho kết quả Tecno Spark 8C nhanh hơn M3/10 hơn một bậc độ lớn
  • Có những trang khi thiết bị càng chậm thì lại chậm siêu tuyến tính, và độ chậm của một trang không dự đoán tốt độ chậm của trang khác
  • Discourse, Medium, Reddit có vẻ không dùng nhiều CPU trên M3 và M1, nhưng trên Tecno Spark 8C lại nằm trong nhóm chậm nhất
  • Reddit dùng ~90% CPU ngay cả khi chỉ chờ mà không tương tác gì, nên CPU bị hiển thị là ∞

Điểm mạnh của site cũ và trang đơn giản

  • Các site cũ nhìn chung nhanh hơn site mới, và những site gần như không thay đổi nhiều về mặt hình ảnh trong 10–20 năm thuộc nhóm nhanh nhất
  • MyBB nhanh hơn Discourse 3.6x / 5x trên M3, và 19x / 33x trên Tecno Spark 8C
  • WordPress(old) được đo nhanh hơn Medium 17.5x / 10x trên M3 Max, và 4x / 19x trên Tecno Spark 8C
  • Ghost là một ngoại lệ: dù là nền tảng hiện đại ra mắt muộn hơn Medium 1 năm, nó vẫn cho hiệu năng có thể cạnh tranh với các nền tảng cũ
  • NodeBB trong bài test phụ lục cũng gần như là ngoại lệ trong nhóm diễn đàn hiện đại
    • Trên M1 là 0.3s / 0.4s
    • Trên Tecno Spark 8C là 3.4s / 7.2s
    • Nhanh hơn Discourse rất nhiều, và sau khi tải thì việc cuộn và chạm tab về cơ bản vẫn hoạt động

Tải động và cái bẫy của tối ưu hóa chỉ số

  • Các site như Discourse, Reddit, Substack tải trước một phần trang rồi kéo phần còn lại về động nên tính khả dụng thực tế còn tệ hơn điểm số trong bảng
  • Trên thiết bị chậm, rất khó đoán khoảng cách cần cuộn, và nếu cuộn quá xa có thể kích hoạt tải thêm khiến trang bị treo
  • Những trang xóa nội dung cũ đã cuộn qua gần như không thể dùng trên thiết bị chậm
  • Các trang tải động khó tận dụng tìm kiếm Ctrl/Command+F nhanh sẵn có của trình duyệt và phải tự triển khai tìm kiếm riêng
    • Tìm kiếm trong Google Docs trong vài tháng hoặc khoảng 1 năm gần đây tải chậm đến mức khó dùng ngay sau khi tài liệu vừa mở
    • Tìm kiếm của Discourse chưa bao giờ hoạt động tốt trên thiết bị chậm hoặc cả trên thiết bị không thực sự nhanh
  • Về lý thuyết, việc xử lý CPU nặng lúc đầu có thể giúp tương tác sau đó nhanh hơn, nhưng các trang được test đều chậm ở tải ban đầu, tải tiếp theo và cả tương tác sau tải

Game hóa LCP

  • LCP ban đầu là chỉ số ước lượng thời điểm nội dung chính của trang hiện ra với người dùng, nhưng phép đo của Chrome lại gần với thời điểm xảy ra một lần paint lớn trên màn hình hơn
  • Một số site hiển thị nhanh màn hình loading lớn nhưng không hữu ích cho người dùng để hạ LCP, rồi chia nội dung thực thành các cập nhật nhỏ để nó không bị tính vào LCP
  • Discourse đã công khai triển khai Discourse Splash và giới thiệu rằng màn hình splash lớn giúp giảm mạnh LCP khi tải chậm
  • Phản hồi chính thức từ Discourse có ý rằng nếu banner nội dung thực lớn hơn splash thì sẽ bất lợi cho LCP
  • Hai trường hợp có chênh lệch lớn giữa LCP* theo nội dung hữu ích và LCP do Chrome đo là Wix và Discourse
    • Wix là 6x trên M3, 12x trên M1, 3x trên Tecno Spark 8C
    • Discourse là 10x trên M3, 12x trên M1, 4x trên Tecno Spark 8C

Tác động của tối ưu hiệu năng đến kinh doanh

  • Ở các công ty lớn, cải thiện hiệu năng site và app có giá trị tài chính đủ lớn để đo được bằng A/B test
  • Ngay cả trong holdback dài hạn, cải thiện hiệu năng cũng là một can thiệp có ảnh hưởng tương đối lớn đến tăng trưởng và tỷ lệ giữ chân
  • Tại Twitter, độ trễ p99 theo quan sát người dùng vào khoảng 60s không chỉ ở India và nhiều nước châu Phi mà cả ở United States
  • Ở mỗi quốc gia đều có đủ nhiều người dùng với thiết bị hoặc kết nối chậm, nên yếu tố giới hạn gần với mức kiên nhẫn của người dùng hơn là phân bố thiết bị và kết nối trung bình của toàn dân số
  • Việc giảm 60s xuống 50s trên thiết bị chậm cũng có thể mang lại tác động tương tự như giảm 5s xuống 4.5s cho người dùng thiết bị cao cấp, và điều đó ảnh hưởng đến doanh thu, tăng trưởng, giữ chân

Thiết kế có tính đến thiết bị cấu hình thấp

  • Trên thiết bị chậm hoặc trong môi trường băng thông thấp, kết nối không ổn định, trải nghiệm tốt nhất nhìn chung là tải nhiều nội dung dưới dạng trang tĩnh cùng một lúc
  • Việc có thuộc tính width, height, alt phù hợp cho ảnh là hữu ích, nhưng progressive JPEG không giúp được nhiều một cách đặc biệt
  • Với thiết bị chậm nhưng kết nối nhanh, các trang tĩnh nhẹ hoạt động tốt, và cả những trang động nhẹ được chú trọng hiệu năng cũng có thể dùng được
  • Ở các trang nặng, việc tải thêm khi cuộn và chặn tìm kiếm làm hỏng mô hình tương tác còn sử dụng được
  • Substack có thể có LCP nhanh cho bài viết trên iPhone 8, nhưng để cuộn xuống dưới header có trường hợp phải chờ 6s cho lần tải trang tiếp theo rồi sau đó lại chờ thêm 1s~2s
  • Ở chiều ngược lại, các trang plain HTML lớn lại hoạt động tương đối tốt trên thiết bị cấu hình thấp
  • Zig standard library documentation tải toàn bộ source code ngay từ đầu và render cục bộ, nhưng trên Tecno Spark 8C sau 4.7s CPU vẫn giữ được độ phản hồi tương đối

Người dùng thu nhập thấp và khả năng truy cập

  • Tecno Spark 8C có thể mua với giá khoảng USD 50-60 ở Nigeria và USD 100-110 ở India, nhưng tỷ lệ so với thu nhập hộ gia đình trung vị ở các khu vực đó lớn hơn nhiều so với iPhone đời hiện tại ở Mỹ
  • Xét trên quy mô toàn cầu, Tecno Spark 8C không phải là thiết bị rẻ nhất, còn Itel P32 cũng thuộc nhóm cao hơn so với những thiết bị cấu hình thấp nhất đang được sử dụng thực tế
  • Theo Alex Russell, thị phần iOS là 7% ở India và 6% ở Latin America
  • Dựa trên telemetry của Windows, phần lớn người dùng laptop và desktop dùng thiết bị cấu hình thấp có khả năng chậm hơn iPhone mới nhất
  • Trong các “lifeline” phone cấp cho người cần hỗ trợ có cả iPhone 6 hoặc iPhone 8, nhưng cũng có nhiều thiết bị còn thấp hơn Itel P32, và hạn mức dữ liệu nhỏ khiến sau khi dùng hết thì việc tìm việc, điền mẫu phúc lợi hay dùng Maps có thể trở nên khó khăn
  • Ứng dụng di động có thể được tải sẵn khi có kết nối tốt, nhưng nếu web app buộc phải tải vài MB JavaScript nén mỗi lần truy cập thì không thể dùng trên kết nối hạn chế

Điều kiện thí nghiệm và giới hạn

  • Mỗi site được đo theo cách tìm trải nghiệm “cơ bản nhất” có thể
    • WordPress dùng demo của theme mặc định hiện tại twentytwentyfour
    • Shopify dùng theme xuất hiện đầu tiên trong danh sách theme
    • Discourse, vBulletin, XenForo, phpBB, MyBB dùng các trang tìm được từ diễn đàn chính thức
  • Đây là một dự án ngắn, thu thập dữ liệu và phân tích trong vòng một ngày, nên không phản ánh được theme phổ biến nhất hay phân bố tùy biến thực tế của người dùng
  • Laptop được test ở khoảng 60% pin, không cắm nguồn, trong phòng 20°C, sau khi để gần đạt trạng thái cân bằng nhiệt
  • Thiết bị di động được test khi sạc khoảng 100%, cắm nguồn, không mở app hay tab khác
  • Trong thực tế, đa số người dùng trên cùng thiết bị có thể sẽ thấy hiệu năng tệ hơn do có nhiều app và tác vụ nền hơn
  • Kích thước được đo trên mobile, nên nếu mobile và desktop nhận tài nguyên khác nhau thì số liệu phản ánh kích thước tài nguyên cho mobile
  • CPU được đo bằng thời gian CPU của luồng chính; thời gian ở các luồng khác có được ghi lại nhưng không dùng làm chỉ số

Các trường hợp đáng chú ý theo từng site

  • Wix trên Tecno Spark 8C không giữ được cuộn ổn định, và trên Itel P32 thì lỗi không theo cách tái hiện cố định
  • Patreon có hiệu năng cuộn tệ hơn con số tải ban đầu, khó tìm bài cũ đến mức phải duy trì riêng một chỉ mục bài Patreon
  • Discourse có LCP bị game hóa mạnh; ngay cả trên M3 Max với kết nối 1Gbps, LCP do Chrome đo chỉ là 115ms nhưng nội dung thực phải đến 1.1s mới tải xong
  • Bluesky hiển thị màn hình trống trên Itel P32
  • Hai trường hợp sử dụng Shopify thực tế đầu tiên đều chậm hơn rất nhiều so với trang demo được test
  • Tumblr gặp lỗi JavaScript trên Itel P32, nhưng nhờ vậy trang lại tải nhanh hơn và việc cuộn cùng bấm link vẫn hoạt động
  • MyBB không cung cấp bản mobile nên có thể bất lợi với Google, nhưng trên mobile chậm thì việc cuộn và chạm thật sự hoạt động tốt
  • Woo Commerce khó so với Shopify chỉ bằng hiệu năng tải ban đầu; cần so sánh riêng bao gồm cả luồng thực tế như giỏ hàng và checkout nên bị loại khỏi bảng

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-03-17
Ý kiến trên Hacker News

  • Gần đây khi thử dùng một chiếc điện thoại Android tương đối chậm, tôi thấy ngay cả những trang web trông như chỉ có văn bản và hình ảnh cũng có thể tải chậm đến mức khổ sở.
    Nút thắt thực sự không phải là mạng, mà gần với trình theo dõi, quảng cáo và JavaScript phình to hơn.
    Trên điện thoại cũ chậm, ngay cả một trình duyệt đầy đủ như Firefox Mobile cũng quá nặng, khiến người ta phải dùng trình duyệt nhẹ như Firefox Focus; nhưng vì không dùng được tiện ích mở rộng nên cũng không dùng được uBlock Origin, và trải nghiệm web còn tệ hơn.
    Một số trang phàn nàn nếu không dùng trình duyệt “chuẩn” và trở nên unusable, còn các công ty thì ép cài ứng dụng thay thế.
    Trước đây từng có các phiên bản giản lược cho thiết bị và kết nối chậm, nhưng chúng đang dần biến mất; có vẻ là vì nếu không có JavaScript phình to thì khó vận hành mạng lưới quảng cáo và theo dõi.

    • Đây đúng là thế tiến thoái lưỡng nan hoàn toàn, vì web hiện đại về cơ bản vô dụng nếu không có chặn quảng cáo.
      Đặc biệt tệ hơn khi các quảng cáo ngẫu nhiên bị nhét vào những trang cuộn vô tận.
    • Ngay cả khi dùng trình duyệt chuẩn, cũng có trường hợp các công ty cố tình làm hỏng website để buộc người dùng dùng ứng dụng.
      Ví dụ gần đây, web shop của Nike hiện một lỗi vô dụng trong lúc thanh toán, và đội hỗ trợ chỉ nói “hãy thử dùng ứng dụng”.
      Các trang đặt vé của những hãng hàng không châu Âu cũng là ví dụ điển hình về việc website của các tập đoàn lớn thường xuyên hỏng.
      Thật lạ khi cho rằng, vào năm 2024, dù có nguồn lực gần như không giới hạn mà vẫn không làm nổi một website hoạt động được thì lại không ảnh hưởng xấu đến thương hiệu.
    • Chín trên mười ứng dụng kiểu đó rất có thể chỉ là lớp vỏ trình duyệt chứa một bản sao offline một phần của website.
    • Khi viết mã cho trang chính của nokia.com 10 năm trước, chúng tôi đã phát hiện việc tải tài nguyên chậm bằng nhiều cách và đặt cờ để tắt các chức năng bổ sung.
      Vì trang phải hoạt động ở mọi quốc gia, và một phần đáng kể những chiếc điện thoại chậm nhất là sản phẩm của chính công ty đó.
    • Tôi vẫn còn giữ một chiếc MacBook Pro đời 2013 vì đó là bàn phím tốt nhất Apple từng làm.
      Nó không nhanh, nhưng không gặp khó khăn khi dùng website; chỉ là không tức thì như phần cứng mới, còn lại vẫn đủ dùng.
      Tuy nhiên tôi có dùng uBlock Origin.
      Tôi tò mò liệu những thiết bị Android như vậy trên thực tế có yếu hơn một chiếc MacBook cấu hình cơ bản 11 năm tuổi hay không.

  • Tôi rất đồng ý với ý chính của Dan rằng cần ý thức về mức độ bất bình đẳng trên toàn cầu, nhưng cũng nên bao gồm cả các nước thu nhập trung bình như Mỹ Latinh và Đông Nam Á.
    Ví dụ có những người dùng có hạn mức dữ liệu hằng tháng chỉ ở mức vài GB, còn RAM/CPU thì ngang flagship Mỹ của 10 năm trước.
    Không đến mức hoàn toàn không dùng được Discourse, nhưng trải nghiệm rất có thể sẽ chậm một cách khó chịu.
    Tôi cho rằng việc Dan nhận thấy các cải thiện tăng dần về CPU/RAM/đĩa làm tăng mức độ tham gia theo cách đo được chủ yếu cũng là vì nhóm người dùng này.
    Biểu đồ của Dan cho thấy người dùng các thiết bị rẻ nhất như Itel P32 không được lợi đáng kể từ tối ưu hóa từng bước.
    Thứ có thể giúp là một cấu trúc client hoàn toàn khác, hy sinh tính năng và độ trau chuốt để cung cấp mã mỏng nhất có thể, tức một chế độ lite/cơ bản thay thế.
    Tuy nhiên cách tiếp cận này thường không thành công, vì vấn đề thấu cảm lại xuất hiện: các lập trình viên Mỹ đánh giá sai nên giữ gì và bỏ gì vì hiệu năng.

    • Tôi không hiểu vì sao đó phải là một lựa chọn “thay thế”.
      Tôi tự hỏi Discourse hiện cung cấp gì hơn PhpBB hay diễn đàn DLang.
      Ngoài thiết kế thân thiện với di động, trong một thế giới bình thường thì chỉ cần sửa vài dòng CSS responsive là đủ.
    • Tôi đang sống ở một quốc gia nghèo ở Đông Nam Á, và những người dùng gói dữ liệu nhỏ không tiết kiệm dữ liệu nhờ các website hiệu quả hơn, mà dùng Wi-Fi có ở khắp nơi.
      30GB dữ liệu mỗi tháng giá $3.64, tương đương khoảng 4–6 giờ làm theo mức lương tối thiểu.
      Điều quan trọng hơn là mọi người không dùng dữ liệu phung phí như ở phương Tây.
      Quán cà phê, nhà hàng, siêu thị, trung tâm mua sắm đều có Wi-Fi miễn phí, và hầu hết mọi người hỏi mật khẩu Wi-Fi trước cả thực đơn.
      Tôi chưa từng thấy hay nghe ai nói rằng website ngốn dữ liệu quá nhanh.
      Nghe giống một nỗi lo do những người chưa từng thực sự sống ở nước đang phát triển nghĩ ra.
      Ở đây, lý do hết dữ liệu là xem video trên TikTok, Instagram, Facebook, chứ không phải do website phình to.
    • Nếu mọi trang đều hiệu quả hơn, thời điểm người dùng không chuyên cảm thấy “máy tính chậm rồi, phải mua máy mới” cũng có thể bị trì hoãn, từ đó kéo dài tuổi thọ của laptop và PC.
      Bloatware cài kèm máy tính cũng tương tự.
      Gần đây tôi mua laptop mới và được đề xuất gói “tinh chỉnh” giá $50.
      Thử tưởng tượng đại lý xe mới đưa ra đề xuất như vậy thì sẽ thấy kỳ lạ.
    • Ngay cả trên iPhone đời trước, một số trang như vậy thật sự khó chịu đến mức không chịu nổi.
      Nếu ở nơi sóng kém thì vấn đề còn tệ hơn gấp 10 lần.
      Đây không phải chuyện UI phức tạp với header cố định và quảng cáo khiến chỉ còn nhìn thấy một phần ba màn hình, mà là vấn đề kích thước của chính những website được chắp vá tùy tiện cho đến khi trông giống tài liệu thiết kế.
      Những trang vốn đã phình to ngay cả nếu được làm đúng cách sẽ trở nên không thể dùng trên kết nối Internet chậm, chưa nói đến phần cứng chậm.
      Thật khó tưởng tượng cảm giác dùng Internet trong môi trường như mô tả, và tôi chỉ hy vọng những người đó dùng các trang địa phương phù hợp với băng thông và thiết bị của họ, thay vì phải đối mặt với đống rác phình to mà chúng ta gặp.
    • Tôi sống ở Canada, gói dữ liệu của tôi cũng chỉ vài GB, và tôi vừa nâng cấp khỏi một chiếc flagship gần 10 năm tuổi.
      Hầu hết website gần như là tra tấn.

  • Điều thú vị là phần lớn chỉ đổ lỗi cho sếp hoặc các tập đoàn lớn đáng sợ
    Các lập trình viên không thừa nhận rằng cũng có một nhóm lớn lập trình viên web kém năng lực, không hiểu rõ về hiệu quả và có vẻ cũng chẳng muốn tìm hiểu
    Họ cũng phải chịu trách nhiệm cho thế giới phần mềm web đáng buồn này, không kém gì những ông sếp hay tầng lớp lãnh đạo doanh nghiệp ép người ta tạo ra phần mềm tệ

    • Tôi từng làm việc với những người như vậy
      Khi hỏi về các phần cụ thể của “sản phẩm đầu ra” là HTML, CSS, JS, họ nhìn tôi như thể tôi đang nói một ngôn ngữ khác
      Họ đến từ thế giới framework JavaScript và chẳng nghĩ nhiều về đầu ra bên dưới nó
      Triết lý của tôi thì gần như ngược hẳn: tôi hỏi đâu là lượng mã tối thiểu, có thể bảo trì, để tạo ra kết quả tương đương với một website HTML+CSS+JS được viết tay tốt
      Thường thì sản phẩm cuối nhỏ hơn vài bậc độ lớn
      Có người hỏi tôi làm thế nào để lọc theo thời gian thực 1000 hàng trong bảng mà vẫn tải nhanh và chạy tốt trên di động, tôi nói rằng chỉ gửi toàn bộ dữ liệu ngay ở yêu cầu đầu tiên rồi ẩn động những dữ liệu không khớp bộ lọc
      Webserver chỉ cần chuyển cùng dữ liệu đã cache cho tất cả mọi người, và JavaScript chạy trên site cũng chỉ có vậy, nên với họ nó trông nhanh một cách kỳ lạ
      Khi nhìn vào HTML của các hàng bảng tương tự trong giải pháp dựa trên framework của họ, 80% là boilerplate thậm chí không được dùng đến
      Phát triển web đã trở nên quá cứng nhắc, và nhiều người đã đi quá xa khỏi bản chất của công nghệ web
    • Khoảng 5 năm trước, tôi ứng tuyển vào một công ty giúp người dân ở nông thôn châu Phi bán hàng hóa họ sản xuất dễ dàng hơn
      Nếu đối tượng người dùng chính là ở Mỹ hoặc EU, việc không tối ưu quá mức cho phần cứng cấu hình thấp và kết nối băng thông thấp, độ trễ cao, không ổn định có thể cũng có lý
      Nhưng nếu nhắm tới nông thôn châu Phi thì tối ưu quyết liệt có vẻ là điều hiển nhiên
      Thế mà trang chủ lại tải một ảnh khổng lồ 2MB, rồi thu nhỏ bằng CSS xuống 500×1000 pixel, và những phần sau còn tệ hơn
      Tôi không nhớ chính xác kích thước payload JS, nhưng nó là vài MB; dù phần lớn trông giống một ứng dụng backend dựa trên template truyền thống, frontend lại cực kỳ nặng
      Ý tưởng thì hay nên tôi vẫn ứng tuyển, nhưng công nghệ thì kinh khủng
      Tôi còn không qua được vòng phỏng vấn đầu, nên không biết vì sao lại như vậy, nhưng thật khó tưởng tượng điều gì khác ngoài việc các lập trình viên Tây Âu không thực sự nhận ra mình đang làm gì ở khía cạnh này
    • Từ góc nhìn của người từng làm ở “tập đoàn lớn đáng sợ”, trách nhiệm thuộc về họ 100%
      Điểm khởi đầu không phải là lập trình viên mà là ngân sách
      Nếu cấp trên không am hiểu công nghệ hoặc không có nền tảng kỹ thuật, họ thường cấp ngân sách cho tính năng mới nhưng phân bổ quá ít, hoặc hoàn toàn không phân bổ, cho bảo trì và xử lý nợ kỹ thuật
      Ngay cả khi có ngân sách bảo trì, gần như toàn bộ cũng do các đội bảo trì offshore rẻ hơn đảm nhiệm
      Đội tính năng xây dựng một tính năng trong 6 tháng, có một “phiên KT” kéo dài 1 giờ với đội bảo trì offshore, rồi bàn giao mã
      Đội offshore có một phần thông tin về tính năng, nhưng không đủ để quản lý nợ kỹ thuật hiện có; họ chỉ giữ cho mọi thứ không bốc cháy
      Khi chu kỳ này lặp lại 100~1000 lần trong tổ chức, rất nhanh sẽ có tình trạng frontend lẽ ra tối đa chỉ cần 250 nghìn dòng lại trở thành 2 triệu dòng
      Dù các kỹ sư giỏi nhất tham gia đội tính năng mới, họ vẫn phải làm việc trong chiếc hộp đã được tạo sẵn
      Nếu mockup và các phần tử không khớp, có thể mockup sai, UI kit đã được nâng cấp, hoặc UI kit hiện có cần refactor, nhưng không có ngân sách cho việc đó
      Vì vậy đội được chỉ đạo sao chép component rồi chỉnh sửa cho phù hợp với tính năng của mình
      Khi bàn giao cho đội bảo trì, đội mới cũng không muốn đụng đến phần việc của tính năng cũ nên cứ để nguyên
      Ban điều hành phi kỹ thuật không biết sự khác biệt, và sau nhiều năm các đội liên tục copy/paste để khớp tính năng mới, codebase có hơn 50 component mang tên “Button”
    • Điều đó không công bằng
      Nếu trong đội có lập trình viên lành nghề coi trọng hiệu quả, và họ thúc đẩy một site hiệu quả hơn hoặc xây dựng hiệu quả hơn ngay từ đầu, trang có thể tốt hơn
      Nhưng phần lớn là vấn đề động lực khuyến khích
      Nếu ban quản lý không quan tâm, lập trình viên rất có thể sẽ thích làm cho nó chạy được trong một nửa thời gian rồi đẩy backlog đi, hơn là dành thời gian để nâng cao hiệu quả
    • Thường thì phần mềm web tệ đi kèm với nội dung tệ
      Vì vậy thiết bị chậm là một bộ lọc tuyệt vời giúp tránh rác

  • Gần đây tôi mới chuyển từ một chiếc flagship LG 6 năm tuổi sang Galaxy mới, và chênh lệch hiệu năng thật khổng lồ
    Lẽ ra không nên như vậy
    Khi ra mắt nó là thiết bị rất cao cấp, cũng chưa quá cũ và vẫn hoạt động như mới
    Việc các máy Galaxy S9 dùng để thử nghiệm cũng gặp khó khăn tương tự cho thấy không chỉ riêng điện thoại của tôi có vấn đề
    Giá mà bài test có Amazon thì tốt
    Theo kinh nghiệm của tôi, website Amazon thuộc hàng tệ nhất trong những thứ tệ nhất trên thiết bị di động hơn 4 năm tuổi
    Ngay cả trên phần cứng di động cao cấp tương đối gần đây, trong số các site tôi truy cập thường xuyên, nó là site duy nhất gần như không thể dùng được

    • Sau khi dùng hai thiết bị Snapdragon 835 7 năm tuổi, tôi nhận ra RAM và phiên bản Android mới tạo ra khác biệt lớn
      Tôi dùng hằng ngày OnePlus 5 chạy Android 14 qua LineageOS, và trải nghiệm người dùng cho các tác vụ không phải game là đủ ổn
      Điện thoại này có RAM 6GB nên cũng tương đương các máy tầm trung hiện nay
      Phàn nàn duy nhất là tôi đã phải thay pin và việc tháo máy khá phiền
      Ngược lại, Galaxy S8 dùng cùng SoC nhưng có bộ nhớ 4GB và Android 9 gốc đã được Samsung chỉnh sửa thì giật lag không dứt
      Chênh lệch 2GB bộ nhớ có thể có ảnh hưởng, nhưng khác biệt giữa hai máy là một trời một vực
      Tôi không biết khả năng quản lý bộ nhớ của Android 14 tốt hơn Android 9 rất nhiều, hay phần mềm chậm chạp, phình to của Samsung đang kéo thiết bị lại
      Dù sao thì việc nhiều công ty không thử nghiệm trên thiết bị cũ và giá rẻ thật khó chịu
      Nếu nhắm tới người dùng toàn cầu, họ cần nhìn vào thực tế rằng phần lớn thế giới không dùng flagship mới nhất
    • Tôi tự hỏi đã có ai thử tắt JavaScript trên Amazon chưa
      Thực ra nó không hoạt động tệ đến vậy
      Tất nhiên tôi đồng ý rằng đáng ra không nên phải làm thế
    • Gần đây tôi đến Brazil và bị giật mất điện thoại mới ngay trên tay, giờ đang dùng một máy dự phòng 4 năm tuổi, mà thành thật thì tôi không cảm thấy khác biệt
      Có điều tôi dùng Firefox với mọi trình chặn quảng cáo, nên có vẻ điều đó có ích
    • Tôi có một chiếc Palm Phone, và ở thời điểm này tôi cho rằng gần như không thể duyệt web được
    • Trên iPhone 8 chạy iOS 16 mới nhất thì Amazon không có vấn đề

  • Công nghệ ngày nay quá thờ ơ ngay cả với những người không quen dùng công nghệ
    Tôi nghĩ smartphone là ví dụ tiêu biểu
    Tôi đã thấy rất nhiều người hầu như không dùng được thiết bị của mình, hoặc hoàn toàn không biết gì về nó, và với họ mọi thứ trông như ma thuật hắc ám
    Vấn đề lớn nhất là sự phụ thuộc quá mức vào điều hướng bằng cử chỉ, thứ vô hình nên gần như không tồn tại
    Thanh cử chỉ của iPhone thì còn có thể lần mò ra bằng cách nào đó, nhưng họ không có khái niệm gì về Trung tâm thông báo hay Trung tâm điều khiển
    Những người này không hề ngu ngốc, và trong các lĩnh vực khác họ có thể giỏi hơn tôi rất nhiều
    Với công nghệ, vấn đề không phải là thiếu cố gắng, mà là thiếu giao diện trực quan

    • Việc mua iPhone mới mà không có tài liệu đi kèm cũng chẳng giúp ích gì
      Muốn xem tài liệu thật sự thì phải tự tìm đến trang tài liệu trên website Apple, rồi đào sâu thêm một chút mới thấy một trang chỉ đại khái cho thấy vài cử chỉ có thể dùng
      Khi nào và nên dùng cử chỉ nào thì cũng chẳng có gì hơn ngoài một câu ví dụ
      Đó mới chỉ là chuyện của hệ điều hành
      Tôi tự hỏi có bao nhiêu ứng dụng cung cấp kèm tài liệu giải thích cách các tính năng cử chỉ được dùng trong chính ứng dụng của họ
      https://support.apple.com/guide/iphone/learn-basic-gestures-...
    • Tôi từng thấy những người trung niên có lẽ đến cả đầu cassette cũng không biết dùng, máy đánh chữ cũng thấy khó
      Rõ ràng họ lớn lên xung quanh những thiết bị đó
      Vì vậy tôi nghĩ đây không chỉ là lỗi của công nghệ hiện đại
    • Nhìn từ bên ngoài, ít nhất là với các giao diện sản phẩm hào nhoáng, có vẻ chúng được thiết kế theo kiểu một cỡ cho tất cả
      Thay vì để người dùng chọn thiết kế và cách tương tác phù hợp với mình, nhà thiết kế hoặc người phụ trách sản phẩm lại hành xử như thể họ biết điều gì là tốt nhất cho mọi người dùng
    • Vấn đề phụ thuộc quá mức vào điều hướng bằng cử chỉ không phải là vấn đề của smartphone nói chung, mà là vấn đề riêng của iPhone
      Đó là một trong những bất mãn lớn nhất của tôi sau khi chuyển từ Android sang
      Nút quay lại ở đâu, nút Home ở đâu, và bản thân các nút ở đâu tôi cũng không biết
      Tôi thật sự ghét sự ám ảnh với chủ nghĩa tối giản của Apple, và khi chiếc điện thoại này chết, tôi sẽ quay lại Android

  • Bài viết này về cơ bản khó đọc với tôi, một người 48 tuổi, trên desktop
    Thêm các dòng dưới đây vào body trong công cụ dành cho nhà phát triển thì tôi đọc được
    font-size: 18px;
    line-height: 1.5em;
    max-width: 38rem;
    Làm vậy mới thấy nó dễ đọc và đẹp hơn biết bao
    Tôi đọc nhiều bài của Dan Luu, nhưng lần nào cũng phải chỉnh như thế này
    Nói nghiêm túc, hỡi các kỹ sư, để làm trang dễ đọc hơn chỉ tốn thêm 64 byte thôi

    • Tôi 53 tuổi và đã quá thời điểm lẽ ra phải đi đo kính ít nhất 5 năm, nên giờ kính vẫn mắc ở đầu mũi và đôi khi còn phải chỉnh cả góc nhìn
      Trang đó gần như ổn, chỉ cần phóng to bằng CTRL + là được
      Trang đó gần như là văn bản thuần túy và hầu như không có thao tác gì
      Bạn có giải pháp phù hợp với trường hợp sử dụng của bạn, và tôi cũng có giải pháp của tôi
      Độc giả khiếm thị cũng có thể truy cập bằng giải pháp của riêng họ
      Vì mã nguồn đơn giản nên các giải pháp trợ năng cũng trở nên đơn giản một cách hợp lý
      Tôi cho rằng Dan biết cách giao tiếp hiệu quả
      Tức là giữ mọi thứ đơn giản, và không giả định rằng nội dung nhất định sẽ được đọc bằng mắt
      Người đọc có thể dễ dàng thay đổi cách hiển thị cho phù hợp với mục đích của mình
      Nếu không thích cách hiển thị này, trước khi đọc có thể tự định dạng lại
      Có thể nói Dan đã cung cấp thông điệp dưới dạng một luồng văn bản đơn giản, dễ thao tác
    • Tôi nghĩ đề xuất chỉnh sửa là hợp lý, nhưng nếu Dan Luu tự thêm các quy tắc CSS đó, ở đây hẳn đã có phản hồi than phiền về mật độ thấp và “quá nhiều khoảng trắng”
      Nhìn chung, độc giả của Luu có khả năng khá thích cách tiếp cận ít kiểu dáng
    • Tôi không đồng ý
      Người dùng có thể thay đổi kích thước cửa sổ, cỡ chữ, màu sắc, v.v. theo sở thích của mình
      Không nên phải chỉnh cho từng file mỗi lần, và nên được phép thêm một file CSS người dùng có thể áp dụng cho nhiều file
    • Nếu phông chữ quá nhỏ, có thể đổi cỡ chữ mặc định của trình duyệt
      Nó nằm trong trang cài đặt mặc định của Firefox
      Nếu website ép font-size: 18px;, với những người dùng đã chọn cỡ chữ lớn hơn trong trình duyệt, chữ có thể lại trở nên nhỏ hơn
    • Tôi đồng ý rằng nên thêm một lượng CSS tối thiểu
      Tuy nhiên cũng có thể dùng chế độ đọc của trình duyệt, chỉ cần một cú nhấp thay vì phải qua nhiều bước trong công cụ dành cho nhà phát triển

  • Nhân tiện, Raspberry Pi 3 không dùng được YouTube
    Chuyện này mới xảy ra trong khoảng một năm qua; trước đó vẫn có thể “xem” video ở khoảng 10–15FPS, đủ để xem video sửa chữa trong xưởng
    Khi Raspberry Pi Model B, tức mẫu đầu tiên, ra mắt, nó có thể phát video 1080p từ kho lưu trữ, xem YouTube và chơi game
    Không biết YouTube đang làm gì, và các dịch vụ khác cũng đang làm gì
    Nếu thật sự nghiêm túc về khủng hoảng và biến đổi khí hậu, cần soi rất chặt những mánh khóe kiểu này của Google và Meta
    Việc đốt chu kỳ CPU vì lợi nhuận — đoán mò thì có lẽ do công nghệ quảng cáo — khiến YouTube hỏng trên thiết bị tiêu thụ điện thấp, đáng ra phải bị báo chí chỉ trích mạnh, và dù trải nghiệm người dùng tổng thể có tệ hơn thì cũng nên dùng các dịch vụ hiệu quả hơn

    • Có thể là do thiếu giải mã video bằng phần cứng chăng
      Pi3 có tăng tốc phần cứng x264, nhưng YouTube đã bắt đầu dùng codec khác từ một thời gian trước
    • YouTube chắc chắn đang nặng hơn
      Ngay cả trên MacBook Air Intel đời đầu năm 2021, video cũng ngẫu nhiên bị đứng hình khi tải ở mức trung bình, điều trước đây không xảy ra
    • Theo mọi dữ liệu, mức tiêu thụ năng lượng của thiết bị phía client gần như chỉ là sai số làm tròn xét về mức đóng góp vào biến đổi khí hậu
      Tấn công vào đó để giải quyết biến đổi khí hậu cũng vô lý chẳng kém cấm ống hút nhựa hay túi nylon
    • Tôi dùng Invidious để duyệt trang, còn video thực tế thì xem bằng một script gỡ rối/giải mã lớp che giấu để lấy URL stream thật rồi chuyển cho VLC
      Thêm một điểm tham chiếu nữa: YouTube của 10 năm trước hẳn sẽ hoàn toàn ổn trên phần cứng đó
      Thủ phạm là sự phình to chung của web, cụ thể hơn là những con quái vật trừu tượng hóa đã trở nên phổ biến trong JS
      Ngay cả với người hoàn toàn không tin vào “khủng hoảng khí hậu”, vẫn có thể nói rằng theo thời gian, tay nghề và chất lượng đã biến mất, tạo ra mớ hỗn loạn này
      Vì vậy tôi nghĩ đây là chủ đề mà mọi phía trên phổ chính trị đều có thể đồng ý
    • Cần có một tổ chức giám sát theo dõi độ nặng của trang theo từng website và từng người dùng, rồi công khai tên để làm họ xấu hổ
      Có thể làm theo kiểu Consumer Reports, hoặc là một add-on hoạt động giống Nielsen ratings

  • Người bên Discourse đó là ví dụ điển hình của việc thiết kế sản phẩm dựa trên thế giới mà mình ước là tồn tại, chứ không phải thế giới thực chúng ta đang sống
    Có hàng tỷ thiết bị dùng Qualcomm SoC, chúng sẽ tiếp tục tồn tại và tiếp tục được sản xuất, bán ra
    Dù phàn nàn thế nào cũng không thay đổi được
    Hãy chấp nhận và tối ưu cho những thiết bị đó
    Người dùng các thiết bị đó không quan tâm đến lời than phiền của lập trình viên; nếu phần mềm bị crash, họ sẽ chỉ nghĩ đó là lập trình viên phần mềm kém năng lực

    • Hoặc cũng có thể chọn con đường nói rằng “cái này không dành cho bạn”

  • Thường thì tôi thích bài của Dan Luu, nhưng bài này có cảm giác lệch hướng
    Bảng LCP/CPU thì hay, nhưng sau đó bài lại trôi sang kiểu tâm lý học sa-lông
    Dựa vào vài bình luận ngẫu nhiên của nhà sáng lập Discourse rồi yêu cầu độc giả tưởng tượng thái độ của các kỹ sư phần mềm
    Thậm chí còn lôi cả Knuth xuống dựa trên phát biểu về hiệu năng đơn nhân so với đa nhân và phát biểu liên quan đến Itanium, trong khi đó là một điểm tranh luận học thuật đã cũ
    Bài viết quá mềm, dựa nhiều vào cãi vã trên Internet nên tôi thấy khó đứng vững

    • Nhưng thực tế chẳng phải vẫn có thái độ như vậy sao
      Lời của nhà sáng lập Discourse chỉ là một minh họa rất rõ thôi
      Nếu gần đây đã dùng web, nó đã phình to đến mức vượt quá tưởng tượng, tới mức Google giờ gọi Largest Contentful Paint 2,4 giây là nhanh: https://blog.chromium.org/2020/05/the-science-behind-web-vit...
      Đây là dữ liệu từ 4 năm trước nên hiện tại rất có thể còn tệ hơn
      Không cần tìm đâu xa: từ việc YouTube trên desktop tải 2,5MB CSS, cho đến chuyện thứ mà nhà sáng lập Vercel khoe là một website rất nhanh lại mất 20 giây để tải chỉ cần áp một chút hạn chế: https://x.com/dmitriid/status/1735338533303259571
    • Tôi hầu như chưa từng thấy công ty nào coi hiệu năng là chuyện nghiêm túc
      Một dịch vụ API đơn giản cho frontend có thời gian phản hồi 500ms cũng chẳng ai cười chê
      Tôi cũng nghi ngờ không biết có bao nhiêu kỹ sư biết và quan tâm chi phí cloud của mình là bao nhiêu
    • Tôi nghĩ Knuth đúng ở một mức nào đó
      Tính song song ngày nay không được dùng trong 90% phần mềm, trừ các ca sử dụng chuyên biệt hoặc trường hợp chạy cùng một chương trình đơn luồng trên nhiều mục dữ liệu
      Cả ngôn ngữ lập trình lẫn phần cứng đều chưa hỗ trợ tốt tính song song hạt mịn, và việc làm cho phần mềm cổ điển chạy nhanh bằng cách tiếp cận song song là rất khó
    • Không hiểu đang tranh luận chuyện gì
      Luu thật ra viết khá hào phóng
      Knuth gần như đang phàn nàn rằng bữa trưa miễn phí kéo dài hàng thập kỷ sắp kết thúc
    • Tôi nghĩ phần tóm tắt khá ổn
      Jeff Atwood chỉ là ví dụ được chọn thôi
      Những nhà tư tưởng phát triển web nổi tiếng có nhiều người theo dõi liên tục tuôn ra các quan điểm tương tự, và nhiều follower cứ thế tiếp nhận lời họ nói

  • Mọi công ty đều đã ngừng quan tâm, đặc biệt là những công ty từng ở tuyến đầu về tiêu chuẩn và các thực hành thiết kế web tốt như Google và Apple
    Gần đây Google đã chấm dứt HTML Gmail, vốn chạy nhanh và ổn ngay cả trên điện thoại Android đời 2008 với RAM 256MB và Firefox cũ
    Tất nhiên, phiên bản JavaScript mới phình to sẽ giết chết trình duyệt
    Đây là ví dụ cực đoan, nhưng điện thoại giá rẻ có RAM 2GB, và giờ khó có thể kỳ vọng hiệu năng hợp lý khi duyệt web bằng những thiết bị như vậy
    Web di động rất tệ, và đây là điều có chủ đích nhằm đẩy người dùng vào các ứng dụng “native”
    Vì điều đó giúp các công ty như Apple và Google thu thập dữ liệu và hiển thị quảng cáo dễ dàng hơn

    • Một phần thì chắc chắn là vậy, nhưng tôi không biết với Amazon hay Decathlon, chuỗi thể thao và dã ngoại lớn ở châu Âu, thì sao
      Trang của họ trên di động thật khủng khiếp, và Decathlon cũng khủng khiếp cả trên desktop không có hiệu năng cao
      Vậy mà họ cũng chẳng quảng bá ứng dụng một cách nổi bật, nên có lẽ chỉ nên xem đó là sự kém năng lực
      Có vẻ các lập trình viên chỉ kiểm thử mọi thứ trên những thiết bị cao cấp được nối với backbone
    • Hôm thứ Năm, Google đã khai tử “sản phẩm” duy nhất còn dùng được
      RIP Google
      Reddit mới thì không dùng nổi, old Reddit thì quá cũ kỹ
      Twitch chỉ còn ở mức miễn cưỡng dùng được vì các vấn đề về chat và stream video
      Danh sách còn dài
      Khi đã có công thức cuối cùng, mọi thay đổi đều trở thành thay đổi tệ hại để bảo đảm việc làm
      Một ngày nào đó, những con khỉ trên cục đất này sẽ nhận ra việc làm và tiền bạc không hề tồn tại, nhưng khi ấy sẽ quá muộn
      Không, chính là bây giờ rồi
      RIP Humans