Start a project

Speed, security & SEO

Astro on Cloudflare Workers · Performance · Attack surface · Ranking

Speed is not a feature added at the end. It is the framework choosing what to send — and what it refuses to send is what makes the site harder to break.

Measured with Lighthouse 13.5.0 on mobile against the live sites, not a staging build. Each score below is the median of four runs across all six production sites. Lab scores move a point or two between runs, so read them as a range rather than an exact number.

The problem

A framework runtime is downloaded by every visitor before the page can finish working, whether or not the visitor needs it. That is a few hundred kilobytes, on the slowest connection in the room, before anyone reads a word.

It is also an attack surface. A publishing component carries a history of vulnerabilities that only get exploited when the visitor’s browser runs code the page never needed. Sending less is both the fast path and the safe one.

What I built

01

Pages are HTML, not a bundle

Astro renders to plain HTML at the edge and ships no framework runtime to the visitor. The three scripts the BrightSmile page loads total 2.4 KB compressed. Everything else the page needs is already in the HTML, which is why it renders before the network has finished thinking about it.

A measurement of what the BrightSmile Dental page downloads: three JavaScript files totalling 2,454 bytes, and no framework runtime
The entire JavaScript budget: 2.4 KB

02

Security headers set at the edge, on every response

HTTPS, HSTS for two years, nosniff, a referrer policy and a full content security policy are set in the Worker rather than left to a plugin. One function at a single choke point, so a cached hit and a cache miss both get them — a site that sends them only on the happy path looks configured and is not.

The HTTP response headers from the Aldridge & Kane site, showing strict-transport-security, x-content-type-options, referrer-policy, x-frame-options and a content security policy
The actual response headers, from curl -sI

03

Core Web Vitals are the ranking lever

Google ranks on speed as a signal, not a bonus. The screenshot here is the desktop run: 100 for performance, accessibility, best practices and SEO, a 1.2s largest paint, zero blocking time and no layout shift. On an emulated phone — slow 4G, a Moto G Power — BrightSmile reads 98–99 across four runs, and that is the number I quote, because it is the screen your patients are actually on.

A Google PageSpeed Insights report for BrightSmile Dental, captured on an emulated Moto G Power over slow 4G: 100 for performance, 100 for accessibility, 100 for best practices, 100 for SEO, and 2 out of 2 for agentic browsing. First contentful paint 0.8 seconds, largest contentful paint 1.2 seconds, total blocking time 0 milliseconds, cumulative layout shift 0, speed index 1.3 seconds.
PageSpeed Insights, mobile — 100 / 100 / 100 / 100, LCP 1.2s, CLS 0

The result

100
PageSpeed, this site, mobile
0
layout shift, on every site
2.4 KB
JavaScript sent to the visitor

↳ the handover

The audit is repeatable — Lighthouse will run the same check against your site at any time, and you are welcome to. If the numbers on this page ever stop matching the live sites, that is my problem, not yours.

Open the PageSpeed report itself Check this homepage's live score