Website speed optimisation: a practical guide for business websites

Most slow business websites aren’t slow for one reason. A crowded server, an oversized banner photo, a chat widget and a handful of tracking tags each add a delay, and together they leave phone visitors staring at a blank screen. Website speed optimisation means finding which delays matter most on your site, and removing them in a sensible order.

Speed is one ingredient of what makes a good website, and it only pays off when the page is worth waiting for.

The short answer

Website speed optimisation is the work of making pages show their main content quickly, react quickly to taps and clicks, and stay stable while they load, for real visitors on real phones.

• Measure real visits. Google rates a page as good when Largest Contentful Paint is 2.5 seconds or less, Interaction to Next Paint 200 milliseconds or less and Cumulative Layout Shift 0.1 or less, at the 75th percentile of visits.
• Fix from the server outward: server response and caching, render-blocking code, images and fonts, then third-party scripts.
• Start cheap. Resizing images and caching pages usually come before new hosting or a rebuild.
• Keep it fast with a performance budget and monthly checks of real-user data.

What “fast” means: three numbers from real visits

A page doesn’t load in one moment, so a single “page load time” hides more than it shows. Google’s Core Web Vitals ask three questions instead: has it appeared, does it respond, and does it stay put?

In between is “needs improvement”. A page passes when at least three in four visits (the 75th percentile) meet each threshold, judged separately on mobile and desktop. Older phones and patchy mobile data count, so a site that feels instant on office Wi-Fi can still fail.

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. Core Web Vitals explained covers each metric.

Field data vs lab data

Field data comes from real Chrome users via the Chrome UX Report (CrUX), covering the previous 28 days. Both the Core Web Vitals assessment in PageSpeed Insights and Search Console’s Core Web Vitals report use it. Low-traffic pages may have no data of their own; PageSpeed Insights then shows whole-site figures, or nothing.

Lab data comes from Lighthouse: one simulated load, on an emulated mid-range phone and throttled connection for the mobile test. It isn’t what visitors experience, but it’s repeatable, so use it to diagnose problems and test fixes. Its 0–100 score is a lab summary, not a verdict; how to read a PageSpeed Insights report explains what to act on.

Why speed is worth the effort, and where it stops

A slow first screen gives visitors time to change their mind, and a sluggish form is harder to finish. But speed is one conversion lever among several: a fast page with a vague headline still fails. How page speed affects conversions explains how to measure the effect, and the conversion rate optimisation guide sets speed beside messaging, proof and forms.

For search, Google says Core Web Vitals are used by its ranking systems, though relevance still comes first.

When we redesigned a property developer’s website, load time fell from about nine seconds to two and buyer enquiries rose 40% in the three months after launch. Speed wasn’t the only change, though: the site was also restructured around the buyer journey.

Where speed is won or lost: from the server outward

A page load is a chain: the server responds, the browser reads the HTML, discovers the CSS, fonts, images and scripts, then draws the page. An early delay pushes back everything after it, so diagnose in that order. Why is my website slow? walks through it.

1. Hosting and server response

Crowded shared hosting, outdated PHP, slow database queries and a server far from your visitors all show up as a long Time to First Byte (TTFB). As a rough guide, web.dev suggests 0.8 seconds or less. TTFB isn’t a Core Web Vital, but a slow one makes a good LCP very hard.

Check it yourself. In Chrome DevTools, open the Network panel, reload and select the first request: the Timing tab shows how long the browser waited for the server. If it stays slow after caching, read how to choose web hosting for speed.

2. Caching, compression and CDNs

• Page caching serves stored copies of pages instead of rebuilding them for every visitor. Exclude carts and logged-in areas, and clear it when content changes.
• Browser caching lets returning visitors reuse images, CSS and scripts.
• Compression (Brotli or gzip) shrinks HTML, CSS and JavaScript in transit.
• A content delivery network (CDN) serves files from locations near each visitor, which matters most when customers are in several countries.

Website caching and CDNs explained covers when you need each layer.

3. HTML, CSS and JavaScript

Browsers hold back the first paint until the stylesheets in the page head have arrived, and a script there without defer or async stops the HTML being read until it has downloaded and run. Heavy themes and page-builder add-ons often load everything everywhere.

