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

Posted by textlanes33 3 days ago

198128Original

Comments

Comment by pigbearpig 3 days ago

Respectfully, I don't understand this. They never needed Next.js for a static blog.

This is like writing a post about how I didn't need a Ferrari to commute to work and I saved money by taking the bus.

Comment by dbbk 3 days ago

Next.js is not a good fit for most applications. It honestly never has been. It has just been Vercel's relentless over-the-top marketing that has been trying to convince junior developers that it is.

Comment by 150g2 2 days ago

[dead]

Comment by littlecranky67 3 days ago

Next.js supports fully static export, so they should have went with that.

I run a dynamic website on nextjs static export - landingpages and docs are fully static, login and user dashboard use REST calls to a non-nextjs backend. Blazing fast, no nodejs or SSR in production.

Comment by onion2k 3 days ago

Next.js supports fully static export, so they should went with that.

Keeping an unnecessary dependency for legacy reasons is never a good move. Be bold and delete things. Your software will be better for it.

Comment by littlecranky67 3 days ago

Wouldn't say unnecesarry. Nextjs static export has features such as dynamic chunking, eager-loading of chunks when you hover over a link, routing etc. With a plugin you get image optimization (different image quality levels and dimensions based on viewport size) etc.

But yes, another static site blog generator would also work.

Comment by kypro 3 days ago

> Wouldn't say unnecesarry. Nextjs static export has features such as dynamic chunking, eager-loading of chunks when you hover over a link, routing etc.

As someone who's ran a blog for 25 years it's surprising I never knew these things were necessary until now.

Comment by phoghed 3 days ago

As someone who’s never ran a blog for the past 25 years it’s surprising I never knew a blog was necessary until now

Comment by nkmnz 2 days ago

As someone who's never ran for the past 25 years it's surprising I never knew.

Comment by jakelazaroff 3 days ago

All those features might be good in some contexts, but they're also literally the reason the author's blog couldn't get 100s on Lighthouse.

Comment by rhdunn 2 days ago

The picture element [1], [2] supports controlling which image is used via a media selector, allowing you to serve smaller images on smaller devices and on things like the viewport orientation.

