Why your business website is slow and what to fix first

A slow website does not always display an error. Sometimes the page appears after a few seconds, but its main button does not respond. Sometimes the heading loads first and a large image shifts everything just as the visitor tries to select a link. A form may work on the office laptop and struggle on an ordinary phone over a mobile connection.

To the customer, each version feels unreliable. To the business, that friction can appear as abandoned calls, unfinished forms, interrupted bookings, and advertising spend that produces visits without a useful next step.

The answer is neither a random caching plugin nor a perfect synthetic score. A useful performance process begins with the real customer journey, identifies the dominant constraint, and fixes causes in the order that customers and the business will notice.

“Slow” can describe three different problems

Speed is not one moment. A page can paint its background quickly while delaying the content that matters. It can look complete while ignoring the first interaction. It can respond quickly but move controls around while resources arrive.

Core Web Vitals provide three practical reference points:

| Metric | What it represents for the visitor | Good threshold | | ------- | --------------------------------------------------- | ----------------------------- | | LCP | When the page’s primary content becomes visible | no more than 2.5 seconds | | INP | How quickly the page responds to interactions | no more than 200 milliseconds | | CLS | How stable the visible layout remains while loading | no more than 0.1 |

The thresholds are assessed at the 75th percentile so that the experience is good for most visits, not only for a favourable test run. The official explanation of Core Web Vitals thresholds covers both the metrics and the reasoning behind them.

These figures are diagnostic boundaries, not the whole customer experience. A site can meet them and still present a confusing form. It can load a vague offer quickly. Performance supports clarity and action; it does not replace them.

Start with field data, then use laboratory tests

PageSpeed Insights can present two useful perspectives. Chrome UX Report field data, when the site receives enough eligible traffic, summarises how real Chrome users experienced a page or origin over recent weeks. Lighthouse runs a controlled test and identifies technical opportunities under simulated conditions. Chrome’s guide to CrUX performance tools explains how these sources differ.

Do not treat them as interchangeable:

• Field data includes a range of phones, networks, locations, and behaviours, but takes time to accumulate.
• Laboratory data is fast and repeatable, but represents one simulated configuration.
• Direct observation shows whether the problem prevents the actual job: reading, calling, submitting, viewing a menu, or booking.

Test at least the homepage, one service page, an image-heavy project or gallery, and the complete contact journey. Test the first visit rather than only refreshing after the browser has cached resources. Use a phone, mobile data, and a device reasonably close to what customers use—not only the fastest computer in the team.

Our guide to planning a business website for the real mobile visit covers the customer journeys that should be reviewed beyond screen width.

Images are often the best first place to investigate

A large photograph can be entirely justified by the design and still be delivered badly. Problems arise when the site sends one enormous source to every screen, uses an inefficient format, fails to reserve the image dimensions, or starts loading the whole gallery before the visitor reaches it.

Review:

• file weight and the resolution actually required in the layout;
• responsive variants for phones, tablets, and desktops;
• modern formats and compression appropriate to the subject;
• width and height reserved before the asset loads;
• deferred loading for images below the initial viewport;
• correct priority for the primary image when it is the LCP element;
• new photographs uploaded later through the content system.

Do not compress everything until materials, food, or faces look damaged. The goal is to deliver the right image at the right size and time. The web.dev guide to optimising LCP explains why discovering and prioritising the primary resource can matter as much as reducing its file size.

Set an editorial rule too. If the team can upload unrestricted multi-megabyte originals, the problem will return with the next content update.

Third-party scripts have a cost, even when installation is easy

Analytics, advertising, chat, consent tools, maps, booking systems, review widgets, video players, and hosted fonts may all add value. Each can also add connections, code, processing, and a dependency the website cannot fully control.

Create an inventory:

1. Which service is loaded?
2. On which pages is it genuinely needed?
3. Who uses it inside the business?
4. Which measurable outcome does it support?
5. Can it start later or only after consent?
6. What happens when the provider responds slowly?

An abandoned chat widget, three platforms measuring the same action, or a social feed loaded on every page creates cost without a clear benefit. Removing an unnecessary dependency is usually more robust than finding another technique to “optimise” it.

