Do note that while Astro is a fine choice, your blog has much snappier page transitions with speculative prefetching and pre-rendering, while maintaining an equally good Lighthouse score.

As projects scale this matters more. For example, hard page transitions will accrue the cost of re-initializing the entire application’s scripts for every click.

Also, being able to split things across pages with almost zero extra overhead in navigation time and bundle time makes it way easier to structure big, complicated sites or web apps.

the fact that you can use whatever component framework you want and mix and match is pretty awesome. been hooked on astro ever since trying it out once :)

another low-hanging fruit for optimisation that nray.dev is not using, is the new inline-stylesheets option: https://docs.astro.build/en/reference/configuration-referenc...

using the 'auto' option usually reduces it to a single global sheet and page-specific inlined css. especially if you are writing a lot of short style blocks in your components, this is very very handy to reduce the amount of served css files.

I wish any company on the web that spends 6-7 figures a year on their website would hire either of you to make a website that actually loads before I click away.

I worked for many of those and... it is more complicated.

When you are a small team, it is easy to create a performant site because you work in a tight circle with shared conventions, rules, etc. and it is always the same people that work on the project.

When you are a large organization (think Facebook blog), there will be hundreds of engineers/designers/copywriters/... that are exposed to the codebase over the course of many years. Each will need to make a 'quick change' that over time compounds into the monstrosities that you are referring to.

The best you can do is add automated processes into CI/CD that prevent shipping anything that does not meet certain criteria. This might hold for a while... but as soon something borks the shipping velocity and some higher-up starts asking for names, those checks will be removed "temporarily" to unblock what that's burning.

As an engineer who takes pride in developing accessible and performant software, this killed the drive/joy for me of working for large orgs.

> over time compounds into the monstrosities that you are referring to

After dealing with this in a previous job I've found great joy in working on legacy code - when a project has hit rock-bottom it can only get better.

The initial request size is not a great way to compare frontend frameworks. Next goes into a lot of effort to optimize navigation around your site, and gives you full usage of React in your frontend so you can show amazing things like charts, forms etc.

If the JS files are set to load asynchronously, the initial load should be almost equally as fast, and React should load in the background. Afterwards, additional navigation should be near instant.

Depends how pages are generated. If they are using getStaticProps this is not true because the HTML needs to be "hydrated" with the React runtime which requires javascript. Astro will prebuild the static pages.

Look for a tag like this: <script id="__NEXT_DATA__" type="application/json">

The page will render perfectly fine before it is hydrated when using getStaticProps. To verify , simply run LightHouse in Chrome on a page with cache busting on and look at the screenshot timeline. It will render in a fraction of a second, long before React gets loaded.