[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

[2] https://caniuse.com/picture

Comment by littlecranky67 2 days ago

Great and all such, but it doesn't do the actual work of resizing your one highres image to all those breakpoints - which is part of the build process in NextJS.

Comment by CharlieDigital 3 days ago

My experience with Next.js is that because it mixes multiple paradigms, it makes using any single one of them more complicated and error prone.

Not just as the dev delivering the solution, but also library and package authors.

Ran into lots of issues around Next 12, Next 13 was very buggy, moved to Astro and never looked back.

Comment by christophilus 3 days ago

Image optimization is the only thing in that list I might care about, and every CDN I’ve ever used provides it out of the box.

Comment by cpursley 3 days ago

Astro blows away next.js for static sites, especially blogs.

Comment by littlecranky67 3 days ago

Care to elaborate and backup you wild claim with some facts?

Comment by flexagoon 3 days ago

How is it a wild claim that an optimized plain html site is better for a static blog than a site with a huge redundant JS bundle?

Comment by pier25 2 days ago

This is not even a remotely wild claim.

Comment by flexagoon 3 days ago

The static export still keeps a large JS bundle which is mostly unnecessary

Comment by vanderZwan 3 days ago

I think we should blame the elders for teaching people new to the trade wrong.

Because "heavyweight SPA for a static blog" isn't exactly a rare problem.

Comment by austin-cheney 3 days ago

My super large SPA loads in 150ms on localhost. Yes, if it were just a static blog I might get it down to about 60ms.

The problem isn’t the size of the code. It’s the unnecessary framework complexity. Suggesting this to a corporate JavaScript developer, though, is like throwing acid on your own face as they whine about how impossible it is to do their jobs.

Comment by graemep 3 days ago

> My super large SPA loads in 150ms on localhost.

Which is great if people only use it from localhost.

Comment by austin-cheney 2 days ago

Across a network it’s still only 300ms.

Comment by graemep 2 days ago

Which means the difference between your APS and a static website is "loads reasonably fast" vs "loads instantly".

Comment by austin-cheney 2 days ago

Sure, but that misses the point. My big SPA is faster without React and likely faster than a blog that appears to be static text generated from React. Yes, it would be much faster if it were just a few paragraphs of static text, but then it would not display any of the content that it is supposed to display, such as an a remote command shell interface or resource utilization graphs.

Comment by graemep 2 days ago

That is reasonable but not clear to me.

The point being made further up the thread was that people are using SPAs for static text.

Comment by 2 days ago

Comment by dbbk 3 days ago

It wasn't the elders, it was Vercel itself which has a vested interest

Comment by vjvjvjvjghv 3 days ago

Young software devs don’t listen to their elders. They know better.

Comment by cbarrick 3 days ago

The OP is building a blogging platform, with an editor. It's not just a personal blog.

TBF, they could have explained that better in the post.

Comment by phoghed 3 days ago

We’re also talking about a 5-point difference for the pagespeed score. It’s clear not many of these people read the post.

Comment by mort96 2 days ago

The editor can be React, maybe even Next.js, but why does the generated page need to be?

Comment by legulere 3 days ago

It's more like they realised they can also commute by bike or foot never realizing before that that was even an option

Comment by z3t4 3 days ago

It's like taking a plane and adding 6 hours to the commute. But flying is more fun, at least in the short run. If you need to do it for years you would use more simple and stable tools.

Comment by vjay15 3 days ago

exactly just use a ssg like zola/hugo and call it a day smh

Comment by ogou 3 days ago

The vast majority of websites don't need Next.js or React. Those are only useful if you need dynamic and modular updates within the structure, or state management. We've defaulted to React because of the name recognition and simple intertia. It's not a good framework for websites in general.

Comment by tempay 3 days ago

I'm not convinced you need React/Next.js even in those cases. Web components work and LLMs are so capable of using them that I find there is increasingly little utility in big frameworks.

Comment by agos 3 days ago

Any web components solution is probably going to be as big as React

Comment by CharlieDigital 3 days ago

Difference is in the eventing model and complexity of state management in React's hooks based model vs vanilla's. WC is aligned with how JS callbacks naturally work. React is the only framework that points the callback to the component function.

Comment by EricFrost 2 days ago

I wrote Solarite b/c I wanted a simple and fast web component solution without a compilation step.

https://eric-frost.github.io/solarite/

Comment by kalcode 2 days ago

These days you can write in say React or SolidJs or JSX I guess to say, and have it transformed into HTML only with no JavaScript.

You get the best of both worlds, better language than XML/HTML and yah, you can deliver only HTML since the consumer typically doesn't need all that JavaScript, spa stuff. The Island Architecture.

Feels like a good in-between. Good DX for me, great UX and mostly HTML with some JavaScript sprinkled and fallback for users.

Comment by fergie 3 days ago

No idea why this idea is being downvoted, because it is totally correct, even more so in the LLM-coding era.

Comment by pampas 3 days ago

My home is much easier to heat now I've moved from an aircraft hanger into a cottage.

Comment by christophilus 3 days ago

More like, I moved from Wallace and Grommit self walking pants back to regular pants.

Comment by Hamuko 3 days ago

But what if you need to park an aircraft at some point in your future? Aren’t gonna feel silly for not anticipating that potential need?

Comment by adverbly 2 days ago

Self-hosted and deployed k8s on your own private cloud is really the only option if you think about it.

Note, I say that while literally knowing people who run k8s clusters on pis for heir home lab with like 3 users. Good people. I love them to death, but they also may or may not have recently tested positive for autism.

Comment by jasomill 2 days ago

So build a cottage inside the hanger and only heat the cottage. Problems solved.

Comment by Exoristos 3 days ago

Do tech influencers never tire of announcing their incompetency in their subject area?

Comment by darkwater 3 days ago

Who is this guy? The blog has just this single post

Comment by s1n_ 3 days ago

Seemingly not

Comment by 4pkjai 3 days ago

I wrote not so basic CRUD application that uses HTML and vanilla javascript. I don't even minify the javascript. That website loads significantly faster than all the other websites I have made.

Comment by smt88 3 days ago

This is obvious and not an interesting observation.

The question is how to get a good and efficient dev experience while also preserving that level of speed.

AI has now made that question mostly irrelevant, since it can generate and rapidly edit vanilla webpages without a framework to make the DX better.

Comment by NohatCoder 3 days ago

It is obvious, yet so many people don't understand it.

There is no secret ingredient, writing a website, or anything really, without a framework is not wildly more difficult than using a framework.

Save for a few cases where all you really want to do is covered by the default configuration, you generally don't end up writing a lot less code with a framework. Worst case, you end up spending most of your time working around the framework.

Comment by smt88 3 days ago

> you generally don't end up writing a lot less code with a framework

What? This is absolutely untrue for anything that isn't a trivial v1 prototype. Complex applications have a lot of boilerplate, which is unavoidable with the baggage of HTML and CSS.

There's a reason people are obsessed with web frameworks. Writing vanilla HTML/CSS/JS for large or complex apps is an enormous pain.

Comment by preg_match 2 days ago

It really depends on your application. If you’re building a static site, if you’re not using a static site generator or writing HMTL/CSS by hand you’re wasting your time.

React et al. won’t just be 10x slower, it will also use 5x the amount of code with 5x the complexity.

People are obsessed with web frameworks because it’s more fun to engineer frameworks than make products or ship applications. Applications are boooooring. But, most of the time, you’re just wasting your time with the framework.

Comment by jasomill 2 days ago

AI has now made that question mostly irrelevant, since it can generate and rapidly edit vanilla webpages without a framework to make the DX better.

Not consistently over time it can't — at least not the usual LLM-as-a-service suspects, which don't even guarantee the model you use today will function identically tomorrow — unless you use it to create your own static site generator, which may or may not make sense depending on whether existing, battle-tested tools don't already fit the bill.

Comment by smt88 2 days ago

What about it isn’t consistent over time?

Claude seems better at frontend dev work than at any other category of task. It’s far better than the last senior frontend dev I worked with.

Comment by SwellJoe 3 days ago

I use Hugo published to Github Pages for my blog. I've never thought about performance (it's Fast Enough™ when I visit it), but I just checked and it's 100 on pagespeed. The magic of a static HTML blog is you don't have to think about performance. An entire category of problem just disappears.

