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

WebP là gì? Tại sao tôi nên sử dụng quảng cáo này?

WebP là phương pháp nén có tổn hao và không tổn hao có thể dùng cho nhiều loại hình ảnh, hình ảnh trong suốt và đồ hoạ trên web. Bạn có thể điều chỉnh mức độ nén có tổn hao để chọn giữa kích thước tệp và chất lượng hình ảnh. WebP thường có khả năng nén trung bình nhiều hơn 30% so với JPEG và JPEG 2000 mà không làm giảm chất lượng hình ảnh (xem Nghiên cứu so sánh).

Về cơ bản, định dạng WebP hướng đến việc tạo các hình ảnh nhỏ hơn, đẹp hơn có thể giúp web nhanh hơn.

Những trình duyệt web nào hỗ trợ sẵn định dạng WebP?

Các quản trị viên trang web quan tâm đến việc cải thiện hiệu suất của trang web có thể dễ dàng tạo các phương án thay thế WebP tối ưu hoá cho hình ảnh hiện tại và phân phát các giải pháp đó trên cơ sở được nhắm mục tiêu cho các trình duyệt hỗ trợ WebP.

  • Hỗ trợ tệp WebP có tổn hao
    • Google Chrome (máy tính) 17 tuổi trở lên
    • Google Chrome dành cho Android phiên bản 25 trở lên
    • Microsoft Edge 18 trở lên
    • Firefox 65 trở lên
    • Opera 11.10 trở lên
    • Trình duyệt web gốc, Android 4.0 trở lên (ICS)
    • Safari 14 trở lên (iOS 14 trở lên), macOS Big Sur trở lên
  • Hỗ trợ WebP có tổn hao, không tổn hao và alpha
    • Google Chrome (máy tính) 23 trở lên
    • Google Chrome dành cho Android phiên bản 25 trở lên
    • Microsoft Edge 18 trở lên
    • Firefox 65 trở lên
    • Opera 12.10 trở lên
    • Trình duyệt web gốc, Android 4.2 trở lên (JB-MR1)
    • Mặt trăng nhạt từ 26 tuổi trở lên
    • Safari 14 trở lên (iOS 14 trở lên), macOS Big Sur trở lên
  • Hỗ trợ Ảnh động WebP
    • Google Chrome (máy tính và Android) 32 tuổi trở lên
    • Microsoft Edge 18 trở lên
    • Firefox 65 trở lên
    • Opera 19 trở lên
    • Safari 14 trở lên (iOS 14 trở lên), macOS Big Sur trở lên

Xem thêm:

Làm cách nào để phát hiện trình duyệt có hỗ trợ WebP?

Bạn chỉ nên phân phát hình ảnh WebP cho những ứng dụng có thể hiển thị đúng cách hình ảnh đó và quay lại sử dụng các định dạng cũ cho những ứng dụng không thể. May mắn là có một số kỹ thuật giúp phát hiện tính năng hỗ trợ WebP, cả ở phía máy khách và phía máy chủ. Một số nhà cung cấp CDN cung cấp tính năng phát hiện hỗ trợ WebP trong dịch vụ của họ.

Thương lượng nội dung phía máy chủ thông qua tiêu đề Chấp nhận

Các ứng dụng web thường gửi tiêu đề của yêu cầu "Accept" (Chấp nhận), cho biết những định dạng nội dung mà họ sẵn sàng chấp nhận khi phản hồi. Nếu trình duyệt cho biết trước rằng trình duyệt sẽ "chấp nhận" định dạng image/webp, thì máy chủ web sẽ biết rằng trình duyệt có thể gửi hình ảnh WebP một cách an toàn, giúp đơn giản hoá quá trình thương lượng nội dung. Xem các đường liên kết sau để biết thêm thông tin.

Hiện đại hoá

Advancedizr là thư viện JavaScript để thuận tiện phát hiện việc hỗ trợ tính năng HTML5 và CSS3 trong các trình duyệt web một cách thuận tiện. Tìm các thuộc tính Modernizr.webp, Modernizr.webp, Modernizr.webp và Modernizr.webp.

Phần tử HTML5 <picture>

