Choosing an image format is only one part of managing images on a website. Someone still has to upload the file, find it later, replace it without breaking a page, and understand which version is the original. A smaller download is useful; an upload process that nobody trusts is not.
I would build the workflow around the Media Library attachment, with a clear distinction between a source asset and the versions delivered to visitors. The editor should not have to remember a different optimisation ritual for every page.
Check what the installation can process
WordPress introduced WebP support in version 5.8, including its use through the Media Library where the image-processing environment supports it. That history does not establish what every current host, plugin combination or image editor will do. Test the actual installation before promising an automatic conversion workflow.
Use a small set of representative images: a photograph, a graphic with sharp lettering, and an image with transparency. Check upload, thumbnail generation, cropping, replacement and the final page. A successful upload is only the first step.
Decide where conversion belongs
There are several reasonable arrangements. An editor can upload a prepared WebP, a WordPress image-processing integration can create optimised derivatives, or an image delivery service can transform requests. Choose one clear owner for each step. Multiple overlapping optimisers make it difficult to explain which file a visitor is seeing.
WordPress provides the image_editor_output_format filter for changing the output format used during image processing. That is a development hook, not a promise that adding a snippet will convert an entire existing library. Existing attachments and already generated sizes need a separately planned migration.
Keep the source file available, either in a documented archive or through a workflow that retains it safely. Do not assume every optimisation plugin preserves originals in the same place. If a photograph might later be needed for print, a tighter crop or a larger display, the web derivative should not become its only surviving copy.
Preserve the attachment, not just the filename
An attachment carries more than a path: alternative text, a caption, credit information and links from saved content can all depend on it. Replacing files directly in an uploads directory can leave that information out of step with the actual image. Use a replacement or regeneration process that understands WordPress records.
Give uploads useful names before they reach the library. Describe the image’s purpose rather than a sequence such as “final-final-small”. Alternative text needs its own decision: describe relevant content, and leave decorative images empty when the surrounding text already supplies the information.
When updating an established site, start with a small batch and keep a recovery copy. Confirm that article images, cards, social previews and lightboxes still point at usable assets before processing everything. Include a page that deliberately opens the larger image, because a thumbnail check will not catch a damaged original.
Measure the delivered result
Compare files at the same displayed dimensions and a quality level that suits the material. WebP is not a reason to send a very large image into a small card. Inspect fine lines and text as well as photographs; the most noticeable damage may be somewhere a casual glance misses.
On the final page, inspect the selected image source and transferred bytes. Check responsive sizes at more than one viewport, then confirm that caching does not keep an old version visible after replacement. Record the settings that produced the accepted result so the next upload follows the same process.
Loading behaviour is a separate decision. A sensibly sized WebP can still be delayed at the wrong moment, as discussed in native image lazy-loading in WordPress. The useful workflow brings both decisions together while leaving everyday editing straightforward.