Comment by ct520 3 days ago

Same we moved from Wordpress to Hugo when looking to update our company site page. Using AI to update the legacy Wordpress theme just wasn’t it. Had updated brand and style guide, Claude made short work of porting to Hugo and Google speed rankings were excellent even without cdn etc

Comment by mceachen 3 days ago

I use Hugo as well. If any of your pages have larger media, look into Pipes to get images ladder srcsets built for you automatically. Very fancy. https://gohugo.io/hugo-pipes/introduction/

Comment by stackghost 3 days ago

What’s an image ladder src set?

Comment by mceachen 3 days ago

An “image ladder” is the same image resampled at several widths. It’s not a standard term; MDN calls the technique “resolution switching”.

A srcset lists those versions, and the browser picks the one that fits the current viewport and screen density. https://responsiveimages.org/ has details.

For an example, view the source of https://photostructure.com/tags/. All the header art looks like this:

That’s generated by https://gist.github.com/mceachen/d5915e46d1294489698e155eb11..., which uses Hugo’s resources.Get and .Resize.

Comment by nullify88 3 days ago

Hugo is great. I had Claude make the framework for my wifes site using Hugo, Netlify free tier, and Decap CMS. And I forced Claude to avoid any Javascript for the non CMS parts.

Comment by twoquestions 2 days ago

I'm really wondering why OP didn't reach for Astro right away, it's purpose built for this precise use case! Still, glad they had fun.

Comment by graemep 3 days ago

> Hugo is the best of the bunch, but in the end, setting it up is still a hassle.

Then chooses an approach that looks like a lot more work than setting up Hugo.

Comment by benstigsen 1 day ago

I've tried so many things over the years, my own webservers with Python and Go, my own templating systems, various markdown converters, different SSGs (Astro, Hugo, Zola, Lume), in the end I've always found markdown limiting, when it comes to structuring and formatting content.

Now I use a git repository with a simple git hook, which runs a tiny bash script on commit, allowing for basic HTML templating. The static site is then served with Caddy.

I know not everyone like the design of my website, but I personally do which is why I still have it :^)

[0] https://stigsen.dev

[1] https://git.stigsen.dev/stigsen/stigsen.dev

Comment by ichi_10 2 hours ago

[flagged]

