Should you really use the picture tag to serve your WebP images?

Why does Google emphasize the picture tag over other methods?

The tag allows declaring multiple image sources with different MIME types. The browser evaluates each in order and loads the first one it understands. If WebP is not supported, it falls back to JPEG or PNG without server-side intervention.

This client-side approach avoids relying on user-agent detection or complex HTTP content negotiation. It simplifies maintenance and ensures predictable behavior across the board. Google prefers this simplicity because it reduces the risks of configuration errors that could harm Core Web Vitals.

Which browsers do not support WebP and why does it still matter?

Safari on iOS prior to iOS 14 and Internet Explorer do not interpret WebP. Even though the market share for these clients is decreasing, it remains significant for certain audiences (businesses locked into IE, older iPhones). Without a fallback, these users see a broken image, which degrades the experience and can increase the bounce rate.

For an e-commerce site or a media platform, serving a broken image to 5-10% of traffic is unacceptable. The JPEG fallback ensures that 100% of visitors see the content, while the majority benefit from the reduced weight of WebP. It’s a pragmatic compromise that preserves performance without sacrificing compatibility.

What is the exact syntax recommended by Google?

Google advises structuring the picture element with a as the first element, followed by a classic pointing to the JPEG or PNG. The browser tests the declared MIME types and skips those it doesn’t understand. The srcset attribute can also handle responsive variants in each source.

This syntax avoids double loading: a single file is downloaded by the client. This is crucial for Core Web Vitals, particularly LCP, since the hero image is often the largest asset on the page. Serving a 80KB WebP instead of a 250KB JPEG mechanically saves time on LCP.

• Guaranteed compatibility: the JPEG fallback prevents broken images on older browsers.
• Optimal performance: WebP reduces weight by an average of 25-35%, speeding up LCP.
• Simplicity of implementation: no user-agent detection or complex server logic required.
• SEO-friendly: Googlebot reads WebP natively, so there’s no loss of image indexing.
• Native responsive: srcset works within each source to manage screen densities.

Is this recommendation consistent with observed real-world practices?

Yes, in hundreds of technical audits, the picture element clearly dominates among high-performing sites. Alternative approaches (server-side user-agent detection, Content-Negotiation Accept: image/webp) exist but present problems with CDN caching and maintenance. Cloudflare, Fastly, and other CDNs poorly manage content negotiation if the Vary: Accept is not configured correctly, leading to serving JPEGs to WebP clients or vice versa.

The picture tag eliminates this class of bugs. The browser decides, period. Modern frameworks (Next.js, Nuxt, Gatsby) automatically generate picture elements with srcset and WebP + fallback. It has become the de facto standard, with Google merely formalizing this industry consensus.

What nuances should be added to this statement?

Google does not specify whether the fallback should be JPEG or PNG. For photos, JPEG remains optimal; for logos or icons with transparency, PNG is appropriate. The recommendation is generic, but the choice of fallback format depends on the type of image. [To be verified]: Google has never published data quantifying the impact on LCP of a poorly fallbacked WebP versus a well-compressed JPEG.

Another nuance: if your CDN supports AVIF (an even more efficient format than WebP), you can stack three sources: AVIF, WebP, JPEG. But be cautious, as AVIF is only supported by recent Chrome/Edge and Firefox. The HTML becomes: , , . Google does not mention AVIF here, but it is consistent with the picture logic: the browser moves down the cascade until it finds a type it understands.

In which cases does this rule not apply or pose problems?

On a site with thousands of legacy images already online, rewriting all the HTML to insert picture tags is a heavy task. Older CMSs (WordPress without dedicated plugins, Drupal 7, Magento 1) do not automatically generate this syntax. You would then need to go through a plugin or rewrite the templates, which can break existing layouts if the CSS relies on a simple .

Another edge case: AMP pages. AMP enforces which does not natively support picture. You need to use AMP's fallback attribute, which has a different syntax. Google could have specified this exception, but the official documentation remains general. Lastly, on high-traffic sites with aggressive CDN, some prefer content negotiation to avoid URL duplication (one for WebP, one for JPEG in the srcset). This is an architectural debate, not resolved by this statement.

What should you actually do on your site to comply with this recommendation?

First step: audit your existing setup. Crawl the site with Screaming Frog or Sitebulb and extract all tags. Identify those already serving WebP (src or srcset attribute) and those still in pure JPEG/PNG. Prioritize above-the-fold images and hero images, as they directly impact LCP.

Next, generate WebP versions of each priority image. Tools like cwebp (Google CLI), Squoosh, or ImageMagick allow for batch conversion. Aim for a quality level equivalent to the original JPEG (generally quality 80-85 for WebP). Store both formats (WebP + JPEG) in the same directory or on the CDN, with consistent names (e.g., hero.webp and hero.jpg).

What mistakes should you avoid when implementing picture?

Classic mistake: forgetting the type attribute in the source tag. Without type="image/webp", the browser does not know it is WebP and may attempt to load the file even if it does not support it, leading to silent failures. Always explicitly declare the MIME type.

Another trap: placing the JPEG fallback after the img tag instead of using img as the final fallback. The correct syntax is: picture > source WebP > img JPEG. The img serves as a fallback and carries essential attributes like alt, width, height for accessibility and CLS. Never duplicate these attributes on sources, only on the img.

How do you check that the fallback actually works?

Test with BrowserStack or a real iOS 13 device and IE11. Chrome DevTools allows you to disable WebP via the Network panel > Disable cache + override user-agent, but this is not 100% reliable. A real-world test will avoid unpleasant surprises post-deployment.

Also verify that the CDN does not cache the wrong variant. If the Vary: Accept is not configured server-side and the CDN serves a unified cache, an IE user might receive WebP from the cache, breaking the display. With picture, this problem disappears since the HTML explicitly declares both URLs, but remain vigilant if you mix picture and content negotiation.

• Generate WebP versions of all strategic images (hero, products, banners).
• Rewrite critical tags into .
• Retain alt, width, and height attributes on the final tag to avoid CLS and accessibility issues.
• Test the fallback on Safari iOS 13 and IE11 (BrowserStack or real devices).
• Check that the CDN does not cache the wrong variant (Vary: Accept if server negotiation).
• Monitor LCP before/after WebP migration via PageSpeed Insights and CrUX to quantify the real gain.