Verra Our free website audit. Score your site in under a minute, no email needed.
Check my site
Performance
Our website scored 73 on a phone while scoring 100 on a laptop. We sell performance work. Here is exactly what was wrong, what we did about it, and how to check the numbers without taking our word for anything.
73 to 97
Performance on a phone
4.5s to 2.5s
Largest paint
3 changes
Nothing rewritten
Background
We build a free audit tool called Verra, and while testing it we pointed it at our own domain. It reported a performance score of 73 on a phone against 100 on a laptop, and flagged the gap as a high severity finding. Our own service pages say we build against real performance budgets and test on a mid range Android rather than a laptop. Our own tool disagreed.
That is an uncomfortable position to be in publicly, because the tool is free and anybody can run it against us. It is also the most useful kind of bug report, because it arrived with evidence attached.
The diagnosis
The largest paint was taking 4.5 seconds, and 2.1 seconds of that was spent after the browser already had everything it needed. The page had downloaded the image, parsed the HTML and was simply not drawing anything. Blocking time was only 173 milliseconds, so the JavaScript was not slow. Something was holding the content back rather than something being heavy.
The work
Anything above the fold now renders visible in the HTML the server sends, and rises into place with a transform only animation. Opacity is never touched, so the browser can paint on the first frame instead of waiting for script. The entrance animation survived intact.
Every scroll reveal on the page was building its own intersection observer and forcing a synchronous layout to check its position. That is now a single shared observer with no layout reads. Honest note: this one did not move the numbers.
The Google tag was running a 134 millisecond task while the page was still trying to draw. It now loads once the page is idle. Consent defaults still apply first, and no data is lost.
Results
Three samples taken from Google PageSpeed Insights on mobile, after deploying. The score before the work was 73 with a largest paint of 4.5 seconds.
| Measure | Before | After | What it means |
|---|---|---|---|
| Performance score on a phone | 73 | 97 | Above 90 is the band Google treats as good. |
| Largest contentful paint | 4.5s | 2.5s | This is the moment the main content appears. Google wants it under 2.5 seconds. |
| Total blocking time | 173ms | 90ms | How long the page ignores taps and scrolls while it works. |
| Layout shift | 0 | 0 | Nothing jumped around before or after, which is the part users notice most. |
What we got wrong
Two of the three changes did far less than expected. Replacing twenty two observers with one was supposed to cut the time spent on layout, and that figure barely moved, from 619 to 616 milliseconds. Deferring the analytics tag helped less than hoped, because it still runs and still gets measured, just later. Almost the entire gain came from the first change alone. We are leaving the other two in because both are simply less machinery doing the same job, but presenting all three as the fix would be a nicer story than a true one.
Do not take our word for it
This is our own website, so none of it depends on trusting us. Every number above is reproducible in about a minute.
Built with
That gap is extremely common and usually comes from one or two specific things rather than the whole build. Run the free audit and see what it says, or send us the URL and we will look at it properly.
