Trong một tập gần đây của podcast Search Off the Record, Martin Splitt và John Mueller đã thảo luận về thời điểm lazy loading mang lại lợi ích và khi nào nó có thể làm chậm trang.
Splitt đã sử dụng ví dụ thực tế trên developers.google.com để minh họa một tình huống phổ biến: đặt mặc định lazy loading cho tất cả hình ảnh có thể làm chậm Largest Contentful Paint nếu bao gồm cả những hình ảnh nằm ở khu vực phía trên màn hình.
Ông cho biết hệ thống quản trị nội dung đang dùng cho developers.google.com mặc định áp dụng lazy loading cho mọi hình ảnh và điều này không thực sự tốt. Theo Splitt, việc lazy load hero image là rủi ro vì bạn đang yêu cầu trình duyệt trì hoãn tải phần tử quan trọng nhất trong vùng hiển thị, từ đó đẩy lùi thời điểm LCP và có thể gây xê dịch bố cục nếu không khai báo kích thước. Ông nhấn mạnh rằng nếu bạn sử dụng lazy loading cho hình ảnh hiển thị ngay lập tức trên màn hình, gần như chắc chắn sẽ ảnh hưởng đến LCP.
Lazy Loading làm chậm LCP như thế nào?
LCP đo thời điểm phần tử văn bản hoặc hình ảnh lớn nhất trong viewport ban đầu được hiển thị.
Thông thường, trình duyệt sẽ phát hiện sớm hero image thông qua cơ chế preload scanner và ưu tiên tải nó để hiển thị nhanh nhất có thể. Tuy nhiên, khi thêm thuộc tính loading=”lazy” vào hero image, bạn đã thay đổi cách trình duyệt sắp xếp mức độ ưu tiên tải tài nguyên.
Hình ảnh sẽ bị xem là tài nguyên ưu tiên thấp, các tài nguyên khác được tải trước. Trình duyệt chờ đến khi hoàn tất một số bước xử lý bố cục và công việc khác rồi mới yêu cầu tải hero image. Khi đó, hình ảnh phải cạnh tranh băng thông với script, CSS và các tài nguyên khác đã được đưa vào hàng đợi. Sự trì hoãn này khiến thời điểm hiển thị phần tử lớn nhất bị lùi lại, làm tăng điểm LCP.
Trên mạng chậm hoặc thiết bị có CPU hạn chế, tác động này càng rõ rệt. Nếu không khai báo width và height, hình ảnh tải muộn còn có thể gây xê dịch bố cục và tạo cảm giác giật.
Rủi ro SEO với một số thư viện lazy load
Hiện nay, các trình duyệt đã hỗ trợ sẵn thuộc tính loading cho hình ảnh và iframe, giúp giảm nhu cầu sử dụng JavaScript nặng. WordPress đã áp dụng native lazy loading mặc định, góp phần phổ biến phương pháp này.
Tuy nhiên, một số thư viện lazy loading cũ hoặc tùy chỉnh có thể ẩn URL hình ảnh trong các thuộc tính không tiêu chuẩn. Nếu URL thực không nằm trong thuộc tính src hoặc srcset trong HTML mà Google render, hình ảnh có thể không được thu thập và lập chỉ mục.
Splitt cho biết Google đã thấy nhiều thư viện sử dụng các thuộc tính như data-source thay vì source. Nếu URL không nằm trong thuộc tính chuẩn, Google có thể không nhận diện được.
Cách kiểm tra trang của bạn
Hãy sử dụng tính năng URL Inspection trong Google Search Console để xem HTML đã render và xác nhận rằng hình ảnh phía trên màn hình cũng như các module lazy load đều hiển thị URL trong các thuộc tính chuẩn. Không nên chỉ dựa vào ảnh chụp màn hình xem trước. Nếu HTML đã render chứa đầy đủ URL hình ảnh trong thuộc tính source của thẻ image, bạn có thể yên tâm rằng Google sẽ nhận diện được.
Tác động đến xếp hạng
Splitt cho rằng tác động đến thứ hạng là tương đối nhỏ. Core Web Vitals có ảnh hưởng đến ranking, nhưng trong phần lớn trường hợp, đây chỉ là một yếu tố rất nhỏ.
Bạn nên làm gì tiếp theo?
Giữ chế độ tải thông thường cho hero image và các hình ảnh phía trên màn hình, đồng thời khai báo đầy đủ width và height. Sử dụng loading=”lazy” mặc định cho hình ảnh và iframe phía dưới màn hình. Nếu dùng thư viện cho preview, video hoặc nội dung động, hãy đảm bảo HTML cuối cùng hiển thị URL thật trong các thuộc tính chuẩn và kiểm tra lại bằng HTML đã render.
Nhìn về phía trước
Lazy loading vẫn hữu ích nếu được áp dụng có chọn lọc. Hãy coi đây là giải pháp dành cho nội dung không quan trọng ngay lập tức. Luôn xác minh cách triển khai bằng HTML đã render và theo dõi xu hướng LCP của bạn theo thời gian để đảm bảo hiệu suất được cải thiện bền vững.
Tài liệu tham khảo
https://www.searchenginejournal.com/google-why-lazy-loading-can-delay-largest-contentful-paint-lcp/554418/
