WDSL

London web design guide

By Web Design Studio London

How We Build 100/100 PageSpeed Websites for London Businesses

Most London business websites we audit score between 30 and 60 on mobile PageSpeed. Ours score 100. This is the exact stack and the specific decisions behind that gap — not theory, but what we actually do on every build.

Ask for advice
Developer building a fast, high-performance Next.js website for a London business

01

The number most London sites are losing on

When we audit a typical London small business website, the mobile PageSpeed score sits between 30 and 60. The desktop number flatters everyone, so it is the mobile figure that matters — most of your London traffic is on a phone on mobile data. A score in that range usually means a Largest Contentful Paint (the moment the main content appears) of three to six seconds. Google's own research puts the bounce probability up by roughly 90% as load time goes from one to five seconds. In a market as competitive as London web design, that is enquiries walking out before the page has even rendered.

The sites we build score 100 on mobile and desktop, with LCP under 1.5 seconds on a mid-range phone over 4G. That is not because we are cleverer — it is because we made a small number of structural decisions that most agencies skip. Here is each one.

02

Decision 1 — static export, not a live CMS

The single biggest lever is architecture. A standard WordPress site renders each page by running PHP and database queries on a server every time someone visits, then loads a theme and a stack of plugins on top. That is a lot of work happening between the click and the content.

We build with Next.js and export the entire site to static HTML at build time. By the time a visitor arrives, every page already exists as a finished file — there is no server thinking, no database query, no plugin chain. The browser receives HTML that is ready to paint immediately. For a service business whose pages do not change minute to minute, this removes an entire category of slowness that a CMS reintroduces on every request. The trade-off is that content updates require a rebuild rather than a live editor — a non-issue for most service businesses, and the reason the site is both faster and more secure (there is no live admin panel or database to attack).

03

Decision 2 — self-hosted WebP images, never hotlinked

Images are where most fast frameworks still end up slow, because the images themselves are heavy. On this very site we ran the migration ourselves: every hero and card image was converted to WebP at 1200px wide and served from our own domain rather than hotlinked from a third party. The result was an average image weight of around 77KB — a fraction of the 200–400KB a typical un-optimised JPEG carries, and with no dependency on an external host that could slow down or disappear.

The lesson for any London business: a single un-optimised hero image can cost you more PageSpeed than your entire layout. WebP (or AVIF) plus correct sizing plus same-origin hosting is the difference between an image that paints instantly and one that drags your LCP past three seconds. We never hotlink images from stock sites in production — it hands control of your load time to someone else's server.

04

Decision 3 — a Cloudflare edge in front of everything

Static files are only fast if they are physically close to the visitor. We deploy to Cloudflare's edge network, which caches the site across data centres worldwide. A visitor in London is served from a London-area edge node, not from a single origin server that might sit in another country. Time to First Byte — how long the browser waits before it receives anything at all — drops to well under 200 milliseconds.

This also means the site stays fast under load. A local news mention or a viral social post that would slow a shared-hosting WordPress site to a crawl is absorbed by the edge cache without the visitor noticing. For a London business that occasionally gets a spike — a press feature, a seasonal rush — that resilience is part of what 'fast' actually means in practice.

05

Decision 4 — ship almost no JavaScript

Modern websites are often slow not because of images or servers but because of JavaScript. Every animation library, chat widget, analytics tag, and page builder ships code that the phone has to download, parse, and execute before the page becomes interactive. This is what wrecks the Interaction to Next Paint and Total Blocking Time metrics that Google now weighs.

We ship the minimum. Interactions that genuinely need JavaScript get it; everything else is plain HTML and CSS that the browser renders without running any script. Analytics loads after the page is interactive, never before. The result is a page that is usable the instant it appears, rather than one that looks ready but ignores taps for two seconds while a bundle finishes executing. Most London agency sites we test fail here — they look designed, but they are heavy.

06

Why this matters more for London businesses specifically

London is one of the most competitive local search markets in the world, and Core Web Vitals are a confirmed Google ranking signal. When two London web design or service businesses are otherwise evenly matched on content and links, the faster site wins the position — and then converts more of the traffic it earns, because fewer visitors bounce before the page loads. Speed compounds: better rankings bring more visitors, and a faster page turns more of them into enquiries.

There is also a trust dimension specific to higher-value London sectors. A private clinic in Marylebone, a fintech in Canary Wharf, or a law firm in the City is judged partly on its website the moment it loads. A slow, janky site quietly signals a business that cuts corners. A site that appears instantly and responds to every tap signals the opposite — before a single word is read.

07

What to check on your own site today

Run your homepage through Google PageSpeed Insights and read the mobile score, not the desktop one. If it is under 90, the usual culprits, in order, are: a heavy un-optimised hero image, a CMS and plugin stack doing work on every request, render-blocking JavaScript from widgets and builders, and an origin server far from your visitors with no edge cache. Each of those is fixable, but past a certain point it is cheaper and faster to rebuild on a static foundation than to keep patching a slow one.

That is the approach we take on every project: static Next.js, self-hosted WebP, a Cloudflare edge, and minimal JavaScript. It is why our London builds score 100 while the sites they replace scored 40 — and why those scores hold up months later instead of degrading as plugins accumulate.

Vali Neagu

Written by

Vali Neagu

Founder, Web Design Studio London

Building conversion-focused websites and web applications for London businesses. Next.js, design, and strategy — in-house, fixed price.

Related services

Turn the research into a page.

These commercial pages connect the guide to enquiry-focused services, which supports topical depth and conversion.