Website Page Speed, Platform by Platform: What Actually Makes a Site Fast

Every platform can be fast. Every platform can be slow. The one you build on doesn't decide your Core Web Vitals — it decides how easy or hard those numbers are to hit, and how quickly they degrade once real content and real marketing teams get involved.

This is the honest, vendor-agnostic version. WordPress, Headless WordPress, Next.js, Astro, Shopify, WooCommerce — what makes each quick or sluggish, and how to get a Lighthouse score of 90+ on any of them. Our house line holds throughout: the platform is chosen to fit your needs, not because it's the one we always reach for.

We recently took a client's mobile Lighthouse score from 46 to 94. No re-platform. Same CMS. We'll come back to how, because the fixes tell you more than any benchmark chart.

Why page speed matters (and why it's not optional anymore)

Page speed stopped being a nice-to-have when Google folded Core Web Vitals into ranking signals. Three metrics carry most of the weight:

• LCP (Largest Contentful Paint) — how fast the main content renders. Target: under 2.5 seconds.
• CLS (Cumulative Layout Shift) — how much the page jumps around as it loads. Target: under 0.1.
• INP (Interaction to Next Paint) — how quickly the page responds when someone taps or clicks. Target: under 200ms. INP replaced First Input Delay in March 2024, and it's less forgiving.

Miss those and you're not just annoying visitors — you're handing an edge to competitors who didn't. Speed is a genuine SEO input, not a vanity score.

The conversion maths are blunter still. Google's own research found that as mobile page load goes from one second to three, the probability of a bounce rises 32%. By five seconds it's around 90%. Faster sites convert more, hold attention longer, and cost less in wasted ad spend. We've measured session-duration lifts north of 40% on rebuilds where the only headline change was speed.

And the reality is mobile. Most of your traffic is on a mid-range phone on a patchy connection, not the developer's laptop on office fibre. That gap is exactly where good scores go to die.

What actually makes a site slow

Before we go platform by platform, the fundamentals — because they're the same everywhere. A slow site is almost always slow for one of these reasons:

• JavaScript weight. The single biggest culprit. Every kilobyte of JS has to be downloaded, parsed, and executed on the main thread — and on a mid-range phone the CPU is the bottleneck, not the network. Heavy JS wrecks INP.
• Images. Unoptimised hero images and below-the-fold media are the classic page-weight offenders. A 4MB PNG where a 120KB WebP would do is a self-inflicted wound.
• Render-blocking CSS. Big stylesheets that must load before anything paints push LCP out.
• Third-party scripts. Chat widgets, analytics, A/B tools, marketing tags, embedded fonts. Each one is code you don't control, running on your critical path.
• Hosting and TTFB (Time to First Byte). Cheap shared hosting sits your server thousands of miles from your visitor and answers slowly. A slow TTFB caps how fast everything downstream can be.

Notice that none of those are named "WordPress" or "Shopify". The platform influences how much of each you inherit by default — but the levers are universal.

Platform by platform

WordPress site speed: why the bad rap, and how to fix it

WordPress powers something like 40% of the web, which means it also powers most of the slow web — so it gets blamed. The truth: WordPress isn't slow. Bad WordPress is slow.

What makes it slow is almost never the core. It's page builders (Elementor, Divi, WPBakery) that ship enormous DOMs and bloated CSS, plus a graveyard of plugins each loading their own scripts on every page. Stack ten of those and you've got 2MB of JavaScript before you've written a word.

How we make WordPress fast:

• No page builders. We build custom themes with clean, semantic markup — Tailwind for CSS, hand-written templates. No builder overhead, ever.
• Ruthless plugin discipline. Every plugin has to earn its place. If it adds front-end weight for a back-end convenience, it's gone or replaced.
• Proper caching and a CDN. Full-page caching plus an edge CDN drops TTFB dramatically.
• Right-sized, modern images. WebP/AVIF, correct dimensions, lazy-loading below the fold.

Done properly, a custom WordPress build hits 90+ comfortably. The platform gives you a phenomenal editor; the discipline is what keeps it fast.

Headless WordPress: keep the editor, drop the theme

Headless WordPress is the move when a client loves the WordPress editing experience but you want front-end performance to be non-negotiable. You keep WordPress as the content API and render the front end with a modern framework, served from the edge.

The upside is that you inherit none of the theme's front-end baggage. No theme scripts, no builder CSS, no plugin front-end injections. You ship exactly the JavaScript you write and nothing else. Editors carry on in an interface they know; visitors get a statically generated or edge-rendered page.

The trade-off is complexity — two systems to maintain, and previewing draft content takes more plumbing. Worth it for content-heavy sites where speed is a commercial priority. Overkill for a five-page brochure site.

Next.js performance: control the JavaScript

Next.js is our default for ambitious, app-like builds, and its performance story is genuinely strong — if you use it deliberately.

• React Server Components render on the server and ship zero JS for anything that isn't interactive. That's the headline INP win: most of your page becomes HTML, not a hydration payload.
• Static generation and ISR (Incremental Static Regeneration) let you serve pre-built pages from the edge and refresh them on a schedule — near-static speed with dynamic content.
• Image and font optimisation are built in and excellent when you actually use them.

The catch: Next.js will happily let you ship a heavy client bundle if you're careless with client components, oversized dependencies, and eager hydration. The framework gives you the tools to control the JavaScript — it doesn't force you to. Discipline still decides the score.

Astro and static sites: near-zero JavaScript

For content sites, marketing sites, and blogs, Astro is the quiet overachiever. It ships zero JavaScript by default and renders to static HTML. Interactivity is opt-in through "islands" — small, isolated components that hydrate independently, so a single interactive widget doesn't drag the whole page into a hydration cost.

The result is the fastest baseline of anything here. LCP and INP tend to be excellent with almost no tuning, because there's simply very little to execute. If your site is mostly content with pockets of interaction, static-first is hard to beat.

The limit is inherent: Astro is built for content, not complex app state. When you need a rich, stateful interface — a portal, a dashboard, a booking flow — you want Next.js. Match the tool to the job.

Shopify speed: hosted checkout, theme vs headless

Shopify removes an entire class of speed problems by hosting everything — infrastructure, CDN, and a checkout that's already tuned. TTFB is rarely your issue on Shopify.

Where Shopify slows down is the theme layer. Merchants pile on apps — reviews, upsells, pop-ups, loyalty widgets — and each one injects scripts. Bloated themes and a dozen third-party apps will drag a Shopify store's mobile score into the 40s just as fast as any WordPress site.

Fast Shopify means a lean, custom theme, aggressive app auditing (every app is front-end weight), and for high-traffic stores, going headless with Shopify's Hydrogen or a custom front end — keeping the bulletproof hosted checkout while controlling everything above it.

WooCommerce: the self-hosted reality

WooCommerce is WordPress plus a shop, which means it inherits both WordPress's flexibility and its performance responsibilities. Unlike Shopify, you own the hosting — and that's the make-or-break.

WooCommerce on cheap shared hosting is a bad time: cart and checkout pages are dynamic and can't be fully cached, so a slow server shows immediately. WooCommerce on proper managed hosting, with object caching (Redis), a real CDN, and a lean custom theme, is genuinely quick and gives you total control over the experience and the data.

Choose WooCommerce when you want ownership and flexibility and you're willing to invest in the hosting to back it. Choose Shopify when you'd rather the platform carried the infrastructure burden. Neither is "faster" in the abstract — the setup decides.

The biggest speed killers we see (and the fixes)

Across audits, the same offenders come up again and again. This is where the 46-to-94 story lives.

That client had a 14MB page. The worst of it: a heavy 3D model loading in the hero, plus a smooth-scroll library and a stack of scroll-triggered JavaScript running on every frame. Beautiful in a demo, brutal on a phone.

What we did:

• Replaced the 3D model with a static, right-sized image. Page weight dropped from ~14MB to ~1MB. That one change did most of the work.
• Removed the smooth-scroll and excess JS. Native scrolling is smooth and free; the library was costing us INP for a feel most users never noticed.
• Lazy-loaded everything below the fold. Images and media only load as you approach them.
• Right-sized every image. Correct dimensions, modern formats, no 3000px files displayed at 400px.

Mobile Lighthouse: 46 → 94. No re-platform, no new CMS. The platform was never the problem.

The recurring killers, and their fixes:

• Hero video or 3D that autoloads → static poster image, load the heavy asset only on interaction.
• Unoptimised images → WebP/AVIF, correct dimensions, lazy-load.
• Too much JavaScript → cut libraries you don't need, defer the rest, render on the server.
• Third-party scripts on the critical path → audit them, delay non-essential ones, question whether each earns its keep.
• Cheap hosting → proper managed hosting with edge caching. TTFB is the foundation everything else sits on.

How we get 90+ on any platform

There's no secret. There's a method, and it's the same regardless of what's underneath.

We measure first. Lighthouse for lab data, and Google's field data (CrUX) for what real visitors actually experience — the two often disagree, and the field data is the one Google ranks on. We look at LCP, CLS, and INP separately, because a single "score" hides which lever to pull.

We set a performance budget. A hard ceiling on page weight and JavaScript before a build ships. It's much cheaper to protect a budget than to claw back a bloated site later.

We're honest about trade-offs. A cinematic 3D hero and a top mobile score are often in tension. Our job is to tell you that plainly and find the version that keeps the impact without the 14MB — a static frame, a lighter treatment, load-on-interaction. Design and speed aren't enemies, but they need refereeing.

We match the platform to the need. Content site with pockets of interaction? Astro or headless. App-like product? Next.js. Client who lives in the WordPress editor? Custom WordPress, done lean. Shop that wants zero infrastructure worry? Shopify. Shop that wants ownership? WooCommerce on real hosting. If you're weighing it up, our Build Spec tool walks you through it, and you can always talk to us.

The platform is a starting point. The score is a choice you make afterwards.