Why is Next.js so slow??

It's getting to the point where I can just feel that an app is using server components when I use it. Nearly 1 second page navigations. I'm sure it could be improved, but I've yet to come across a server component app in the wild that feels good. It's about to save Vzero, but I just checked and I'm not even sure they're using them anymore. As per usual, DAX is mostly right, slightly inflammatory, and not showing the whole picture in this particular instance. I think there's a lot to dive into here. I agree with him that most of the server component apps I have seen have been really really rough. But I don't agree this is the fault of server components. I'm going to say something a little

controversial on this one. I think the blame for the slow server component sites falls less on the next team on Verscell and certainly less on the React team and the people working on server components directly and more on people like me. In order for this to work and work well, we need to deeply understand how server components behave and what they mean for us as developers because there is no excuse for any website to be as slow as this one is. It almost feels like we've gone back in time to the way

pages worked before. I want to break down what makes sites like this so slow, how we got here in the first place, and most importantly, how to use server components correctly so that we can have the fastest possible websites while also matching the great DX that we expect from tools like React and Next.js. Sadly, developer experience doesn't pay the bills. I've learned that lesson enough times. So, we're going to do a quick word from today's sponsor right before we dive in. Building apps has never been easier thanks to all these AI tools. And deploying them has never been easier, too. at least until you need to add a CDN, a DOS protection layer, file

storage, a database, automatic builds during CI and pull requests, and all these other things that we expect now as developers in order to keep moving as fast as our editors let us. That's why today's sponsor, Savala, has changed the game for all of you guys that need to host real servers. Once I saw this dashboard, I immediately got it because Savala makes it so easy to deploy an actual server instance and throw the right infra in front of it. Setting up Cloudflare in order to handle DOS protection, CDNs, and all of that stuff that you really should be doing in front of your app is particularly annoying,

especially if you're using frameworks that are expecting traditional server hosting, like you know, Elixir, Laravel, Rails, etc. This has made my life significantly easier when deploying things that aren't my usual JS stack. Not that it doesn't work with that stack, it actually works really well with all that stuff, too. Where things get way cooler is the pipeline feature where you can set up preview, dev, and production environments. S plural. Yes. So people can file a poll request and automatically spin up a preview app that will sleep after not being used for a while. These workflows are obnoxious to set up and we had whole teams at Twitch building all of these things so that we

could have better code review experience. All of a sudden it's just a feature built into the platform. And as I said before, it's not just servers and it's not just the Cloudflare integration. It's so many more things like object storage and databases, too. Doesn't matter if you're trying to host a static site, an Nex.js app, some crazy stuff in Python, some weird side project you built in Rails 8 years ago. Pretty much everything you'd ever want to ship is going to work on Savala. And I know that for a fact because this is built by Kinsta, the company that made WordPress actually hostable. Check them out today at/savala and you'll get $50 of free credit applied to your account. This

video is inspired by a lot of the push back I'm seeing on server components. Obviously, this and the performance side, that's the most important piece. But also complaints like Michael Jackson from the Remix team saying that server components are nice in theory, but they're not working out. Evan here saying that server components aren't necessarily a problem. They unlock cool patterns, but the overhead is the issue here. And me responding with probably too many words to Dax's post trying to break down what happened and how we got here. I could just read this to you. And

believe me, part of me was tempted to just read this out considering especially how positive the attention and feedback was to it, but I'd rather go in detail on how we got here and why these apps are so slow. I'm going to do a real brief history of the web. If you want a deeper version of this, I have a long video that I think is genuinely super underappreciated. All the ways HTML gets to your browser. I think this is one of my best videos, even if I don't look like that anymore. If you want a deep dive on all of this, check