Blog Author Drops Next.js and Scores 100 in Every Lighthouse Category

The creator of the Bloffy platform removed Next.js from the public-facing part of his blog and scored 100 in every Lighthouse category. In an article published on October 26, 2026, he explains why he chose Hono for pages with almost no interactivity. As the blog author writes, caching and image optimization were already in place, but the pages were still loading the framework’s JavaScript.

Why caching and images weren’t enough

The author wanted to build a lightweight blog platform that would let people run multiple blogs and make their pages accessible to users. Existing services didn’t work for him for various reasons: some felt bloated, while others didn’t offer the ease of working with Markdown, HTML, and CSS that he needed. So he set out to build his own platform.

At first, dropping Next.js wasn’t the plan. The author used the framework’s caching and a CDN to reduce latency for visitors in different regions. Then he decided that a CDN was enough for a static site: having to manage the Next.js cache as well, invalidating both caches whenever he published a post, was inconvenient.

For images, he chose Cloudflare Image Transformations rather than a custom file-processing setup he would have to maintain. According to him, the free tier allows 5,000 images. After these changes, the blog, still running on Next.js 16.1.6, was already getting high scores, but not 100. He ran the tests through pagespeed.web.dev.

What changed after the move to Hono

Looking into it further, the author found legacy JavaScript he hadn’t added himself. He removed the application’s client components and kept only server components, but the score didn’t change. In his tests, parts of the Next.js client runtime remained even on a static page: scripts needed for routing and hydration. The next/link and next/image components also brought in client-side code.

Even dropping those two components didn’t eliminate the App Router code. Removing the scripts entirely would have meant using a workaround to strip them from the generated HTML. Instead, the author moved the public-facing part to Hono, which appealed to him for its simplicity and JSX support. The blog management app stayed on Next.js—he considers it a good fit there.

Before the move, unused JavaScript totaled 230,460 bytes; afterward, it was 407 bytes. According to the author, the new public-facing page loads no JavaScript. Build time fell by about 40%. A long task before the page was displayed took 309.3 ms on Next.js and 68.01 ms on Hono—roughly 78% less.

The author reports a score of 100 in every category for the blog page. The article also includes a result for a test site with an SEO score of 69: indexing is deliberately disabled there. Those figures come from different pages, and the milliseconds saved shouldn’t be taken as a promise of the same result on every site.

What this means for site owners

The main practical question is what visitors do on a particular page. If they’re mostly reading, it’s worth checking how much code the page loads for features it doesn’t use. An interface with more complex interactions may call for a different approach: the author kept Next.js for the blog management app.

Before switching frameworks, it makes sense to measure performance and inspect the code being loaded. In this case, caching and images had already been optimized; the reason for the further overhaul was the JavaScript left on static pages. The move meant rebuilding the public-facing part that had already been created, so it’s worth weighing the work involved as well as the Lighthouse scores.

My take: simplicity has to justify the rebuild

I agree with the idea that a page shouldn’t carry a complex tool just because you’ve already chosen it. But I wouldn’t chase 100 points in all four categories at any cost. For a small shop like our spare-parts workshop, speed matters, but I also need to update stock levels myself. If chasing a score makes that routine task harder, the benefit becomes questionable.

I’d first define the scope of work and the budget, then compare options on the pages the shop actually needs. While the product range and processes are simple, an off-the-shelf platform seems more sensible to me than a custom solution. WordPress can work for a small shop too, provided it’s maintained regularly. A fixed price is convenient when it’s clear in advance which pages and processes are changing. So I read this experience not as advice to abandon Next.js, but as a reason to check whether a tool’s capabilities match the day-to-day work of the site.

Sources

Where the news comes from. The text is a retelling in the author’s own words; the facts come from the source, the opinion is the author’s.

1. Removing Next.js Got My Blog to 100 on Every Lighthouse Category korindiehacker.bloffy.blog

About the author

Feliks Uus

Owner of a bicycle repair shop

We have a small repair shop and spare parts store in Tartu; I want to gradually move some sales online. I’m comparing CMSs and payment methods, but first I’m checking whether I can easily update stock myself.

All posts by the author