How this site scores 100/100 on PageSpeed — every decision explained
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: no web fonts
This is the single biggest one, and it’s a decision to not do something.
There is no Google Fonts link on this site. No @font-face rule. No font files at all. Every word you’re reading is set in whatever your device already had installed — San Francisco on an iPhone, Roboto on Android, Segoe on Windows.
A typical web font setup costs you two or three round trips before any text is readable: fetch the CSS, parse it, discover the font file, fetch that, then render. During that window visitors stare at either blank space or a flash of the wrong typeface. There are mitigations — font-display: swap, preloading, subsetting — and they all reduce a cost that only exists because you chose to pay it.
What we gave up: a distinctive typeface. Real cost, and for a brand-heavy site it might be the wrong trade. We decided a performance company loading three font files would be slightly embarrassing.
Decision 2: almost no 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.
Across every page, the total client-side JavaScript is one 8.5 KB file, and it only loads on the free audit tool page — where it genuinely needs to handle a form and render results. The homepage, the pricing content, the blog: no framework runtime, no hydration, no virtual DOM reconciling a page that was already finished.
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 — and all of it happens 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 scripts, for Vercel Analytics and Speed Insights. They’re deferred and served from this domain rather than a third party, but they are JavaScript and we’re not going to pretend otherwise. “Zero JavaScript” would be a lie. “No framework runtime, and 8.5 KB of hand-written JavaScript on exactly one page” is the truth, and it’s still unusual.
What we gave up: the convenience of reaching for a component library the moment something needs to be interactive. The audit tool’s form is hand-written vanilla JavaScript. It took longer to build than importing a framework would have, and that is the actual trade — developer time for visitor time.
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. No fonts, 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.