HTML5 hỗ trợ phần tử <picture>, cho phép bạn liệt kê nhiều mục tiêu hình ảnh thay thế theo thứ tự ưu tiên để ứng dụng khách sẽ yêu cầu hình ảnh đề xuất đầu tiên mà ứng dụng có thể hiển thị đúng cách. Xem cuộc thảo luận này trên HTML5 Rocks. Phần tử <picture> luôn được nhiều trình duyệt hỗ trợ.

Trong JavaScript của riêng bạn

Một phương pháp phát hiện khác là cố gắng giải mã một hình ảnh WebP rất nhỏ sử dụng một tính năng cụ thể và kiểm tra xem có thành công hay không. Ví dụ:

// check_webp_feature:
//   'feature' can be one of 'lossy', 'lossless', 'alpha' or 'animation'.
//   'callback(feature, result)' will be passed back the detection result (in an asynchronous way!)
function check_webp_feature(feature, callback) {
    var kTestImages = {
        lossy: "UklGRiIAAABXRUJQVlA4IBYAAAAwAQCdASoBAAEADsD+JaQAA3AAAAAA",
        lossless: "UklGRhoAAABXRUJQVlA4TA0AAAAvAAAAEAcQERGIiP4HAA==",
        alpha: "UklGRkoAAABXRUJQVlA4WAoAAAAQAAAAAAAAAAAAQUxQSAwAAAARBxAR/Q9ERP8DAABWUDggGAAAABQBAJ0BKgEAAQAAAP4AAA3AAP7mtQAAAA==",
        animation: "UklGRlIAAABXRUJQVlA4WAoAAAASAAAAAAAAAAAAQU5JTQYAAAD/////AABBTk1GJgAAAAAAAAAAAAAAAAAAAGQAAABWUDhMDQAAAC8AAAAQBxAREYiI/gcA"
    };
    var img = new Image();
    img.onload = function () {
        var result = (img.width > 0) && (img.height > 0);
        callback(feature, result);
    };
    img.onerror = function () {
        callback(feature, false);
    };
    img.src = "data:image/webp;base64," + kTestImages[feature];
}

Lưu ý rằng tải hình ảnh là không chặn và không đồng bộ. Điều này có nghĩa là tốt nhất bạn nên đặt bất kỳ mã nào phụ thuộc vào khả năng hỗ trợ WebP vào hàm callback.

Tại sao Google phát hành WebP dưới dạng nguồn mở?

Chúng tôi tin tưởng sâu sắc vào tầm quan trọng của mô hình nguồn mở. Với WebP ở nguồn mở, bất cứ ai cũng có thể làm việc với định dạng này và đề xuất cách cải thiện. Với thông tin và đề xuất của bạn, chúng tôi tin rằng WebP sẽ trở nên hữu ích hơn nữa trong vai trò định dạng đồ hoạ theo thời gian.

Làm cách nào để chuyển đổi tệp hình ảnh cá nhân sang WebP?

Bạn có thể sử dụng tiện ích dòng lệnh WebP để chuyển đổi tệp hình ảnh cá nhân sang định dạng WebP. Hãy xem bài viết Sử dụng WebP để biết thêm chi tiết.

Nếu có nhiều hình ảnh cần chuyển đổi, bạn có thể sử dụng shell của nền tảng để đơn giản hoá thao tác. Ví dụ: để chuyển đổi tất cả các tệp jpeg trong một thư mục, hãy thử các cách sau:

Windows:

> for /R . %I in (*.jpg) do ( cwebp.exe %I -o %~fnI.webp )

Linux / macOS:

$ for F in *.jpg; do cwebp $F -o `basename ${F%.jpg}`.webp; done

Làm cách nào để tự đánh giá chất lượng hình ảnh WebP?

Hiện tại, bạn có thể xem các tệp WebP bằng cách chuyển đổi các tệp đó thành một định dạng phổ biến sử dụng tính năng nén không tổn hao, chẳng hạn như PNG, rồi xem các tệp PNG trong bất kỳ trình duyệt hoặc trình xem hình ảnh nào. Để biết nhanh về chất lượng WebP, hãy xem Thư viện trên trang web này để so sánh ảnh song song.