JavaScript largely decides INP. Taps are handled on the browser’s main thread, and any task over 50 milliseconds (a “long task”, in web.dev’s terms) can leave a tap waiting. Defer what the first screen doesn’t need, load features only where they’re used, and break up long tasks. Render-blocking resources explained shows how to find the culprits.

4. Images and fonts

On many business pages the LCP element is an image, usually a hero photo or carousel slide, so images are often both the LCP problem and the cheapest fix.

• Serve images at their displayed size in WebP or AVIF, with srcset and sizes so phones get smaller files.
• Set width and height so the browser reserves space and nothing jumps.
• Lazy-load images below the first screen, never the hero. Give the hero fetchpriority="high" instead.
• Keep the main image out of CSS backgrounds, where the browser finds it late.

For fonts: fewer families and weights, WOFF2 files, preloading only the fonts the first screen needs, and font-display set so text shows in a fallback font while yours loads. On multilingual sites, split large fonts into unicode-range subsets, so browsers fetch only the subsets a page’s text needs. Image optimisation for websites goes further.

5. Third-party scripts

Chat widgets, tag managers, heatmaps, A/B testing tools and video or map embeds run code you don’t control on the same main thread as yours, which makes them a frequent cause of poor INP.

Check it yourself. List every tag and widget with its owner and purpose, and remove anything nobody can explain. Load chat and video on click behind a lightweight placeholder (a “facade”), and avoid testing tools that hide the page until their script arrives. Third-party scripts and website speed covers the full audit.

Website speed optimisation fixes, ranked by impact and effort

To work out how to improve website speed without a rebuild, start with Search Console’s Core Web Vitals report. It groups similar URLs, showing whether a problem affects one template or the whole site. Then work down this list:

Test as you go:

1. Find what fails: which metric, on which template, on mobile or desktop.
2. Find the cause. PageSpeed Insights names the LCP element and what delays it; the Performance panel in Chrome DevTools shows the long tasks behind poor INP.
3. Fix the earliest link in the chain first, then retest in the lab.
4. Release and watch the field data for a few weeks, since each figure covers the previous 28 days.

On WordPress, how to speed up a WordPress website shows how to make these fixes safely.

Keeping a site fast after launch

Website performance optimisation isn’t a one-off project. Sites slow down one full-size photo, plugin and marketing tag at a time.

Set a performance budget

Agree limits before anything new is added: a maximum hero image weight, a cap on third-party tags, a mobile lab LCP target for key templates. Each new tool fits the budget or replaces something.

Monitor real-user data

Check Search Console’s Core Web Vitals report monthly and after major changes. If traffic is too low for CrUX, real-user monitoring collects the same metrics from your own visitors; Google’s open-source web-vitals library is a common starting point.

Build speed into maintenance

Retest key templates after theme and plugin updates, resize photos on upload and review tags quarterly. The website maintenance checklist puts these jobs on a schedule.

• Key templates pass Core Web Vitals on mobile, in field data
• TTFB is around 0.8 seconds or less on key pages
• Every third-party tag has an owner and a reason

Every guide in the performance series

Frequently asked questions

What is a good page load time for a website?

Rather than one total load time, aim for Google’s Largest Contentful Paint target: the main content visible within 2.5 seconds for at least 75% of real visits.

Is it worth chasing the last few PageSpeed points?

No. The score summarises one simulated load, and the last few points rarely change anything visitors notice. Aim to pass Core Web Vitals on real-user data, and use the score to spot when something gets worse.

Does website speed affect SEO?

To a degree. Google says Core Web Vitals are used by its ranking systems, but relevant, helpful content comes first. Speed helps a good page compete; it won’t rescue a weak one.

Where to start

Run your most important page through PageSpeed Insights on mobile and note which Core Web Vital is furthest from good. LCP points to the server, render-blocking code or images; INP to JavaScript and third-party scripts; CLS to unsized images, embeds and fonts.

For a second opinion, a free website audit checks your load time, Core Web Vitals and image weight, and names the few fixes worth making first. Our website care plans then handle updates, backups and monitoring, with monthly speed work on the Growth plan. If the slowness is built into the theme, a website redesign deals with it at the source.