warning Critical findings
speed Measured performance
checklist Phased plan
The panel that lies: what I find when I audit a live site
A technical audit of a client site that was live and appeared to work. Measured, not opined: figures taken with an automated browser at four screen widths.
Tech stack
Headless ChromeMeasured at 4 widthsRemediation plan
flag
Context
The site was online and, from the outside, looked finished. The audit was not there to redesign it: it was there to measure how well it does its job for someone opening it on a phone over mobile data, which is how most people open it.
search
Findings
- • The admin panel saved changes in the browser itself and answered «published»: whoever used it believed they were updating the site, and they were not.
- • 858 MB of PDF files served to the public, with downloads of up to 6.9 minutes over a 4G connection.
- • A 4.67 MB homepage and a main content load time of between 6 and 9 seconds.
construction
Recommendation
- • A first phase of roughly one day of work, prioritised by impact over effort.
- • Homepage from 4.67 MB down to around 0.9 MB.
- • Main content load time from 6-9 seconds down to a range of 1.5 to 2.5 seconds.
lightbulb
What I learned
That the worst failure is not the one that breaks, it is the one that lies. A panel confirming a publication that never happened destroys trust in the whole system, and nobody reports it as a bug because on screen everything went fine.