Comparative Analysis on WebP and JPEG Decoding Performance

[Serge]

Dear WebP Project Team,

I am exploring the performance of WebP decoding in comparison to JPEG decoding for an image processing project. During my comparative analysis, I've noticed that decoding JPEG images has been consistently faster compared to decoding WebP images, despite the renowned efficiency of the WebP format. Below are the average results from my tests:

    JPG Texture Load Time: 3 ms

    WebP Texture Load Time: 8 ms

To furnish a precise understanding of the testing environment and methods used, I have attached a minimal test project with this email. The project is structured using CMake and utilizes the latest versions of the libjpeg-turbo and libwebp libraries for decoding.

I have adhered to the recommended practices for decoding WebP images and optimized the settings to the best of my knowledge. However, the slower decoding time for WebP images as opposed to JPEG images is unexpected. I am keen on understanding if there's any potential for optimization or if there might be some settings that I may have overlooked.

I would be grateful if your team could review the attached project and provide any insights or recommendations that could aid in enhancing the decoding time for WebP images in my project.

I value your time and expertise on this matter and am looking forward to your valuable feedback. I am open to providing any additional information you may require for a thorough analysis.

Thank you.

[Vincent Rabaud]

The usual rule of thumb that we empirically found is that lossy WebP
is 2/3 times slower to encode (with default settings) than JPEG, and
1.5 slower to decode.
That can vary depending on the image size/complexity.
Also, make sure you export both to the same color space (it seems you
do not convert to RGB for jpeg). You can have a look at how we do it
at: https://chromium.googlesource.com/webm/libwebp/+/refs/heads/1.0.1/imageio/jpegdec.c#292

> --
> You received this message because you are subscribed to the Google Groups "WebP Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss...@webmproject.org.
> To view this discussion on the web visit https://groups.google.com/a/webmproject.org/d/msgid/webp-discuss/C3D58CBB-625C-49B0-A906-377D883B2495%40gmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups "WebP Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss...@webmproject.org.
> To view this discussion on the web visit https://groups.google.com/a/webmproject.org/d/msgid/webp-discuss/C3D58CBB-625C-49B0-A906-377D883B2495%40gmail.com.

[Pascal Massimino]

Hi Serge,

On Thu, Oct 5, 2023 at 11:46 AM Serge <koz...@gmail.com> wrote:

Dear WebP Project Team,

I am exploring the performance of WebP decoding in comparison to JPEG decoding for an image processing project. During my comparative analysis, I've noticed that decoding JPEG images has been consistently faster compared to decoding WebP images, despite the renowned efficiency of the WebP format.

Note that WebP is not supposed to always decode faster, but to *download* faster due to smaller size. The extra decoding time (compared to JPEG) is offset by the transfer gain for a total win.

Here's a diagram from my slides:

(last row is about Incremental decoding, an extra gain on top).

Hope it helps,

skal/

 

Below are the average results from my tests:

    JPG Texture Load Time: 3 ms

    WebP Texture Load Time: 8 ms

To furnish a precise understanding of the testing environment and methods used, I have attached a minimal test project with this email. The project is structured using CMake and utilizes the latest versions of the libjpeg-turbo and libwebp libraries for decoding.

I have adhered to the recommended practices for decoding WebP images and optimized the settings to the best of my knowledge. However, the slower decoding time for WebP images as opposed to JPEG images is unexpected. I am keen on understanding if there's any potential for optimization or if there might be some settings that I may have overlooked.

I would be grateful if your team could review the attached project and provide any insights or recommendations that could aid in enhancing the decoding time for WebP images in my project.

I value your time and expertise on this matter and am looking forward to your valuable feedback. I am open to providing any additional information you may require for a thorough analysis.

Thank you.

[Sergei]

Thank you all for your responses. I carried out a series of tests across release builds on Android and iOS devices. To my surprise, WebP consistently outperformed JPEG in read + decoding speed.
On iOS, WebP was approximately 1.5 times faster, while on Android, the performance gain ranged from about 2.5 to 4 times.

