WordPress has strong responsive-image behavior, but a WebP migration can still go wrong if site owners only check that a .webp file exists. The browser may choose an unexpected size, the theme may output a JPEG fallback, a plugin may rewrite markup, or a CDN may serve a different variant than the HTML suggests.
The practical question is not "Did conversion run?" The question is "Is the rendered page delivering the right image to the right viewport?" Weak WebP advice skips that verification step. A real audit records the rendered markup, selected candidate, response Content-Type, fallback path, and template where the image appears.
Understand What srcset Is Doing#
The srcset attribute gives the browser a list of image candidates. The sizes attribute helps the browser estimate how large the image will appear in the layout. WordPress uses this mechanism to serve responsive images when it has the required image sizes available. The WordPress developer guide on responsive images explains the platform behavior in more detail.
In a WebP workflow, each size may need a WebP counterpart, a fallback, or a delivery rule. If only one size is converted, the browser may still choose an older JPEG candidate at some breakpoints.
With GetWebP, the Batch Conversion workflow scans wp-content/uploads, generates .webp sibling files, optionally generates .avif sibling files, and keeps the original files in place. The Media Library status column is useful, but it is not the final proof. The final proof is the public page response.
Inspect Rendered HTML#
Do not rely on the editor screen. Open the public page and inspect the rendered image element. WordPress themes, block output, page builders, image plugins, lazy-loading tools, and CDNs can all modify final markup.
Check:
srcvaluesrcsetcandidatessizesvalue- file extensions or negotiated formats
- width and height attributes
- lazy-loading attribute
- CSS layout width
The rendered HTML is what the browser uses. The media-library file list is only part of the story.
GetWebP's Frontend Delivery documentation describes the PHP delivery hooks for post content, featured images, programmatic attachment calls, and output buffering. It also states that delivery checks whether a .webp sibling exists before rewriting the image. That is why rendered HTML inspection should be paired with a disk/status check for the generated sibling.
Look for one of these patterns:
<img src="/uploads/photo.jpg.webp" srcset="/uploads/photo-768.jpg.webp 768w, /uploads/photo-1200.jpg.webp 1200w" alt="...">
or, with picture fallback:
<picture>
<source srcset="/uploads/photo.jpg.avif" type="image/avif">
<source srcset="/uploads/photo.jpg.webp" type="image/webp">
<img src="/uploads/photo.jpg" alt="...">
</picture>
The second pattern is easier to audit for fallback behavior because the original img source remains visible.
Verify the Browser's Chosen Candidate#
A correct-looking srcset can still produce surprising results if sizes does not match the layout. The browser may download a larger file than necessary because it believes the image will be wider than it really is.
Use DevTools to inspect the current source selected by the browser. Test at mobile, tablet, and desktop widths. If a 1200-pixel image is selected for a 360-pixel slot, the issue may be sizes, template CSS, or missing intermediate files.
This is where responsive-image work often saves more than changing compression settings.
Record the viewport and rendered slot. For example:
Template: single post
Viewport: 390px wide
Rendered image slot: 358px
Browser-selected candidate: 640w WebP
Response Content-Type: image/webp
Potential issue: none
And a failing case:
Template: category card
Viewport: 390px wide
Rendered image slot: 164px
Browser-selected candidate: 1200w JPEG
Potential issue: missing WebP candidate for generated thumbnail or incorrect sizes attribute
Check WebP and Fallback Relationships#
Some WordPress setups generate WebP files beside originals. Others rewrite image URLs dynamically. Others use a CDN or image service. Each pattern needs different verification.
For explicit files, confirm that each responsive size has the expected WebP output:
article-hero-300x200.webp
article-hero-768x512.webp
article-hero-1024x683.webp
For rewritten delivery, check response headers and actual downloaded file type. The browser's network panel is more reliable than the filename alone.
GetWebP's Getting Started guide recommends opening a page with images, filtering the Network panel by images, and checking response Content-Type for image/webp or image/avif. Do this on the public URL after cache purge, not only inside wp-admin.
If DevTools still shows JPEG or PNG after conversion, use the plugin Troubleshooting checklist: confirm frontend delivery is enabled, clear stale page/CDN caches, test private browsing, and compare PHP delivery against server rewrite if needed.
Watch Lazy Loading on Important Images#
WordPress and themes may add lazy loading automatically. Lazy loading is useful for below-the-fold images, but it can delay a visible hero or featured image. MDN's img element reference documents the loading attribute and related image behavior.
For templates where the featured image appears at the top of the page, check whether it is lazy-loaded. If it is also the likely Largest Contentful Paint element, measure before accepting that behavior.
The correct decision depends on the template. A below-the-fold related-post thumbnail can be lazy. A top hero image usually deserves closer attention.
GetWebP rewrites src and srcset while preserving loading, width, height, and other attributes. That is good for stability, but it also means a bad lazy-loading decision can remain bad after the format migration. If a custom lazy-load plugin moves URLs into data-src, test output-buffer delivery because normal src/srcset inspection may miss the real downloaded URL.
Test Theme and Plugin Variations#
A WordPress site may output images differently in:
- classic editor posts
- block editor posts
- archive cards
- widgets
- product pages
- page builder sections
- custom theme templates
- RSS or email templates
Verify more than one page type. A WebP pipeline that works in blog posts may fail in a product gallery or custom landing page.
Use a matrix rather than a single screenshot:
| Page type | Image role | Required check |
|---|---|---|
| Single post | featured image | post_thumbnail_html, selected candidate, lazy loading |
| Block editor post | inline image | the_content, srcset, fallback |
| Archive card | thumbnail | rendered slot width and selected candidate |
| WooCommerce product | gallery and variation thumbnail | product image rewrite and selected variant |
| Page builder section | hero/background image | output buffer or server rewrite behavior |
| Custom template | programmatic image call | wp_get_attachment_image output |
Keep Alt Text and Attachment Data Intact#
Responsive delivery should not break the editorial data around the image. Make sure alt text, captions, and attachment relationships remain intact after conversion or URL rewriting.
If a workflow creates separate WebP attachments instead of derivatives, editors may accidentally choose the wrong file and lose the original metadata relationship. Prefer a workflow that keeps the editorial attachment stable and generates optimized delivery assets behind it.
In GetWebP's WordPress model, the original remains the attachment and generated WebP/AVIF files are sibling variants. That is the right shape for editorial continuity: the alt text, caption, featured-image relationship, and gallery membership should stay tied to the original attachment record.
A Simple Verification Record#
For each key template, record:
Template: single post
Image role: featured image
Rendered width: 820px desktop, 390px mobile
Selected source: 1024w desktop, 640w mobile
Format served: WebP
Fallback available: yes
Alt text preserved: yes
Lazy loading: disabled for hero
GetWebP status: WebP complete in Media Library
Delivery mode: PHP picture tags
Fallback test: original JPEG returned 200
Cache state: CDN purged before test
This gives site owners a practical audit trail.
WordPress srcset and WebP can work together well, but only when the real output is verified. Check rendered HTML, selected candidates, response headers, fallback behavior, lazy loading, cache state, and editor metadata before declaring the migration complete.
Jack
GetWebP EditorJack writes GetWebP guides about local-first image conversion, WebP workflows, browser compatibility, and practical performance checks for teams that publish images on the web.