Performance conversations with clients can become vague very quickly.
A site feels slow, a page feels heavy or someone says it loads fine on their laptop but not on their phone. Those comments are useful because they describe a real experience, but they are hard to act on without more context. I wanted a way to connect those comments to something measurable without turning the conversation into a wall of technical scores.
That was why Core Web Vitals interested me in 2020. The useful part was not that they gave developers another set of numbers to chase. The useful part was that the metrics described things visitors actually notice: when the main content appears, whether the page responds to interaction and whether the layout jumps around while somebody is trying to read or tap something.
Starting With The Visitor Experience
I found it easier to explain performance by starting with what the visitor saw. If the largest image or heading took too long to appear, the page felt slow even if some smaller assets had already loaded. If a button took too long to respond, the interface felt broken. If the content shifted after a late-loading advert, font or image appeared, the page felt unstable.
Those observations mapped much better to practical work than a generic performance score. A score might tell me the page needs improvement, but it does not always explain where the visitor is feeling the problem. Looking at the user experience first made the technical audit more useful.
Finding The Real Causes
On a typical WordPress site, the causes were rarely surprising. Large hero images were often responsible for slow first impressions. Third-party scripts could delay interaction. Missing image dimensions or late-loading embeds could push content around after the page had already started rendering.
I started grouping performance work around those behaviours. If the main content was slow, I looked at server response, caching, the largest visible image and render-blocking files. If the page moved while loading, I looked for images without width and height attributes, injected banners or components that did not reserve space. If interactions felt sluggish, I looked at JavaScript running during the first few seconds of the visit.
Explaining Trade-Offs
The metrics also helped with trade-offs. If a client wanted another tracking script, a chat widget or a heavier visual effect, the conversation could move from opinion to impact. The question became whether the feature was useful enough to justify the extra work the browser had to do.
That did not mean every heavy feature had to be removed. Some features are commercially useful. The important part was making the cost visible. Once the cost was visible, decisions became easier to make honestly.
What I Took From It
Retrospectively, Core Web Vitals gave me a better language for performance work. I still cared about asset sizes, caching, JavaScript and images, but I could connect those details to what the visitor experienced on the page.
That made the work easier to justify. Instead of saying a site needed performance improvements because a tool said so, I could explain that the main content appeared too late, the layout moved after loading or the page was asking the browser to do too much before someone could interact with it. That is a much better conversation to have with a business owner because it connects technical work to the person using the website.