Your website's speed isn't determined by the hosting plan you pick at the last minute. It's baked into the stack decisions you make at the start: rendering model, asset strategy, image formats, script budget, and server architecture. Get those right and everything else is fine-tuning. Get them wrong and no amount of caching will save you.
We build sites that consistently hit LCP under 1.5 seconds. The reason isn't magic — it's deliberate technical choices made before writing the first line of code. Here's what actually moves the needle.
Rendering model: server-side wins for most business sites
Client-side rendering — React SPAs, for example — sends an empty HTML shell and builds the page in the browser. That means users see nothing until JavaScript finishes loading and executing. For a marketing site or service business, that delay is pointless. Nobody needs a single-page app to read your "About" page.
Server-side rendering sends complete HTML to the browser. Content appears immediately, before JavaScript even loads. For brochure sites, service pages, and portfolios, this is the fastest option by a margin that matters.
Google can render JavaScript, but it queues pages for a second pass. Server-side rendered HTML is indexed immediately. For small business sites, that gap matters.
Asset strategy: every kilobyte is a choice
A typical WordPress theme loads Bootstrap (150KB), jQuery (85KB), a slider library (90KB), and the theme's own framework (200KB+). That's over 500KB of JavaScript before your content loads. Most of that code is unused on any given page.
Performance-first means zero framework overhead. Write only the CSS and JavaScript the page actually needs. Our median total JavaScript payload is under 50KB — roughly a tenth of a typical page builder site.
The same discipline applies to CSS. We write component-scoped styles compiled through a purge process. The shipped CSS contains only the classes the page uses. No 300KB stylesheet loaded on every page "just in case."
For a brochure or service site, anything over 100KB of JavaScript deserves scrutiny. Our builds typically ship under 50KB total. If your site loads 500KB+ of JS on every page, most of it is framework overhead that your visitors don't benefit from.
Image discipline: the biggest LCP lever
Images are typically the largest asset on any page and the primary driver of LCP. Getting images right means four things, done consistently.
- Modern formats: WebP as baseline, AVIF where browser support allows. Both are 25–50% smaller than JPEG at equivalent quality. The ideal setup uses AVIF as the primary source with WebP fallback via the
<picture>element. - Explicit dimensions: every
<img>tag carries width and height attributes. This prevents layout shift (CLS) and lets the browser reserve space before the image loads. - Hero preloading: the LCP image gets a
<link rel="preload">in the document head, so the browser fetches it before parsing the rest of the page. - Lazy loading everything else: below-the-fold images use
loading="lazy"so they don't compete with critical content.
This isn't complex. It's just disciplined. Most slow sites we audit have oversized PNGs with no dimensions and no lazy loading — fixable in an afternoon if you know what to look for.
Hosting: the floor under everything
You can build the fastest site in the world and lose it all on a £3/month shared hosting plan with a server in Virginia. For UK businesses serving UK customers, your server needs to be in the UK.
UK-based NVMe hosting typically delivers Time to First Byte under 200ms. Budget shared plans with US-based servers add 200–500ms before the browser even starts rendering. TTFB is the floor under your LCP — you can't go faster than your server responds.
Every build we produce runs on enterprise-grade hosting through our Unity Tech partnership. NVMe storage, UK data centres, automatic failover, air-gapped backups. You don't need to evaluate hosting providers. We've already made the right call.
The 5-step stack selection process
-
Define your goals and conversion priorities. What's the site's job? Lead generation? Bookings? Portfolio showcase? The answer narrows your options immediately.
-
Set CWV non-negotiables. Decide upfront: LCP under 2.0s, INP under 150ms, CLS under 0.08. These become your acceptance criteria, not aspirations.
-
Shortlist two stack options. Don't evaluate ten platforms. Pick the two most credible routes for your use case and compare them head-to-head on speed, cost, maintenance, and team fit.
-
Prototype key templates. Build the homepage and one service page in each option. Measure real performance, not theoretical benchmarks from the platform's marketing site.
-
Select based on measured outcomes. The stack that hits your CWV targets with the lowest maintenance overhead and best cost-over-three-years wins. Not the one with the nicest dashboard.
Quick answers
Does the rendering model matter for search visibility?
Yes. Google can render JavaScript, but it queues pages for a second pass — the "second wave" of indexing. Server-side rendered HTML is indexed immediately on the first crawl. For small business sites, SSR removes an unnecessary delay between publishing and ranking.
Can I improve my existing site's stack without a full rebuild?
Sometimes. Image optimisation, script deferral, and moving to better hosting can improve scores significantly without rewriting the site. But if the core stack is the bottleneck — a heavy CMS theme loading 500KB+ per page — those quick wins have a ceiling. Our free audit tells you which route makes more sense.
How much JavaScript is too much?
For a brochure or service site, anything over 100KB of JavaScript deserves scrutiny. Our builds typically ship under 50KB total. If your site loads 500KB+ of JS on every page, most of it is framework overhead that your visitors don't benefit from.
Does hosting really affect Core Web Vitals?
Directly. Time to First Byte is the floor under your LCP score. A slow server adds 200–500ms before the browser even starts rendering. UK-based NVMe hosting typically delivers TTFB under 200ms.