Làm cách nào để lấy mã nguồn?

Mã chuyển đổi có trên phần tải xuống của trang dự án nguồn mở WebP. Mã cho bộ giải mã hạng nhẹ và thông số kỹ thuật của VP8 có trên trang web WebM. Xem trang Vùng chứa RIFF để biết thông số kỹ thuật của vùng chứa.

Kích thước tối đa của hình ảnh WebP có thể là bao nhiêu?

WebP tương thích với luồng bit với VP8 và sử dụng 14 bit cho chiều rộng và chiều cao. Kích thước pixel tối đa của hình ảnh WebP là 16383 x 16383.

Định dạng WebP hỗ trợ không gian màu nào?

Để phù hợp với luồng bit VP8, WebP lỗ chỉ hoạt động với định dạng hình ảnh Y'CbCr 4:2:0 (thường được gọi là YUV420) 8 bit. Vui lòng tham khảo Mục 2, "Tổng quan về định dạng" của RFC 6386, Hướng dẫn giải mã và định dạng dữ liệu VP8 để biết thêm chi tiết.

WebP không suy hao chỉ hoạt động với định dạng RGBA. Vui lòng xem Thông số kỹ thuật về luồng Bit không mất dữ liệu WebP.

Hình ảnh WebP có thể lớn hơn hình ảnh nguồn không?

Có, thường là khi chuyển đổi từ định dạng có tổn hao sang định dạng WebP không tổn hao hoặc ngược lại. Điều này chủ yếu là do sự khác biệt về không gian màu (YUV420 so với ARGB) và việc chuyển đổi giữa các màu này.

Có 3 tình huống điển hình:

  1. Nếu hình ảnh nguồn ở định dạng ARGB không tổn hao, thì việc giảm tần số lấy mẫu không gian xuống YUV420 sẽ tạo ra các màu mới khó nén hơn so với màu gốc. Trường hợp này thường có thể xảy ra khi nguồn ở định dạng PNG với ít màu sắc: việc chuyển đổi sang WebP có tổn hao (hoặc tương tự như tệp JPEG có tổn hao) sẽ khiến kích thước tệp lớn hơn.
  2. Nếu nguồn ở định dạng có tổn hao, thì việc sử dụng tính năng nén WebP không tổn hao để ghi lại bản chất có tổn hao của nguồn thường sẽ dẫn đến kích thước tệp lớn hơn. Ví dụ: điều này không chỉ áp dụng với WebP và có thể xảy ra khi chuyển đổi một nguồn JPEG sang định dạng WebP hoặc PNG không tổn hao.
  3. Nếu nguồn ở định dạng có tổn hao và bạn đang cố nén dưới dạng WebP suy hao với chế độ cài đặt chất lượng cao hơn. Ví dụ: việc cố gắng chuyển đổi tệp JPEG lưu ở chất lượng 80 thành tệp WebP có chất lượng 95 thường sẽ dẫn đến kết quả là tệp lớn hơn, ngay cả khi cả hai định dạng đều bị tổn hao. Thường thì bạn không thể đánh giá chất lượng của nguồn. Vì vậy, bạn nên giảm chất lượng WebP mục tiêu nếu kích thước tệp luôn lớn hơn. Một khả năng khác là tránh sử dụng chế độ cài đặt chất lượng mà thay vào đó là nhắm đến một kích thước tệp nhất định bằng cách sử dụng tuỳ chọn -size trong công cụ cwebp hoặc API tương đương. Ví dụ: việc nhắm mục tiêu 80% kích thước tệp gốc có thể chứng minh tính hiệu quả hơn.

Lưu ý rằng việc chuyển đổi một nguồn JPEG thành WebP có tổn hao hoặc một nguồn PNG thành WebP không suy hao, kích thước tệp sẽ không như vậy.

WebP có hỗ trợ hiển thị liên tục hay xen kẽ không?

WebP không cung cấp tính năng làm mới giải mã tăng dần hoặc xen kẽ theo định dạng JPEG hoặc PNG. Điều này có thể tạo ra quá nhiều áp lực lên CPU và bộ nhớ của ứng dụng giải mã vì mỗi sự kiện làm mới đều liên quan đến việc truyền đầy đủ hệ thống giải nén.

