Website nên sử dụng webp để lưu hình ảnh tăng tốc độ load site, tốt cho SEO

S2RETAIL tháng 8 21, 2020

Webp là gì? 

Làm thế nào để sử dụng được webp?

WEBP là một định dạng hình ảnh mới cao cấp cho Web 

webp là 1 image format cao cấp , cung cấp nén dữ liệu Lossless and lossy tức là nén không mất dữ liệu cho hình ảnh trên website, giúp website load nhanh hơn với các kích thước hình ảnh nhỏ hơn. Sử dụng WebP, quản trị viên web và nhà phát triển web có thể tạo hình ảnh nhỏ hơn, phong phú hơn để làm cho web nhanh hơn.
Hình ảnh được nến dữ liệu webp thì nhỏ hơn 26% so với lưu thành file PNG và 25 đến 34% so với lưu với định dạng jpeg, và có chỉ số chất lượng SSIM như nhau.
Định dạng webp hổ trợ tính minh bạch(supports transparency) cũng được biết đến như 1 kênh alpha với chi phí bổ sung 22% byte. Đối với các trường hợp có thể chấp nhận nén RGB mất dữ liệu, lossy WebP also supports transparency  , thường cung cấp kích thước tệp nhỏ hơn 3 × so với PNG.

Cách hoạt động của webp

Lossy Webp đã sử dụng mã dự đoán để nén và mã hoá hình ảnh , cũng có thể sử dụng 1 vài phương thức khác như codec VP8 video để nén khung hình ảnh chính trong video. Mã hoá dự đoán là sử dụng giá trị của các ô kế bên , từng pixel để dự đoán giá trị cho ô pixel tiếp theo và mã hoá sự khác biệt.
Lossless WebP compression sử dụng hình ảnh đã thấy để mô phỏng lại chính xác các ô pixel mới ,nó cũng sẽ sử dụng bảng màu cục bộ nếu không tìm thấy mô phổng thích hợp.

Tệp WebP bao gồm dữ liệu hình ảnh VP8 hoặc VP8L và một vùng chứa dựa trên RIFF . libwebpThư viện độc lập phục vụ như triển khai tham chiếu cho đặt tả webp và có sẵn từ kho lưu trử của trình duyệt hoặc dưới dạng tarball.

Hỗ trợ WebP 


WebP được hỗ trợ nguyên bản trong Google Chrome, Firefox, Edge, trình duyệt Opera cũng như nhiều công cụ và thư viện phần mềm khác. Các nhà phát triển cũng đã hỗ trợ thêm nhiều công cụ chỉnh sửa hình ảnh. WebP bao gồm thư viện mã hóa và giải mã nhẹ libwebp và các công cụ dòng lệnh cwebpvà dwebpđể chuyển đổi hình ảnh sang và từ định dạng WebP, cũng như các công cụ để xem, trộn và tạo hoạt ảnh cho hình ảnh WebP. Mã nguồn đầy đủ có sẵn trên trang tải xuống .

Những trình duyệt web nào hỗ trợ WebP?

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

  • Hỗ trợ mất dữ liệu WebP
    • Google Chrome (máy tính để bàn) 17+
    • Google Chrome dành cho Android phiên bản 25+
    • Microsoft Edge 18+
    • Firefox 65+
    • Opera 11.10+
    • Trình duyệt web gốc, Android 4.0+ (ICS)
  • Hỗ trợ WebP mất dữ liệu, không mất dữ liệu và alpha
    • Google Chrome (máy tính để bàn) 23+
    • Google Chrome dành cho Android phiên bản 25+
    • Microsoft Edge 18+
    • Firefox 65+
    • Opera 12.10+
    • Trình duyệt web gốc, Android 4.2+ (JB-MR1)
    • Trăng nhạt 26+
  • Hỗ trợ WebP Animation
    • Google Chrome (máy tính để bàn và Android) 32+
    • Microsoft Edge 18+
    • Firefox 65+
    • Opera 19+

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

Bạn sẽ chỉ muốn phân phát hình ảnh WebP cho các máy khách có thể hiển thị chúng đúng cách và quay trở lại các định dạng cũ cho các máy khách không thể. May mắn thay, có một số kỹ thuật để phát hiện 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 như một phần của dịch vụ của họ.

Tại sao Google phát hành WebP dưới dạng mã 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 trong mã nguồn mở, bất kỳ ai cũng có thể làm việc với định dạng và đề xuất các cải tiến. Với thông tin đầu vào 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 như một định dạng đồ họa theo thời gian.

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

