Website speed optimisation: Core Web Vitals, WordPress and when custom build is faster (2026)
A slow website costs you customers. Here is how to improve LCP, INP and CLS step by step — for WordPress, WooCommerce and new builds.
- Google evaluates website speed via Core Web Vitals: LCP (Largest Contentful Paint, load time of main content) should be below 2.5 seconds, INP (Interaction to Next Paint, interactivity) below 200 milliseconds and CLS (Cumulative Layout Shift, layout shifts) below 0.1. Measure for free via PageSpeed Insights (pagespeed.web.dev).
- For WordPress websites, three interventions together account for the biggest gains: a caching plugin (WP Super Cache, W3 Total Cache or LiteSpeed Cache), conversion of images to WebP or AVIF format, and an audit of unnecessary plugins. Together they typically reduce load time by 30–60 per cent.
- A custom-built website (Next.js or a similar modern stack) has structurally better performance than a WordPress theme out of the box: no unused CSS/JS, static rendering and a performance budget baked into the build. This matters when WordPress optimisations have reached their ceiling.
Why website speed matters for SMEs: revenue, SEO and user experience
A slow website costs customers directly. Google measures website speed via Core Web Vitals and uses the scores as a ranking factor for organic search results and Google AI Overviews. Google research shows that 53% of mobile visitors abandon a page that takes longer than 3 seconds to load. For SME websites — webshops, service providers, agencies — every delay means fewer enquiries, fewer orders and a lower position in Google. The good news: the three most impactful improvements (caching, image optimisation and plugin audit) can be applied to most WordPress websites without major investment. When performance still lags after those steps, a newly built website on a modern stack is the most effective solution.
The three Core Web Vitals: what they measure and what the thresholds are
Core Web Vitals are the three metrics defined by Google for load performance, interactivity and visual stability. Google uses them as a direct ranking signal.
LCP — Largest Contentful Paint: load time of the main content
LCP measures how long it takes for the largest visible element on the page (usually a hero image or heading) to fully load. Thresholds: good is below 2.5 seconds, needs improvement is 2.5–4 seconds, poor is above 4 seconds. LCP is most affected by large images, slow server response (TTFB) and render-blocking JavaScript or CSS. Preload the hero element with <link rel="preload"> and use next-gen image formats (WebP or AVIF) with explicit width and height attributes.
INP — Interaction to Next Paint: responsiveness when clicking and tapping
INP (replaces the CWV metric FID from March 2024) measures the delay between a user interaction — click, tap, keystroke — and the visible response of the page. Threshold: good is below 200 milliseconds, needs improvement is 200–500 ms, poor is above 500 ms. INP problems are most common on WooCommerce pages with heavy JavaScript (sliders, live chat, widgets). Deferring or async-loading non-critical scripts and removing unnecessary plugins improves INP directly.
CLS — Cumulative Layout Shift: visual stability without surprises
CLS measures how much the layout unexpectedly shifts as the page loads. A high CLS score occurs when images are loaded without width and height attributes, web fonts cause text to jump, or ads push content downward. Threshold: good is below 0.1, needs improvement is 0.1–0.25, poor is above 0.25. The fix is straightforward in most cases: add width and height to all img elements and use font-display: swap for web fonts.
TTFB — Time to First Byte: how quickly does the server respond?
TTFB is not a Core Web Vital but is a direct precursor: how long does it take before the browser receives the first byte from the server? Google considers TTFB below 800 milliseconds good. A high TTFB points to a slow hosting server, overcrowded shared hosting, no server-side caching or a distant server without a CDN. Switching to managed hosting (indicative — check with provider) or adding a caching layer (e.g. Cloudflare free tier) are the most effective measures.
Five changes that make most WordPress websites 30–60% faster
WordPress websites carry more weight than necessary by default — themes load CSS and JavaScript you are not using on every page. These are the five changes with the highest return.
1. Install a caching plugin: WP Super Cache, W3 Total Cache or LiteSpeed Cache
A caching plugin stores HTML pages as static files so PHP and the database do not have to run on every page request. This reduces server load and TTFB immediately. WP Super Cache (free) is the simplest option; W3 Total Cache (free) offers more settings; LiteSpeed Cache (free) is only available on LiteSpeed hosting servers but delivers the best results. Activate page caching and recommended settings after installation. Always use only one caching plugin at a time.
2. Convert images to WebP or AVIF and enable lazy loading
Images account for the largest share of page weight on most SME websites. WebP files are on average 25–34% smaller than JPEG at comparable quality; AVIF is even smaller but has less broad browser support. Plugins such as Imagify, ShortPixel or EWWW Image Optimizer (all indicative — check prices with provider) convert existing images automatically. Ensure all off-screen images load lazily (WordPress 5.5+ supports this by default via loading="lazy"). Add width and height to every img element to avoid CLS.
3. Plugin audit: remove everything you are not actively using
Every active WordPress plugin loads extra code — JavaScript, CSS, PHP functions — on every page request, even if it only runs in the background. List all installed plugins and deactivate everything you do not actively use. Replace multiple separate plugins with combined alternatives where possible (e.g. an SEO plugin with sitemap functionality instead of two separate ones). Use Browser DevTools (Network tab) or GTmetrix to see which scripts are heaviest.
4. WooCommerce optimisations: disable cart fragments
WooCommerce loads an AJAX request (cart-fragments.min.js) on every page by default to keep the shopping cart up to date — even on pages without cart functionality. This blocks loading and worsens INP and LCP. Disable cart fragments via your caching plugin or via a lightweight snippet if you do not need a persistent cart. Also compress product images for catalogue pages (use WooCommerce image sizes with fixed width and height, e.g. 300×300 px for product thumbnails).
5. CDN and better hosting: server location and speed closer to the visitor
A Content Delivery Network (CDN) such as Cloudflare (free tier for small sites) stores static files on servers closer to the visitor, reducing load times across the Netherlands and Europe. For websites on cheap shared hosting (€1–3/month), switching to managed WordPress hosting (indicative — check with provider) is the most impactful step: better server hardware, a faster PHP version and built-in server-side caching. Choose a hosting location in Amsterdam or Frankfurt for Dutch visitors.
When is a new custom website faster than an optimised WordPress site?
WordPress optimisation has a ceiling. When a website continues to show a high LCP, INP or CLS after caching, image optimisation and plugin audit, the theme or build itself is the bottleneck. A custom-built website resolves this fundamentally.
Static rendering: no database call on every request
A website built with Next.js (the stack Delahaye Solutions uses) renders pages as static HTML at deploy time. There is no PHP, no database call and no server-side processing time on each visit. TTFB is therefore structurally lower than with WordPress, even without a caching plugin. Static sites are also inherently more secure: there is no PHP vulnerability or database to compromise.
Performance budget: only the code you actually use
A WordPress theme loads hundreds of kilobytes of CSS and JavaScript that are not used on every individual page. A custom Next.js website loads only the code that specific page needs (per-route code splitting). Combined with optimisations such as next/image (automatic WebP conversion and lazy loading), font-display: swap and preload hints, this results in structurally better Core Web Vitals without manual adjustments.
When custom build is worth considering: three signals
Three signals that a new website makes more financial sense than further WordPress optimisation: (1) PageSpeed Insights still scores below 70 on mobile after optimisation, (2) the theme or page builder (Elementor, Divi, WPBakery) causes heavy JavaScript blocking that caching plugins cannot resolve, or (3) the website has a high conversion goal (webshop, lead form) where every additional second of load time has direct revenue impact. Delahaye Solutions builds websites from €1,250 (Starter, single project) and €2,950 (Business, larger projects) — indicative, see pricing page for current overview.
Website speed optimisation: frequently asked questions
How do I measure the Core Web Vitals of my website for free?
What is a good PageSpeed score for an SME website?
Which caching plugin is best for WordPress?
Does a CDN really help for a Dutch SME website?
When should I choose a new website instead of optimising my WordPress website?
Slow website? We optimise or rebuild.
From a speed audit to a complete new website on Next.js — we look at what delivers the most for your specific situation.
Book my free call →Free consultation · response within 1 business day · no cure, no pay