Trung bình, việc giải mã một hình ảnh JPEG tăng dần tương đương với việc giải mã đường cơ sở 3 lần.

Ngoài ra, WebP cung cấp tính năng giải mã tăng dần, trong đó tất cả byte đến của luồng bit có sẵn sẽ được dùng để cố gắng tạo ra một hàng mẫu có thể hiển thị sớm nhất có thể. Điều này vừa giúp tiết kiệm bộ nhớ, CPU và công sức vẽ lại trên ứng dụng vừa cung cấp chỉ dẫn bằng hình ảnh về trạng thái tải xuống. Tính năng giải mã gia tăng được cung cấp thông qua API Giải mã nâng cao.

Làm cách nào để sử dụng các liên kết Java libwebp trong dự án Android của tôi?

WebP hỗ trợ các liên kết JNI với giao diện bộ mã hoá và giải mã đơn giản trong thư mục swig/.

Xây dựng thư viện trong Eclipse:

  1. Hãy nhớ cài đặt trình bổ trợ ADT cùng với các công cụ NDK và thiết lập đường dẫn NDK một cách chính xác (Preferences > Android > NDK).
  2. Tạo một dự án mới: File > New > Project > Android Application Project (Tệp > Mới > Dự án > Dự án ứng dụng Android).
  3. Clone (Sao chép) hoặc giải nén libwebp vào một thư mục có tên jni trong dự án mới.
  4. Thêm swig/libwebp_java_wrap.c vào danh sách LOCAL_SRC_FILES.
  5. Nhấp chuột phải vào dự án mới rồi chọn Android Tools (Công cụ Android) > Add Native Support ... (Thêm tính năng hỗ trợ mã gốc...) để đưa thư viện này vào bản dựng.

  6. Mở thuộc tính của dự án rồi chuyển đến Bản dựng C/C++ > Hành vi. Thêm ENABLE_SHARED=1 vào phần Build (Incremental build) để xây dựng libwebp dưới dạng một thư viện chia sẻ.

    Lưu ý: Nhìn chung, việc đặt NDK_TOOLCHAIN_VERSION=4.8 sẽ cải thiện hiệu suất bản dựng 32 bit.

  7. Thêm swig/libwebp.jar vào thư mục dự án libs/.

  8. Tạo dự án. Thao tác này sẽ tạo libs/<target-arch>/libwebp.so.

  9. Sử dụng System.loadLibrary("webp") để tải thư viện trong thời gian chạy.

Xin lưu ý rằng bạn có thể tạo thư viện theo cách thủ công bằng ndk-build và Android.mk đi kèm. Trong trường hợp đó, bạn có thể sử dụng lại một số bước nêu trên.

Làm cách nào để sử dụng libwebp với C#?

WebP có thể được xây dựng dưới dạng một DLL xuất API libwebp. Sau đó, bạn có thể nhập các hàm này vào C#.

  1. Tạo libwebp.dll. Thao tác này sẽ thiết lập WEBP_EXTERN đúng cách để xuất các hàm API.

    libwebp> nmake /f Makefile.vc CFG=release-dynamic

  2. Thêm libwebp.dll vào dự án của bạn rồi nhập các hàm mong muốn. Lưu ý rằng nếu sử dụng API đơn giản, bạn nên gọi WebPFree() để giải phóng mọi vùng đệm được trả về.

    [DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]
static extern int WebPEncodeBGRA(IntPtr rgba, int width, int height, int stride,
                                 float quality_factor, out IntPtr output);
[DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]
static extern int WebPFree(IntPtr p);

void Encode() {
  Bitmap source = new Bitmap("input.png");
  BitmapData data = source.LockBits(
      new Rectangle(0, 0, source.Width, source.Height),
      ImageLockMode.ReadOnly,
      PixelFormat.Format32bppArgb);
  IntPtr webp_data;
  const int size = WebPEncodeBGRA(data.Scan0,
                                  source.Width, source.Height, data.Stride,
                                  80, out webp_data);
  // ...
  WebPFree(webp_data);
}

