There’s a badge at the top of this site claiming a perfect 100/100 on Google PageSpeed. Claims like that are cheap, so this post is the receipts: every decision behind the number, why we made it, and what it cost us.
We’d rather you finish this and think “oh, that’s all it is” than “wow, impressive.” Fast sites aren’t clever. They’re mostly a series of things you decided not to do.
What the number actually is
Measured on the day we wrote this, on both mobile and desktop:
| Measurement | Result |
|---|---|
| Performance score | 100 / 100 |
| Largest Contentful Paint | 0.9 s |
| Total Blocking Time | 0 ms |
| Cumulative Layout Shift | 0 |
| Opportunities flagged by Lighthouse | 0 |
One important caveat before we go further, because it’s the kind of thing most people posting these screenshots leave out: this is lab data. Google simulates a mid-range phone on a throttled connection. It isn’t the same as what real visitors experience, which is called field data and comes from Chrome’s real-user reporting. This site doesn’t get enough traffic yet for Google to publish field data for it — so a perfect lab score is a statement about how the page is built, not proof of what every visitor feels.
We’d rather tell you that than let you assume otherwise.
Decision 1: one font, and only one
Updated 8 October 2026. When this post first went up, the answer here was “no web fonts at all”. The site has since been redesigned, and it now uses exactly one. Here is how, and why it didn’t cost the score.
A typical web font setup costs two or three round trips before any text is readable: fetch a stylesheet from Google, parse it, discover the font file, fetch that from another server, then render. Visitors stare at blank space or a flash of the wrong typeface while it happens. That is the cost we refused before, and still refuse.
What changed is that one file can now do the work of a family. Archivo is a variable font with two axes, weight and width, so the wide headlines, the narrow labels and the body text you’re reading all come from a single 90 KB file. It is served from our own domain, so there is no request to anyone else. It is preloaded, so the browser starts fetching it with the page. And it is set to font-display: optional, which means that if it hasn’t arrived within about a tenth of a second, the page simply keeps the system font for that visit instead of waiting or reflowing. It can never delay text, and it can never make the layout jump.
What we gave up: 90 KB, once, cached afterwards. And the bragging right of “no web fonts”, which the old version of this post had. We decided a distinctive face was worth one well-behaved file.
Decision 2: none of our own JavaScript
This is the one that moves the needle most on a real site, and the one people underestimate.
This site is built with Astro, which renders components to plain HTML at build time and ships no JavaScript to the browser unless you explicitly ask for it. Since the redesign we don’t ask for it anywhere. The mobile menu is a native <details> element. The FAQ answers open the same way. The blog’s topic filter is radio buttons and CSS. The contact and waiting-list forms are ordinary HTML forms that post to the server and get a confirmation page back.
Even the free speed check works with JavaScript switched off. It used to be the one page with a script, 9.7 KB of it, to submit the address and draw the results. Now the form submits to a page that the server renders and streams: the “checking” panel arrives instantly, and the results follow in the same response a minute later, when Google has answered.
That’s why Total Blocking Time is 0 ms. There’s nothing to block on.
JavaScript is uniquely expensive compared to everything else a page loads. An image of the same size downloads and decodes; a script has to be downloaded, parsed, compiled and executed, all on the main thread, the same single thread the browser needs to respond to a tap. A 300 KB image and 300 KB of JavaScript are not remotely the same cost. This is why phones suffer so much more than the laptop you built the site on.
Being straight about what does load: two small scripts, for Vercel Analytics and Speed Insights, together about 4.6 KB. They’re served from this domain rather than a third party and set no cookies, but they are JavaScript and we’re not going to pretend otherwise. “Zero JavaScript” would be a lie. “None of our own JavaScript, on any page” is the truth.
What we gave up: a little polish. Without a script, a form can’t show “Sending…” in place; it goes to a confirmation page instead. A results page can’t redraw itself; it streams in from the server. We think that’s the right trade for a site whose whole argument is that most of what pages ship is unnecessary.
Decision 3: the CSS ships inside the HTML
One line of config:
build: {
inlineStylesheets: "always",
}Every stylesheet is inlined into the HTML document rather than served as a separate file. The build output contains zero external CSS files.
This matters because CSS is render-blocking — the browser refuses to paint until it has the stylesheet, since painting first would mean flashing unstyled content. An external stylesheet is therefore a mandatory round trip inserted between “HTML arrived” and “anything visible.”
Inlining removes that round trip entirely. The HTML is bigger, but it arrives in one response, and the browser can paint the moment it finishes reading.
What we gave up: cross-page CSS caching. A returning visitor re-downloads the styles with each page instead of reusing a cached file. For a site this small, one fewer round trip on first paint beats caching on the second page. On a large app with heavy shared CSS, we’d probably decide the other way.
Decision 4: icons are inline SVG
Every icon is an SVG element written directly into the markup. No icon font, no sprite sheet, no image requests.
Icon fonts are a particularly bad deal: you download a whole alphabet to use six glyphs, it’s render-blocking like any font, and it renders as tofu boxes if it fails. Inline SVG costs a few hundred bytes inside HTML you were already downloading.
It does make the source files noisier — a single icon can be fifteen lines of path data. We’ll take verbose source over an extra network request.
Decision 5: it’s just files
Every page here is pre-rendered to static HTML at build time and served from a CDN edge near you. There’s no server rendering a template per request, no database query, no cold start. The two API endpoints behind the forms are the only server-side code, and nobody hits them just by reading a page.
The fastest possible response to “give me this page” is a file that already exists.
Decision 6: one URL, no redirect hops
sitespeedlabs.com permanently redirects to www.sitespeedlabs.com, and the site declares a single canonical form for every URL — no trailing slashes, one spelling, everywhere.
This sounds like housekeeping rather than performance, until you measure it. A redirect is a full round trip before the real page even begins loading. While setting this up, we audited both addresses: the redirecting one scored 99 where the canonical scored 100 — Lighthouse flagged “server is slow to respond” and “requests are chained,” and both were really just the redirect.
One point, from one hop, on a page that was otherwise perfect. If your site sends visitors through two or three redirects — plenty do, especially after a domain migration — that’s the cheapest fix you’ll ever make.
Decision 7: nothing third-party
Every decision so far was about code we wrote. This one is about code we didn’t let in, and for most real sites it matters more than all the others combined.
There is no chat widget on this site. No tag manager, no ad pixel, no heatmap recorder, no cookie-consent platform, no A/B testing tool, no “customer engagement” suite. Load the homepage and your browser talks to exactly one domain: ours. The only outbound link on the page is to our X profile, and that’s an anchor you can click, not a resource that loads.
That matters because third-party scripts are the worst kind of JavaScript. You didn’t write them, you can’t optimise them, they change without telling you, and they execute on your visitors’ devices with the same access to the main thread as your own code. A chat widget you added once and forgot about can quietly triple in size over a year. Your site gets slower and nothing in your own codebase changed.
They’re also the hardest to remove, because each one is somebody’s tool. Marketing wants the pixel, sales wants the chat, someone wants the session recorder. That’s a real business conversation, not a technical one.
What we gave up: genuinely useful things. No live chat means a visitor with a question has to use the contact form. That’s a real cost, and for a business doing volume it might be the wrong call.
If your site is slow and you only do one thing, open the list of scripts loading on your homepage and ask, for each one, what it earned last quarter. Most sites are carrying at least one they’d struggle to justify.
What we’d tell you to do first
If you took one thing from this: most of it was subtraction. One font, no framework, no stylesheet request, no icon library, no redirect chain, nothing third-party. We didn’t optimise a slow site into a fast one — we declined to add the things that make sites slow.
And if you took one action from it, make it the JavaScript. Fonts and images are worth fixing, but scripts are the only thing on the list that competes with your visitors for the thread the browser needs to stay responsive.
That’s also the honest reason a perfect score is easier for us than for you. This is a marketing site with no logged-in state and no product catalogue, and we can simply decline the tools a bigger business genuinely needs. If you’re running one, some of those are non-negotiable, and a 100 may not be available to you.
Which is fine. 100 is not the goal. The goal is Core Web Vitals in the green for your real visitors — that’s what Google actually uses for ranking, and it’s achievable on almost any site, including ones with a chat widget and a tag manager. A perfect lab score is a nice flex. Green field data is the thing that makes you money.
If you want to know where your site stands, the free check on this site will tell you in plain language — and it’ll tell you whether Google has real-visitor data for you, which matters more than the score it prints.