Tải từng phần hình ảnh và các phần tử <iframe>

Hình ảnh và phần tử <iframe> thường tốn nhiều băng thông hơn các loại khác của chúng tôi. Trong trường hợp các phần tử <iframe>, việc xử lý thêm một lượng hợp lý có thể liên quan đến việc tải và hiển thị các trang trong đó.

Trong trường hợp tải từng phần hình ảnh, việc trì hoãn việc tải hình ảnh bên ngoài khung nhìn ban đầu có thể hữu ích trong việc giảm tranh chấp băng thông để biết thêm các tài nguyên quan trọng trong khung nhìn ban đầu. Điều này có thể cải thiện Nội dung lớn nhất hiển thị (LCP) của trang trong một số trường hợp khi kết nối mạng kém và băng thông được phân bổ lại có thể giúp các ứng viên LCP tải và vẽ nhanh hơn.

Trong trường hợp liên quan đến các phần tử <iframe>, Lượt tương tác với nội dung hiển thị tiếp theo của trang Bạn có thể cải thiện (INP) trong quá trình khởi động bằng cách tải từng phần. Điều này là do một <iframe> là một tài liệu HTML hoàn toàn riêng biệt có các tài nguyên phụ riêng. Mặc dù các phần tử <iframe> có thể chạy trong một quy trình riêng, nhưng đây không phải là điều bất thường để họ chia sẻ một quy trình với các luồng khác, việc này có thể tạo ra điều kiện nơi trang trở nên ít phản hồi hơn với hoạt động đầu vào của người dùng.

Do đó, việc trì hoãn việc tải hình ảnh ngoài màn hình và các phần tử <iframe> là một đáng để theo đuổi và đòi hỏi nỗ lực tương đối thấp để có được kết quả tốt lợi nhuận về hiệu suất. Mô-đun này giải thích cách tải từng phần hai loại phần tử cho trải nghiệm người dùng nhanh hơn và tốt hơn trong thời gian giai đoạn khởi động quan trọng.

Tải từng phần hình ảnh bằng thuộc tính loading

Bạn có thể thêm thuộc tính loading vào các phần tử <img> để cho trình duyệt biết cách các tệp đó sẽ được tải:

  • "eager" thông báo cho trình duyệt rằng hình ảnh sẽ được tải ngay lập tức. ngay cả khi vị trí nằm ngoài khung nhìn ban đầu. Đây cũng là giá trị mặc định cho thuộc tính loading.
  • "lazy" trì hoãn việc tải hình ảnh cho đến khi hình ảnh nằm trong một khoảng cách đã đặt tính từ khung nhìn hiển thị. Khoảng cách này thay đổi theo trình duyệt, nhưng thường được đặt là đủ lớn để hình ảnh tải vào lúc người dùng cuộn đến.

Một lưu ý khác là nếu bạn đang sử dụng phần tử <picture>, Thuộc tính loading vẫn phải được áp dụng cho phần tử con <img> của nó, chứ không phải chính phần tử <picture>. Điều này là do phần tử <picture> là một vùng chứa chứa các phần tử <source> bổ sung trỏ đến các phần tử khác nhau ứng viên hình ảnh và ứng viên mà trình duyệt chọn sẽ được áp dụng trực tiếp cho phần tử con <img>.

Không tải từng phần hình ảnh trong khung nhìn ban đầu

Bạn chỉ nên thêm thuộc tính loading="lazy" vào các phần tử <img> có được đặt bên ngoài khung nhìn ban đầu. Tuy nhiên, có thể phức tạp khi biết rằng vị trí chính xác của một phần tử tương đối trong khung nhìn trước trang kết xuất. Kích thước khung nhìn, tỷ lệ khung hình và thiết bị khác nhau phải xem xét.

Ví dụ: khung nhìn trên máy tính có thể khá khác với khung nhìn trên điện thoại di động vì thiết bị này hiển thị nhiều không gian dọc hơn, có thể vừa với hình ảnh trong khung nhìn ban đầu sẽ không xuất hiện trong khung nhìn ban đầu của thiết bị thực nhỏ hơn. Máy tính bảng được dùng hướng dọc cũng hiển thị rất nhiều không gian theo chiều dọc, thậm chí có thể lớn hơn một số không gian trên máy tính để bàn thiết bị.

