Eradicating Next.js Got My Blog to 100 on Every Lighthouse Class

My weblog simply scored an ideal 100 on each Lighthouse class. I like running a blog. I wished to construct a weblog that’s mild, quick, freed from muddle, capable of run a number of blogs, and absolutely accessible on high of that. And lastly, in the end, I’ve roughly pulled it off. It was fairly a tedious course of. Ugh… and I even needed to take away Next.js, the framework I’d been utilizing most. It was far, way more painful than I anticipated. I’d wish to share the journey of bettering efficiency whereas constructing this weblog.

When you consider blogs, a number of names come to thoughts. Medium, Blogger, Ghost… But none of them glad me. Medium and Blogger are bloated with options, and their precise efficiency wasn’t satisfying both.

Blogger

Medium

Hmm…… And there was one other drawback: it’s a problem to work immediately with the markup and uncooked code all of us love (Markdown, HTML, CSS).

For the document, all efficiency measurements had been taken with pagespeed.web.dev.

Of course, there are many options: WordPress, Ghost, Hugo. I didn’t like WordPress’s plugin hell. Ghost needs to be self-hosted (there’s ghost.org too, however it’s method too costly…), and each model improve broke one thing within the editor, so preserving it updated was a chore. Hugo is the most effective of the bunch, however in the long run, setting it up remains to be a problem. Looking again, I assume what I actually wished was SaaS.

The one I favored most was Bear Blog. Great efficiency. I like its product philosophy, too. But its excessive minimalism was a draw back for me. The editor UX didn’t work for me, both.

If it not less than let me add AdSense and fix photographs without spending a dime, I in all probability would’ve simply used Bear Blog.

As quick as Bear Blog, however with a bit extra performance and higher usability. That’s the weblog I wished to construct. Oh, and in case you’re curious, you may test it out at bloffy.co.

Anyway. Enough about me. Let me share how I truly improved the efficiency.

Obviously, caching is a must.

It goes with out saying that caching is crucial. Get caching proper and efficiency improves dramatically. And Next.js makes caching actually handy.
There’s ISR, and it additionally extends fetch with a next option for caching. Handy. Using these nicely alone will get you a good distance on efficiency.

Unfortunately, although, our website may be reached from anyplace within the planet. Why is that unlucky? Within the identical area, caching makes issues quick, however guests from different areas nonetheless find yourself consuming the community latency.

No, silly. That’s what a CDN is for.

Yes. That’s why we use a CDN. And in case you deploy a Next.js app to Vercel, you get a CDN out of the field. I don’t dislike Vercel; it’s extremely handy. But the Pro plan is costly proper from the beginning, there’s the serverless chilly begin drawback, and the dependency on the Vercel ecosystem isn’t one thing you may ignore both.

So why not use a distinct CDN service? Cloudflare, for instance. I actually assume Cloudflare is a genuinely good firm. You can run large-scale transport systems and most apps on it without spending a dime. But then I figured I didn’t really want Next.js’s caching anymore. Having to invalidate two caches each time I publish a put up makes issues a ache to handle.

In quick, for a static web site, I figured a CDN alone is sufficient. And that’s motive primary why I didn’t want Next.js.

Image optimization.

Images today run over 10MB. Serve these on the net as-is and your efficiency will go utterly off the rails.

Optimizing photographs is sort of a problem. You must resize per machine, compress, after which deal with the CDN on high of that. On a earlier mission, I had a serverless operate (AWS Lambda) compress and resize photographs each time one landed in storage (S3), and I put CloudFront in entrance because the CDN. It was a reasonably affordable setup for tailoring issues precisely the way in which I wished. But it’s additionally a setup that wants a good quantity of maintenance.

So this time I went with Cloudflare’s Image Transformations. Even on the free tier you get 5,000 photographs, so I exploit it with out a second thought.

At this level I sound like a Cloudflare gross sales rep. I’m simply an bizarre solo developer.

For reference, this was Next.js 16.1.6.

Pretty excessive scores. But this isn’t sufficient. We need 100. A clear, no-asterisks 100. So I dug into what the issue was.

It stated a considerable quantity of legacy JavaScript was discovered, and it wasn’t code I wrote. It got here from the framework runtime that Next.js ships in its bundle.

But this web page is a static web page with zero interplay. Every web page is pre-rendered with ISR, and I assumed I’d adopted the Next.js tips nicely. So as an experiment, I ripped out each shopper element the app had, left solely server parts, and measured once more. The rating didn’t budge.

At first I suspected hydration, however as soon as I dug in, the issue wasn’t hydration alone. The trigger was the shopper runtime that Next.js all the time ships, even for static pages. Even with solely server parts, the runtime chunks, hydration, and the RSC payload for the router all keep. That’s as a result of subsequent/hyperlink and subsequent/picture are themselves shopper parts ('use shopper'), so having simply these two is sufficient to pull within the runtime and set off hydration.

So what if I strip out subsequent/hyperlink and subsequent/picture too? The App Router’s personal runtime, the router and error boundaries, nonetheless stays. There’s no official technique to get it right down to zero; the one choice was a hack: stripping the scripts out of the rendered HTML. That’s when it hit me: “If I’m going to try this, why am I even utilizing Next.js?”

You can see that the majority of the JavaScript is code that isn’t wanted. Unused code alone involves 230,460 bytes. That’s not good.
Most static web sites don’t want JavaScript in any respect. Unused JavaScript is required even much less.

This is the place I actually agonized. Is dropping Next.js for the sake of 100 factors the best name? I’d spent a number of time constructing the public-facing net app.

In the tip, for the standard of the weblog (even when it’s simply 5 factors), I made a decision to tear Next.js out solely. My judgment was that I wouldn’t want Next.js’s extra options in the long term both. I thought of going absolutely vanilla, however I didn’t wish to hand over the productiveness and transport systems advantages of a framework. I wanted to search out the best one.

I selected Hono. I favored its technical philosophy. “Fast and easy” was precisely the answer I wanted most, and JSX assist was a bonus. The migration value didn’t look too massive, both.

Ta-da. Finally, 100.

Tada. And identical to that, 100 throughout the board. Go forward and run the very web page you’re studying proper now by way of pagespeed.web.dev.

There’s no JavaScript, and unused code dropped sharply to 407 bytes. As a bonus, construct time went down by about 40% too.

Oh, why is web optimization at 69? That website was constructed for testing, and it intentionally blocks search indexing. That’s why it’s 69.

By the way in which, in case you rating 100 on the whole lot in DevTools, Lighthouse truly units off fireworks for you. 🎉🎉

Next.js Performance (server components only)

Hono Performance

The lengthy job that runs earlier than something is rendered on display took 309.3ms on Next.js, and after I constructed the identical web page with Hono, it took 68.01ms. That’s roughly a 78% enchancment.

Is a JS payload, hydration included, actually doing a static website any good? I don’t assume so. It leaves behind pointless JavaScript, so most often I feel it’s merely not wanted.

That stated, for an interaction-heavy app, I feel Next.js is usually a nice framework. In reality, the administration app for this very weblog is constructed with Next.js!

P.S. This weblog runs on Bloffy, the running a blog platform I’m constructing. If you need a weblog that scores like this with out the setup, you may attempt it at bloffy.co.