четверг, 5 октября 2023 г. в 22:50:15 UTC+2, Pascal Massimino:

[Rob Mason]

I'm seeing a webp download noticeably slower than the equivalent jpg it's generated from.

The jpg is 314kb, the webp is 316kb, and visibly loads from top to bottom over 250ms. The jpg loads in 50ms and appears instantly to the user.

I'm seeing this on every image I try - even though the webp is smaller by 5-15kb, it loads visibly slower to the user, appearing blank and then loading down the page incrementally over about 200ms, whereas the slightly larger jpg loads instantly. Considering people generally have better connection speeds these days, I'm thinking that we're actually making performance of the website worse by using webp, increasing the delay on loading by shifting it onto the CPU of the device - particularly when people are often using phones with fast connections.

[James Zern]

Hi,

On Tue, Feb 18, 2025 at 4:02 AM 'Rob Mason' via WebP Discussion <webp-d...@webmproject.org> wrote:

I'm seeing a webp download noticeably slower than the equivalent jpg it's generated from.

The jpg is 314kb, the webp is 316kb, and visibly loads from top to bottom over 250ms. The jpg loads in 50ms and appears instantly to the user.

I'm seeing this on every image I try - even though the webp is smaller by 5-15kb, it loads visibly slower to the user, appearing blank and then loading down the page incrementally over about 200ms, whereas the slightly larger jpg loads instantly. Considering people generally have better connection speeds these days, I'm thinking that we're actually making performance of the website worse by using webp, increasing the delay on loading by shifting it onto the CPU of the device - particularly when people are often using phones with fast connections.

The incremental rendering you're seeing is indicative of a slow connection rather than a fast one. Chrome will update the image as data becomes available, but on a connection with reasonable throughput it usually renders the image all at once. The transfer itself can be affected by server side and local caching as well. Locally in Chrome, caching can be disabled in the developer tools and the transfer times will be given in the network tab.

 

To view this discussion visit https://groups.google.com/a/webmproject.org/d/msgid/webp-discuss/81bfd82d-460a-42d7-8f93-0059d4590ea9n%40webmproject.org.

[James Zern]

On Wed, Feb 19, 2025 at 4:25 PM James Zern <jz...@google.com> wrote:

Hi,

On Tue, Feb 18, 2025 at 4:02 AM 'Rob Mason' via WebP Discussion <webp-d...@webmproject.org> wrote:

I'm seeing a webp download noticeably slower than the equivalent jpg it's generated from.

The jpg is 314kb, the webp is 316kb, and visibly loads from top to bottom over 250ms. The jpg loads in 50ms and appears instantly to the user.

I'm seeing this on every image I try - even though the webp is smaller by 5-15kb, it loads visibly slower to the user, appearing blank and then loading down the page incrementally over about 200ms, whereas the slightly larger jpg loads instantly. Considering people generally have better connection speeds these days, I'm thinking that we're actually making performance of the website worse by using webp, increasing the delay on loading by shifting it onto the CPU of the device - particularly when people are often using phones with fast connections.

The incremental rendering you're seeing is indicative of a slow connection rather than a fast one. Chrome will update the image as data becomes available, but on a connection with reasonable throughput it usually renders the image all at once. The transfer itself can be affected by server side and local caching as well. Locally in Chrome, caching can be disabled in the developer tools and the transfer times will be given in the network tab.

To add a little more to this, comparing same sized Jpeg and WebP on a fast connection might show some slight regression depending on the image size and complexity, but there can be additional factors that hurt the overall page load performance; in most cases the webp file should be smaller, which gives it an advantage in transfer time. The lighthouse tool in Chrome developer tools can give some guidance and help track improvements. One metric that WebP can help improve is Largest Contentful Paint (LCP) [1].

[1]: https://web.dev/articles/optimize-lcp