The site had everything the usual advice tells you to do. Caching was in place, stylesheets loaded without holding up the page, images were properly sized and served at sensible dimensions for each device. It was still taking seven and a half seconds before a visitor could reliably tap anything, and nobody could work out why. The cause turned out to be a single line of styling near the top of the stylesheet. Removing it cut that by 86 per cent, and changed nothing about how the site looks or behaves.
What we were trying to solve
A busy online shop scoring badly on Google’s PageSpeed test. Every obvious culprit had already been dealt with. The reports kept pointing at something called “blocking time”, which sounds like the page is slow to load, except the page was loading perfectly well. Something else was going on, and the standard advice had run out.
What we found
One line, written by hand years earlier, that applied a small animation to every element on the page. Not to the buttons and links you would animate on purpose, but to everything, including hundreds of things nobody would ever animate.
On the home page that meant 1,579 of the 1,628 elements were being watched for animation at all times.
Why that slowed everything down
Browsers animate things in two very different ways, and the difference matters more than you would expect.
Fading a button or changing its colour is cheap. The graphics chip handles it, the same one that plays video, and the page carries on responding to taps and scrolls while it happens.
Moving or resizing anything is expensive. For that, the browser has to re-measure and re-arrange the whole page, and it can only do that using the same single thread it uses to notice you tapping. While it is measuring, it cannot respond to you.
That one line told the browser to be ready for both kinds, on everything. So instead of a handful of buttons doing cheap colour fades, the browser was holding more than fifteen hundred elements permanently ready for the expensive kind of change.
That is what blocking time actually measures. It is not the page loading slowly. It is the browser being too busy re-measuring itself to notice you are there.
What changed
What was measured | Before | After | |
Blocking time | 7,555 ms | 1,090 ms | 86% less |
Layout work | 6,760 ms | 1,107 ms | 84% less |
Worst-case tap delay | 2,492 ms | 393 ms | 84% less |
Elements animating expensively | 951 | 3 |
Other work was going on that week, so not every improvement the site saw came from this. But layout work and blocking time are what this particular change acts on, and the last row can only have come from it, because icons and images do not cause a browser to re-measure a page.
Nothing on the site looks different. Every hover effect, every fade, every animation a visitor might actually notice still works exactly as it did.
What we put in its place
We did not remove animation. We moved it to the things people actually interact with, the links, buttons, menu, add to cart control and product tiles, and we named the specific effects we wanted rather than saying “anything”.
Before touching it, we counted what every hover effect on the site actually changed. There were 174 of them. Every single one changed a colour, a shadow, a border or a fade. Not one moved or resized anything. That is why this was a safe change rather than a gamble, and the counting took about ten minutes.
We also found three animations that had never worked at all. They were set to animate something browsers cannot animate, and had been sitting there doing nothing for years.
What to check on your own site
How much this costs you depends on how much is on your pages. The damage scales with the number of elements, so a simple brochure site with a couple of hundred might lose a fraction of what we did, while a shop with long product grids and listings will be closer to our figures. But the browser is doing needless work either way, and it quietly gets worse every time the site grows. Ours had been there for years, getting more expensive with every product page we added, and nobody noticed because it never broke anything. It only ever made things slower.
Two things to look at, and neither needs a developer.
Search your stylesheet for the words transition: all. If it appears next to an asterisk, which is CSS for “everything”, you may have the same problem sitting in your site right now.
Then open your PageSpeed report and look for a line called “Avoid non-composited animations”. Most people never see it, because it sits below all the advice about images and caching. That is where this shows up, and it is the only place it does.
The point
Every performance guide talks about images, caching and scripts. That advice is right, and we had followed all of it. None of those guides mentions auditing what your stylesheet is quietly animating, and on this site that one omission was costing more than every image on the page combined.
The fix took an afternoon. Finding it took considerably longer, and the only reason we found it at all was that we ran out of things experience told us to try.