Tuy nhiên, có một số trường hợp mà rõ ràng là bạn nên tránh đang áp dụng loading="lazy". Ví dụ: bạn chắc chắn nên bỏ qua thuộc tính loading="lazy" từ các phần tử <img> trong trường hợp hình ảnh chính, hoặc các trường hợp sử dụng hình ảnh khác mà các phần tử <img> có khả năng xuất hiện phía trên hoặc gần đầu bố cục trên bất kỳ thiết bị nào. Điều này thậm chí còn quan trọng hơn đối với hình ảnh có khả năng là ứng cử viên LCP.

Các hình ảnh được tải từng phần cần phải đợi trình duyệt hoàn tất bố cục trong để biết liệu vị trí cuối cùng của hình ảnh có nằm trong khung nhìn hay không. Điều này có nghĩa là nếu một phần tử <img> trong khung nhìn hiển thị có loading="lazy" , thì URL đó chỉ được yêu cầu sau khi tất cả CSS được tải xuống, phân tích cú pháp và sẽ được áp dụng cho trang—thay vì được tìm nạp ngay khi trang được phát hiện bởi trình quét tải trước trong mã đánh dấu thô.

Vì thuộc tính loading trên phần tử <img> được hỗ trợ trên tất cả trình duyệt không cần phải sử dụng JavaScript để tải từng phần hình ảnh, vì JavaScript bổ sung vào trang để cung cấp những tính năng mà trình duyệt đã cung cấp ảnh hưởng đến các khía cạnh khác của hiệu suất trang, chẳng hạn như INP.

Bản minh hoạ về tính năng tải từng phần hình ảnh

Tải từng phần các phần tử <iframe>

Tính năng tải từng phần của các phần tử <iframe> cho đến khi các phần tử đó hiển thị trong khung nhìn có thể lưu dữ liệu quan trọng và cải thiện tải các tài nguyên quan trọng bắt buộc để tải trang cấp cao nhất. Ngoài ra, vì các phần tử <iframe> về cơ bản là toàn bộ tài liệu HTML được tải trong một tài liệu cấp cao nhất, chúng có thể bao gồm một số lượng đáng kể các tài nguyên phụ—đặc biệt là JavaScript—có thể sẽ ảnh hưởng đáng kể đến INP của trang nếu các tác vụ trong những khung đó yêu cầu thời gian xử lý đáng kể.

Nội dung nhúng của bên thứ ba là một trường hợp sử dụng phổ biến cho các phần tử <iframe>. Ví dụ: trình phát video được nhúng hoặc bài đăng trên mạng xã hội thường sử dụng phần tử <iframe>, và chúng thường đòi hỏi một số lượng lớn nguồn phụ, mà cũng có thể dẫn đến tranh chấp băng thông cho các tài nguyên của trang cấp cao nhất. Là một ví dụ: tải từng phần nội dung nhúng của một video trên YouTube sẽ giúp tiết kiệm hơn 500 KiB trong khoảng thời gian lượt tải trang ban đầu, trong khi tải từng phần trình bổ trợ nút Thích của Facebook tiết kiệm được hơn 200 KiB — hầu hết trong số đó là JavaScript.

Dù bằng cách nào, mỗi khi có <iframe> dưới màn hình đầu tiên trên một trang, bạn nên đặc biệt cân nhắc việc tải từng phần nếu bạn không cần tải trước, vì làm như vậy có thể cải thiện đáng kể trải nghiệm người dùng.

Thuộc tính loading cho các phần tử <iframe>

Thuộc tính loading trên các phần tử <iframe> cũng được hỗ trợ trong tất cả trình duyệt. Giá trị cho thuộc tính loading và các hành vi của chúng là tương tự như với các phần tử <img> sử dụng thuộc tính loading:

  • "eager" là giá trị mặc định. Mã này thông báo cho trình duyệt tải <iframe> HTML của phần tử và các tài nguyên phụ của nó ngay lập tức.
  • "lazy" trì hoãn việc tải HTML của phần tử <iframe> và các tài nguyên phụ của nó cho đến khi nó nằm trong khoảng cách được xác định trước từ khung nhìn.

