Why Layerstop ships landing pages as single HTML files with zero third-party scripts

One file, no build step, no trackers. Here's what that actually buys you — and the four tradeoffs I'd rather name than hide.

The page you clicked here from is one file. So is this one. Markup, CSS, JavaScript, images — all of it in a single document your browser downloads once and renders. No bundler, no CDN, no analytics snippet, no chat widget, no cookie banner.

That isn't nostalgia. It's a decision about who pays for the complexity.

The default is heavier than it looks

A typical modern landing page: a framework, a component library, a CSS framework, a form provider, an analytics script, a heatmap tool, a chat widget, and a consent manager to legally cover the four scripts above. The median web page is around 2.5 MB.

Each of those scripts is its own DNS lookup, TLS handshake and round trip. Each one is a third party who can slow your page down, break it, or quietly start collecting data nobody on your side audited. And the founder who paid for the page can't fix any of it without hiring someone. That's the real cost — not the kilobytes.

What one file buys you

Speed you don't have to defend. One request for the document, zero blocking third-party requests. Nothing renders late because a tag manager was slow. The page holds up on bad hotel wifi in a way a 2.5 MB bundle structurally cannot.

A page that still works in three years. No npm install that no longer resolves, no framework major version, no deprecated SDK. HTML written in 2010 renders today; a 2021 build pipeline often won't even install. Your landing page should outlive whatever was fashionable when it shipped.

Actual ownership. You get a file. Open it in any text editor. Host it anywhere that serves static files — Netlify, Cloudflare Pages, GitHub Pages, an S3 bucket, a folder on a Raspberry Pi. No proprietary export, no page-builder subscription, no vendor who can raise your rent.

Privacy by construction. Zero third-party requests means zero third-party data collection — not "we configured it carefully," structurally none. It's also why there's no cookie banner on this site. There's nothing to consent to.

The four tradeoffs

Single-file isn't free. I'd rather say so than let you find out later.

• It doesn't scale to a 40-page site. One file is right for one page done exceptionally well. Past about three pages you want a real templating step, and I'll tell you that on the call rather than sell you a sprint.
• Every effect is hand-written. The blur reveals, ink reveal, 3D gallery and tilt-scroll on the main page are all vanilla JavaScript, because importing a library to do them would defeat the point. That's more of my hours, not fewer.
• No analytics out of the box. You get an empty slot and a recommendation (Plausible, roughly 1 KB, no cookie banner). I'd rather you add it deliberately than inherit it.
• Inlined assets make the file big on disk. The main page's HTML is heavy because the images are base64'd into it. Still one cached request — but if you diff it in git, you'll notice.

How to check any of this yourself

Don't take my word for it. On any page I've built:

1. View source. It should be readable, commented and complete.
2. Open DevTools → Network, reload, sort by domain, and count the domains that aren't the site's own.
3. Run it through PageSpeed Insights and the W3C validator. Neither of them works for me.

The main page runs a live self-audit that counts its own resources in your browser, specifically so you don't have to trust a number I typed in.

The point

It's not that one HTML file is always right. It's that most landing pages carry complexity nobody chose, nobody audits, and the person who paid for the page can't remove. Starting from a single file makes every addition a decision instead of a default.