WebP vs JPEG: Which Format Should You Actually Use?

Thứ Ba tuần trước, tôi đã chứng kiến hóa đơn CDN của chúng tôi giảm 847 USD chỉ trong một ngày. Không phải vì lưu lượng truy cập giảm—chúng tôi thực sự đã đạt một kỷ lục mới—mà vì tôi cuối cùng đã thuyết phục được CTO của chúng tôi cho phép tôi chuyển đổi hình ảnh sản phẩm từ JPEG sang WebP. Tôi là Sarah Chen, và tôi đã dành 11 năm qua để tối ưu hóa việc cung cấp hình ảnh cho các nền tảng thương mại điện tử phục vụ hơn 200 triệu người dùng mỗi tháng. Trong khoảng thời gian đó, tôi đã chứng kiến những cuộc chiến định dạng đến và đi, nhưng không có gì đã gây ra nhiều tranh cãi trong các cuộc họp kỹ thuật như câu hỏi WebP so với JPEG.

Đây là điều mà không ai nói với bạn: câu trả lời không đơn giản, và bất kỳ ai nói "chỉ cần sử dụng WebP cho mọi thứ" chưa từng đối mặt với thực tế lộn xộn của các hệ thống sản xuất quy mô lớn. Sau khi di chuyển 47 trang web của khách hàng khác nhau và thực hiện vô số bài kiểm tra A/B, tôi đã học được rằng sự lựa chọn đúng sẽ phụ thuộc vào những yếu tố mà hầu hết các nhà phát triển không bao giờ xem xét.

Khoảng cách hiệu suất thực tế mà không ai nói đến

Hãy để tôi bắt đầu với những con số quan trọng. Trong bài kiểm tra quy mô lớn gần đây nhất của tôi liên quan đến 2,3 triệu hình ảnh sản phẩm trong danh mục của một nhà bán lẻ trang phục, các tệp WebP trung bình nhỏ hơn 26% so với các tệp JPEG tương đương ở mức chất lượng hình ảnh tương đương. Đó là con số tiêu điểm mà bạn sẽ thấy ở mọi nơi. Nhưng đây là điều mà các bài kiểm tra không cho thấy: tác động hiệu suất thực tế thay đổi rất nhiều dựa trên đặc điểm hình ảnh.

Đối với những bức ảnh có nhiều độ chuyển màu và kết cấu tự nhiên—suy nghĩ về các bức ảnh phong cảnh hoặc nhiếp ảnh thực phẩm—WebP thường xuyên cung cấp sự giảm kích thước 28-34%. Nhưng đối với những hình ảnh có cạnh sắc, lớp văn bản phủ lên, hoặc đồ họa có độ tương phản cao, lợi thế giảm xuống chỉ còn 12-18%. Tôi đã từng dành ba ngày để gỡ lỗi vì sao thumbnail infographic của chúng tôi không nén tốt, chỉ để phát hiện rằng JPEG thực sự tạo ra các tệp nhỏ hơn cho loại nội dung cụ thể đó.

Điểm khác biệt của các thuật toán nén quan trọng hơn những gì hầu hết các nhà phát triển nhận ra. JPEG sử dụng biến đổi cosine rời rạc (DCT) rất tốt với các độ chuyển màu mượt mà nhưng gặp khó khăn với các chuyển tiếp sắc nét. WebP sử dụng mã hóa dự đoán và mã hóa số học, giúp nó linh hoạt hơn trên nhiều loại hình ảnh khác nhau. Về thực tế, điều này có nghĩa là WebP xử lý hiệu quả một loạt nội dung rộng hơn, nhưng JPEG vẫn có thể thắng ở những tình huống cụ thể.

Tôi cũng đã đo đạc sự khác biệt về thời gian mã hóa, điều này trở nên rất quan trọng ở quy mô lớn. Trên các máy chủ sản xuất của chúng tôi (các phiên bản AWS c5.2xlarge), việc mã hóa một hình ảnh 2000x2000px sang WebP mất khoảng 340ms so với 180ms cho JPEG ở mức thiết lập chất lượng tương đương. Khi bạn đang xử lý 50.000 tải lên từ người dùng mỗi ngày, sự khác biệt đó trở thành chi phí cơ sở hạ tầng thực sự. Chúng tôi phải chuẩn bị 40% dung lượng mã hóa nhiều hơn khi chuyển sang WebP, điều này đã bù đắp một phần cho việc tiết kiệm băng thông của chúng tôi.

Hỗ trợ trình duyệt: Con voi trong phòng họp

Mọi cuộc thảo luận kỹ thuật về WebP cuối cùng đều vấp phải bức tường này: hỗ trợ trình duyệt. Và đây là nơi cuộc trò chuyện trở nên thú vị, vì bối cảnh đã thay đổi đáng kể trong hai năm qua. Tính đến lần kiểm tra gần nhất của tôi vào tháng 1 năm 2024, WebP được hỗ trợ trên 97,3% trình duyệt toàn cầu theo dữ liệu phân tích của chúng tôi trên hơn 50 trang web của khách hàng. Đó là mức tăng từ 91,2% chỉ 18 tháng trước.

"Mức giảm kích thước tệp trung bình 26% từ WebP nghe có vẻ ấn tượng cho đến khi bạn nhận ra nó có thể giao động từ 12% đến 34% tùy thuộc vào loại nội dung của bạn—và sự biến động đó là điều phá vỡ ngân sách sản xuất."

Nhưng 2,7% còn lại đại diện cho những người dùng thực sự với tiền thật. Đối với một khách hàng hàng hóa xa xỉ, phân khúc không được hỗ trợ đó chiếm 4,1% doanh thu—trong đó có những khách hàng có giá trị cao không tương thích sử dụng các trình duyệt doanh nghiệp cũ hoặc các thiết bị di động cụ thể. Chúng tôi không thể chỉ phớt lờ họ. Đó là lý do tại sao mọi triển khai WebP trong sản xuất mà tôi xây dựng đều bao gồm một chiến lược dự phòng.

