The first change

The site's icon font was replaced with SVG masks. Each icon class used in the markup got its own mask in the stylesheet, so any element that asked for an icon by class name kept rendering the same icon without a single markup change.

Two icons didn't ask by class name. The forward and back arrows on the homepage gallery were drawn in the stylesheet itself, from the icon font's glyph codes. The swap was keyed off the classes in the markup, so it never saw them. With the font gone, those glyph codes pointed at nothing, and the arrows rendered blank.

The same change added a rule that gave large icons flex layout and automatic side margins. On pages where icons sat in a row, that rule shifted them out of alignment into a stair-step, and icons that had been left-aligned ended up centered.

The check that passed

Early the next morning, a second pass purged unused rules from the stylesheet and cut it from 283KB to 209KB minified. Deleting that much CSS by hand-picked spot checks would have been a guess, so the purge was verified mechanically: every page was captured at desktop and phone widths before and after, and the screenshots were compared pixel by pixel.

Every page matched. The purge really had changed nothing visible.

But the "before" screenshots were taken from the site as it stood that morning - after the icon swap. The blank arrows and the shifted icon rows were in both sets of screenshots, so they matched too. The comparison had no way to tell a regression that was already there from a page that was correct.

How they surfaced

Both regressions were found by eye, not by the check. The stair-stepped icons showed up on the About page, and the missing arrows on the homepage gallery. Both were fixed the same day, within about four hours of the diff passing.

The fixes themselves were small. The arrows moved to the same SVG masks as every other icon, and the centering rule was removed so the icon rows lined up again.

What the diff actually proved

A before-and-after comparison proves one thing: nothing changed since the baseline. It says nothing about whether the baseline was right. Take the baseline after an unverified change, and that change gets quietly promoted to "correct" - every later comparison will protect it.

Two habits would have caught both regressions before they shipped:

  • Take one baseline for the whole cleanup, from the last known-good state before its first change, and compare every step against it.
  • Before changing how something is drawn, inventory every place it can come from - classes in markup, content values in the stylesheet, and scripts - not just the obvious one.

The broader rule, and where the baseline belongs when removing things at scale, is in the Insight Delete With Proof.

Cleaning up a site you can't afford to break?

A cleanup checked against a real baseline removes what's dead and proves nothing else moved.