Tối ưu ảnh cho website: WebP, AVIF, ảnh responsive, tải lười và ảnh LCP

Ảnh thường là phần nặng nhất của một trang web và cũng là phần tử lớn nhất trên màn hình đầu tiên. Sai 1 thuộc tính ở ảnh hero là LCP chậm đi hoặc bố cục bị xê dịch.

Bài này trình bày cách chọn định dạng (JPEG, PNG, WebP, AVIF, SVG), khai báo kích thước, ảnh responsive, tải lười, xử lý ảnh LCP và SEO ảnh. Nguồn chính là web.dev, MDN, Google Search Central, tài liệu Next.js và Web Almanac 2025, đối chiếu đến ngày 22/10/2026.

Click Star đã có bài riêng về tốc độ website và Core Web Vitals, về Next.js hay WordPress và về checklist SEO trước khi ra mắt; bài này chỉ đi sâu vào ảnh. Click Star làm dịch vụ thiết kế website chuẩn SEO tải nhanh, nên có lợi ích liên quan.

Điểm chính

• Theo Web Almanac 2025, ảnh là phần tử LCP ở 76,0% trang di động và 85,3% trang máy tính.
• WebP và AVIF thường nhỏ hơn JPEG và PNG, nhưng mức giảm phụ thuộc ảnh. Trên 2 ảnh mẫu của Click Star, AVIF còn 51% đến 57% dung lượng JPEG, WebP còn 56% đến 98%.
• Mọi ảnh cần width và height (hoặc aspect-ratio). Web Almanac 2025 ghi 62% trang di động có ít nhất 1 ảnh thiếu kích thước.
• Ảnh responsive cần srcset kèm sizes đúng khung hiển thị; thiếu sizes, trình duyệt coi ảnh rộng 100% khung nhìn.
• Ảnh LCP không dùng loading="lazy", nên có trong HTML ban đầu và nên có fetchpriority="high", nhưng chỉ cho 1 đến 2 ảnh.
• Google không lập chỉ mục ảnh nền CSS. Ảnh có nghĩa với nội dung phải nằm trong thẻ img kèm alt mô tả.
• Hãy kiểm bằng Lighthouse, PageSpeed Insights, DevTools và xem ảnh bằng mắt trước khi đổi định dạng hàng loạt.

Ảnh tác động đến trang web đến đâu

Theo Web Almanac 2025 (chương Page Weight, đăng 15/1/2026), trang chủ trung vị trên di động nặng 2,56 MB, trong đó ảnh là 911 KB.

Chương Performance cho biết ảnh LCP chủ yếu là JPG (khoảng 57%), rồi PNG (26%), WebP (11%) và AVIF (0,7%). Đây là dữ liệu toàn cầu.

web.dev (cập nhật 31/3/2025) cảnh báo thời gian tải ảnh thường chưa phải điểm nghẽn lớn nhất của LCP. Nén nhỏ hơn chỉ giải quyết một phần; ảnh bị phát hiện muộn hoặc bị tải lười thường gây trễ nhiều hơn.

Chọn định dạng nào: JPEG, PNG, WebP, AVIF hay SVG

JPEG nén có mất dữ liệu, hợp với ảnh chụp; MDN (cập nhật 8/10/2026) ghi JPEG kém với chữ, nét vẽ và không có kênh trong suốt. PNG nén không mất dữ liệu, hợp với ảnh chụp màn hình, sơ đồ, logo, nhưng theo web.dev (cập nhật 13/8/2024) tệp lớn hơn nhiều.

WebP có cả chế độ mất và không mất dữ liệu. Theo MDN, WebP mất dữ liệu trung bình nhỏ hơn JPEG 25 đến 35% ở mức nhìn tương đương, bản không mất dữ liệu thường nhỏ hơn PNG khoảng 26%, và theo web.dev, các trình duyệt hiện đại đều hỗ trợ.

AVIF: MDN nêu ví dụ AVIF mất dữ liệu nhỏ hơn JPEG khoảng 50%, nhưng không hiển thị tăng dần (tệp phải tải xong mới hiện). Theo MDN, hỗ trợ từ Chrome 85, Edge 121, Firefox 93, Safari 16.1, và nên có phương án dự phòng.

