One File, Zero External Requests: What That Rule Actually Costs You

Every landing page tutorial starts with a framework. This one starts with a constraint I imposed on my own three templates and what broke when I held it: one HTML file, no CDN, no webfont, no build step, no analytics.

I ship these as a product, so the numbers below are measured, not remembered. Three templates, 537 lines of HTML between them, one @media rule, one inline script of 16 non-blank lines, and zero requests to anything that isn't the file itself.

The claim is testable, and you should test it

"Zero external requests" is easy to say and easy to get wrong, because the usual leaks are invisible in the source: a <link> to a font, a favicon pointing at a CDN, one <script src> someone pasted from a snippet.

Run this in the folder:

grep -o -E '(src|href)="[^"]*"' *.html | grep -v '^\s*$' | sort | uniq -c | sort -rn

Anything in the output that starts with http, //, or data: other than an inline asset is a leak. In my three files the only hits are href="#section" anchors and the placeholder text. That grep — not a badge, not my word — is the whole proof.

The second check is the one people skip: open the file with the network disconnected. Double-click it. If anything is missing, the page was lying to you.

What the rule buys, honestly

It loads anywhere. A page with no dependencies renders on a hotel wifi that blocks CDNs, on a phone in a tunnel, from a USB stick, and from an email attachment. This is not hypothetical if your reader is opening your page at a conference or in a country where a specific CDN is blocked this week.

Nothing third-party can break it. The most common way a small site goes down is not your host. It's a font, an analytics snippet, or a widget whose endpoint moved, whose certificate expired, or whose account got disabled. A zero-request page has no supply chain.

Nobody is watching your reader. No third party learns who opened the page, which matters when the page is for a client who is not comfortable with five trackers on a form they haven't filled in yet.

It is editable. A non-technical client can open the file in a text editor and change a sentence. That is the single most underrated property of a small page, and it dies the moment you add a build step.

What it costs — the part the pitch usually omits

No shared design tokens. Three files means three copies of the same colour and type scale. When you change the palette you change it three times, and the fourth time you forget one. The mitigation is boring and real: keep the :root block identical at the top of every file and diff those blocks before you ship.

Responsive behaviour is hand-written. One @media rule across 537 lines sounds like a boast and it is mostly a consequence: the layout is a single column that goes two-above-a-breakpoint, so there is almost nothing to re-flow. If your design has a sidebar, a card grid and a sticky nav, you will need more than one rule, and you will need to test them. I have not tested these pages against Core Web Vitals thresholds on any host, and I am not going to pretend a text-only argument can substitute for that.

No dependency management, including the useful kind. No shared component means no shared bug fix. If you find yourself writing the same lightbox twice, that is the signal the constraint has stopped costing you simplicity and started costing you time. At that point a build step is the right answer, and you should take it — deliberately, not by default.

Forms are the hard case. A page with zero requests cannot submit anything. So a signup form either posts to a third-party endpoint (one request, chosen on purpose) or the page is a brochure with a mailto: link. Both are defensible. What is not defensible is shipping a form that looks like it works.

The structure that carries a cold reader

Independent of the file rule, the pages that convert have four parts in this order:

1. What it is, in a sentence a stranger could repeat accurately.
2. Who it is for, said narrowly enough that the right person feels addressed and the wrong one leaves.
3. One piece of proof — a number, a name, a screenshot, a result. Not five.
4. One action, with the friction removed.

The failure mode I see most is a page that opens with a clever headline, spends three screens on feelings, and puts the price and the button below a fold most readers never reach. If your first sentence needs 60 words, you have two sentences and one of them belongs further down.

To find what a reader actually has to fill in, count the placeholders:

grep -o -E '\[[^]]+\]' *.html | wc -l

Across my three templates that returns 97 bracketed spans sitting on 51 lines. That number is the real cost of reusing a landing page: not the HTML, the 51 decisions.

The full write-up

I put the four-part structure, the exact :root block I keep identical, and the two cases where a single file is genuinely the wrong choice into a longer guide on my site: One File, Zero External Requests.

I sell the three templates as HTML Landing Page Templates, $9, and the shop has a $19 bundle. But the grep commands above do more for you than buying anything does, because they tell you whether your page is telling the truth.