Comment by dzink 3 days ago

I’ve been beating giants in SEO with a static site precompiled at deployment time through includes with Gulp. Plain vanilla JS and CSS.

Comment by sampli 3 days ago

Nextjs can get you 100 if you use it properly. Like anything it’s just a tool that can increase complexity if you want it to

Comment by tkzed49 3 days ago

I have a next.js SSG blog that easily hits 100 and loads ~instantly. I just don't think there's any point trying to have a rational discussion about next on hn.

Comment by sampli 2 days ago

Yeah. I do SSG for landing pages and then you can auth and get an SPA. Very versatile, high lighthouse scores

Comment by asafel 3 days ago

[flagged]

Comment by altmanaltman 3 days ago

It's pretty easy to get 100 on every lighthouse category even while using next. The scoring is based on how fast a page loads and what blocks its loading time. If you develop it with a bit of care, that is a non-issue. My funny agency website (https://www.pixlw.com/) is purely nextjs and it scores a 100 on Lighthouse as well because I kept working on it till it didn't.

Comment by benmccann 3 days ago

I got straight 100s using SvelteKit on https://c3.ventures

Comment by ActionHank 3 days ago

Gotta be honest, I think the no man’s land that nextjs occupies is more of a niche than most people realise.

Comment by aftbit 3 days ago

What are the best static site generators for blogs these days?

Comment by arecsu 3 days ago

I love Astro. It is so extensive to your liking and if you want to have complex interactive stuff at some point, you can just add a framework of your liking (react, vue, svelte, etc) and it will still work wonders. It doesn't abstract that much, and yet provides a nice UX and performance is top notch, which is why I love it so much. You can do from the most simplest website and blog on it, to the most complex content driven websites. I use it for so many different things, both hobbyist and professionally.

Comment by stackghost 3 days ago

Astro is based on npm is it not? Given the state of that ecosystem and the rate at which new vulnerabilities are being discovered these days, I prefer to stay as far away from Node as I can.

Comment by moi2388 3 days ago

Npm? It’s just the package manager. You can use pnpm or yarn or bun if you like?

Comment by noraquinn 3 days ago

[flagged]

Comment by esperent 3 days ago

I'm going to push back against Astro because all the server island stuff is over-engineered for a blog, while in the meantime Astro is not designed for more complex sites so I'm not sure what it's purpose is really.

I would say that in the era of agentic coding you don't need any framework. Just a backend + router + markdown generator. I use Hono + Tanstack router for the first two. Tell any decent LLM to wire those up for you and you'll have a simple static site ready to go in an hour or two.

Comment by woutr_be 3 days ago

The server islands are completely optional tho, if you don’t want to use them, you don’t have to. For a simple blog you can just use collections, and plain HTML/CSS.

I’ve used Astro for more complex applications, and it’s perfectly suitable for that too.

Of course, if you’re building an SPA, then it’s probably not the best choice.

Comment by chrisweekly 3 days ago

+1 for TanStack Router (and TanStack Start if your needs evolve to merit a metaframework).

Comment by abound 3 days ago

I use Hugo for one blog [1] and Zola for another [2], I think they're both pretty simple to use once you wrap your mind around how they structure things.

Astro is also great (as others have noted) esp if you want to leverage the JS ecosystem at large.

[1] https://frominsidethebox.com

[2] https://yakshed.com

Comment by dotnetcarpenter 3 days ago

Astro https://astro.build/

Comment by danpalmer 3 days ago

I'm on Hugo. It's simple, capable, well documented, LLMs understand it well, and I don't have to touch the JS ecosystem. My previous setup was with a Node based SSG and it broke on literally every update and had a hundred dependencies.

Comment by hn_throw2025 3 days ago

I moved away from Hugo because I was tired of it breaking backwards compatibility. I found that upgrading my Hugo version meant that old static website projects wouldn’t compile, and needed amendments. I keep an older Hugo binary around as I don’t have time for that now. Any new website projects are Astro, and I will aim to convert the older projects to Astro when time allows.

Comment by jazzypants 3 days ago

Astro is fantastic.

https://astro.build/

Comment by OuterVale 3 days ago

So many great options. I always opt for Web Origami though.

