Picture this: you’ve followed every framework guideline, pre-rendered every page and stripped out every interactive component. Your blog still won’t score 100. That’s where one solo developer ended up, according to a post that reached 184 points on Hacker News. To get a clean 100 in every Lighthouse category, he had to remove the framework he’d used most: Next.js.
His path there works as a practical playbook for anyone shipping a fast static site, including the many sites that AI coding tools now scaffold on heavy frameworks by default.
⚡ Quick Start
You’ll learn: how to diagnose and fix performance problems on a static site, from caching and CDNs to images and unused JavaScript.
You’ll need:
- A static or mostly static site (a blog, docs or a landing page)
- pagespeed.web.dev for measurement (the author ran every test there)
- A CDN account. The author used Cloudflare’s free tier
Step 1: Figure out what you actually need
The author tested the usual options before building anything. Medium and Blogger felt bloated and slow. WordPress meant “plugin hell.” Ghost needed self-hosting, and editor upgrades kept breaking things. Hugo came closest, but setup was still a hassle. Bear Blog had great performance, but its extreme minimalism and lack of free images and AdSense ruled it out.
Why it matters: Writing down your real requirements (speed, Markdown and HTML control, multiple blogs, accessibility) tells you which tools are overkill before you sink time into them.
Step 2: Get caching right
Caching gives you the biggest early win. Next.js makes it easy with ISR (Incremental Static Regeneration) and an extended fetch that accepts a next option for caching.
Why it matters: Good caching alone takes you a long way. It just can’t fix distance.
Step 3: Add a CDN for global visitors
Caching speeds things up within one region. Visitors farther away still pay the network latency. A CDN fixes that by serving copies from servers near each visitor.
Vercel bundles a CDN with Next.js, but the author pointed to the pricey Pro plan, serverless cold starts and ecosystem lock-in. He chose Cloudflare instead.
Step 4: Drop the duplicate cache
Once the CDN was in place, Next.js caching became a burden. Every new post meant invalidating two caches. His conclusion: for a static site, a CDN alone is enough.
Tip: Two cache layers mean two places for stale content to hide. Keep one if you can.
Step 5: Optimize images
Modern photos often top 10MB. Serve them raw and performance “will go completely off the rails.” On an earlier project he’d built a Lambda + S3 + CloudFront pipeline, which worked but needed a lot of upkeep. This time he used Cloudflare Image Transformations, which covers 5,000 images on the free tier.
Step 6: Measure and read the warnings
On Next.js 16.1.6 the scores were high but not perfect. PageSpeed flagged a large amount of legacy JavaScript. He hadn’t written it. It came from the framework runtime.
Step 7: Test by elimination
He removed every client component and kept only server components. The score didn’t move. Hydration (the step where JavaScript attaches to server-rendered HTML) was part of the story, but not all of it.
Why it matters: Pulling things out one at a time tells you whether the problem lives in your code or in the platform.
Step 8: Find the real culprit
Next.js ships a client runtime even on static pages. next/link and next/image are themselves client components ('use client'), so those two alone pull in the runtime and trigger hydration. Remove them and the App Router’s own router and error boundaries still stay. The only way to get to zero was a hack that strips scripts out of the rendered HTML. Unused code alone came to 230,460 bytes.
That’s when it clicked for him: “If I’m going to do that, why am I even using Next.js?”
Step 9: Make the hard call
He struggled with it, since he’d put a lot of time into the app. He still removed Next.js entirely. His view was that the extra features wouldn’t pay off long term, and a few points of quality were worth it. He considered going fully vanilla but chose a different route, which the full post describes.
🧭 What This Means
What stands out is the core lesson: most static websites don’t need JavaScript at all. Frameworks quietly charge you for features you never use. That matters more now that AI assistants reach for React-based stacks by default.
Next steps:
- Run your site through pagespeed.web.dev and look for unused or legacy JavaScript
- Ask whether your CDN already covers what your framework caching does
- Try a static-first generator on a test page and compare the scores
- When an AI tool scaffolds a project, tell it you want zero client-side JavaScript
The full write-up on Hacker News covers the rebuild that came after Next.js.