WebP tương thích với dò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ợ những không gian màu nào?

Phù hợp với dòng bit VP8, WebP bị mất dữ liệu hoạt động riêng với định dạng hình ảnh 8 bit Y'CbCr 4: 2: 0 (thường được gọi là YUV420). Vui lòng tham khảo Phần 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.

Lossless WebP hoạt động độc quyền với định dạng RGBA. Xem thông số kỹ thuật về luồng bit không mất dữ liệu của WebP .

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

Có, thường là khi chuyển đổi từ định dạng mất dữ liệu sang WebP không mất dữ liệu 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à sự chuyển đổi giữa chúng.

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

  1. Nếu hình ảnh nguồn ở định dạng ARGB không mất dữ liệu, việc 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. Tình huống này thường có thể xảy ra khi nguồn có định dạng PNG với ít màu: chuyển đổi sang WebP bị mất (hoặc, tương tự như JPEG bị mất) sẽ có khả năng dẫn đến kích thước tệp lớn hơn.
  2. Nếu nguồn ở định dạng mất dữ liệu, việc sử dụng nén WebP không mất dữ liệu để nắm bắt bản chất mất mát của nguồn thường sẽ dẫn đến tệp lớn hơn. Điều này không phải riêng đối với WebP và có thể xảy ra khi chuyển đổi nguồn JPEG sang định dạng WebP hoặc PNG không mất dữ liệu.
  3. Nếu nguồn ở định dạng bị mất và bạn đang cố nén nó dưới dạng WebP bị mất với cài đặt chất lượng cao hơn. Ví dụ: cố gắng chuyển đổi tệp JPEG được lưu ở chất lượng 80 sang tệp WebP với chất lượng 95 thường sẽ dẫn đến tệp lớn hơn, ngay cả khi cả hai định dạng đều bị mất. Việc đánh giá chất lượng của nguồn thường không thể thực hiện được, 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 lớn hơn một cách nhất quán. Một khả năng khác là tránh sử dụng cài đặt chất lượng và thay vào đó nhắm mục tiêu kích thước tệp nhất định bằng cách sử dụng -sizetùy chọn trong cwebpcông cụ hoặc API tương đương. Ví dụ: nhắm mục tiêu 80% kích thước tệp gốc có thể tỏ ra mạnh mẽ hơn.

Lưu ý rằng việc chuyển đổi nguồn JPEG thành WebP bị mất dữ liệu hoặc nguồn PNG thành WebP không mất dữ liệu không dễ bị bất ngờ về kích thước tệp như vậy.

WebP có hỗ trợ hiển thị lũy tiến hay xen kẽ không?

WebP không cung cấp làm mới giải mã liên tục hoặc liên tục theo nghĩa JPEG hoặc PNG. Điều này có khả năng gây quá nhiều áp lực lên CPU và bộ nhớ của máy khách giải mã vì mỗi sự kiện làm mới liên quan đến một lần chuyển toàn bộ qua hệ thống giải nén.

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

Ngoài ra, WebP cung cấp giải mã gia tăng , trong đó tất cả các byte đến có sẵn của dòng bit được sử dụng để thử và tạo ra một hàng mẫu có thể hiển thị càng sớm càng tốt. Điều này vừa tiết kiệm bộ nhớ, CPU và nỗ lực vẽ lại trên máy khách vừa cung cấp các dấu hiệu trực quan về trạng thái tải xuống. Tính năng giải mã gia tăng có sẵn thông qua API giải mã nâng cao .

