Speed isn't a feature you bolt on at the end. It's a consequence of decisions made at the very start — how the site is built, where it's served from, and how much work the browser has to do before a visitor sees anything. That's why the honest answer to "can you make my site faster?" is usually another question: how is it built right now?
At Blincks we've spent years making WordPress websites fast. In the last couple of years we've added a second and third way of building — headless WordPress, and fully modern stacks on Next.js. Here's how we choose between them, and what each one actually gives you.
Why most websites are slow
A traditional WordPress page is assembled on demand. A visitor asks for a page, the server wakes up PHP, queries the database, runs your theme and every active plugin, and finally produces HTML. Then the browser downloads a pile of CSS and JavaScript that each plugin insisted on adding — much of it for features that page never uses.
None of that is WordPress's fault, exactly. It's the cost of a system designed to be infinitely extensible. But it does mean the typical site carries weight it doesn't need, and every request pays for it again.
Way one: optimized WordPress
Sometimes the right answer is to keep what you have and make it genuinely fast. A well-built WordPress site with a lightweight theme, a disciplined plugin diet, proper caching, a CDN, and modern image formats will comfortably load in under two seconds and score well into the 90s on PageSpeed.
We reach for this when the site is content-led, the team is happy in WordPress, and a rebuild would be spending money to solve a problem that tuning can solve. It's the cheapest path to a real improvement, and for a lot of businesses it's the correct one.
Way two: headless WordPress
Headless means splitting the website in two. WordPress stays exactly where it is — same dashboard, same editor, same workflow your team already knows — but it stops being responsible for what visitors see. Instead it becomes a content API, and a Next.js front end renders the actual pages.
The result is a site that behaves like a modern web app: pages are pre-rendered and served as static files from a CDN, navigation between them feels instant, and no visitor request ever waits on PHP or a database query.
- Your editors keep the WordPress dashboard — nothing about writing a post changes
- Pages are pre-built and served from the edge, so there's no server render on each visit
- Plugin front-end bloat disappears — the front end only ships what it actually uses
- Better security posture: your WordPress admin isn't the public-facing surface
- You can redesign the front end without migrating a single piece of content
The trade-off is honest complexity. There are two systems to deploy instead of one, some WordPress plugins that inject front-end functionality need a rethink, and previewing drafts takes a little wiring. For a brochure site with three pages, that's overkill. For a content-heavy site where speed is tied to revenue, it pays for itself.
Way three: fully modern — Next.js at the edge
When a project doesn't need a traditional CMS at all, we build it entirely in Next.js and deploy it to the edge. The site you're reading right now is exactly that: a Next.js application exported to static HTML, CSS, and JavaScript, served from Cloudflare's global network, with a small Worker handling the dynamic parts — contact forms, the client dashboard, job applications — backed by Cloudflare's D1 database and R2 storage.
No origin server sits in the request path. A visitor in Karachi and a visitor in Toronto both get the page from a datacentre near them. And because we control every byte, we can be ruthless about what ships:
- Fonts are self-hosted and inlined at build time — no render-blocking round-trip to Google Fonts
- Every image is converted to AVIF and WebP, sized correctly, and given explicit dimensions so nothing shifts as it loads
- Below-the-fold images are lazy-loaded and de-prioritized so they never compete with the hero for bandwidth
- The build targets modern browsers, so we don't ship polyfills for features every current browser already supports
- Third-party scripts load on interaction, not on page load — the scheduling widget only downloads when someone actually clicks it
“Every one of those decisions is worth a few hundred milliseconds. Stack them together and you get a site that's loading before the visitor's finger leaves the screen.”
— The Blincks performance principle
Vercel or Cloudflare?
Both are excellent, and the choice matters less than people think. Vercel is built by the team behind Next.js, so every framework feature works on day one and the developer experience is superb — it's the path of least resistance for a pure Next.js app.
We chose Cloudflare for this site because we wanted the whole stack in one place: static assets, the API Worker, the database, file storage, DNS, and CDN all under one roof, with predictable pricing and no egress fees. If a project leans heavily on Next.js's server-side features, we'll usually recommend Vercel. If it wants an integrated edge platform — or the domain is already on Cloudflare — we'll usually recommend Cloudflare. We're happy to build on either, and we'll tell you which one we'd pick for your project and why.
So which one is right for you?
A rough guide, and the questions we'd ask in a first call:
- Happy in WordPress, site is reasonably built, just feels sluggish → optimize what you have
- Content-heavy, editors need WordPress, but speed is costing you conversions → headless WordPress
- Marketing site or web app with no real CMS requirement, speed is the priority → Next.js at the edge
- Not sure → that's normal, and it's exactly what a consultation is for
The thread running through all three is the same: decide the architecture deliberately, then sweat the details. That's the whole job. A fast website isn't a lucky outcome — it's a series of small, unglamorous choices made correctly, over and over, until the page appears before anyone has time to wonder whether it will.
If your site feels slower than it should, we're glad to take a look and tell you honestly which of the three paths we'd recommend — including the one where you don't need to rebuild anything at all.
Want us to take a look at your site?
Book a free 30-minute consultation — no pressure, just a real conversation about what would make the biggest difference.