Website speed

Website speed optimisation is the work of making pages load and respond quickly, especially on mobile phones and ordinary connections. Fast pages keep visitors, support conversions and are part of the page experience that search engines evaluate. Slow pages lose people before they see your offer, and every second of delay can cost enquiries you have already paid to attract.

This guide explains how to measure speed correctly, what Core Web Vitals mean and a practical method to improve them, with particular attention to WordPress sites. It is part of our web hosting and infrastructure cluster and works with technical SEO, domain and hosting and conversion optimisation.

Why speed matters

Speed affects three things. Visitor experience: people abandon slow pages, particularly on mobile. Conversion: faster pages tend to convert better because fewer visitors leave and forms and checkouts feel smoother. Search visibility: Google uses page experience signals, including Core Web Vitals, as part of its ranking systems, though relevance and content quality remain more important. Speed alone will not make a poor page rank, but a slow page can lose to an equally good fast one.

For paid traffic, speed matters even more, because you pay for each click that never loads. See Google Ads for the landing page link.

The Core Web Vitals

Core Web Vitals are three measures of real user experience.

• Largest Contentful Paint (LCP) measures how quickly the main content appears. A good LCP is 2.5 seconds or less.
• Interaction to Next Paint (INP) measures how quickly the page responds to taps and clicks across the visit. A good INP is 200 milliseconds or less.
• Cumulative Layout Shift (CLS) measures unexpected movement of content as the page loads. A good CLS is 0.1 or less.

These thresholds apply at the 75th percentile of real visits, separately for mobile and desktop. Google explains them on web.dev. Other metrics, such as Time to First Byte, help diagnose causes.

Measure before you change anything

Use two kinds of data.

• Field data comes from real users. The Core Web Vitals report in Google Search Console shows which groups of pages pass or fail, and PageSpeed Insights shows field data from the Chrome User Experience Report where enough traffic exists.
• Lab data comes from simulated tests, such as Lighthouse in PageSpeed Insights. It is repeatable and good for diagnosis but does not capture everything real visitors experience.

Test on mobile first, and test your key pages: the home page, top service pages, the checkout and landing pages used in ads. Record baseline numbers and the date so that you can judge improvements. A perfect score is not the goal. Passing Core Web Vitals in field data, and feeling fast to real people, is.

Step 1: Fix the server and hosting

If the server responds slowly, nothing else can compensate. Signs include a high Time to First Byte, slow admin pages and speed that varies by time of day. Causes include overloaded shared hosting, old PHP versions, unoptimised databases and missing server-level caching. Upgrade to a current PHP version, enable server caching or move to hosting designed for your platform, as discussed in domain and hosting. A server location near your visitors also helps.

Step 2: Add caching

Caching stores ready-made versions of pages so that the server does not rebuild them for every visit. Use page caching, browser caching with sensible expiry headers and object caching for dynamic sites where available. Many managed hosts include caching, and conflicting cache plugins can cause trouble, so use one approach. Exclude pages that must stay dynamic, such as cart, checkout and account pages. MDN's guide to HTTP caching explains the principles.

Step 3: Optimise images

Images are usually the heaviest part of a page and the most common LCP element.

• Resize images to the dimensions they are actually displayed at.
• Compress them, and use modern formats such as WebP or AVIF where supported.
• Serve responsive sizes using the srcset attribute so phones do not download desktop images.
• Lazy-load images below the fold, but never lazy-load the main image at the top, which should load with high priority.
• Set width and height attributes so the browser reserves space and avoids layout shifts.
• Use video carefully, with a poster image and no autoplay of heavy files.

Step 4: Reduce and defer scripts and styles

JavaScript affects loading and responsiveness. Remove unused plugins and scripts, load scripts only on the pages that need them, defer non-critical scripts, minify and combine files sensibly and avoid large libraries for small features. Review third-party scripts such as chat widgets, tracking pixels, maps and social embeds, each of which can add significant delay. Load them after user interaction where possible, and use Google Tag Manager carefully, since adding many tags can slow pages.

For CSS, remove unused rules, inline critical styles for the top of the page when practical and avoid render-blocking stylesheets. Many themes and page builders load far more code than a page needs, so a lightweight theme makes a large difference.

Step 5: Fonts

Web fonts can delay text. Use fewer families and weights, host fonts locally where licences allow, preload the main font file, use font-display so text appears immediately with a fallback font and subset fonts to the characters you need. System fonts are the fastest option and can look good with careful design.

Step 6: Improve responsiveness (INP)

Poor INP is usually caused by long JavaScript tasks that block the browser from responding. Reduce JavaScript, break up heavy tasks, avoid large DOM sizes, remove unnecessary animation and test interactions such as menu opens, filters and form fields on a mid-range phone, not only on a fast laptop. Consent banners and chat widgets are common culprits.

