While investigating a website header’s performance, we found it repeatedly measuring things we had already defined in the styles.
The header changes size as you scroll. Its code was checking the expanded and compact layouts to work out the animation, then doing that setup again during startup.
We removed the repeated work. Did that make the page noticeably faster?
We couldn’t establish that from the evidence we had.
Forty checks became zero
The browser’s style rules already described the two layouts. We changed the animation to use those definitions directly, with JavaScript supplying how far the visitor had scrolled.
In our local desktop comparison, the repeated style checks fell from forty to zero. The navigation underline’s measurement passes fell from three to one.
We still measured the links themselves because fonts and screen size can move them. Storing those positions let the underline reuse them when someone hovered over a link or reached it with the keyboard.
That was useful cleanup. It removed repeated setup while keeping measurements we actually needed.
The stopwatch didn’t give us a headline
The local measurements took fractions of a millisecond. We also couldn’t reproduce the long startup task that had prompted the investigation in a browser trace—a recording of what the browser was doing over time.
So we had evidence of less repeated work, but no measured loading improvement we could fairly attribute to the change.
We checked the header’s sizes, scrolling in both directions, resizing, keyboard focus, and reduced-motion behavior. Those checks supported keeping the change. A production-equivalent trace was still needed to investigate the original delay.
Forty down to zero is a pleasing number to write in a notebook. It doesn’t, by itself, tell us how the page feels to the person using it.