Why is my website slow, and how can I check it?

What does a slow website actually mean?

“Slow” can describe several different experiences. Your main service may take too long to appear after opening the page, or the page may look ready but the “Send” button responds late. Sometimes a form jumps just as a visitor tries to click. These problems aren't described by the same metric and may not require the same fix.

For a business, the first question isn't “what's the score?”, but which customer task is affected, where and under what conditions. A broken contact form, for instance, may matter more urgently than a decorative animation.

Check website speed in six steps

1. Choose three different URLs. Include the homepage, an important service page and contact or booking page. A fast homepage doesn't prove the form works properly.
2. Open them on a real phone. Check when the main offer becomes readable, whether the menu works and whether you can submit the form. Try the normal customer journey, not only your fast office Wi-Fi.
3. Run a test in Google PageSpeed Insights. Enter the specific page URL and review mobile and desktop reports separately.
4. Separate the two datasets. The “real-user experience” section may show aggregated data from Chrome users; Lighthouse lab tests use a simulated environment. They aren't two colour labels for the same test.
5. Record the symptom and data. Note the date, URL, device, LCP/INP/CLS values (if available), lab findings and whether you could reproduce the problem.
6. Retest the customer journey after fixing things. A changed score isn't enough: menus, bookings, analytics and forms must continue to work. Real-user metrics respond later.

Real-user data or lab results?

PageSpeed real-user data, where available, typically reflects a rolling 28-day period, so it won't update instantly after every change. Lighthouse is a snapshot and may vary between runs because the test environment or network differs. A lab score of 45/100 can't tell you how many customers you lose.

What if no real-user data is available?

New pages or pages with few visitors may lack a sufficient URL-level sample. The tool may offer site-wide results instead or show no such data. That doesn't automatically mean good or bad performance. Use lab tests, manual mobile checks and monitor real data later.

LCP, INP and CLS: three important user metrics

These are Google's “good” thresholds; real-user classification uses the 75th percentile. They don't guarantee SEO rankings.

The LCP element could be the large introductory image on a service page. INP can be particularly noticeable in a slowly opening mobile menu or booking field. CLS can be dangerous when a late-loading element moves the “Send” button. Three different problems call for three different repair plans.

The Search Console Core Web Vitals report also assesses groups of URLs; it doesn't provide independent data for every page. A good status doesn't mean there are no other usability or business problems.

Symptom → measurement → possible cause → next action

This table is a troubleshooting starting point, not a remote diagnosis of an unknown site. A “possible cause” becomes a confirmed fault only after investigation.

If the contact form sometimes fails, that's a repair priority. If a decorative feature worsens the lab score but the journey works, first weigh the effort against the business impact.

What slows websites down in practice?

Images and main content

A multi-megabyte hero image, poorly chosen resolution or late-loading picture often creates an obvious delay. Suitable formats, resolution, caching and resource priorities can help. But don't automatically lazy-load the most important above-the-fold LCP image: using loading="lazy" there can delay essential initial content. Images further down the page may need different handling.

Fonts, styles and JavaScript

Too many fonts, unnecessary animations, external chat or advertising tracking code may block rendering and interactions. Before disabling anything, note its purpose: accidentally removing conversion tracking can hurt the business too. The goal isn't to eliminate all external code but to load necessary elements appropriately and in the right order.

Hosting, servers and external services

A slow server or unreliable booking integration can also worsen the experience. More expensive hosting isn't a universal fix: first establish whether server response is the bottleneck. If an external service behind the form is slow, compressing images alone won't help.

Targeted optimisation or a complete website redesign?

Start with a targeted fix if problems involve a few measurable resources or pages, the basic structure works and the change can be tested safely. Consider redesigning if core features fail regularly, the architecture has too many dependencies, mobile use is poor at several critical points, or changes have become disproportionately risky.

Replacing a website also requires preserving URLs, redirects and tracking. The guide to domain changes and website redesign explains the checks in order. The comparison of on-page, off-page and technical SEO covers the wider technical picture.

Tell us these five things when requesting speed improvements or redesign

You don't need a detailed understanding of LCP, INP or JavaScript faults to ask for help. What you experience as a customer is the best starting point.

1. Which page is affected? Send the URL of the problematic page.
2. What is the customer trying to do? For example, read about a service, request a quote or book an appointment.
3. What's stopping them? Slow loading, broken button, shifting content or disappearing form.
4. When and on which device did you see it? Mobile or desktop, and roughly when it happened.
5. What's the important business goal? More useful quote requests, easier phone contact or a better mobile experience.

Sources and professional references

Related guides