Bản minh hoạ iframe tải từng phần

Mặt tiền

Thay vì tải tệp nhúng ngay trong khi tải trang, bạn có thể tải tệp nhúng đó trên nhằm phản hồi tương tác của người dùng. Bạn có thể làm việc này bằng cách hiển thị hình ảnh hoặc một phần tử HTML thích hợp khác cho đến khi người dùng tương tác với phần tử đó. Khi người dùng tương tác với phần tử đó, bạn có thể thay thế phần tử đó bằng nội dung nhúng của bên thứ ba. Kỹ thuật này được gọi là mặt tiền.

Một trường hợp sử dụng phổ biến cho thành phần tượng trưng là các video được nhúng từ các dịch vụ của bên thứ ba trong đó thì việc nhúng có thể liên quan đến việc tải thêm nhiều công cụ và có thể tốn kém nguồn phụ—chẳng hạn như JavaScript—ngoài nội dung video. Trong phạm vi như vậy trường hợp, trừ phi video có lý do chính đáng để tự động phát — nhúng video yêu cầu người dùng tương tác với chúng trước khi phát bằng cách nhấp vào nút phát .

Đây là cơ hội tốt nhất để hiển thị hình ảnh tĩnh về mặt trực quan nhúng video và tiết kiệm băng thông đáng kể trong quá trình này. Sau khi người dùng lượt nhấp vào hình ảnh, thì hình ảnh đó sẽ được thay thế bằng lượt nhúng <iframe> thực tế kích hoạt HTML của phần tử <iframe> của bên thứ ba và các tài nguyên phụ của nó để bắt đầu đang tải xuống.

Ngoài việc cải thiện tải trang ban đầu, một lợi thế quan trọng khác là nếu người dùng không bao giờ phát video, tài nguyên cần thiết để phân phối video không bao giờ đã tải xuống. Đây là một mẫu tốt vì nó đảm bảo người dùng chỉ tải những gì xuống họ thực sự muốn mà không đưa ra những giả định có thể lỗi về nhu cầu của người dùng.

Tiện ích trò chuyện là một trường hợp sử dụng tuyệt vời khác cho kỹ thuật thành phần tượng trưng. Thường gặp nhất tiện ích trò chuyện tải xuống một lượng đáng kể JavaScript có thể ảnh hưởng đến tải trang và khả năng phản hồi hoạt động đầu vào của người dùng. Giống như việc tải bất kỳ nội dung nào lên thì chi phí phát sinh vào thời gian tải, nhưng trong trường hợp tiện ích trò chuyện thì không mọi người dùng đều không bao giờ có ý định tương tác với nó.

Mặt khác, với một thành phần tượng trưng, có thể thay thế lệnh "Bắt đầu" của bên thứ ba Trò chuyện" có một nút giả. Sau khi người dùng tương tác một cách có ý nghĩa với hình ảnh đó – chẳng hạn như giữ con trỏ trên đó trong một khoảng thời gian hợp lý, hoặc với một lần nhấp chuột—tiện ích trò chuyện thực tế, hoạt động được đặt vào vị trí khi người dùng cần thông tin đó.

Mặc dù chắc chắn bạn có thể xây dựng mặt tiền của riêng mình, nhưng bạn có các nguồn mở có sẵn cho các bên thứ ba phổ biến khác, chẳng hạn như lite-youtube-embed đối với video trên YouTube, lite-vimeo-embed đối với video trên Vimeo và React Live Chat Trình tải cho tiện ích trò chuyện.

Thư viện JavaScript tải từng phần

Nếu bạn cần tải từng phần các phần tử <video>, các hình ảnh của phần tử <video> poster, hình ảnh do thuộc tính CSS background-image tải hoặc các hình ảnh khác không được hỗ trợ bạn có thể làm như vậy bằng giải pháp tải từng phần dựa trên JavaScript, chẳng hạn như lazysizes hoặc yall.js, vì việc tải từng phần những loại tài nguyên này không phải là tính năng ở cấp trình duyệt.

