Check the Real Layout Before Optimizing Image Sizes

Before changing a WordPress image’s sizes attribute, check how wide that image actually appears. I was preparing an archive-card optimization when the active site showed five desktop columns, while the theme and task plan assumed six. A saved CSS override caused the difference. A hint based on six columns could have selected an image too small for the real layout, particularly on a high-density display. I paused the implementation to document the mismatch. The next step was to decide which layouts the helper needed to support before measuring any reduction in image transfer.

Measure the rendered image width

The browser uses sizes with viewport width and device pixel ratio to choose a source candidate. A six-column hint for a five-column grid can select an image that is too small. The page may still look acceptable on my display while becoming soft on a high-density screen.

Because the promised change was “bytes only, no visible difference,” accurate rendered geometry was not a detail. It was the foundation of the feature.

Check saved CSS and theme overrides

The theme stylesheet defined one desktop grid. WordPress settings stored another preference. A later database-managed CSS snippet overrode both on the active site. Reading only the code would have produced a tidy patch for a layout that users did not actually see.

This is common in mature WordPress systems: theme code, child themes, customizer values, snippets, plugins, and host behavior combine at runtime. A baseline must inspect the rendered page, not just the intended architecture.

Define when to pause the change

The plan said to stop if the real grid differed from the documented layout. That sentence removed pressure to rationalize the mismatch after discovery. I recorded the active versions, saved column settings, override source, viewport measurements, and the images that would be quality-sensitive.

A stop condition is useful because it converts uncertainty into an expected outcome. Finding the mismatch early avoids testing a patch against the wrong layout.

There were three valid next decisions. I could model both the five-column site override and six-column theme default conservatively. I could remove the saved override through a separately authorized content/configuration change. Or I could keep the optimization scoped to the theme default and accept that the active site was not yet eligible.

Those options have different ownership and rollout risks. Choosing among them silently inside an image helper would turn a performance task into an undocumented decision about supported layouts.

Record source selection and image quality

1. Measure the rendered component at breakpoint edges.
2. Record device pixel ratio and selected currentSrc.
3. Find site-level and child-theme overrides.
4. Include low-resolution and unusual srcset fixtures.
5. Define the visible-quality floor.
6. Write stop conditions before implementation.
7. Keep layout, media regeneration, and source selection as separate changes.

Only after that would I write a failing test for the new hint.

Resolve the layout assumptions before implementation

It would have been easy to claim a smaller transfer in one Lighthouse run. The real goal was lower transfer with unchanged geometry and sharpness across supported sites. Shipping against a incorrect layout assumptions would have optimized the measurement while weakening the image.

Restraint also kept rollback simple: there was nothing to undo, no content had changed, and the decision could be made with complete evidence.

The baseline still produced useful work. Stopping did not mean the session produced nothing. I documented the effective column counts at mobile, tablet, and desktop widths; identified the database-managed override; recorded representative normal, low-resolution, and unusual candidate sets; and clarified that no missing-image fixture existed. That evidence narrowed the next decision and prevented another developer from repeating the investigation.

It also exposed an unresolved question about who controls the layout. If saved CSS can override the documented component layout, a reusable renderer cannot safely assume only repository styles exist. The team now has to decide whether site-level presentation is an intentional supported variant or configuration drift to remove. That decision belongs with the people responsible for the site’s design and content, not inside a performance helper. The measurements remain useful even though no implementation changed. The deliverable can be a clearer scope, a test fixture list, and a precise reason to wait.

I communicated the pause in outcome language: no page, media item, saved setting, or production environment changed; the intended byte reduction remains unverified; and the unresolved choice is whether the site override is supported behavior. That is more useful than saying the task is “blocked,” because it tells the next decision-maker exactly what is safe and what remains open.

The pause also protected the low-resolution fixtures. An optimization tested only on ideal source images can hide quality regressions until the least replaceable asset reaches a dense display. Edge content belongs in the baseline, not at the end.

Make the optimization testable

Write down the rendered widths, breakpoints, device pixel ratios, and image candidates before changing source-selection hints. Include a low-resolution asset and any layout that differs from the theme default. Decide what quality must remain unchanged and which unexpected findings should pause implementation. Once the supported layouts are clear, compare selected image files and visible sharpness before and after the patch. Smaller transfers are useful only when they preserve the result the reader needs.

Photo by Lukas Blazek on Pexels.