Step 7: Prevent layout shifts (CLS)

Layout shift happens when elements appear and push content around. Reserve space for images, videos, advertisements and embeds by setting dimensions, avoid inserting content above existing content, load fonts so that they do not cause jumps and animate with transforms, not layout properties. Cookie banners should overlay or reserve space rather than push the page down.

Step 7b: Optimise third-party embeds

Maps, videos, social feeds and booking widgets can add large amounts of code. Replace live embeds with a lightweight placeholder, such as a thumbnail with a play button, and load the real embed only when the visitor clicks. For maps, consider a static image linking to the full map. For social feeds, ask whether visitors actually need them on that page. Each embed removed from a landing page is a performance gain and often improves focus.

Step 8: Use a CDN where it helps

A content delivery network stores copies of static files on servers around the world and delivers them from the closest one. It reduces latency, offloads traffic from your server and often adds security features. It is particularly valuable for sites with international visitors or heavy media. Configure it carefully so that dynamic pages and logged-in sessions are not cached incorrectly.

WordPress-specific tips

• Choose a lightweight theme, and avoid page builders unless they are necessary.
• Audit plugins and delete those you do not need. Check what each one loads on the front end.
• Use one reputable caching or performance solution that fits your host.
• Clean the database of old revisions and transients periodically.
• Keep PHP, WordPress, themes and plugins updated.
• Test changes on staging before applying to the live site, as described in WordPress and business websites.

E-commerce considerations

Stores have heavy product images, dynamic carts and many scripts. Prioritise optimising product and category images, caching what can be cached, limiting apps and plugins, optimising checkout scripts and testing on mobile networks. See e-commerce stores for more.

Monitor continuously

Speed degrades as sites change. Add monitoring, review the Core Web Vitals report monthly, re-test after major content or plugin changes and set a performance budget, such as maximum image size and number of third-party scripts. Include speed in your regular website maintenance checks.

Speed optimisation checklist

1. Measure baseline field and lab data for key pages on mobile.
2. Check hosting, PHP version and server response time.
3. Enable page and browser caching.
4. Resize, compress and modernise images, with correct dimensions and lazy loading below the fold.
5. Prioritise the largest above-the-fold element.
6. Remove unused plugins and scripts, and defer the rest.
7. Audit third-party scripts and load them late.
8. Optimise fonts.
9. Reserve space for media and embeds to stop layout shift.
10. Consider a CDN.
11. Re-measure and record the improvement.

A worked example: bringing a slow service page under 2.5 seconds

A service page has a four-second Largest Contentful Paint on mobile. Inspection shows that the largest element is a 2 MB hero photograph, the server takes more than a second to respond, a chat widget and two tracking scripts load before the content and fonts block text from appearing. The fixes are practical: resize and compress the hero image and serve it in a modern format with a preload hint, enable page caching on the server, defer the chat widget until a user interaction, load analytics through a tidy Tag Manager container, preload the primary font and apply a fallback so that text appears at once. After the changes the page is retested in the lab and, over the following weeks, watched in field data. The gains come from a handful of targeted changes, not from installing more plugins.

Speed and user behaviour

Speed work is most useful when tied to behaviour. Compare conversion rate and engagement for fast and slow sessions, segment by device and connection and look at the landing pages used in advertising first, since slow ones waste paid clicks. Share simple before and after numbers with your team so that speed becomes part of the definition of a finished page, not an afterthought.

Performance budgets and governance

Set limits and keep to them. A simple performance budget might state that no page may exceed a set total weight, that hero images must be compressed to a target size, that only approved third-party scripts may be added and that each new plugin requires a speed check. Assign someone to approve new scripts, because marketing tools tend to accumulate silently. Review the budget quarterly and tighten it as your tools improve.

Common speed mistakes

• Chasing a perfect lab score and ignoring real-user data.
• Installing several optimisation plugins that conflict.
• Uploading full-size camera photos.
• Lazy-loading the hero image.
• Adding every tracking and chat widget available.
• Optimising the desktop only.
• Ignoring hosting quality.
• Not retesting after changes.

Getting help

We offer free technology consulting through our Apply Form, and can audit a few key pages, tell you what is causing slowness and recommend the changes that matter most. If you want hands-on implementation, you can request it as a paid service from our pricing plans.

More from the blog

• Website Performance

More in Web Hosting & Infrastructure

See the full Web Hosting & Infrastructure overview.

• Domain and hosting
• Security and backups

Frequently asked questions

Sources and further reading

• Core Web Vitals (web.dev)
• PageSpeed Insights
• HTTP caching (MDN)
• Core Web Vitals report (Search Console Help)