It is more like a dialect of JavaScript optimised for developing static sites than a static site generator in and of itself. It has lots of 'builtins' for things like RSS and converting Markdown to HTML. It is so wonderfully flexible and doesn't lock you into a specific site structure like others SSGs do.

https://weborigami.org/

Comment by analog_daddy 3 days ago

Not sure about the best, but Zola is good enough for basic blogging needs. I liked the part that it was a single binary, so you don’t have to keep up with any breaking changes unless you want a new feature or a bug is bothering you.

Whatever you use, I feel it is tradition to have 3 odd blog posts about journey of building a SSG of your own since nothing else matched exactly what you needed and that’s it. Then you should forget that blog ever existed.

Comment by ovrnightr 3 days ago

I'm not a blogger, but I run multiple blogs.

Comment by verdverm 3 days ago

I'm using tanstack+tailwind and Ai to write a few scripts for doing what static generators would do. Keep it simple, make it unique, bring back the weird

Comment by burntcaramel 3 days ago

I made QIP Router where every part of rendering and making the HTTP response is customizable via WebAssembly. You often have a lot more control than a traditional static site generator that requires a particular plugin made — just make your own!

https://qip.dev/docs/router

Comment by 7777777phil 3 days ago

I love using hugo. Also wrote about some time ago how I got a perfect 100/100 Lighthouse score with Hugo and plain CSS. Feel free to have a look: https://philippdubach.com/posts/hugo-lighthouse-100/

Comment by vunderba 3 days ago

I've been using Astro for my main blog and have been reasonably happy with it, but recently branched out for my Lab site to be just a simple static hub built with Vite/TypeScript/Tailwind, where each project subpage is bundled in its own slug folder so they can bring in additional dependencies.

Comment by hutusi 3 days ago

I created a static blog framework called Amytis: https://github.com/hutusi/amytis and I'm really excited for you to give it a try.

Comment by jddecker 3 days ago

I like Zola. It is opinionated, but easy to pick up and get running in an hour or so. Not so great if you are working on a large website with lots of interconnected pages, but perfect for a blog, personal, or small company website.

Comment by ErenayDev 3 days ago

I use Zine [1]. its inspired from Hugo, written in Zig. but probably not the "best" for some use cases.

[1] https://zine-ssg.io

Comment by chanux 2 days ago

I tried Eleventy for building a simple product website and really liked it. Not quite sure about the future with the acquisition/rebranding.

Comment by 3 days ago

Comment by slopinthebag 3 days ago

ai. like have them take your language of choice, your templating of choice, your architecture of choice etc and spit out something. they've seen enough that it can pretty much oneshot something relatively simple.

edit: i mean have the ai write the generator, don't use it to actually generate pages...

Comment by brlewis 3 days ago

This is the right answer to the vague question of "best".

I started with an empty repo, wrote the first half of a README describing my decision-making process in choosing a static site generator, and conversed with an AI to finish the decision and set everything up.

https://writing.brlewis.com/posts/2026/blog-based-on-git/

Comment by tiborsaas 3 days ago

I've done this after evaluating some "ready made please deploy me" solutions. Ended up picked Rust with Axum and it's crazy fast, code is super simple, but really powerful.

Comment by 3 days ago

Comment by dev_l1x_be 3 days ago

Turns out static html and css is pretty good for static content?

Comment by firefoxd 3 days ago

Not to brag*, but that's what I've been doing since 2013 on my php blog [0]. It was actually the result of a hn warm hug of death. My CDN is just a separate webserver serving all static assets using nginx.

Both my css and js are dynamically minified and included in the html depending on which component is loaded on the page.

[0]: https://idiallo.com/blog/handling-1-million-web-request

* I am bragging

Comment by reassess_blind 3 days ago

I feel like these large frameworks will slowly die out with the advent of agents.

The big selling point of them was a fast, convenient dev experience with many features (most often unused) being built-in.

Now, those built-in features are becoming a security risk as more vulnerabilities are being found in their 1000s of lines of code, and the developer experience benefit is being nullified by agents whittling away the human involvement anyway.

Comment by cpursley 3 days ago

Sadly, the code LLM tools seem to default to the NextJS dumpsterfire stack.

Comment by ninalanyon 3 days ago

It's surely not difficult to tell the LLM to not use various tools and techniques? At least that works when I use one to create Bash scripts. Anything slightly complicated and the LLM drags in a dependency on Python when an AWK script would most likely be faster, shorter, and easier to maintain. So I just tell it 'Don't use Python',