SVG là ảnh vector, hợp với logo, biểu tượng, sơ đồ, không hợp với ảnh chụp (web.dev). Google Search hỗ trợ cả WebP, AVIF và SVG (cập nhật 2/3/2026). Suy luận của Click Star: đổi định dạng không khiến ảnh bị loại, nhưng URL tệp đổi theo đuôi mới nên cần chuyển hướng.

Phép đo của Click Star: WebP và AVIF trên ảnh mẫu

Đây là phép đo của Click Star, không phải số liệu ngành. Click Star dùng 2 ảnh từ thư viện ảnh của NASA (theo hướng dẫn của NASA, đọc 22/10/2026, nội dung nói chung không thuộc bản quyền ở Hoa Kỳ).

Ảnh 1 là cảnh bình minh Artemis I (mã NHQ202208310005, gốc 3955 x 3272 px, JPEG) với nhiều vùng màu mịn, ảnh 2 là Cosmic Cliffs của kính Webb (mã carina_nebula, gốc 2000 x 1158 px, PNG) với nhiều chi tiết.

Mỗi ảnh được thu về 1.600 px ngang bằng bộ lọc Lanczos, mã hóa bằng Pillow 11.3.0 (libwebp 1.5.0, libavif 1.3.0) với JPEG optimize, WebP method 4, AVIF speed 6. Vì thang quality không tương đương, Click Star tìm quality thấp nhất của WebP và AVIF mà SSIM không thấp hơn JPEG quality 80.

SSIM là hàm tự viết bằng numpy, tính trên độ sáng theo khối 8x8 không chồng lấn và so với ảnh đã thu nhỏ, nên có thể lệch so với công cụ khác.

Ảnh 1: JPEG 139,9 KB, WebP 137,4 KB, AVIF 79,6 KB. Ảnh 2: JPEG 333,5 KB, WebP 187,0 KB, AVIF 171,6 KB.

Ở ảnh 1, WebP gần bằng JPEG (98%) còn AVIF còn 57%; ở ảnh 2, WebP còn 56% và AVIF còn 51%. Cùng một định dạng cho kết quả rất khác tùy ảnh.

Với đồ họa phẳng, 1 infographic 2.100 x 1.056 px của Click Star có PNG 211,2 KB (PNG tái mã hóa bằng Pillow; tệp gốc 206.766 byte), WebP không mất dữ liệu method 6 là 88,2 KB (khoảng 42%) và AVIF không mất dữ liệu speed 4 là 62,3 KB (khoảng 30%).

Thứ tự WebP và AVIF có thể đảo tùy ảnh: trong một lần thử khác trên đồ họa phẳng tổng hợp, WebP không mất dữ liệu nhỏ hơn AVIF. Theo tài liệu Next.js, AVIF mã hóa lâu hơn khoảng 50% nhưng nhỏ hơn WebP khoảng 20%, và Next.js vẫn khuyên WebP cho đa số trường hợp.

Khai báo kích thước để tránh xê dịch bố cục

Mọi ảnh cần có width và height. Theo web.dev (cập nhật 7/2/2025), trình duyệt dùng 2 thuộc tính này để tính tỷ lệ và chừa chỗ trước khi ảnh tải xong; nếu không đặt được, hãy dùng aspect-ratio trong CSS.

Ảnh responsive: srcset, sizes và picture

Ảnh responsive giải 3 bài toán. Đổi độ phân giải theo màn hình dùng srcset với sizes. Đổi cách cắt ảnh dùng picture với media. Đổi định dạng dùng picture với source và type (MDN, các trang cập nhật 6/11/2025 và 1/10/2026).

Theo trang thẻ img của MDN (cập nhật 11/9/2026), descriptor w phải khớp độ rộng thật của tệp, không trộn w với x trong 1 srcset, và thiếu sizes thì mặc định là 100vw.

