Engineering
This page is the demonstration.
Every agency says their websites are fast. Almost none publish the numbers or the method. Everything described here is verifiable in the browser you're reading it in.
What the site ships
Uncompressed totals across the production build. Individual pages load only the assets they use.
On measurement
Method matters as much as the number.
A performance score with no stated device, connection or date is not evidence; it's a screenshot. Any number we publish for this site states all three, and we re-measure when the site changes.
The same applies to field data. Chrome UX Report data needs real traffic volume before it exists, so early on there may not be any; and we'll say that rather than present lab numbers as field numbers.
It's the same rule we apply to client work: a metric without a source and a date doesn't get published. In this codebase that's enforced rather than trusted; the component that renders a number throws a build error if it has no source.
The stack, and why
Astro; static-first
Pages are generated at build time. Your browser receives finished HTML with nothing to assemble. Most sites in this industry run WordPress with a page builder and a stack of plugins, which means the server builds each page on request and the browser downloads several hundred kilobytes of JavaScript to make it work.
One self-hosted variable font
A single woff2 served from this domain; no third-party font request, which removes a render-blocking dependency on someone else's infrastructure. The width axis does real work: condensed for display, normal for body. One family, two voices.
No framework on the client
No React, no Vue, no Svelte. Nothing on this site requires them.
Contrast verified by script
The palette runs through an automated WCAG check on every build, including deliberate assertions that certain colour combinations must fail. If the palette drifts, the build tells us instead of a user finding out. It caught a real defect during development; a border colour measuring 1.67:1 against white, failing the 3:1 requirement for input outlines. We changed the colour rather than lowering the standard.
What speed is actually worth
People leave slow sites. Most visitors to a local service site are on a phone, often on mobile data, often in a hurry. Load time is the first filter.
Google charges you more for slow landing pages. Page experience feeds Google Ads Quality Score, and Quality Score affects cost per click. A slow landing page means paying more for the same position, indefinitely.
Nothing to patch. No plugins means no plugin vulnerabilities and no update treadmill. The security surface of a static site is close to nothing.
What we refused to ship
Deciding what to leave out is most of what makes a site fast. Each of these is a real request we've had.
- An animation library
- CSS and about fifteen lines of JavaScript handle every transition here.
- A carousel library
- Native CSS scroll-snap does it.
- An icon package
- Inline SVG, only the icons actually used.
- Magnetic buttons and a custom cursor
- They hurt touch accuracy, cost JavaScript, and add nothing.
- A cookie consent platform
- No non-essential tracking means nothing to consent to.
- Chat widgets
- Typically the single heaviest third-party script on a small business site.
- Multiple analytics tools
- One, configured properly.
Where WordPress is the better choice
If you publish complex content daily, need several non-technical editors working simultaneously, or depend on a specific plugin ecosystem; a membership system, a complex booking engine, a large catalogue; WordPress is genuinely the better tool and we'll tell you so.
Static builds suit sites where content changes weekly rather than hourly and where speed and reliability matter more than editorial flexibility. That describes most local service businesses. It doesn't describe all of them.
We'd rather lose the project than build the wrong thing on it.
How it's tested
- Automated accessibility checks on every template
- Contrast verification as part of the release checks
- Keyboard-only navigation pass
- Screen reader structural check
- Eleven viewport widths from 320px to 1920px
- 200% and 400% zoom
- Reduced-motion pass, checking content is still visible
- Broken link and orphan page checks
- Structured data validation
Lighthouse catches roughly a third of accessibility issues. The rest needs a keyboard-only pass and a screen reader. We do both.Read our accessibility statement.
Start a project
Want this measured on your site?
We'll run the same checks against what you have now and send you the results.