Tại sao tôi nên sử 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 và alpha 1 bit của GIF.

  2. WebP hỗ trợ cả nén mất dữ liệu và không mất dữ liệu; trên thực tế, một hình ảnh động có thể kết hợp các khung hình bị mất và không mất dữ liệu. GIF chỉ hỗ trợ nén không mất dữ liệu. Các kỹ thuật nén mất dữ liệu của WebP rất phù hợp với các 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 GIF  . GIF động được chuyển đổi thành WebP bị mất nhỏ hơn 64%, trong khi WebP không mất dữ liệu nhỏ hơn 19%. Điều này đặc biệt quan trọng trên các mạng di động.

  4. WebP mất ít thời gian hơn để giải mã khi tìm kiếm. Trong Blink , cuộn hoặc thay đổi tab có thể ẩn và hiển thị hình ảnh, dẫn đến các hoạt ảnh bị tạm dừng và sau đó chuyển tiếp đến một điểm khác. Việc sử dụng CPU quá mức dẫn đến hoạt ảnh giảm khung hình cũng có thể yêu cầu bộ giải mã tìm kiếm chuyển tiếp trong hoạt ảnh. Trong các tình huống này, WebP động mất 0,57 lần tổng thời gian giải mã 2 so với GIF, dẫn đến ít rung hơn trong khi cuộn và phục hồi nhanh hơn từ mức tăng đột biến sử dụng CPU. Điều này là do hai ưu điểm của WebP so với GIF:

    • Hình ảnh WebP lưu trữ siêu dữ liệu về việc mỗi khung có chứa alpha hay không, loại bỏ nhu cầu giải mã khung để thực hiện việc xác định này. Điều này dẫn đến suy luận chính xác hơn về các khung trước đó mà một khung nhất định phụ thuộc vào, do đó làm giảm sự giải mã không cần thiết của các khung trước đó.

    • Giống như một bộ mã hóa video hiện đại, bộ mã hóa WebP bổ sung các khung hình chính theo các khoảng thời gian đều đặn (điều mà hầu hết các bộ mã hóa GIF không làm). Điều này cải thiện đáng kể việc tìm kiếm trong các hình ảnh động dài. Để tạo điều kiện chèn các khung như vậy mà không làm tăng đáng kể kích thước hình ảnh, WebP thêm cờ 'phương pháp trộn' cho mỗi khung ngoài phương pháp xử lý 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 đã được xóa về màu nền mà không buộc khung hình trước đó phải ở 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, giải mã đường thẳng của WebP tốn nhiều CPU hơn GIF. Lossy WebP mất 2,2 lần thời gian giải mã như GIF, trong khi WebP không mất dữ liệu mất 1,5 lần.

  2. Hỗ trợ WebP gần như không phổ biến như hỗ trợ GIF, vốn là phổ biến một cách hiệu quả.

  3. Việc thêm hỗ trợ WebP vào các trình duyệt sẽ làm tăng dấu vết mã và bề mặt tấn công. Trong Blink, đây là khoảng 1500 dòng mã bổ sung (bao gồm thư viện WebP demux và bộ giải mã hình ảnh WebP phía Blink). Lưu ý rằng vấn đề này có thể được giảm bớt trong tương lai nếu WebP và WebM chia sẻ mã giải mã phổ biến hơn hoặc nếu các khả năng của WebP được gộp lại 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 <img> thẻ có thể có ý nghĩa về lâu dài . Tuy nhiên, làm như vậy bây giờ, với mục đích WebM <img>có thể thực hiện vai trò được đề xuất của WebP động, là một vấn đề:

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

  2. Hỗ trợ codec video và vùng chứa rất khác nhau trên các trình duyệt và thiết bị. Để tạo điều kiện thuận lợi cho việc chuyển mã nội dung tự động (ví dụ: đối với 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 thẻ hình ảnh của họ hỗ trợ định dạng nào. Thậm chí điều này có thể không đủ, vì các loại MIME như "video / webm" hoặc "video / mpeg" vẫn không cho biết hỗ trợ codec (ví dụ: VP8 so với VP9). Mặt khác, định dạng WebP được đóng băng một cách hiệu quả và nếu các nhà cung cấp gửi nó đồng ý gửi WebP động, thì hoạt động 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 sử dụng để biểu thị hỗ trợ WebP, không cần thay đổi tiêu đề chấp nhận mới.

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

  4. WebM hiện không kết hợp tất cả các kỹ thuật nén từ WebP. Kết quả là, hình ảnh này nén với WebP tốt hơn đáng kể so với các lựa chọn thay thế:

1 Đối với tất cả các so sánh giữa GIF động và WebP động, chúng tôi đã sử dụng tập hợp khoảng 7000 ảnh GIF động được lấy ngẫu nhiên từ web. Những hình ảnh này đã được chuyển đổi thành WebP động bằng công cụ 'gif2webp' sử dụng cài đặt mặc định (được xây dựng từ cây nguồn libwebp mới nhất tính đến ngày 10/08/2013). Các số so sánh là giá trị trung bình trên các hình ảnh này.

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

3 WebM giữ 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 YUV4: 2: 0, chúng ta cần 4 byte trên 6 pixel (hoặc 3/2 byte trên mỗi pixel). Vì vậy, các hệ quy chiếu này sử dụng 4*3/2*(width+96)*(height+96)byte bộ nhớ. Mặt khác, WebP sẽ chỉ cần khung trước đó (trong RGBA) khả dụng, tức là 4*width*heightbyte bộ nhớ.

Nguồn từ Nhà Phát Triển của Google.
Reactions

Đăng nhận xét

0 Nhận xét