Dropping Next.js cut a blog's unused JavaScript to 407 bytes

A static blog carries hundreds of kilobytes of JavaScript it never runs. The author of korindiehacker set out to score a clean 100 on every Lighthouse category and could not. Next.js 16.1.6 was sending 230,460 bytes of unused code to every page, by his count. He rebuilt the blog on Hono instead. Unused code dropped to 407 bytes, and the Lighthouse score hit 100 across the board.

What the measurement showed

The author ran pagespeed.web.dev against a page he had built with Next.js. Lighthouse flagged a large amount of what it calls legacy JavaScript. The author checked, and the code was not his. It came from the framework runtime that Next.js adds to every bundle. He stripped out every client component, left only server components, and ran the test again. The score did not budge. He writes that the client runtime is sent even when the page uses only server components.

Why the runtime stays

The author traced the cause. Next.js keeps the runtime chunks, the hydration glue and the RSC router payload. All three stay on a static page with no interaction. Two things bring them in. next/link and next/image carry a 'use client' directive, so a page that uses either imports the runtime. He stripped those too, but the App Router's own runtime stayed, along with the router and the error boundaries. The author writes there is no official way to zero this out. The only path left was a hack that strips the scripts out of the rendered HTML.

The rewrite on Hono

The author picked Hono as the replacement and migrated the blog. He writes that fast and simple was the exact fit, and that Hono's JSX support kept the migration cost small. The new build pushes no JavaScript on a static post. The author's measurement after the move is 407 bytes of unused code, down from 230,460. The Lighthouse score reached 100 on performance, accessibility, best practices and SEO. He adds that build time went down by about 40 percent.

The author also measured the long task that runs before anything is drawn on screen. On Next.js 16.1.6, that task took 309.3 milliseconds. On Hono, the same page took 68.01 milliseconds. The author writes that is a 78 percent fall. His conclusion is narrow and worth taking at his word: a JavaScript payload with hydration is overhead on a static site, so most static sites do not need it. He adds that Next.js remains a good fit for interaction-heavy applications. The admin app for this blog is itself built on Next.js. The claim here is about the shape of the site, not about the framework in general.

Source

• korindiehacker: Removing Next.js Got My Blog to 100 on Every Lighthouse Category