Developer hits perfect 100 Lighthouse scores by dropping Next.js for Hono

What happened

A developer has published a first-hand account of taking their blog to a perfect 100 in every Lighthouse category, and the decisive step was removing Next.js, the framework they had used the most. The post, which surfaced on Hacker News's front page, walks through the caching work, the diagnosis of what was capping the score, and the eventual rewrite in Hono.

The project began as an attempt to build a lighter alternative to hosted platforms. According to the author, Medium and Blogger felt bloated and slow, WordPress meant plugin maintenance, Ghost required self-hosting or a costly plan and broke on upgrades, and Hugo was capable but a chore to set up. Bear Blog came closest, but its extreme minimalism, restricted editor and lack of free image uploads ruled it out. The target became a blog as fast as Bear Blog with somewhat more functionality.

Caching and images came first

The Next.js version, built on version 16.1.6, already followed standard performance practice. Pages were pre-rendered with ISR, and the author notes that Next.js's caching features get you a long way on performance by themselves. For global reach the site sat behind a CDN, and images were handled with Cloudflare's Image Transformations, which the author says includes 5,000 images on the free tier.

The author also explains why the Vercel-and-Next.js pairing lost its appeal: the Pro plan is expensive from the outset, serverless cold starts remain an issue, and dependence on the Vercel ecosystem is hard to ignore. Once a CDN does the heavy lifting, Next.js's own cache becomes a second cache to invalidate on every publish. For a static site, the author concluded, a CDN alone is enough.

That work produced high but not perfect scores.

The runtime floor Next.js couldn't get under

Lighthouse flagged a large volume of legacy JavaScript in the bundle that the author had not written; it came from the framework runtime Next.js ships, on pages with zero interactivity. As an experiment, the author removed every client component and left only server components. The score did not move.

The root cause, as the author describes it: next/link and next/image are themselves marked as client components, so including either one is enough to pull in the client runtime and trigger hydration. Remove those too, and the App Router's own runtime, including the router and error boundaries, still remains. There is no official way to get it to zero; the only option was a hack that strips the scripts from the rendered HTML. At that point, the author reasoned, the framework was no longer earning its place.

The unused JavaScript alone came to 230,460 bytes.

The rewrite in Hono

For the replacement, the author chose Hono, drawn to its lightweight design and its JSX support, with a migration cost that looked manageable. Going fully vanilla was considered and rejected in favour of keeping framework-level productivity. The results, measured with pagespeed.web.dev:

• Perfect scores of 100 across every Lighthouse category.
• Unused JavaScript dropped from 230,460 bytes to 407 bytes.
• The long task that runs before anything renders fell from 309.3ms to 68.01ms, an improvement the author puts at roughly 78%.
• Build time fell by about 40%.

One screenshot shows an SEO score of 69; the author clarifies that the site in question deliberately blocks search indexing. And Next.js has not been abandoned entirely, since the blog's management app is built with it. The author's view is that Next.js remains a good framework for interaction-heavy applications.

Why it matters

This is a concrete data point in the recurring framework-versus-static-site debate. React meta-frameworks ship a client runtime, including router and hydration machinery, even to pages with no interactivity, and as this account shows there is no supported path to zero while staying inside the framework. For content sites where every Lighthouse point matters, that runtime is a floor you cannot build under. The alternative does not have to be hand-written HTML: a small server-side framework with JSX support kept the author's ergonomics while shipping almost nothing to the browser. The conclusion is deliberately narrow, which is what makes it useful. The problem was not Next.js in general, but Next.js applied to a static page that never needed its client-side machinery in the first place.