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 file totals across the production build. These are an inventory of local files, not the bytes transferred during a visit or a Core Web Vitals result.
On measurement
Method matters as much as the number.
The inventory above excludes inline scripts and third-party downloads. Its JavaScript grouping does not trace module imports. To measure a visit, inspect the browser network log; a performance report also needs a device, connection, date and test conditions.
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 same discipline applies to how we measure AI search visibility for AI search optimization.
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, with 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.
Slow landing pages weaken your ads. Google weighs landing page experience when it judges ad quality in each auction, and ad quality affects both position and price. Quality Score is the diagnostic that reports it, not an input to the auction.
Nothing to patch. No plugins means no plugin vulnerabilities and no update treadmill. The security surface of a static site is small.
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.
- Advertising trackers and social media pixels
- Measurement is Google Analytics and Microsoft Clarity session recording, both named in the privacy policy. Analytics loads asynchronously on arrival; Clarity loads after interaction or a twelve-second fallback.
- Chat widgets
- Typically the single heaviest third-party script on a small business site.
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.
Prefer to talk? (786) 305-5203 or WhatsApp