My blog fair scored a ideal 100 on all Lighthouse category. I affection blogging. I wanted to build a blog that’s light, fast, liberated of clutter, capable to run multiple blogs, and completely accessible on top of that. And finally, at lengthy last, I’ve additional or small pulled it off. It was fairly a tedious process. Ugh… and I equal had to eliminate Next.js, the example I’d been using most. It was far, far additional achy than I expected. I’d akin to portion the journey of improving achievement during construction this blog.
Why did I decide to build my own blog?
When you think of blogs, a few names arrive to mind. Medium, Blogger, Ghost… But none of them satisfied me. Medium and Blogger are bloated alongside features, and their genuine achievement wasn’t satisfying either.
Blogger
Medium
Hmm…… And there was another problem: it’s a hassle to activity immediately alongside the markup and raw code we all affection (Markdown, HTML, CSS).
For the record, all achievement measurements were taken alongside pagespeed.web.dev.
Of course, there are plentifulness of alternatives: WordPress, Ghost, Hugo. I didn’t akin WordPress’s plugin hell. Ghost have to be self-hosted (there’s ghost.org too, but it’s way too expensive…), and all type upgrade bankrupt item in the editor, so keeping it up to date was a chore. Hugo is the finest of the bunch, but in the end, environment it up is motionless a hassle. Looking back, I conjecture what I really wanted was SaaS.
The one I liked most was Bear Blog. Great performance. I affection its merchandise philosophy, too. But its extreme minimalism was a downside for me. The publishing company UX didn’t activity for me, either.
If it at smallest let me add AdSense and nexus images for free, I likely would’ve fair used Bear Blog.
As accelerated as Bear Blog, but alongside a bit additional functionality and improved usability. That’s the blog I wanted to build. Oh, and if you’re curious, you can inspect it out at bloffy.co.
Anyway. Enough concerning me. Let me portion how I really improved the performance.
Let’s hit 100 on Lighthouse Performance.
Obviously, caching is a must.
It goes without saying that caching is essential. Get caching correct and achievement improves dramatically. And Next.js makes caching really convenient. There’s ISR, and it additionally extends fetch alongside a next choice for caching. Handy. Using these fine solitary gets you a lengthy way on performance.
Unfortunately, though, our location can be reached from anyplace in the world. Why is that unfortunate? Within the identical region, caching makes things fast, but visitors from another regions motionless end up dining the network latency.
No, silly. That’s what a CDN is for.
Yes. That’s why we use a CDN. And if you deploy a Next.js app to Vercel, you get a CDN out of the box. I don’t dislike Vercel; it’s incredibly convenient. But the Pro scheme is pricey correct from the start, there’s the serverless chilly commencement problem, and the dependency on the Vercel ecosystem isn’t item you can disregard either.
So why not use a distinct CDN service? Cloudflare, for example. I honestly think Cloudflare is a genuinely nice company. You can run large-scale infrastructure and most apps on it for free. But afterward I figured I didn’t really need Next.js’s caching anymore. Having to invalidate two caches all period I publish a article makes things a ache to manage.
In short, for a fixed website, I figured a CDN solitary is enough. And that’s logic figure one why I didn’t need Next.js.
Image optimization.
Images these days run complete 10MB. Serve those on the web as-is and your achievement volition go entirely off the rails.
Optimizing images is fairly a hassle. You have to resize per device, compress, and afterward grip the CDN on top of that. On a former project, I had a serverless function (AWS Lambda) compress and resize images whenever one landed in retention (S3), and I put CloudFront in forefront as the CDN. It was a beautiful sensible setup for tailoring things exactly the way I wanted. But it’s additionally a setup that needs a fair amount of upkeep.
So this period I went alongside Cloudflare’s Image Transformations. Even on the liberated tier you get 5,000 images, so I use it without a second thought.
At this item I audio akin a Cloudflare revenue rep. I’m fair an average solo developer.
Ta-da. Here’s the Next.js blog’s achievement following all that caching and depiction optimization.
For reference, this was Next.js 16.1.6.
Pretty elevated scores. But this isn’t enough. We desire 100. A clean, no-asterisks 100. So I dug into what the issue was.
It stated a significant amount of bequest JavaScript was found, and it wasn’t code I wrote. It came from the example runtime that Next.js ships in its bundle.
But this leaf is a fixed leaf alongside zero interaction. Every leaf is pre-rendered alongside ISR, and I idea I’d followed the Next.js guidelines well. So as an experiment, I ripped out all client component the app had, remaining lone server components, and measured again. The mark didn’t budge.
At archetypal I suspected hydration, but formerly I dug in, the issue wasn’t hydration alone. The logic was the client runtime that Next.js continually ships, equal for fixed pages. Even alongside lone server components, the runtime chunks, hydration, and the RSC payload for the router all stay. That’s since next/link and next/image are themselves client components ('use client'), so having fair those two is adequate to drag in the runtime and trigger hydration.
So what if I band out next/link and next/image too? The App Router’s own runtime, the router and error boundaries, motionless remains. There’s no authoritative way to get it downward to zero; the lone choice was a hack: stripping the scripts out of the rendered HTML. That’s whenever it hit me: “If I’m going to do that, why am I equal using Next.js?”
And then, the unused code.
You can see that the bulk of the JavaScript is code that isn’t needed. Unused code solitary comes to 230,460 bytes. That’s not good. Most fixed websites don’t need JavaScript at all. Unused JavaScript is needed equal less.
This is anywhere I really agonized. Is dropping Next.js for the purpose of 100 points the correct call? I’d spent a lot of period construction the public-facing web app.
Let’s eliminate Next.js.
In the end, for the norm of the blog (even if it’s fair 5 points), I decided to rip Next.js out entirely. My judgement was that I wouldn’t need Next.js’s excess features in the lengthy run either. I considered going completely vanilla, but I didn’t desire to provision up the efficiency and infrastructure benefits of a framework. I needed to discover the correct one.
I chose Hono. I liked its specialized philosophy. “Fast and simple” was exactly the resolution I needed most, and JSX assistance was a bonus. The immigration disbursal didn’t appearance too big, either.
Ta-da. Finally, 100.
Tada. And fair akin that, 100 throughout the board. Go onward and run the extremely leaf you’re study correct now through pagespeed.web.dev.
There’s no JavaScript, and unused code dropped sharply to 407 bytes. As a bonus, build period went downward by concerning 40% too.
Oh, why is SEO at 69? That location was built for testing, and it deliberately blocks hunt indexing. That’s why it’s 69.
By the way, if you mark 100 on everything in DevTools, Lighthouse really sets off fireworks for you. 🎉🎉
Hono vs. Next.js Performance
Next.js Performance (server components only)
Hono Performance
The lengthy project that runs before item is rendered on display took 309.3ms on Next.js, and whenever I built the identical leaf alongside Hono, it took 68.01ms. That’s approximately a 78% improvement.
Does your fixed location really need Next.js?
Is a JS payload, hydration included, really doing a fixed location any good? I don’t think so. It leaves rearward unnecessary JavaScript, so in most cases I think it’s merely not needed.
That said, for an interaction-heavy app, I think Next.js can be a awesome framework. In fact, the administration app for this extremely blog is built alongside Next.js!