Dung lượng tăng nhanh theo độ rộng. Với ảnh 1, JPEG quality 80 nặng 23,3 KB ở 480 px, 51,1 KB ở 800 px, 91,8 KB ở 1.200 px và 139,9 KB ở 1.600 px (phép đo của Click Star).

Tải lười: chỉ dành cho ảnh dưới màn hình đầu

loading="lazy" trì hoãn tải ảnh đến khi gần vào khung nhìn; mặc định là eager. Google (cập nhật 10/12/2025) khuyên không tải lười nội dung có khả năng hiện ngay khi mở trang.

Bài "The performance effects of too much lazy loading" của web.dev (cập nhật 31/3/2022) nêu thử nghiệm A/B trong phòng thí nghiệm, theme twentytwentyone. Tắt tải lười giảm LCP ở trang lưu trữ 13% trên máy tính và 15% trên di động; chỉ tải lười ảnh dưới màn hình đầu (đoán bằng một heuristic thử nghiệm) thì giảm 14% và 18%, byte ảnh không đổi.

Ở trang bài đơn lẻ, chênh lệch nằm trong biên sai số, và đây chưa phải số đo thực địa. Web Almanac 2025 ghi khoảng 16% đến 17% trang vẫn tải lười chính ảnh LCP.

Ảnh LCP: vị trí trong HTML, fetchpriority và preload

web.dev (cập nhật 31/3/2025) nêu 3 khuyến nghị cho ảnh LCP. Ảnh nên có ngay trong HTML ban đầu (img có src hoặc srcset, không chèn bằng JavaScript hay data-src), không bao giờ tải lười, và nên có fetchpriority="high".

Theo web.dev (cập nhật 14/11/2023), trên Chrome ảnh mặc định bắt đầu ở mức Thấp rồi được nâng lên Cao khi bố cục xác nhận ảnh nằm trong khung nhìn; từ Chrome 117, 5 ảnh lớn đầu tiên bắt đầu ở mức Trung bình.

fetchpriority chỉ là gợi ý, và web.dev nói đặt mức cao cho nhiều hơn 1 đến 2 ảnh làm thuộc tính mất tác dụng. Web Almanac 2025 ghi 17,3% trang di động có ảnh LCP dùng fetchpriority="high".

Preload hữu ích khi ảnh không có trong HTML, ví dụ ảnh nền khai báo trong CSS: dùng link rel="preload" as="image" kèm fetchpriority="high". Nên đặt ảnh LCP cùng nguồn gốc với trang, vì tên miền khác tốn thêm bước kết nối.

Tài liệu Next.js (cập nhật 28/9/2026) cho biết từ Next.js 16 thuộc tính priority bị coi là lỗi thời để thay bằng preload, và đa số trường hợp nên dùng loading="eager" hoặc fetchPriority="high".

Thuộc tính decoding (sync, async, auto theo MDN) ít quan trọng hơn: một bài trên blog cá nhân tunetheweb.com (6/2023) kết luận đa số nhà phát triển không cần lo về nó.

Ảnh nền CSS, alt text và SEO ảnh

Theo Google Search Central (cập nhật 2/3/2026), Google tìm ảnh trong src của thẻ img (kể cả img nằm trong picture) và không lập chỉ mục ảnh CSS. Ảnh có nghĩa với nội dung nên là img; ảnh nền CSS chỉ để trang trí.

Google gọi alt là siêu dữ liệu quan trọng nhất của ảnh: nên giàu thông tin, đúng ngữ cảnh, không nhồi từ khóa. Tên tệp nên ngắn và mô tả, ảnh nên đặt gần văn bản liên quan.

Web Almanac 2025 (chương Accessibility) ghi khoảng 8,5% alt kết thúc bằng .jpg hoặc .png, thường do công cụ chèn tên tệp. MDN nói alt rỗng dành cho ảnh trang trí.

CDN và định dạng tự động

Theo web.dev (cập nhật 14/8/2019), chuyển sang CDN ảnh có thể tiết kiệm 40% đến 80% dung lượng; đây là nhận định của bài cũ, chưa có đối chứng độc lập.

Với next/image, định dạng được chọn theo tiêu đề Accept và mặc định chỉ có WebP.

