Sự phình to của JavaScript năm 2024

Vấn đề dung lượng của JavaScript

• Trước đây tôi khá xa lạ với phát triển frontend hiện đại, nhưng nhớ đã từng đọc các bài viết về độ “phình” của web khi kích thước trang có thể lên tới vài megabyte.
• Tôi có ấn tượng rằng nếu một trang web trung bình nặng 3MB, thì gói JavaScript có lẽ vào khoảng 1MB.
• Để kiểm tra con số thực tế là bao nhiêu, tôi đã tiến hành một thí nghiệm.

Phương pháp

• Sử dụng Firefox trên macOS (có lẽ các trình duyệt khác cũng tương tự)
• Dùng chế độ bình thường thay vì ẩn danh (vì tôi muốn xem các con số bên trong ứng dụng và nghĩ rằng điều này gần với trải nghiệm thực tế hơn)
• Tắt tất cả tiện ích mở rộng
• Chỉ đo JavaScript
• Ở trạng thái không nén
• Bật service worker (để sát với tình huống thực tế hơn)
• Tắt mọi bộ nhớ đệm (tải từ đầu)

Trang đích

• Ví dụ về một trang phổ biến có chút tương tác: Wikipedia, 0.2MB
• Ví dụ về một trang hơi bị phình: Linear, 3MB
• Ví dụ về các trang đích tệ: Zoom, 6MB; Vercel, 6MB; GitLab, 13MB

Website chủ yếu tĩnh

• Khó có gì đơn giản hơn việc chỉ hiển thị một bức tường chữ tĩnh.
• Vậy mà Medium cần 3MB chỉ để làm việc đó.
• Substack cần 4MB, Quora 4.5MB, Pinterest 10MB, Patreon 11MB.

Tìm kiếm

• Tương tác của ứng dụng chủ yếu chỉ giới hạn ở tìm kiếm.
• StackOverflow cần 3.5MB, NPM 4MB, Airbnb 7MB, Booking.com 12MB.
• Google cần 9MB chỉ để hiển thị một ô văn bản đơn giản và danh sách liên kết.

Ứng dụng một tương tác duy nhất

• Google Translate cần 2.5MB cho hai ô văn bản.
• ChatGPT cần 7MB cho một ô văn bản.

Video

• Loom cần 7MB, YouTube cần 12MB.
• Pornhub, một trang có quan tâm đến hiệu năng, chỉ cần 1.4MB.

Âm thanh

• SoundCloud và Spotify đều cần 12MB.

Email

• Google Mail cần 20MB.
• FastMail cung cấp cùng chức năng nhưng chỉ cần 2MB.

Năng suất

• Todoist cần 9MB, Dropbox 10MB, 1Password 13MB, Trello 13.5MB.
• Discord cần 21MB chỉ để chat.

Chỉnh sửa tài liệu

• Google Docs cần 13.5MB, Notion cần 16MB.

Mạng xã hội

• Twitter cần 11MB, Facebook 12MB, TikTok 12.5MB, Instagram 16MB, LinkedIn 31MB.

Hạng mục khổng lồ

• Jira cần gần 50MB, Slack cần 55MB.
• react.dev ban đầu bắt đầu với 2MB, nhưng khi cuộn có thể tăng vô hạn.

Có đang ngày càng tệ nhanh hơn không?

• Năm 2015, kích thước trung bình của một trang web đã tiệm cận bản shareware của Doom 1 (2.5MB).
• Đến năm 2024, riêng Slack đã chiếm 55MB, tức là chỉ riêng JavaScript đã bằng kích thước của Quake 1 nguyên bản.

10MB lớn đến mức nào?

• 10MB giờ đây không còn cho cảm giác quá lớn hay đặc biệt nữa.
• Nếu giả sử trung bình mỗi dòng có 65 ký tự, thì mỗi website đang gửi khoảng 150.000 dòng mã.
• Google Maps ở mức 4.5MB, tương đối khiêm tốn theo tiêu chuẩn hiện đại.