Tại sao nên dùng WebP động?

Ưu điểm của WebP động so với GIF động

  1. WebP hỗ trợ màu RGB 24 bit với kênh alpha 8 bit, so với màu 8 bit của GIF và alpha 1 bit.

  2. WebP hỗ trợ cả quá trình nén có tổn hao và không tổn hao; trên thực tế, một ảnh động có thể kết hợp cả khung hình có tổn hao và không tổn hao. GIF chỉ hỗ trợ nén giữ nguyên chất lượng. Các kỹ thuật nén có tổn hao của WebP rất phù hợp với hình ảnh động được tạo từ video trong thế giới thực, một nguồn hình ảnh động ngày càng phổ biến.

  3. WebP yêu cầu ít byte hơn GIF1. Ảnh GIF động được chuyển đổi thành WebP có tổn hao nhỏ hơn 64%, trong khi tệp WebP không tổn hao có dung lượng nhỏ hơn 19%. Điều này đặc biệt quan trọng trên mạng di động.

  4. WebP mất ít thời gian hơn để giải mã khi có chức năng tìm kiếm. Trong mục Nhấp nháy, các thẻ cuộn hoặc thay đổi có thể ẩn và hiện hình ảnh, khiến ảnh động bị tạm dừng rồi bỏ qua tới một điểm khác. Việc sử dụng CPU quá mức, dẫn đến ảnh động giảm khung hình cũng có thể yêu cầu bộ giải mã tìm kiếm tiến trong ảnh động. Trong những trường hợp này, WebP động lấy tổng thời gian giải mã gấp 0,57 lần2 so với GIF, nhờ đó giảm hiện tượng giật trong quá trình cuộn và phục hồi nhanh hơn khỏi mức sử dụng CPU tăng đột biến. Điều này là do WebP có hai ưu điểm so với GIF:

    • Hình ảnh WebP lưu trữ siêu dữ liệu về việc mỗi khung hình có chứa alpha hay không. Do đó, bạn không cần phải giải mã khung hình đó để xác định. Điều này giúp dự đoán chính xác hơn về những khung hình trước đó mà một khung hình cụ thể phụ thuộc vào, từ đó giảm hoạt động giải mã không cần thiết cho các khung trước đó.

    • Cũng giống như một bộ mã hoá video hiện đại, bộ mã hoá WebP sẽ thêm các khung hình chính theo cách phỏng đoán (theo phương pháp phỏng đoán của các bộ mã hoá GIF) định kỳ (hầu hết các bộ mã hoá GIF không làm như vậy). Điều này giúp cải thiện đáng kể khả năng tìm kiếm trong ảnh động dài. Để tạo điều kiện chèn các khung như vậy mà không cần tăng đáng kể kích thước hình ảnh, WebP thêm một cờ "phương thức kết hợp" cho mỗi khung hình ngoài phương thức loại bỏ khung mà GIF sử dụng. Điều này cho phép khung hình chính vẽ như thể toàn bộ hình ảnh đã bị xoá thành màu nền mà không buộc khung trước đó phải có kích thước đầy đủ.

Nhược điểm của WebP động so với GIF động

  1. Trong trường hợp không tìm kiếm, phương thức giải mã đường thẳng của WebP sẽ tốn nhiều CPU hơn GIF. WebP suy hao cần thời gian giải mã nhiều gấp 2,2 lần so với GIF, trong khi WebP không suy hao cần 1,5 lần.

  2. Hình thức hỗ trợ WebP gần như không phổ biến rộng rãi như hỗ trợ GIF, nhưng hình thức hỗ trợ này khá phổ biến.

  3. Việc thêm tính năng hỗ trợ WebP cho các trình duyệt sẽ làm tăng mức sử dụng mã và bề mặt tấn công. Trong Blink, có thêm khoảng 1.500 dòng mã bổ sung (bao gồm cả thư viện WebP demux và bộ giải mã hình ảnh WebP phía Blink). Xin lưu ý rằng vấn đề này có thể giảm được trong tương lai nếu WebP và WebM dùng chung mã giải mã phổ biến hơn hoặc nếu các chức năng của WebP được gộp trong WebM.