Cụ thể, tính năng tự động phát và lặp lại các phần tử <video> mà không có bản âm thanh là một giải pháp thay thế hiệu quả hơn nhiều so với sử dụng ảnh GIF động, vì có thể thường lớn hơn vài lần so với tài nguyên video có hình ảnh trực quan tương đương chất lượng. Mặc dù vậy, những video này có thể vẫn đáng kể về mặt băng thông, vì vậy, tải từng phần là một phương pháp tối ưu hoá bổ sung có thể giúp bạn giảm băng thông lãng phí.

Hầu hết các thư viện này đều hoạt động bằng Intersection Observer APIAPI Đối tượng thay đổi nếu HTML của một trang thay đổi sau lần tải đầu tiên—để nhận ra thời điểm một phần tử đi vào khung nhìn của người dùng. Nếu hình ảnh có thể nhìn thấy (hoặc đang tiến gần khung nhìn) rồi đến thư viện JavaScript thay thế thuộc tính không chuẩn (thường là data-src hoặc một thuộc tính tương tự), bằng thuộc tính chính xác, chẳng hạn như src.

Giả sử bạn có một video thay thế ảnh GIF động nhưng bạn muốn tải từng phần bằng giải pháp JavaScript. Có thể thực hiện điều này với yall.js với các tham số sau mẫu đánh dấu:

<!-- The autoplay, loop, muted, and playsinline attributes are to
     ensure the video can autoplay without user intervention. -->
<video class="lazy" autoplay loop muted playsinline width="320" height="480">
  <source data-src="video.webm" type="video/webm">
  <source data-src="video.mp4" type="video/mp4">
</video>

Theo mặc định, yall.js quan sát tất cả các phần tử HTML đủ điều kiện bằng một lớp "lazy". Sau khi yall.js được tải và thực thi trên trang, video sẽ không tải cho đến khi người dùng cuộn vào khung nhìn. Khi đó, data-src các thuộc tính trên các phần tử con <source> của phần tử <video> bị hoán đổi vào các thuộc tính src. Thao tác này sẽ gửi yêu cầu tải video xuống và tự động bắt đầu phát video đó.

Kiểm tra kiến thức của bạn

Đây là giá trị mặc định của thuộc tính loading cho cả phần tử <img><iframe>?

"lazy"
"eager"

Nên sử dụng giải pháp tải từng phần dựa trên JavaScript khi nào?

Đối với các tài nguyên trong đó thuộc tính loading không được hỗ trợ, chẳng hạn như trong trường hợp tự động phát video nhằm thay thế hình ảnh động hoặc để tải từng phần một phần tử <video> hình ảnh áp phích.
Đối với mọi tài nguyên có thể tải từng phần.

Khi nào sử dụng thành phần tượng trưng là một kỹ thuật hữu ích?

Đối với bất kỳ nội dung nhúng của bên thứ ba nào mà tài nguyên cần thiết để tải thì không đáng kể, nhưng có khả năng cao là không phải người dùng nào cũng có thể tương tác với chúng.
Đối với bất kỳ nội dung nhúng nào của bên thứ ba sử dụng đáng kể dữ liệu, bất kể nhu cầu của người dùng.

Tiếp theo: Tìm nạp trước và kết xuất trước

Giờ đây, bạn đã xử lý được thao tác tải từng phần hình ảnh và các phần tử <iframe>, bạn đang ở vị trí tốt để đảm bảo rằng các trang có thể tải nhanh hơn trong khi tôn trọng nhu cầu của người dùng. Tuy nhiên, có những trường hợp trong đó tải suy đoán tài nguyên có thể mong muốn. Trong mô-đun tiếp theo, hãy tìm hiểu về việc tìm nạp trước và kết xuất trước cũng như cách các kỹ thuật này khi được sử dụng thận trọng—có thể tăng tốc đáng kể tốc độ điều hướng đến các trang tiếp theo bằng cách tải chúng sớm hơn.