Tối ưu hóa ảnh WordPress siêu tốc: Web Vitals và WebP

Cập nhật lần cuối: June 28, 2026

Đây là tài liệu đi kèm tập trung vào tốc độ cho hướng dẫn tối ưu hóa hình ảnh WordPress của tôi năm 2026 . Hướng dẫn đó bao gồm thiết lập tổng thể: các plugin, srcset, CDN và htaccess. Tài liệu này thu hẹp lại thành một câu hỏi duy nhất: làm thế nào để hình ảnh WordPress đủ nhanh để đưa Core Web Vitals về màu xanh? Tôi đã đo lường từng bước trên blog nặng hình ảnh của riêng mình, và những cải tiến dưới đây là những gì thực sự giúp Largest Contentful Paint giảm từ 3.8s xuống còn 1.1s.

Câu trả lời nhanh: điều gì làm cho hình ảnh WordPress nhanh?

Nén mỗi hình ảnh sang WebP trước khi tải lên, giới hạn chiều rộng hiển thị để trình duyệt không bao giờ tải xuống tệp 4000px cho một vị trí chỉ cần 400px, lazy-load mọi thứ nằm dưới phần nhìn thấy (below the fold), và đặt một CDN ở phía trước /wp-content/uploads/. Trên blog của tôi, bốn bước này đã cắt giảm tổng trọng lượng hình ảnh đi 84 percent và giảm LCP di động từ 3.8s xuống 1.1s. Largest Contentful Paint trên một blog WordPress hầu như luôn là do hình ảnh gây ra, vì vậy đây là nơi tốc độ được quyết định.

Tại sao hình ảnh WordPress lại chi phối Core Web Vitals của bạn?

Core Web Vitals đánh giá tốc độ cảm nhận, và chỉ số thường xuyên thất bại nhất trên WordPress là Largest Contentful Paint, vốn đối với một trang nội dung thường là hình ảnh hero hoặc hình ảnh inline đầu tiên. Tôi đã chạy PageSpeed Insights trên 40 bài viết của mình và phần tử LCP là hình ảnh trong 37 trường hợp.

Hình ảnh cũng gián tiếp thúc đẩy các chỉ số khác:

• Một hero 4MB làm chặn LCP cho đến khi nó tải xong trên mạng Slow 4G.
• Layout shift tăng đột biến khi hình ảnh xuất hiện mà không có chiều rộng và chiều cao.
• INP bị ảnh hưởng khi một hàng đợi hình ảnh khổng lồ làm cạn kiệt luồng chính trong quá trình phân tích cú pháp (parse).

Google đo lường những chỉ số này từ người dùng Chrome thực tế và tổng hợp chúng thành tín hiệu xếp hạng tìm kiếm, được ghi lại trong hướng dẫn tải nhanh web.dev. Giải pháp hiếm khi nằm ở máy chủ. Nó hầu như luôn nằm ở hình ảnh.

Bạn có thể cắt giảm trọng lượng hình ảnh bao nhiêu?

Tôi đã ghi lại các con số về một blog trước và sau khi tối ưu hóa. Bài viết, nội dung vẫn giữ nguyên, chỉ thay đổi hình ảnh.

Sự giảm từ 9.4MB xuống 1.1MB không phải là trường hợp đặc biệt. Đó là điều xảy ra khi bạn ngừng gửi các tệp JPEG chưa nén ở độ phân giải gốc. Đòn bẩy lớn nhất là định dạng và kích thước, mà hướng dẫn tối ưu hóa hình ảnh cho tốc độ web đã chia nhỏ theo từng chỉ số.

LCP là gì và tại sao nó hầu như luôn là một hình ảnh?

Largest Contentful Paint đánh dấu khoảnh khắc phần tử hiển thị lớn nhất được kết xuất (renders). Trên một blog WordPress, phần tử đó là một ảnh hero, một featured image, hoặc hình ảnh inline lớn đầu tiên — chứ không phải văn bản. Cho đến khi hình ảnh đó được tải xuống, giải mã và vẽ lên, trang sẽ đọc là "vẫn đang tải" đối với người dùng và Google.

