What makes us different
No themes. No page builders. No plugin stacks.
Most local web work is a bought theme with a builder on top. It is quick, it is cheap, and it has a measurable cost. Here is what we do instead, in full.
Most websites in this city are built the same way: buy a theme, add a page builder, install the plugins that fill the gaps, deploy. It is quick and it is cheap, and for a business that just needs an address on the internet it is a defensible choice.
It also has a measurable outcome, and the measurement is public. HTTP Archive tracks Core Web Vitals by platform across millions of real sites. Sites built on frameworks pass at a substantially higher rate than sites built on WordPress, and WordPress's specific weakness is loading: only around a third of WordPress sites record a good server response time, which is what pushes the main content past the 2.5 second mark.
Page builders make it worse. Independent testing of the common WordPress builders puts their Largest Contentful Paint in the five second range on a standard page, because each one ships a large amount of extra markup and script regardless of what the page actually contains.
None of that is a criticism of the people doing the work. It is a description of what the tools produce. We chose a different set of tools, and this page is the whole recipe.
~58% vs ~38%
Core Web Vitals pass rate
Framework-built sites against WordPress sites, measured across real Chrome users rather than in a lab.
HTTP Archive, 2026
~32%
WordPress sites with good server response
Slow response time is the root of most WordPress LCP failures. Its responsiveness is fine; its loading is not.
HTTP Archive / CrUX
~5 seconds
Typical page-builder LCP
Measured on standard pages built with the common WordPress builders. Google's threshold for good is 2.5 seconds.
WP Rocket, 2026
The recipe
Eleven decisions, and none of them are secret.
People call this our secret recipe. We would rather publish it. Knowing the list is not the hard part. Holding to all eleven on every page, on every deploy, for the life of the site is.
Send HTML, not a program that writes HTML
Pages are rendered on the server and arrive finished. The browser paints text as soon as the first bytes land instead of waiting for JavaScript to decide what the page says.
Ship no JavaScript by default
Interactivity is opted into one component at a time. On this site exactly two components ship any JavaScript: the contact form and the mobile menu. Every page renders as finished HTML, the desktop menus are pure CSS, and every animation runs without a line of script.
Inline the CSS
The stylesheet is written into the page rather than fetched as a separate file. That removes the last render-blocking request before first paint, worth roughly a quarter of a second on its own.
Draw the pictures, do not photograph them
Every illustration on this site is vector shapes written into the page, animated with CSS. No image files, no image requests on the path to first paint, and it stays sharp on any screen.
One font, self-hosted, preloaded
A single family, cut down to the characters actually used, served from our own domain and requested early. Fonts loaded from a third party mean a second DNS lookup and a second connection before any text can appear.
Target modern browsers
Compiling for browsers people actually use drops the compatibility code written for browsers they do not. That is a straight subtraction from the JavaScript every visitor downloads.
Never let the LCP element fade in
An element that starts invisible is not counted as painted until it appears, so a reveal animation on your headline adds its own duration to your score. We found this on our own hero and removed it.
Hold back the heavy third parties
Maps, chat widgets and video players load only when a visitor scrolls near them. A single map embed can outweigh an entire well-built page.
Reserve space for everything
Images, banners and embeds get their dimensions declared up front, so nothing shifts under a thumb already moving toward a link. Our layout shift measures zero.
Put a budget in the build
A limit that a future change has to pass. Sites do not get slow in one deploy; they get slow over thirty of them, and a budget is what notices.
Measure the way the field measures
Median of several runs against the live site with the cache warmed, then checked against real-visitor data once it accumulates. A single lab run measures the network that day as much as it measures your site.
What we leave out
Most of speed is subtraction.
Every item here is standard on a typical themed site. None of it is on the pages we build.
- Bought themesThey ship the code for every feature you did not buy them for.
- Page buildersDrag-and-drop convenience is paid for in markup on every page, forever.
- jQueryBundled by most themes out of habit. Nothing we build needs it.
- Icon fontsA whole font file downloaded to draw six symbols we could draw as shapes.
- Sliders and carouselsHeavy, and people almost never look past the first slide.
- Plugin stacksTwenty plugins means twenty sources of scripts, styles and security updates.
- Tracking we did not agreeEvery third-party tag is someone else's code running on your critical path.
- Blind deploymentNothing goes live unmeasured. The numbers come before the handover, not after a complaint.
Being fair about it
Where WordPress is still the right answer.
We are not against WordPress, and we ran it for clients for years. For a site that is mostly articles and pages, edited by people who already know the admin screen, it is a reasonable choice and we will say so.
What we do not do is build a business-critical site by stacking a theme, a page builder and fifteen plugins, then hand it over without measuring it. That is the combination that produces the numbers above.
If you already have WordPress and like it, there is a middle path we do build: keep it as the editing screen your team knows, and replace the public site with a fast front end that reads from it. You keep the workflow and lose the weight.
Questions
About speed, honestly answered.
Is a custom build really faster than a good WordPress setup?
A carefully tuned WordPress site with caching and a light theme can be quick. The difference is the starting point. We start at almost nothing and add only what your pages need. A theme starts at everything it might ever need and asks you to remove the rest, and most of it cannot be removed.
My developer says my site scores well. Why does it feel slow?
Almost always because they tested once, on a laptop, on office broadband. The score Google uses comes from real visitors on real phones. Ask for the median of several runs against the live site, and then ask what Search Console says about field data. Those two numbers frequently disagree with a screenshot.
Does a fast site actually make me money?
It stops you losing enquiries you never knew you had. Published research consistently puts mobile abandonment above half once a page passes about three seconds. We would rather point you at that than invent a number for your business.
Can you make my existing site fast instead of rebuilding it?
Often, yes, and we will say so honestly after an audit. Deferring third party embeds, fixing image sizing and removing unused plugins can move a site a long way. Where a page builder is the cause, there is a floor we cannot get under without replacing it.
What if I want to keep editing in WordPress?
Then keep it. We can leave WordPress as the editing screen your team already knows and rebuild only the public site to read from it. You keep the workflow and lose the weight, which is usually the outcome people actually wanted.
Find out where your site actually stands.
We will run it the way Google does and send you the real numbers with a prioritised list of causes. If the fix is two hours rather than a rebuild, we will tell you that.