It’s often cited that the biggest drag on WordPress page speed isn’t code at all — it’s images. The same-looking photo can end up dramatically smaller in file size depending on whether it stays as JPEG/PNG or gets converted to WebP. This post looks at why WebP tends to be lighter, how browsers negotiate which format to load, and how WordPress itself has adopted the format over time.
Why WebP Is Smaller: A Different Compression Approach
JPEG, standardized back in 1992, is built on discrete cosine transform (DCT) compression. WebP, introduced by Google in 2010, takes a different route: it repurposes the intra-frame compression techniques from the VP8 video codec for still images. Because it inherits prediction-based encoding refined for video, WebP can often hit a smaller file size than JPEG at a comparable level of visible quality loss.
Note: intra-frame compression means compressing a single video frame using only the information within that frame, without referencing neighboring frames. That’s essentially the same problem as compressing one still image, which is why video codec techniques transfer so directly to image formats.
Another advantage of WebP is that it covers multiple use cases under one format. It supports lossy compression for photos, but also lossless compression for things like logos and screenshots, plus alpha-channel transparency (like PNG) and even simple animation (like GIF). Formats that used to require picking JPEG for photos, PNG for transparency, and GIF for animation can now be handled by WebP alone.
How Browsers Decide Which Format to Serve
When WebP was new, browser support was inconsistent, and HTTP content negotiation helped bridge that gap. A browser requesting an image sends a header like Accept: image/webp,image/*,*/*, and a server or CDN can inspect it to decide: if the browser says it understands WebP, serve the lighter WebP version; otherwise, fall back to JPEG or PNG.
Note: content negotiation is the general term for a server returning different content at the same URL depending on what format the client claims to support. The same idea shows up for language (
Accept-Language) and compression (Accept-Encoding), not just image formats.
The same idea can be expressed explicitly in HTML. Wrapping a <source type="image/webp" srcset="photo.webp"> element inside a <picture> tag, followed by a regular <img src="photo.jpg"> fallback, lets the browser pick whichever format it understands first — WebP if supported, the JPEG <img> otherwise. This is convenient because the browser handles the decision itself; no server-side negotiation logic is required.
All major browsers today (Chrome, Firefox, Edge, Safari) support WebP, so the “unsupported” branch of that logic rarely gets exercised in practice. Still, some older email-preview renderers and certain image-processing bots don’t support it, so keeping a fallback in place remains a reasonable default.
WebP Support in WordPress Core
For a long time, WordPress restricted uploadable image formats to JPEG, PNG, GIF, and a few others — trying to upload a .webp file to the media library used to fail with an error about the file type not being allowed for security reasons. WebP was officially added to the allowed MIME type list (wp_get_mime_types()) starting with WordPress 5.8, after which WebP files could be uploaded directly to the media library.
Later versions of WordPress went a step further: derivative sizes generated from an uploaded JPEG (the various sizes registered via add_image_size(), such as thumbnails) can now be automatically converted to WebP and stored alongside the original. The original JPEG file itself is left untouched, while the smaller sizes used in post listings and featured images become WebP — reducing transferred bytes on the display side while preserving compatibility of the source file. Whether this conversion actually happens depends on the server’s image-processing library (GD or Imagick) supporting WebP output, so it isn’t guaranteed on every hosting environment.
A Similar Case in Our Own Codebase: Mapping Extensions to MIME Types
This app’s white-label reporting feature (available on the STD/BIZ plans) touches WebP in a comparable way. The agency-logo upload endpoint (site_manager_web.py::upload_report_logo) includes .webp in its list of allowed extensions, and the endpoint that serves the logo back for preview (report_logo_preview) maintains a lookup table from extension to MIME type:
mime_map = {'.png': 'image/png', '.jpg': 'image/jpeg', '.jpeg': 'image/jpeg',
'.gif': 'image/gif', '.webp': 'image/webp', '.svg': 'image/svg+xml'}
Similarly, the routine that embeds site screenshots into a report PDF (report_generator.py::_encode_image_b64) determines the correct MIME type from the file extension (mapping webp to image/webp) before encoding the file as a base64 data URI.
Why bother with this lookup table at all? Browsers and PDF renderers decide how to interpret an image based on the actual Content-Type header sent (or the MIME type declared inside a data URI) — not the file extension itself. If a .webp file were mistakenly served with a MIME type like image/png, the browser might fail to render it, or offer a download dialog instead of displaying it inline. Explicitly mapping each extension to its correct MIME type is a small, unglamorous step, but it’s the kind of detail that prevents broken image rendering.
Why the OGP Image Generator Still Outputs PNG, Not WebP
On the other hand, this blog’s dynamic OGP image generator — ogp-generator.php, covered previously in our Cache-Control vs. ETag post — deliberately outputs PNG rather than WebP. The reason: social media crawlers from platforms like X (formerly Twitter) and Facebook are separate programs from a person’s browser, and they don’t necessarily track the same level of image-format support as the latest browser releases. Since an OGP image’s job is to be read by a social platform’s crawler rather than a human’s browser, choosing the most broadly compatible format — PNG or JPEG — reduces the risk of a share card failing to render correctly.
Even with the same underlying goal of keeping images small, the right format can differ depending on whether the audience is a general-purpose browser or a social crawler.
Summary
WebP borrows video-codec compression techniques to deliver photos, transparent images, and simple animations in one format, typically at a smaller file size than the JPEG/PNG/GIF combination it replaces. Browsers can negotiate format support through the Accept header or declare it explicitly with the <picture> element, and WordPress core has gradually adopted WebP — first as an upload-allowed format in version 5.8, later with automatic conversion for generated image sizes. Lighter isn’t always better, though: when compatibility with a specific consumer (like a social media crawler) matters more than raw file size, sticking with an older, more universally supported format can be the right call.