Comment by reassess_blind 3 days ago

Yeah, for now. I sense sentiment shifting against these frameworks lately, it might be reflected in their training in a few models time. Or, it’s possible I’m completely off the mark.

Comment by egeozcan 3 days ago

Sentiment needs sentience, direction we're heading is the average of what exists, which works but is senseless.

Comment by post-it 3 days ago

We use nextjs at work and I hate it. Why write each view once when you could write it twice?

I'm open to the idea that we're doing it wrong and that there's a correct and pleasant way to write nextjs, but I think with the tools available today, everyone should just profile and optimize their app so they don't need to render it serverside.

Comment by chrisweekly 3 days ago

I recommend ditching Next.js in favor of Tanstack Start^1, an alternative metaframework that gives you more freedom, better DX, and better defaults. Stick w the best aspects of SPAs and introduce SSR selectively if and when it makes sense.

1. https://tanstack.com/blog/tanstack-start-1-0

Comment by cpursley 3 days ago

Or for a serious stack like Phoenix Liveview.

Comment by agos 3 days ago

Liveview is neat, but it still has quite some raw edges - and it’s not really meant for SSG which is the topic at hand

Comment by cpursley 3 days ago

So Astro, then. I was was replying to the previous poster who did need a real app.

Comment by chrisweekly 2 days ago

I'd love to hear your ideas about what makes TanStack Start less "serious" than Astro

Comment by cpursley 2 days ago

Tanstack vs Phoenix, not Astro. Astro is for static sites. JavaScript is not a serious backend language, but Tanstack SPA isn’t half bad.

Comment by chrisweekly 3 days ago

I'd be grateful if whoever downvoted my comment could explain what they found objectionable.

Comment by littlecranky67 3 days ago

Didn't downvote, but my thought on your comment is: "More freedom" -> "More decision paralysis & anxiety", "New better framework X" -> "Latest hypecycle that will be require me to rewrite and relearn a framework that is deprecated in 18 months" etc.

Comment by chrisweekly 2 days ago

Yeah, that's what I figured too. Sadly, that shallow / kneejerk response leads to unearned mindshare advantage for problematic incumbents like Next.js, and risks stifling meaningful improvement.

TanStack Start absolutely merits a closer look. It's not a flash in the pan or "the new shiny". It's the robust, coherent, independent and logical evolution of battle-hardened wisdom and brilliant design and implementation from first principles. See TanStack Router and TanStack Query for more evidence and background context. I've been around the block (25+ years in webdev) and gained a deep appreciation for Tanner's way of thinking. No affiliation, just a grateful user trying to help others notice by amplifying the signal in the noise.

P.S. Yes I wrote ~"it's not X, it's Y". No I didn't use genAI to write here (nor anywhere, ever).

Comment by tengbretson 3 days ago

Why are you writing the same view twice?

Comment by post-it 2 days ago

Once for SSR, once for client-side; for each entry view.

Comment by Pedro_Ribeiro 2 days ago

I think you're holding it wrong. I've never heard anyone doing this. Why?

Comment by post-it 2 days ago

I'm not sure, I just inherited it. But there's some things like analytics that can only really run in the browser so that might be why.

Comment by prtmnth 3 days ago

Am I missing something? Nextjs static export would have solved this I feel. And hosting it on Cloudflare Pages and put the CDN in front and you're done.

Having said that, sure perhaps Astro would be lighter than Nextjs.

Comment by ceving 3 days ago

Does your static site really need JS at all?

Comment by ninalanyon 3 days ago

Sometimes. It depends on what it is doing and on how good you, or your companion LLM, is at modern CSS.

Comment by LoganDark 3 days ago

Caching isn't essential if you can come up with the pages fast enough, unless you need a CDN due to factors like distance.

Comment by hackersnooze1 2 days ago

I am glad front-end devs are finally realizing how stupid and overengineered they made everything

Comment by wdhilliard 2 days ago

Typical response from a back-end only engineer who thinks front-end engineering is simple, but has no idea how any of it works.

Comment by capitanazo77 2 days ago

Astro is just one prompt away from a perfect 100. “Convert to astrojs, no mistakes”