Quy trình xuất ảnh cho đội nội dung

Đây là khung tham khảo của Click Star, không lấy từ nguồn ngoài; hãy thay độ rộng bằng khung bố cục thật.

• Xuất theo khung, trần tham khảo: ảnh hero 1.600 px ngang, ảnh trong cột nội dung 1.200 px, ảnh thẻ 640 px.
• Ảnh chụp xuất WebP hoặc AVIF (kèm JPEG nếu hệ thống không tự đổi); đồ họa phẳng xuất WebP không mất dữ liệu hoặc PNG; logo xuất SVG.
• Đặt tên tệp ngắn, mô tả, không dấu; viết alt cho mọi ảnh có nghĩa.
• Đánh dấu ảnh hero của từng trang để lập trình gắn fetchpriority và bỏ tải lười.

Đánh giá của Click Star. Thứ tự hợp lý thường là: sửa ảnh LCP (bỏ tải lười, thêm fetchpriority, có trong HTML), khai báo kích thước, rồi mới đến responsive và đổi định dạng. AVIF nên làm sau cùng vì cần xem bằng mắt và chấp nhận chi phí mã hóa.

Nếu phần tử LCP là chữ thì tối ưu ảnh không đổi LCP; Web Almanac 2025 ghi chữ là LCP ở 23,7% trang di động. Trang dịch vụ thiết kế website của Click Star công bố mục tiêu từ 90 điểm PageSpeed trở lên; đó là mục tiêu, không phải kết quả đo.

Cách kiểm

Lighthouse 13 (phát hành 10/10/2025, theo Chrome for Developers) gộp các audit định dạng hiện đại, nén ảnh và ảnh đúng kích thước vào image-delivery-insight. Audit ảnh LCP bị tải lười được thay bằng lcp-discovery-insight, và offscreen-images bị bỏ.

DevTools có insight LCP breakdown (đăng 8/10/2025) chia LCP thành 4 phần: phản hồi máy chủ, độ trễ bắt đầu tải, thời gian tải và độ trễ hiển thị.

Lộ trình 14 ngày (khung tham khảo của Click Star)

• Ngày 1 đến 2: chọn 5 trang quan trọng, xác định phần tử LCP trên di động, ghi định dạng và loading hiện có.
• Ngày 3 đến 5: sửa ảnh LCP, gồm bỏ tải lười, thêm fetchpriority="high" và bảo đảm có trong HTML.
• Ngày 6 đến 9: thêm width và height cho mọi ảnh, thêm srcset và sizes, đổi định dạng qua CDN hoặc next/image.
• Ngày 10 đến 12: rà alt và tên tệp, chuyển ảnh có nghĩa từ nền CSS sang img.
• Ngày 13 đến 14: chạy lại Lighthouse, so với ngày đầu và cập nhật hướng dẫn cho đội nội dung.

Những sai lầm thường gặp

1. Gắn loading="lazy" cho mọi ảnh, kể cả ảnh hero.
2. Gắn fetchpriority="high" cho hàng loạt ảnh, làm thuộc tính mất tác dụng.
3. Bỏ width và height, để trang xê dịch khi ảnh tải xong.
4. Đổi đuôi tệp sang .webp mà không chuyển đổi nội dung thật.
5. Khai báo srcset kiểu w nhưng thiếu sizes hoặc sizes sai khung.
6. Dùng ảnh nền CSS cho ảnh có nghĩa với nội dung, nên Google không lập chỉ mục.
7. Nhồi từ khóa vào alt hoặc để tên tệp làm alt.
8. Đổi toàn bộ sang AVIF mà không xem bằng mắt hay đo lại trên ảnh của chính website.

Điều chưa biết

Click Star chưa tìm thấy số đo riêng cho Việt Nam về định dạng ảnh, tải lười ảnh LCP hay ảnh thiếu kích thước, và chưa đo hỗ trợ AVIF trên thiết bị cũ. Phép đo của Click Star chỉ có 2 ảnh chụp, 1 đồ họa, 1 bộ mã hóa, 1 thước đo, chưa chạy cwebp hay avifenc.