If your business website feels slow, start with the page that earns enquiries or sales, record what is slow, and fix that cause first. A new host may help a slow server response. It will not shrink a giant hero image, remove a blocking pop-up or make a heavy form script respond instantly. This 30-minute triage gives a small-business owner a useful brief for a designer, developer or hosting provider.
If the diagnosis does point to the hosting layer, compare Krystal’s managed WordPress hosting alongside your current plan. Check the live plan’s backup, staging, traffic and support terms against your own needs. First, make sure the server is actually the bottleneck.
What “slow” means to a customer
Google’s current Core Web Vitals look at three different experiences. Largest Contentful Paint (LCP) is when the main visible content appears; the recommended target is 2.5 seconds or less. Interaction to Next Paint (INP) describes how promptly the page responds to a tap, click or keypress; the recommended target is 200 milliseconds or less. Cumulative Layout Shift (CLS) catches unexpected movement; the recommended score is 0.1 or less. These targets are assessed at the 75th percentile of visits, separately for mobile and desktop.
The numbers are diagnostic, not a promise of a search position. Google says good Core Web Vitals help page experience, but a perfect score by itself will not put a page at the top of results. For a local business, the practical question is whether someone can see the offer, use the form and reach the phone number without waiting or mis-tapping.
The 30-minute triage worksheet
- Minutes 0–5: choose one important URL. Use a service, product, booking or contact page that matters to revenue. Write down the exact URL, device and date. Do not average the homepage, blog and shop into one vague score.
- Minutes 5–10: look for real-user data. Open PageSpeed Insights for that URL and check whether its upper section says “This URL” or falls back to the whole origin. Check mobile and desktop separately. A low-traffic page may have no URL-level field data.
- Minutes 10–20: use the lab diagnosis. In the lower PageSpeed Insights section, note the LCP element, server response, render-blocking resources, image delivery, long tasks and layout-shift culprits. A lab run helps locate a cause; it is not a census of your visitors. The standard Lighthouse load test does not measure INP: its Total Blocking Time is a diagnostic proxy, so investigate real interactions separately.
- Minutes 20–25: use the page. On a real phone, load it on an ordinary connection, tap the menu, phone link and main call to action, then complete the enquiry path up to the point where you can safely submit a clearly labelled test.
- Minutes 25–30: write one action. Record the symptom, likely owner, smallest useful change and how you will check that the customer journey still works afterwards.
Use this compact record: URL / device / field-data scope / slow element or interaction / likely cause / proposed change / business-path check. It is far more useful to a developer than a screenshot of a single overall score.
Match the symptom to the first investigation
| What you notice | First place to look |
|---|---|
| Main heading or hero appears late | Identify the LCP element. Check initial server response, when its image or font request begins, file delivery and time before it renders. |
| Page appears, but buttons feel unresponsive | Inspect the slow interaction and the scripts running at that moment. Check forms, pop-ups, chat and analytics integrations. |
| Buttons jump just as you tap | Check images and embeds without reserved dimensions, banners inserted above content and font changes. |
| Only first uncached visits are slow | Compare cached and uncached behaviour, redirects, server response and the host’s caching rules. |
Before changing code, plugins or caching, make a recoverable backup and test on staging where available. Keep a rollback plan. One page can have several causes. Fix the most disruptive one, then measure again. If an image request starts late because a page builder hides it behind JavaScript, simply compressing the image may shift waiting time to the next stage without improving the visible result.
A worked example: a Formby service page
Imagine a local trades website where most enquiries come through a mobile service page. The first screen contains a large photograph, a quote button and a phone link. A PageSpeed lab report flags the photograph as the LCP element. The button is initially visible but moves when a promotion banner loads above it.
The first brief is specific: supply the photograph at an appropriate displayed size, confirm that the main image can be discovered early, reserve space for the banner and image, then recheck the mobile quote and phone journey. Moving hosting would be a premature first change unless the measurements also show a persistent server-response problem.
Important URL → field data scope → LCP, INP or CLS symptom → one controlled change → repeat the customer journey → compare the same URL and device.
When are images, fonts and scripts worth changing?
Images: start with the image actually visible in the first screen. Check its displayed dimensions, generated responsive sizes and whether the browser discovers it promptly. Modern formats can reduce transfer size, but choosing a format alone cannot solve a late request or delayed rendering. Keep the visual quality needed to show real products and work clearly.
Fonts: a custom font may delay text or cause text to reflow when it arrives. Check how many families and weights load, whether a sensible fallback is used and whether the main heading remains readable during loading. Do not remove brand typography blindly; compare the customer-facing result.
Scripts: chat widgets, sliders, forms, consent tools and tracking can all have a purpose. Measure when each runs and whether it delays the main content or a customer action. Removing a script can break enquiries or measurement, so keep a simple before-and-after checklist for the page’s important actions.
When does a hosting change make sense?
Investigate hosting when the initial HTML is consistently slow to arrive, uncached pages struggle, traffic spikes overwhelm the plan, or the current provider cannot support a sensible cache and recovery setup. Compare the same URL under similar conditions before and after any change. A new host should also be judged on migration support, backups, staging, support and email/DNS implications, not a speed promise alone.
Krystal’s current managed WordPress page describes caching, backups that vary by plan, staging and migration support. Review the current Krystal managed WordPress options if those features fit the measured issue and the responsibilities your business needs covered. Our hosting-move checklist covers the email and DNS risks to plan before switching.
Finish with a business-path check
After each speed change, check the exact page on mobile and desktop, then test its phone link, form confirmation and delivery, booking or checkout path as relevant. Record the before and after measurement with the URL, device and whether it was field or lab data. A faster page that loses enquiries has failed the job.
For Formby, Freshfield and L37 businesses, ask Formby Web Design for a website speed and enquiry-path review if you want a practical diagnosis and a prioritised change brief.
Sources checked 23 September 2026: Google Web Vitals definitions; Google LCP diagnostic guide; Google INP guide; Google CLS guide; Google Search page-experience guidance; Krystal managed WordPress plan information.
