Starting state and constraints
The client operated an image-heavy WordPress site behind a content delivery network. The August delivery notes record that recent uploads were no longer being converted by the previous image workflow. Original media had to remain available, and repeat runs needed to avoid overlapping or rewriting unchanged files.
A retained file manifest from 5 August contains 8,293 JPEG/PNG source paths. We independently recounted 8,098 paths with a corresponding WebP sibling, leaving 195 without one in that snapshot. This is file presence, not a visual-quality or byte-size audit.
Implementation
- Scan uploaded JPEG and PNG files and generate a WebP sibling alongside the original.
- Use a process lock to prevent overlapping jobs. Skip an existing sibling when it is newer than the source.
- Write new output to a temporary file, compare its size with the original and retain it only when it is smaller and non-empty.
- Record converted, skipped, discarded and failed counts for the operator.
- Serve the format through an Accept-aware server rule, retaining the original as the fallback. The delivery report records that the process was automated.
Supported result and timeframe
| Evidence | What it supports |
|---|---|
| 5 August retained manifest | 8,098 of 8,293 source paths had matching WebP siblings when recounted. |
| 6 August delivery notes and report | Recorded coverage of 8,290 of 8,293 images, with automation in place. |
| Retained implementation script | Original preservation, locking, freshness checks, new-output size checks and per-run counts. |
The later figure is the recorded delivery result, not a fresh full-library inventory. The manifest and report are different evidence types; neither proves that every file was smaller, visually acceptable or served from every CDN cache.
Read the anonymized evidence summary. Full client reports and source paths remain private. No claim about rankings, enquiries, revenue or site-wide load time is derived from these counts.
A separate live check and an important limit
On 17 October we checked one image referenced by the live homepage. A WebP-capable request returned HTTP 200 with image/webp; a request for the original format returned HTTP 200 with image/png. Both responses varied on Accept. This confirms format negotiation for that sample only.
The sampled WebP was 9,806 bytes and the PNG was 6,430 bytes. Format conversion alone therefore did not reduce that asset's transfer size. The script's size comparison applies to newly generated files; it skips existing siblings that are newer than their source. The sample does not establish which process generated that existing file.
A follow-up audit should compare existing derivatives as well as newly generated ones, sample visual quality and check CDN behavior. We did not modify the client site during this publication review. The delivery case is a documented workflow and coverage change, not a claim that all current images are optimized.
What another team can reuse
Treat media optimization as an operated pipeline: preserve originals, make repeat runs safe, define useful output, log failures and verify the response a visitor actually receives. A file extension or coverage count is only one acceptance check.
For deployment and ownership decisions, see our CI/CD project service and CDN comparison guide. Our separate homepage case demonstrates a dated page-level measurement with its own baseline and limits.