Có ba điều làm kéo dài LCP của hình ảnh, và tôi kiểm tra cả ba trên mọi lần kiểm tra:

• Tệp quá lớn so với viewport mà nó chiếm.
• Hình ảnh LCP bị lazy-load nhầm, khiến nó bắt đầu muộn.
• Không có CDN, vì vậy tệp phải đi từ một nguồn gốc duy nhất ở phía bên kia của thế giới.

Hai điều cuối là những lỗi cấu hình bạn có thể khắc phục trong vài phút. Điều đầu tiên là thói quen tải lên, được đề cập trong hướng dẫn kích thước tệp hình ảnh.

Định dạng hình ảnh nào nhanh nhất cho WordPress?

WebP. Nó nhỏ hơn JPEG từ 25 đến 35 percent ở chất lượng cảm nhận bằng nhau, và core của WordPress đã hỗ trợ tải lên nó kể từ phiên bản 6.5. AVIF nén thêm 20 đến 30 percent nữa, nhưng hỗ trợ trình duyệt và CDN vẫn chưa đồng đều, vì vậy tôi coi nó là một lớp nâng cao hơn là nền tảng cơ bản.

Tôi nén sang WebP trước khi tải lên và để CDN thương lượng AVIF đến các trình duyệt hỗ trợ nó. Để tìm hiểu sâu hơn về sự đánh đổi định dạng, so sánh JPG PNG WebP là tài liệu tham khảo tôi gửi cho mọi người.

Làm thế nào để bạn cung cấp kích thước hình ảnh phù hợp cho từng thiết bị?

Đây là điểm mà nhiều người bỏ qua. WordPress tự động tạo các kích thước thumbnail, medium, large và intermediate và xuất ra một srcset, nhưng chỉ khi theme của bạn gọi wp_get_attachment_image() thay vì mã hóa cứng thẻ <img>. Điện thoại không bao giờ được tải xuống tệp 2560px.

Cú pháp mà WordPress xuất ra trông như thế này:

<img
  src="hero-1536x800.webp"
  srcset="hero-768x400.webp 768w,
          hero-1200x628.webp 1200w,
          hero-1536x800.webp 1536w"
  sizes="(max-width: 768px) 100vw, 1200px"
  width="1536" height="800"
  alt="Ảnh hero Storefront ở chiều rộng đầy đủ">

Cách tôi xác minh nó hoạt động: mở DevTools, giới hạn tốc độ về Slow 4G, tải lại và theo dõi tab Network. Điện thoại nên yêu cầu tệp 768w. Nếu mọi thiết bị đều kéo cùng một URL, thì theme đã bị lỗi hoặc trình xây dựng trang (page builder) đang bỏ qua markup responsive. Logic breakpoint nằm trong hướng dẫn responsive image breakpoints.

Làm thế nào để bạn bật lazy loading trong WordPress?

Kể từ WordPress 5.5, mọi <img> đều có loading="lazy" theo mặc định, và 6.1 đã thêm gợi ý fetchpriority="high" cho hình ảnh lớn đầu tiên để nó không còn bị đối kháng với lazy loader nữa. Bạn hiếm khi cần plugin nào cho việc này nữa, đây là một chiến thắng tốc độ thực sự mà không cần cấu hình gì cả.

Hai quy tắc tôi luôn tuân thủ, vì cả hai đều khiến LCP của tôi gặp vấn đề trước khi tôi phát hiện ra:

• Không bao giờ lazy-load hình ảnh LCP nằm trên phần nhìn thấy (above the fold).
• Luôn đặt chiều rộng và chiều cao rõ ràng để ngăn chặn layout shift.

[Tài liệu lazy-loading WordPress] chính thức liệt kê các bộ lọc để loại trừ phần tử LCP và lazy-load iframe. Đối với những cạm bẫy phổ biến, bao gồm cả lỗi hero, hãy đọc bài viết [lazy load images] của chúng tôi .