Kết luận

• Vấn đề không chỉ nằm ở kích thước tải xuống.
• JavaScript còn là thứ mà trình duyệt phải phân tích cú pháp, giữ trong bộ nhớ và thực thi.
• Tôi tin rằng nội dung nên lớn hơn kích thước của mã.
• GitLab cần 13MB mã, hơn 500K LoC JavaScript, chỉ để hiển thị một trang đích tĩnh.

Ý kiến của GN⁺:

1. Đây là một chẩn đoán thực tế về hiện trạng phát triển web, giúp hiểu rõ tác động của kích thước JavaScript trong website tới trải nghiệm người dùng và hiệu năng.
2. Bài viết nhắc các lập trình viên frontend về tầm quan trọng của việc tối ưu hóa, đồng thời cảnh báo không nên dùng tài nguyên quá mức cần thiết.
3. Nó cung cấp các dữ liệu thú vị có thể thúc đẩy thảo luận trong cộng đồng phát triển về hiệu năng website.

[GN⁺]

Ý kiến trên Hacker News

• Các trang web người lớn thực sự là một ví dụ cho việc quan tâm đến hiệu năng; Pornhub chỉ tải tổng cộng 1.4MB dữ liệu. Điều này tốt hơn rất nhiều so với hiệu năng mà một số ông lớn công nghệ thể hiện. Pornhub hầu như không mắc lỗi trong UI/UX cơ bản hay khâu phân phối nội dung.
• Trải nghiệm dùng web khi sử dụng roaming ở vùng nông thôn New Zealand rất tệ. Trải nghiệm người dùng (UX) ngoại tuyến của Spotify cũng cần được cải thiện.
• Đặt câu hỏi vì sao lại đang xem dữ liệu chưa nén. Các ứng dụng động như Spotify và Gmail có thể được bỏ qua nếu sau khi tải trang xong có thể điều hướng nhanh. Một số trang lại quá tập trung vào lần tải ban đầu theo cách làm suy giảm trải nghiệm người dùng.
• Phần mềm phản ánh tổ chức đã tạo ra nó. Phần lớn dữ liệu được truyền đi không phải là JavaScript cần thiết để trang thực sự hoạt động mà là các script phân tích và bên thứ ba. Các nhóm marketing либо không biết về điều này, либо không quan tâm.
• Phân tích về kích thước file JavaScript của các ứng dụng web đã bị thiếu. Ví dụ, Google Translate không phải là một ứng dụng tương tác đơn giản và có nhiều tính năng, nhưng 2.5MB vẫn là quá mức.
• Mọi trang trên website Wordsandbuttons.online đều nhỏ hơn 64KB dù vẫn có hoạt ảnh và tính tương tác. Điều này có được nhờ chính sách không phụ thuộc bên thứ ba.
• Cần thảo luận không chỉ về việc lạm dụng JavaScript mà còn về lượng script theo dõi.
• So sánh lượng JavaScript mà các trang phổ biến tải về. Ví dụ, Pornhub tải lượng JavaScript ít hơn khoảng 10 lần so với YouTube.
• Tình trạng hiện tại của web thật đáng buồn. Những người dùng kết nối Internet tốc độ cao không nhận ra web đã chậm đi đến mức nào. Gần như không thể tưởng tượng việc không dùng trình chặn quảng cáo/tracker.
• Người ta tạo ra và duy trì các framework phức tạp cùng các lớp trừu tượng để giúp việc bảo trì dễ hơn, nhưng nhiều lập trình viên thậm chí còn không nắm được kiến thức JavaScript cơ bản. Các ứng dụng web bị over-engineer, với quá nhiều tầng che khuất ngôn ngữ thực tế. Nếu học chính JavaScript và dùng JavaScript thuần thay vì framework, có thể giảm mạnh quy mô codebase JavaScript.