A static site sheds its framework runtime
A solo developer behind the Bloffy blogging platform says removing Next.js from the public-facing site produced perfect 100 scores across Google Lighthouse’s measured categories. The result is a case study in how framework overhead can affect a largely static website, rather than a general benchmark proving one framework is always faster than another.
The developer measured performance through PageSpeed Insights and found that caching and a content delivery network had already taken the site most of the way toward the target. Bloffy used Cloudflare for distribution and image transformations, reducing the need for application-level caching and a separate image-processing service. That left the JavaScript delivered by the framework as the main unresolved issue.
According to the project account, the blog pages had no interactive features and were pre-rendered. Removing client components did not eliminate the remaining runtime because Next.js routing, error handling, Link and Image components still brought browser-side code and hydration machinery. The developer measured about 230,460 bytes of unused JavaScript before deciding to replace the framework.
Hono takes over rendering
Rather than switch to handwritten HTML, the project moved its rendering layer to Hono, retaining JSX and a framework structure while producing pages without client-side JavaScript. After the migration, the developer reported unused code falling to 407 bytes and build time declining by roughly 40 percent. The live page then reached 100 in Lighthouse performance, accessibility, best-practices and SEO tests, according to the account.
Those figures describe this project’s architecture and measurement conditions. Lighthouse results can vary with the tested page, network, device profile and third-party resources. The developer also noted that a separate test site scored lower for SEO because indexing was intentionally blocked, illustrating why a score needs its configuration context.
The migration reflects a narrower engineering decision: a static publishing surface may not need the navigation and application features of a full React framework. For Bloffy, a CDN could handle global delivery, Cloudflare could transform images, and server-rendered markup could cover the public blog experience. That made the framework’s runtime a cost without a corresponding feature requirement.
Next.js remains designed for applications that need dynamic rendering, routing, data access and interactive React components. The Bloffy experience instead highlights the value of matching tooling to a site’s actual behavior. When pages are effectively documents and require no browser logic, measuring the shipped payload can reveal opportunities that server-side caching alone will not address.
The project’s result is also reproducible in a limited sense: readers can run the published page through PageSpeed Insights and inspect its delivered JavaScript. It does not establish a universal comparison, but it offers a concrete example of how simplifying a static delivery path can improve measured performance.
