WebP là gì? Ưu nhược điểm và khi nào nên dùng【2026】

Lighthouse báo Serve images in next-gen formats. Designer gửi PNG 4MB từ Figma. Dev hỏi: WebP là gì, có nên đổi hết không? — và team bật “Convert to WebP” hàng loạt với quality mặc định.

Kết quả hay gặp ở landing SME / agency VN: LCP tốt hơn vài trăm ms, nhưng chữ trên screenshot mềm, hoặc CMS không nhận .webp khiến ảnh trống. Bài này giải thích WebP format là gì, ưu / nhược điểm thật, và khi nào dùng / khi nào giữ JPEG·PNG — không phải bài so sánh AVIF (xem AVIF vs WebP nếu cần chọn giữa hai next-gen).

Bài viết này giúp bạn

• Hiểu WebP là gì (lossy, lossless, alpha, animation)
• Đọc rõ ưu điểm và nhược điểm theo ngữ cảnh production
• Chọn lossy vs lossless + mức quality theo loại asset
• Viết <picture> fallback đúng khi audience cần
• Case study freelance VN + checklist trước merge

---

WebP là gì?

WebP là định dạng ảnh do Google giới thiệu, dùng codec VP8 (lossy) và VP8L (lossless). Mục tiêu: nhẹ hơn JPEG/PNG trên web mà vẫn giữ chất lượng cảm nhận chấp nhận được.

Khả năng	WebP	JPEG	PNG
Lossy (nén mất mát)	Có	Có	Không (thực tế)
Lossless	Có	Không	Có
Transparency (alpha)	Có	Không	Có
Animation	Có	Không	APNG (hạn chế)
Mục tiêu chính	Web	Ảnh / camera	Đồ họa / alpha

Không nhầm: WebP không thay RAW cho nhiếp ảnh, không thay CMYK cho in ấn, và không tự động “đẹp hơn” nếu bạn resize sai hoặc quality quá thấp.

Lossy vs lossless (điểm hay chọn sai)

• Lossy: bỏ thông tin khó thấy → dung lượng giảm mạnh. Hợp ảnh chụp, banner photo. Quality phổ biến 75–85.
• Lossless: giữ pixel → dung lượng giảm vừa phải. Hợp logo phẳng, icon, screenshot UI, chữ sắc.

Nhiều tool (kể cả browser canvas.toBlob('image/webp')) mặc định lossy. Đưa PNG chữ UI vào lossy quality 70 = “WebP làm hỏng ảnh” — thực ra là sai chế độ nén.

---

Ưu điểm của WebP

1. Dung lượng nhỏ hơn trên nhiều ảnh web

Với ảnh chụp cùng mức cảm nhận, WebP thường nhẹ hơn JPEG khoảng 25–35% (con số phụ thuộc nội dung — luôn đo trên asset thật). PNG có alpha lớn (banner, mockup) chuyển WebP lossy/lossless thường giảm mạnh hơn JPEG đơn thuần vì JPEG không có alpha.

Ít byte hơn → tải nhanh hơn trên 4G Việt Nam, giảm chi phí CDN, và thường cải thiện LCP nếu ảnh hero là phần tử lớn nhất.

2. Một format thay cả JPEG lẫn PNG (trong nhiều case)

Trước đây: photo → JPEG, logo/alpha → PNG, gif ngắn → GIF. WebP gói lossy + lossless + alpha + animation trong một đuôi .webp. Pipeline frontend đơn giản hơn nếu CMS/CDN hỗ trợ.

3. Hỗ trợ trình duyệt năm 2026 đã rộng

Chrome, Edge, Firefox, Safari (từ bản hỗ trợ WebP) cover gần như toàn bộ traffic consumer. Với site B2C / landing hiện đại, WebP-first là hợp lý. Niche còn lại (WebView cũ, một số email client) xử lý bằng fallback.

4. Encode nhanh hơn AVIF trong nhiều toolchain

So với AVIF, encode WebP thường nhanh hơn và dễ làm trong trình duyệt / CI nhẹ. Phù hợp freelancer cần A/B quality trong 5 phút mà không dựng libavif.

---

Nhược điểm của WebP (đừng bỏ qua)

1. Lossy dễ làm mềm chữ và cạnh UI

Ảnh chụp che được artifact; glyph và line 1px thì không. Screenshot Figma, bảng giá, QR trên banner — nếu dùng lossy thấp sẽ “mờ như bị zoom”. Đây là lý do designer phản đối WebP, không phải vì format “xấu”.

Cách xử lý: lossless, hoặc lossy 90–95, hoặc giữ PNG cho lớp chữ.

2. Không phải mọi hệ thống nhận .webp

Một số CMS cũ, plugin WordPress lỗi thời, email HTML, hoặc app WebView nội bộ không decode WebP. Upload xong “ảnh biến mất” trên staging khách hàng. Luôn kiểm tra môi trường deploy thật, không chỉ Chrome local.

3. Tooling và thói quen vẫn lệch về JPEG/PNG

Máy ảnh, Zalo/Telegram compress, Canva export — hay ra JPEG/PNG. Team design gửi PSD/PNG; CI phải thêm bước convert. Chi phí quy trình (không chỉ chi phí byte) là nhược điểm thực tế với agency nhỏ.

