Test a real journey, not only the homepage
Open a service page, complete a form and, if relevant, try the booking flow. Test on a phone and an ordinary connection as well as a desktop. Note what feels slow: the first response, the main image, opening a menu, selecting a date or submitting a request.
A laboratory test is useful for reproducing a problem. Field data shows what real visitors experienced, where enough data is available. Treat them as complementary. A single test score is not a complete judgement of the site, and a quiet site may have too little field data for URL-level conclusions.
Understand the three Core Web Vitals
Core Web Vitals cover main-content loading (Largest Contentful Paint), responsiveness to interactions (Interaction to Next Paint) and visual stability (Cumulative Layout Shift). Google’s Web Vitals documentation explains these measures and how field assessment works.
They help describe different failures. A page can show content quickly but respond poorly when someone taps a filter. Another may be responsive but shift a button as an image appears. Improving one measure will not automatically fix the others.
| Symptom | Possible causes | First check |
|---|---|---|
| Long wait before anything appears | Server processing, redirects or connection delays. | Response timing and unnecessary redirect chains. |
| Text appears but the main image waits | Large images or an image discovered too late. | Image dimensions, file size and how it is loaded. |
| Buttons respond slowly | Heavy scripts or too much work during interaction. | What runs when the control is used. |
| Content jumps while loading | Missing media dimensions or late inserted content. | Space reserved for images, embeds and banners. |
| Checkout or form stalls | An external service or slow application work. | The failing request and its server-side outcome. |
Reduce work before adding infrastructure
Check whether images are served near the size at which they are displayed. Review scripts and embeds: analytics, chat tools, video and third-party widgets can all add work. Keep the ones that serve a clear purpose and load them appropriately without making essential controls unavailable.
For an application, a slow screen may involve an expensive database query or a remote call. More server capacity can hide the symptom without addressing repeated unnecessary work. Ask for timing evidence and a change that can be measured afterwards.
Protect the business action while improving the score
Do not remove useful content or delay essential controls solely to improve a test result. The goal is a usable journey. If a booking confirmation waits for an email service, separate the completed booking from the notification, with visible recovery for failures. The booking reliability guide discusses that distinction.
Before and after a change, test the same page under similar conditions and complete its main action. Check navigation, images, forms and consent behaviour as well as speed. If caching is involved, verify that customers never receive another person’s private information.
Decide whether the problem needs ongoing care or development
Routine monitoring and prioritising improvements may fit Sitewell. A slow custom workflow or substantial frontend change belongs in a development discussion. A full rebuild should follow an assessment of the existing system, not a poor score alone; see redesign versus rebuild.
Get help identifying the slow step
Send a page URL, the action that feels slow and the device you used. That gives us a more useful starting point than a score without context.