Fonts and visual effects can delay useful content

A coherent visual system rarely needs every weight and style in a type family. Each variation and character set can require another resource. If the text waits for the font, the visitor may see the content late or watch it change after it appears.

Keep only the necessary variants, serve them locally where the project and licence allow, choose a close system fallback, and review the layout before and after the web font loads. Avoid shipping a large icon font when the page uses only a few icons.

Use the same discipline for animation, carousels, and video backgrounds. Motion can explain hierarchy, but it should not delay reading or action. An autoplaying decorative video on mobile needs to justify its cost with a real communication role, not simply with how it looked in a presentation.

Hosting can be part of the problem, but it is not the universal answer

A slow server response may come from the hosting region, missing caching, expensive database work, an overloaded CMS, extensions, calls to external services, or pages rebuilt unnecessarily for every request.

Separate server response time from time spent inside the browser before changing providers. More expensive hosting does not fix an 8 MB photograph, a heavy carousel, or six advertising services. Conversely, resizing images does not fix a slow database query.

Ask for an explanation tied to the journey:

• how long the response takes to begin;
• what can be served from a cache;
• what data is calculated for each visit;
• which external services delay rendering;
• whether the problem affects every page or one template;
• how the proposed improvement will be verified.

Excessive JavaScript can make a visible page unusable

A site can display its content quickly and respond slowly when a visitor opens the menu, chooses a date, or types into a form. The browser may be busy initialising components, processing a large amount of code, or repeatedly updating the interface.

Prefer HTML and content that work without complex client logic. Load heavy functionality only where it is used. Avoid making every section interactive simply because the development framework makes that convenient.

Responsiveness must be tested through real actions: opening navigation, recording consent, typing into a form, choosing an appointment, submitting data, and returning to the previous page.

Prioritise fixes by business impact

A useful performance backlog is not sorted only by milliseconds. Use four levels:

1. Blocked journeys: a form, booking, call, account, or payment cannot be completed.
2. Repeated problems on important pages: the service template, portfolio, or navigation affects many visits.
3. Shared causes: the primary image, fonts, scripts, or server response can improve several pages through one change.
4. Polish: small technical improvements with no observable effect on an important task.

Google explicitly notes that good report results do not guarantee top search positions and that pursuing a perfect score purely for SEO may be a poor use of time. Its current page experience guidance recommends evaluating the experience as a whole.

A score of 100 does not rescue an unclear service. Excellent content does not excuse a button that ignores the first tap. Use metrics as quality boundaries and invest first where a customer can feel the improvement.

Prevent the next performance regression

Optimisation fixes the current state. Publishing rules preserve it:

• limits for image dimensions, weight, and formats;
• approval before adding a third-party script;
• components tested on phones and with a keyboard;
• automated checks for primary page templates;
• monitoring of field performance and errors;
• form testing after updates;
• clear ownership for content, integrations, and maintenance.

Include performance in the first 90 days after a website launch. Compare results before and after a change under equivalent conditions. Record what was removed as carefully as what was added.

What a performance audit should deliver

A useful audit does not end with a PageSpeed Insights screenshot. It should explain:

• which pages, devices, and customer journeys are affected;
• what comes from field data and what comes from simulation;
• the likely technical cause;
• the effect on the visitor and business;
• the recommended order of work;
• the effort and risk attached to each change;
• how the result will be verified;
• the rule that will prevent the problem from returning.

If the current platform makes foundational improvements impractical, performance can become one of the signs that the website needs a redesign. A rebuild is not the first answer to every weak score, however. Several clear causes can often be corrected without replacing the entire system.

A fast website is the result of repeated decisions

Performance does not come from one tool. It comes from correctly prepared media, selective features, code delivered only where necessary, suitable infrastructure, and a team that does not add cost without review.

Begin with the customer journey. Measure the important pages. Fix the dominant constraint. Confirm the result in field data, then keep simple rules for the next update.

If your business website feels slow and you need a diagnosis that separates the real cause from generic recommendations, tell us what is not working.