Web Tools · performance audits
Website performance audits that reveal real user bottlenecks
A grounded way to read Core Web Vitals, trace render-blocking work and turn field data into the next useful fix.
The useful version of a web practice is the one that can be repeated by someone else. This note keeps the scope tight, names the trade-offs and ends with a way to check the result. Continue with the performance audits index or meet the Sites To Use editorial desk behind the notes.
Start with the slowest useful moment
A performance audit is most useful when it names the moment a person is waiting for, not just the metric that looks bad. Begin with the first meaningful heading, the first product image or the first control a visitor needs. Record when it becomes visible and what still competes with it for the main thread.
The distinction matters because a page can score acceptably while the thing that gives it meaning arrives late. A small trace of the loading sequence usually explains more than a long list of generic recommendations.
Separate evidence from suspects
Field data describes what people experienced across devices and connections. A local trace helps explain why. Keep the two views beside each other, then mark each possible cause as observed, plausible or still unknown. This makes the audit honest and gives the next person a short queue instead of a cloud of guesses.
Look first for render-blocking styles, oversized hero images, font swaps and scripts that run before interaction. Change one class of work at a time so the result can be attributed.
Leave a repair note
A good audit ends with a small decision record: what changed, which page was checked, what improved and what remains outside the current budget. Repeat the same journey after each meaningful release. Over time that sequence becomes a more reliable instrument than a one-off score.