Tại sao không chỉ hỗ trợ WebM trong <img>?

Việc hỗ trợ các định dạng video bên trong thẻ <img> về lâu dài có thể là hợp lý. Tuy nhiên, việc làm như vậy ngay bây giờ, với ý định rằng WebM trong <img> có thể thực hiện vai trò đề xuất của WebP động, sẽ gặp sự cố:

  1. Khi giải mã một khung dựa trên các khung trước, WebM yêu cầu nhiều bộ nhớ hơn 50% so với WebP động để lưu giữ số lượng khung tối thiểu trước đó3.

  2. Khả năng hỗ trợ vùng chứa và bộ mã hoá và giải mã video rất khác nhau trên các trình duyệt và thiết bị. Để tạo điều kiện chuyển mã nội dung tự động (ví dụ: cho các proxy tiết kiệm băng thông), các trình duyệt sẽ cần thêm tiêu đề chấp nhận cho biết những định dạng mà thẻ hình ảnh của họ hỗ trợ. Ngay cả khi điều này cũng có thể là không đủ, vì các loại MIME như "video/webm" hoặc "video/mpeg" vẫn không chỉ ra việc hỗ trợ bộ mã hoá và giải mã (ví dụ: VP8 so với VP9). Mặt khác, định dạng WebP bị đóng băng một cách hiệu quả và nếu các nhà cung cấp vận chuyển định dạng này đồng ý vận chuyển WebP động, thì hành vi của WebP trên tất cả các UA phải nhất quán; và vì tiêu đề chấp nhận "image/webp" đã được dùng để cho biết khả năng hỗ trợ WebP, nên bạn không cần thay đổi tiêu đề chấp nhận mới nào.

  3. Ngăn xếp video Chromium được tối ưu hoá để phát mượt mà và giả định rằng mỗi lần chỉ có một hoặc hai video phát cùng một lúc. Do đó, phương thức triển khai sẽ được ưu tiên hơn trong việc tiêu thụ tài nguyên hệ thống (luồng, bộ nhớ, v.v.) nhằm tối đa hoá chất lượng phát. Cách triển khai như vậy sẽ không hiệu quả cho nhiều video phát cùng lúc, và cần được thiết kế lại cho phù hợp với các trang web có nhiều hình ảnh.

  4. WebM hiện chưa kết hợp tất cả các kỹ thuật nén từ WebP. Do đó, hình ảnh này nén tốt hơn đáng kể bằng WebP so với các giải pháp thay thế:

1 Để so sánh giữa GIF động và WebP động, chúng tôi đã sử dụng một kho dữ liệu gồm khoảng 7.000 hình ảnh GIF động được lấy ngẫu nhiên trên web. Những hình ảnh này được chuyển đổi sang WebP động bằng công cụ "gif2webp" sử dụng các chế độ cài đặt mặc định (được tạo từ cây nguồn libwebp mới nhất kể từ ngày 8/10/2013). Số liệu so sánh là giá trị trung bình trên những hình ảnh này.

2 Thời gian giải mã được tính toán bằng libwebp + ToT Blink mới nhất kể từ ngày 08/10/2013 bằng công cụ đo điểm chuẩn. "Thời gian giải mã bằng thao tác tìm" được tính là "Giải mã 5 khung đầu tiên, xoá bộ nhớ đệm khung hình, giải mã 5 khung tiếp theo, v.v.".

3 WebM lưu 4 khung tham chiếu YUV trong bộ nhớ, với mỗi khung lưu trữ (chiều rộng + 96)*(chiều cao + 96) pixel. Đối với YUV 4:2:0, chúng ta cần 4 byte trên mỗi 6 pixel (hoặc 3/2 byte mỗi pixel). Vì vậy, các khung tham chiếu này sử dụng 4*3/2*(width+96)*(height+96) byte bộ nhớ. Trong khi đó, WebP chỉ cần khung trước đó (tính bằng RGBA), tức là có 4*width*height byte bộ nhớ.

4 Tính năng kết xuất WebP động yêu cầu Google Chrome phiên bản 32 trở lên