4. Không phải lúc nào cũng thắng PNG nhỏ hoặc SVG

Icon 24×24 đã tối ưu, hoặc logo vector → SVG vẫn tốt hơn. Chuyển icon sang WebP lossy có thể lớn hơn và xấu hơn. WebP không phải câu trả lời cho mọi “ảnh”.

5. Metadata / màu có thể lệch sau convert

Một số converter bỏ color profile → màu “xỉn” so với Figma. Nếu brand màu khắt khe, so sánh side-by-side trên màn hình đã calibrate và giữ pipeline có kiểm soát profile (sRGB).

---

Bảng quyết định: dùng WebP khi nào?

---

Ví dụ số liệu (minh họa tư duy đo)

Giả sử hero hiển thị 1280px rộng (không ship file 4000px):

File	Format	Size (ví dụ)	Ghi chú
hero-src.jpg	JPEG Q85	~280 KB	Baseline
hero.webp	WebP Q80	~190 KB	Thường chấp nhận được
hero.webp	WebP Q95	~260 KB	Ít lợi hơn JPEG
ui-shot.png	PNG	~520 KB	Chữ sắc
ui-shot.webp	WebP lossy Q70	~90 KB	Chữ mềm — fail
ui-shot.webp	WebP lossless	~310 KB	Chữ ổn, vẫn nhẹ hơn PNG gốc

Số tuyệt đối thay đổi theo ảnh — cột quan trọng là quy trình so sánh, không phải tin benchmark blog.

---

Cách nhúng WebP an toàn: <picture>

<picture>
  <source srcset="/images/hero.webp" type="image/webp" />
  <img
    src="/images/hero.jpg"
    width="1280"
    height="720"
    alt="Hero sản phẩm"
    loading="eager"
    fetchpriority="high"
  />
</picture>

• Browser hỗ trợ WebP → lấy <source>.
• Không hỗ trợ → <img> JPEG/PNG.
• Luôn set width/height (hoặc CSS aspect-ratio) để giảm CLS.

Responsive: thêm srcset/sizes cho nhiều width; đừng chỉ đổi đuôi file mà quên resize theo viewport mobile.

---

Case study ngắn: freelance tối ưu landing khách

Bối cảnh: Landing bán khóa học, host trên VPS nhỏ, ảnh hero PNG export từ Canva (~1.8MB), Lighthouse mobile LCP ~4.2s.

Việc làm:

1. Resize hero xuống max width 1600px (hiển thị thực ~1200).
2. A/B JPEG Q85 vs WebP Q80 trên Nén ảnh Kawa — chạy local, không upload mockup chưa public.
3. Chọn WebP Q80 (~210KB) + JPEG fallback.
4. Screenshot bảng học phí giữ PNG (hoặc WebP lossless) vì chữ nhỏ.

Kết quả điển hình: LCP xuống dưới ~2.5s trên 4G throttled; khách không phàn nàn “ảnh mờ” vì UI text không bị lossy mạnh. Thời gian làm ~20 phút — không cần AVIF ngay.

---

Checklist trước khi “đổi hết sang WebP”

1. Asset đã đúng kích thước hiển thị chưa? (WebP không cứu file 5000px)
2. Photo → lossy ~80; UI chữ → lossless / Q90+
3. Có fallback nếu audience/CMS nghi ngờ?
4. So cạnh chữ ở 100% zoom, không chỉ thumbnail
5. Hero có fetchpriority / không lazy sai chỗ?
6. Convention team: class asset → format mặc định (tránh mỗi PR một kiểu)

---

Dùng thử trên trình duyệt (không cần đăng ký)

1. Mở Nén ảnh & WebP
2. Thả JPEG/PNG mẫu (che PII nếu cần)
3. Chọn output WebP, kéo quality, xem trước/sau
4. Thử mục tiêu KB nếu khách giới hạn dung lượng upload CMS
5. Tải về và gắn vào <picture> hoặc build step

Tool xử lý trong trình duyệt — phù hợp ảnh nội bộ hơn dịch vụ upload server lạ. Không xuất AVIF; nếu cần AVIF xem pipeline CLI và bài AVIF vs WebP.

---

Câu hỏi thường gặp

WebP có thay được mọi JPEG trên site không?
Hầu hết ảnh chụp web — có, kèm đo chất lượng. Ảnh đã tối ưu sẵn hoặc audience đặc biệt — không bắt buộc.

WebP có virus / kém an toàn hơn không?
Không liên quan format. Rủi ro nằm ở chỗ bạn upload ảnh đi đâu. Ưu tiên xử lý local.

Safari còn không hỗ trợ WebP?
Đó là thông tin cũ. Safari đã hỗ trợ từ lâu; năm 2026 vấn đề thực tế hơn là CMS/email/WebView chứ không phải “Safari desktop không đọc được”.

Nên quality bao nhiêu?
Bắt đầu 80 cho photo; nếu artifact → tăng dần hoặc lossless cho UI. Tránh tin “luôn 100” — thường phình file gần JPEG mà ít lợi LCP.

---

Liên kết liên quan

• Nén ảnh WebP / JPEG (tool)
• AVIF vs WebP — khi nào chọn
• Danh sách công cụ