CDN tăng tốc hình ảnh WordPress như thế nào?

Một CDN phục vụ mỗi hình ảnh từ edge gần người truy cập nhất và loại bỏ các vòng đi khứ hồi (round-trips) đến nguồn gốc của bạn. Sau khi tôi chuyển một khách hàng khỏi JPEG lưu trữ tại nguồn gốc sang Cloudflare với Polish được bật, TTFB của hình ảnh đã giảm từ 420ms xuống còn 60ms đối với người dùng ở Singapore và Brazil — hai khu vực mà báo cáo PageSpeed của họ là màu đỏ.

Những gì tôi cấu hình trên mọi trang:

• Cloudflare với Polish bật, lossless cộng WebP.
• Cache mọi thứ trong /wp-content/uploads/.
• Bộ nhớ cache trình duyệt một năm cho các kiểu MIME hình ảnh.
• Một lớp AVIF được thương lượng bởi CDN nằm trên WebP.

Caching ở biên (Edge caching) quan trọng nhất đối với các cửa hàng WooCommerce nặng hình ảnh và blog đa tác giả. Thiết lập đầy đủ, bao gồm cả cache headers và purge rules, có trong hướng dẫn CDN hình ảnh.

Điểm mấu chốt: bộ xếp tốc độ bốn bước

Nếu bạn không nhớ bất cứ điều gì khác, hãy nhớ bốn điều này, vì chúng chịu trách nhiệm cho sự giảm LCP mà tôi đã đo lường:

1. Nén sang WebP trước khi tải lên, dưới 200KB mỗi hình ảnh.
2. Giới hạn chiều rộng hiển thị và để srcset phục vụ tệp phù hợp.
3. Lazy-load bên dưới phần nhìn thấy, không bao giờ là hình ảnh LCP.
4. Cache hình ảnh tại edge của CDN với TTL một năm.

Làm những điều này và báo cáo Core Web Vitals của bạn sẽ chuyển sang màu xanh. Bỏ qua bước srcset responsive và ngay cả WebP được nén hoàn hảo vẫn sẽ gửi tệp dành cho máy tính để bàn đến điện thoại.

Danh sách kiểm tra tốc độ trước khi xuất bản

• Hình ảnh LCP là WebP và dưới 200KB.
• Hình ảnh LCP có fetchpriority="high", không phải loading="lazy".
• srcset hiện diện và điện thoại tải tệp nhỏ.
• Mọi hình ảnh đều có chiều rộng và chiều cao rõ ràng.
• Một CDN cache /wp-content/uploads/.
• Bộ nhớ cache trình duyệt cho hình ảnh được đặt là một năm.
• LCP di động dưới 2.5s trong PageSpeed.
• CLS dưới 0.1 mà không có sự dịch chuyển do hình ảnh gây ra.

Một lưu ý thực tế: WebP lossy ở chất lượng dưới 70 cuối cùng sẽ ảnh hưởng đến bạn đối với nhiếp ảnh sản phẩm và màn hình retina, nơi kết cấu và chi tiết cạnh là thứ bán được sản phẩm. Tôi giữ lại mọi bản gốc trong bộ nhớ đám mây và xuất lại từ đó, bởi vì một khi bạn ghi đè nguồn bằng bản sao lossy, chi tiết sẽ mất vĩnh viễn. Hãy thử nghiệm trên năm hình ảnh thực trước khi chuyển đổi hàng nghìn tệp hàng loạt.

Hình ảnh tín dụng

• Không gian làm việc sáng với máy tính để bàn dùng để quản lý trang web WordPress — photo by SHVETS Production trên Pexels
• Văn phòng tại nhà ấm cúng với laptop mở trên bài đăng blog WordPress — photo by Pixabay trên Pexels
• MacBook hiển thị trang tìm kiếm Google trên bàn gỗ ngoài trời — photo by Pixabay trên Pexels
• Lập trình viên đang code trên laptop và màn hình trong văn phòng hiện đại — photo by Claudio Emanuel trên Pexels