- Một thẻ nhúng YouTube `` mặc định, ngay cả khi chỉ đặt một cái trên trang trống, cũng tạo ra 32 request và 1.3MB dữ liệu truyền tải, là gánh nặng lớn so với một UI video nhỏ
- Khi gắn nhiều video, tài nguyên không được chia sẻ nên dung lượng tăng tuyến tính; theo đo đạc của Zach Leatherman, 2 video tăng lên 2.4MB và 3 video lên tới 3.6MB
- Những gì người dùng thấy lúc đầu chỉ là ảnh poster, tiêu đề và nút phát lớn, nên có thể tái hiện cùng trải nghiệm đó nhẹ hơn nhiều bằng Web Component như ``
lite-youtube-embed chỉ khoảng 100KB và chia sẻ tài nguyên giữa nhiều phần nhúng, giúp cải thiện tốc độ và hiệu quả mà không mất tính năng- Vì nhúng YouTube được dùng rất rộng rãi, việc cắt giảm dữ liệu ở mức megabyte cho mỗi embed là một tối ưu hóa thực tế, giúp giảm cả điện năng tiêu thụ lẫn phát thải carbon
Chi phí của nhúng `` mặc định
- Khi chọn
Embed trong menu chia sẻ của YouTube, bạn sẽ nhận được HTML dựa trên ``
- Mã mặc định không có
loading="lazy", nên cả video ngoài màn hình cũng có thể bị tải ngay lập tức
- Chỉ cần YouTube thêm lazy loading vào iframe mặc định là đã có thể cải thiện hiệu năng ngay
- Để biến iframe thành dạng responsive và giữ đúng tỷ lệ gốc, có thể chỉ định trực tiếp iframe nhúng YouTube bằng CSS
iframe[src^="https://www.youtube.com/embed/";] {
inline-size: 100%;
block-size: auto;
aspect-ratio: 16 / 9;
}
Số đo thực tế và mức tăng tuyến tính
- Ngay cả khi chỉ đặt một nhúng YouTube trên trang trống, chi phí tải vẫn rất lớn
-
32 request
- 1.3MB dữ liệu truyền tải
- 2.76 giây tải theo WiFi của tác giả
- Zach Leatherman ghi nhận rằng khi số lượng embed tăng lên, tài nguyên không được chia sẻ nên dung lượng tăng tuyến tính
- 2 embed: 2.4MB
- 3 embed: 3.6MB
- Có vẻ hiện tại kích thước còn lớn hơn so với thời điểm Zach kiểm tra
UI người dùng nhìn thấy lúc đầu rất đơn giản
- Những thành phần người dùng gặp đầu tiên trong nhúng YouTube là khá hạn chế
- Ảnh poster của video
- Tiêu đề video
- Nút phát lớn, bấm vào là chạy
- Mức UI và hành vi này có thể triển khai được mà không cần tải toàn bộ tài nguyên của trình phát YouTube ngay từ đầu
- Khó đánh giá nhận định rằng nhúng nhẹ hơn làm giảm mức độ tương tác nếu không công bố phương pháp và dữ liệu
- Trong quá khứ, khi một kỹ sư YouTube thử nghiệm trang video nhẹ hơn, thời gian tải trung bình lại tăng lên
- Trang nhẹ hơn đã tiếp cận được cả người dùng thiết bị cấu hình thấp và mạng chậm
- Việc người dùng mới có thể truy cập được có thể đã làm chỉ số thời gian tải trung bình chậm đi
- Nếu chỉ nhìn vào thời gian tải trung bình thì có thể bỏ lỡ mức cải thiện tốc độ thực tế theo từng người dùng
Giải pháp thay thế: Web Component ``
- lite-youtube-embed do Paul Irish, một nhân vật gắn liền với hiệu năng tại Google, tạo ra là một Web Component tái hiện trải nghiệm nhúng mặc định theo cách nhẹ hơn
- Phần mô tả dự án giới thiệu rằng nó render như embed thật nhưng nhanh hơn khoảng 224 lần
- Trải nghiệm người dùng gần như giống nhúng YouTube mặc định
- Hiển thị ảnh poster
- Hiển thị tiêu đề
- Hiển thị nút phát lớn
- Phát video khi nhấp
- Khác biệt nằm ở mức dùng tài nguyên và cách chia sẻ chúng
- Nhúng YouTube mặc định: khoảng 1.3MB
- ``: khoảng 100KB
- Có thể chia sẻ tài nguyên giữa nhiều embed
- Có được tốc độ, hiệu quả và quyền riêng tư cơ bản tốt hơn mà không mất tính năng
Cách sử dụng và triển khai liên quan
- Cách dùng là đăng ký Web Component bằng JavaScript rồi sử dụng phần tử ``
- Đều có thể dùng qua cài npm, sao chép trực tiếp hoặc liên kết CDN
import "https://esm.sh/lite-youtube-embed";;
- Cách được README khuyến nghị là đặt HTML trước, rồi tải script bất đồng bộ để áp dụng progressive enhancement
- Có thể đặt
background-image ngay trong HTML để vẫn hiển thị đúng trước khi JavaScript được tải
[Play Video: Keynote (Google I/O '18)](https://youtube.com/watch?v=ogfYd705cRs)
- Cũng có các triển khai và lựa chọn thay thế liên quan
2 bình luận
lite-youtube-embed - Nhúng YouTube nhanh hơn
Ý kiến trên Hacker News
Trên một nền tảng diễn đàn cộng đồng, họ phát hiện YouTube embed và thay bằng thumbnail proxy không được tải trước khi người dùng nhấp vào
Chỉ vì một người trong thread chia sẻ video YouTube mà tất cả những ai mở trang đó phải tải hơn 1MB JavaScript và còn bị Google theo dõi IP là điều không cần thiết
Tôi không quá bận tâm về theo dõi nên vẫn dùng nguyên thumbnail do YouTube cung cấp
Player của SoundCloud cũng cực kỳ nặng
Nếu hotlink thumbnail thì Google vẫn có thể theo dõi từ đó
Tác giả nói không tin có bằng chứng rằng phiên bản nhẹ hơn làm giảm mức độ tương tác, nhưng tôi nghĩ điều đó hoàn toàn có thể xảy ra
Demo của dự án lite-youtube-embed được đề xuất có cả player nhẹ và player thông thường, và phiên bản nhẹ mất thời gian lâu hơn thấy rõ để bắt đầu phát video
Cứ mỗi 1 mili giây tăng thêm trong thời gian tải thì mức độ tương tác lại giảm, còn ở đây chênh lệch có vẻ là hàng trăm mili giây trở lên
https://paulirish.github.io/lite-youtube-embed/
Lập luận từng mili giây đều quan trọng cũng áp dụng cho trang web. Nếu người dùng rời trang thì họ còn chưa kịp tới video
Ngoài ra, việc người dùng không muốn xem video cũng có thể là điều ổn. Cá nhân tôi thích khi trang web có phần tóm tắt để có thể tránh xem video
Tôi cũng không hài lòng với đợt thiết kế lại bản desktop của YouTube; họ dùng quá nhiều diện tích màn hình để quảng bá các video khác thay vì video mà tôi thật sự đến xem. Tôi muốn ít yếu tố gây phân tâm hơn
Ví như đèn giao thông, tôi thích đèn mình đang đi tới là đèn xanh hơn là tất cả đèn đều đỏ trong thời gian ngắn
Nhìn vào hành vi thực tế của các tập đoàn lớn thì rõ ràng họ không bận tâm đến chuyện đó; nếu điều đó không quan trọng với họ thì chúng ta cũng không có lý do gì phải tối ưu hộ họ
Trong trường hợp sử dụng này thì không phải vấn đề lớn, nhưng với phần còn lại của stack thì vẫn cần quan tâm đến hiệu năng
Không hiểu vì sao lại thụt lùi đến mức này, và Google có vẻ đang dần làm hỏng những thứ vốn hoạt động ổn
Có thể tùy môi trường: Firefox, laptop i7-1185G7 khoảng 2 năm tuổi, Windows 11, Edge chế độ 32-bit vẫn đang cập nhật liên tục và vài tuần chưa khởi động lại
Cảm giác chậm phần lớn đến từ biểu tượng loading xoay vòng. Nó giống như tự quảng cáo rằng mình chậm vậy
Độ trễ từ lúc nhấp đến khi phát chắc chắn có ảnh hưởng, nhưng để đo đúng mức đó thì cần một bên có quy mô như YouTube
Về tin đồn rằng embed nhẹ hơn làm giảm mức độ tương tác và lite-youtube-embed được đề xuất, người dùng có thể cảm thấy xa lạ và không tin nếu player chỉ trông hơi khác hoặc hoạt động hơi khác
Trong demo, lite-youtube-embed dù có hiển thị tiêu đề nhưng lại không có liên kết để chuyển sang trang YouTube thật, tạo cảm giác thù địch như thể ngăn người dùng tới “nội dung” gốc
Tất nhiên tính năng đó có thể dễ dàng thêm vào, nhưng nó cho thấy một vấn đề lớn hơn
Tôi hầu như không bao giờ phát video embed, nhưng nếu có phát thì trải nghiệm YouTube thông thường là đủ. Nếu bọc nó trong một lớp lạ khác thì khả năng tôi nhấp vào sẽ giảm
Cách nói “không hy sinh gì cả” trong bài viết này là một ví dụ về việc lập trình viên tưởng rằng mình biết người dùng sử dụng phần mềm như thế nào. Thực tế thì luôn chỉ là phỏng đoán
Tôi hy vọng video sẽ ít đi, sự phụ thuộc vào Google ở khắp nơi và các khối JavaScript cũng ít đi. Vì một web tốt hơn, mong mọi người đừng nhúng video YouTube lung tung khắp nơi
https://paulirish.github.io/lite-youtube-embed/
Giờ đã biết chuyện này, tôi hy vọng các player nhẹ như vậy cũng có nút đó. Dù sao thì cách triển khai này cũng không hoàn toàn chặn cách dễ để lấy liên kết
Nếu phát video thì có thể truy cập được, nhưng như vậy lại trái mục đích. Tôi không muốn phát video, cũng không muốn chờ nó tải xong rồi tạm dừng để bấm nút lưu
Giờ chỉ cần ngăn các blogger dùng nhúng GitHub Gist nữa là được
Hugo và có lẽ các trình tạo site tĩnh khác đều hỗ trợ sẵn các đoạn mã có tô sáng cú pháp, còn các site động hơn cũng có thể dùng highlight.js để loại bỏ phụ thuộc vào dịch vụ bên thứ ba
Dùng một iframe nặng nề cho một đoạn mã nhỏ thật sự rất lạ
https://gohugo.io/content-management/syntax-highlighting/
https://highlightjs.org
Dù tôi không thích, việc “ép” họ thay đổi site cho hợp gu của tôi là vô lý
Nó được sửa trong vài tuần, nhưng tôi ngạc nhiên là tình trạng đó đã tồn tại suốt nhiều năm
Nếu có thể tận dụng Content Security Policy trên trang, có thể chặn quảng cáo để giảm tổng dung lượng của phần nhúng và cải thiện trải nghiệm người dùng
Thông tin liên quan: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...
Content-Security-PolicyVì làm vậy sẽ tắt cơ chế phòng vệ của CSP trước các cuộc tấn công chèn mã. Nếu thật sự cần, có những cách an toàn hơn để cho phép script inline
https://content-security-policy.com/
Có vẻ câu chuyện “phần nhúng nhẹ hơn làm giảm mức độ tương tác” đang thiếu một phần quan trọng
Lẽ ra thời gian tải nhanh hơn thì mức độ tương tác phải tốt hơn. Nhưng nếu phần nhúng nhẹ hơn lại làm tương tác giảm, nghĩa là đã hy sinh một tính năng hoặc hành vi nào đó
Thế mà bài viết này nói không hy sinh gì cả, nên hẳn câu chuyện còn thiếu chỗ nào đó
Ở đây cũng có thể tương tự. Nhờ phần nhúng nhẹ hơn, nhiều người lần đầu tải được video, nhưng do thiết bị hoặc kết nối chậm nên rời đi ở bước phát
Khi đó những người trước đây không tải nổi trình phát hoàn chỉnh và không để lại dữ liệu nào, nay lại xuất hiện như làm tăng tỷ lệ “bỏ xem video”
Người dùng có kỳ vọng và mức chịu đựng thời gian tải khác nhau tùy đối tượng, và trang với video bên trong là hai đối tượng khác nhau
Thời gian tải toàn trang cũng không phải lúc nào cũng gắn với thời gian tải phần nhúng, và việc tải toàn trang có thể che lấp thời gian tải nội dung
Chỉ số quan trọng hơn có thể không phải thời gian tải phần nhúng, mà là độ trễ từ lúc nhấp đến lúc phát
Với người dùng uBlock, có thể dùng bộ lọc click2load như một giải pháp phía người dùng
Tuy nhiên Chrome đang chuyển sang Manifest V3 nên có thể không hoạt động. Có thể tham khảo bộ lọc của yokoffing/filterlists
https://raw.githubusercontent.com/yokoffing/filterlists/main...
Đây là tác giả của Betterfox và trên GitHub còn có các bộ lọc hữu ích khác
Thứ tôi muốn chỉ là một liên kết bình thường, nên trước đây tôi đã viết một userscript ngắn để thay iframe YouTube trên trang bằng liên kết
Với một cách triển khai đơn giản, nó hoạt động tốt đáng ngạc nhiên. Nó tìm các iframe
youtube.com/embedvàyoutube-nocookie.com/embed, đổi thành liên kếtwatch?v=, giữ cả timestamp, và nếu muốn còn có thể gắn thêm ảnh thumbnailPhần nói “càng nhiều phần nhúng thì dung lượng cũng tăng tuyến tính. Hai cái là 2,4MB, ba cái là 3,6MB” nghe hơi lạ
Tôi tò mò vì sao các tài nguyên này không được lấy từ cache. Nếu tất cả đều được tải từ
www.youtube.com, theo same-origin policy thì đáng ra phải dùng được tài nguyên đã cache chứPhần hay nhất trong bài là đoạn nói rằng khi chuyển sang trang nhẹ hơn, thời gian tải trang trung bình lại tăng
Nhìn kỹ hơn thì người dùng thiết bị cấu hình thấp và mạng chậm lần đầu tiên mới thật sự dùng được YouTube, và vì họ dùng nhiều nên trông như mức trung bình bị chậm đi
Tốc độ sử dụng thực tế đã tương đối nhanh hơn với mọi người, và thật ấn tượng khi thấy chỉ số tốc độ tải trang trung bình rốt cuộc chỉ là một cái bẫy vô nghĩa
Trước đây tôi từng làm một extension Firefox biến mọi phần nhúng YouTube thành thumbnail, rồi khi nhấp thì mở YouTube
Ban đầu tôi làm vì điện thoại không có Flash trong khi phần nhúng Flash rất phổ biến, về sau mở rộng để xử lý cả phần nhúng iframe
Trong hầu hết trường hợp, mở bằng toàn bộ website hoặc ứng dụng YouTube cho trải nghiệm người dùng tốt hơn so với một khung nhúng nhỏ
Dù khi đó tôi viết theo API extension cấp cao mới, hỗ trợ giữa các phiên bản trình duyệt vẫn không được duy trì như kỳ vọng, khiến tôi bực nên đã không chuyển sang WebExtension. Đọc bài này làm tôi muốn port lại