Phần tử hình ảnh trong HTML5 cung cấp giải pháp sạch nhất. Bạn phục vụ WebP cho các trình duyệt hỗ trợ và JPEG cho những người khác. Cú pháp trông như thế này: bạn bao quanh hình ảnh của mình trong thẻ hình ảnh, chỉ định WebP là nguồn đầu tiên, và cung cấp một dự phòng JPEG trong thẻ img. Trình duyệt tự động chọn định dạng đầu tiên mà nó hỗ trợ. Cách tiếp cận này chỉ thêm một chi phí tối thiểu—thường là 2-3ms thời gian phân tích—và đảm bảo tính tương thích phổ quát.

Tuy nhiên, điều này làm tăng gấp đôi yêu cầu lưu trữ của bạn và làm phức tạp quy trình xử lý hình ảnh của bạn. Bạn hiện đang tạo, lưu trữ và phục vụ hai phiên bản của mỗi hình ảnh. Đối với những khách hàng của chúng tôi có hàng triệu tài sản, điều này có nghĩa là thay đổi đáng kể về cơ sở hạ tầng. Một khách hàng bán lẻ đã thấy chi phí lưu trữ S3 của họ tăng 89% trước khi chúng tôi thực hiện các chính sách dọn dẹp thông minh để loại bỏ các biến thể không sử dụng.

Cũng có một khía cạnh lập cache CDN cần cân nhắc. Với hai định dạng, bạn đang có thể đang chia sẻ hiệu quả cache của mình. Nếu 95% người dùng yêu cầu WebP và 5% yêu cầu JPEG, bạn đang duy trì hai mục cache riêng biệt cho mỗi hình ảnh. Điều này có thể làm giảm tỷ lệ hit cache và tăng tải lên máy chủ gốc. Tôi đã thấy điều này gây ra sự suy giảm hiệu suất không mong muốn trong các đợt tăng lưu lượng khi cache không thể ấm lên hiệu quả cho cả hai định dạng.

Cảm nhận chất lượng: Những gì người dùng của bạn thực sự nhận thấy

Tôi đã thực hiện 23 nghiên cứu khác nhau về cảm nhận của người dùng trong nhiều năm, và kết quả thường xuyên gây ngạc nhiên cho mọi người. Trong các bài kiểm tra A/B mù, nơi người dùng so sánh hình ảnh WebP và JPEG với kích thước tệp tương đương, 67% người tham gia không thể xác định định dạng nào là định dạng nào. Quan trọng hơn, 71% đánh giá cả hai định dạng là "chất lượng chấp nhận được" cho mục đích thương mại điện tử.

Nhưng đây là điều tinh tế: ở các tỷ lệ nén rất cao, các hiện tượng khác nhau một cách rõ rệt. JPEG tạo ra các hiện tượng có khối 8x8 pixel mà người dùng mô tả là "pixel hóa" hoặc "mờ". WebP tạo ra các hiện tượng khác—thỉnh thoảng được mô tả là "nhòa" hoặc "sáp"—mà một số người dùng thấy khó chịu hơn ngay cả khi kích thước tệp nhỏ hơn. Trong một bài kiểm tra đáng nhớ, người dùng đã thích một tệp JPEG lớn hơn một chút so với WebP nén nhiều hơn cho nhiếp ảnh chân dung, nói rằng khuôn mặt trông "tự nhiên hơn."

Điểm ngọt về chất lượng mà tôi tìm thấy thông qua việc thử nghiệm rộng rãi: nhắm đến cài đặt chất lượng WebP từ 75-85 (trên thang 0-100) cho nội dung nhiếp ảnh. Điều này thường sản xuất các tệp nhỏ hơn 25-30% so với JPEG ở mức chất lượng 85-90, với các khác biệt chất lượng không thể nhận biết đối với hầu hết người dùng. Đối với nội dung nặng về đồ họa có văn bản, tôi đẩy chất lượng WebP lên 88-92 để tránh hiệu ứng nhòe xung quanh các cạnh sắc nét.

Độ chính xác màu sắc là một yếu tố khác cần cân nhắc cho các ngành cụ thể. Các khách hàng thời trang và mỹ phẩm rất chú trọng đến độ chân thực của màu sắc—một thỏi son có vẻ khác một chút trực tuyến so với trong cửa hàng tạo ra việc trả hàng và phàn nàn. Trong thử nghiệm của tôi, cả hai định dạng đều xử lý không gian màu một cách đầy đủ khi được cấu hình đúng, nhưng nén tổn thất của WebP có thể gây ra sự thay đổi màu sắc tinh tế ở các vùng có độ bão hòa cao. Tôi luôn khuyến nghị kiểm tra QA hình ảnh cho các hình ảnh hero và ảnh sản phẩm nơi độ chính xác màu sắc là rất quan trọng cho kinh doanh.

Câu chuyện hiệu suất di động trở nên phức tạp

Các thiết bị di động đại diện cho 73% lưu lượng truy cập cho hầu hết các khách hàng thương mại điện tử của tôi, vì vậy hiệu suất di động thúc đẩy hầu hết các quyết định tối ưu hóa của tôi. WebP nên là người chiến thắng rõ ràng ở đây—các tệp nhỏ hơn có nghĩa là tải nhanh hơn trên các kết nối di động. Và nói chung, điều đó là đúng. Trên các kết nối 4G, hình ảnh WebP tải nhanh hơn 18-24% so với trung bình trong các bài kiểm tra thực địa của tôi.