Performance / 3 min read
Make the useful part of your site arrive sooner.
How to discuss speed with your web team, prioritize the right fixes, and distinguish a lab score from customer experience.
The useful part
Measure loading, response, and stability on the pages customers use. Fix the delay you can demonstrate, then check the same journey again.
Describe the delay before requesting a fix.
“The website is slow” can mean several things. The first content may take too long to arrive. A button may react late. A page may jump when a photograph loads. Start by recording the page, device, network conditions, and action. A short screen recording can make the problem easier for a web team to reproduce.
Choose commercially important pages for the first review: the home page, a high-priority service, the menu or product page, and the booking path. An excellent score on a quiet article does not explain how a large menu or third-party calendar behaves.
Know the three useful measures.
Core Web Vitals cover loading, interaction, and visual stability. Google’s recommended good thresholds are LCP at 2.5 seconds or less, INP at 200 milliseconds or less, and CLS at 0.1 or less, assessed at the 75th percentile and separated by device type. These are reference thresholds, not claimed WebsitePros client results.
Source: web.dev: Core Web Vitals
| Measure | What to ask your team |
|---|---|
| LCP — loading | What is the largest visible content element, and why is it late? |
| INP — interaction | Which customer action takes too long to respond? |
| CLS — stability | Which image, font or component moves content unexpectedly? |
Fix the measured bottleneck.
A large hero photograph can be part of a loading problem, but compressing it is not always the whole solution. The browser may discover it late, wait for another resource, or delay displaying it. web.dev’s LCP guidance recommends inspecting the full loading sequence rather than assuming a single file-size fix explains the result.
Ask for a small before-and-after report that includes the URL, test conditions, observed issue, change, and new result. Keep the same conditions when comparing. If a booking widget is involved, also repeat the booking interaction; removing a useful feature to improve a score can make the customer journey worse.
Keep lab and visitor data separate.
A lab test is useful for reproducing a problem and testing a fix. Data from real visits helps describe what customers experience across devices and connections. Label the evidence you have and acknowledge when visitor data is unavailable. A newly launched or low-traffic site may not provide a useful field sample yet.
Add performance checks to the content workflow. New video, a chat tool, tracking code, or a replacement hero can change the result. The practical goal is a dependable customer path that remains fast as the business adds content, not a screenshot of a score that nobody checks again.
Before you act
A few useful answers.
Does a high Lighthouse score prove every customer has a fast visit?
No. Lighthouse is a lab test under specific conditions. Use it to diagnose and compare changes, and review real visitor data when a useful sample is available.
Should I remove all photography to improve speed?
No. First identify the delay. Proper image sizing, loading behavior, and resource priorities can preserve useful photography while improving the experience.
Your next decision
Bring the real question.
We can review the website, the customer journey, and the work needed to improve it.
Book a meetingReview current services and pricing