I wonder how reliable this is for SSR as well (and sites that opt into SSR might actually have more complicated sites, so skewing the numbers): https://gist.github.com/Alex3917/fec45e5c2114c2c13b41b30e198...
Edit: the biggest issue is that the article is vunerable from severe confirmation bias from the authors admitted sunken costs
I actually think this is a strength of the methodology. Every site is supposed to hit the same set of benchmarks regardless of how simple or complex it is -- less than 1.8 seconds FCP, and <= 3.8 seconds TTI. In this particular run, 1% of Next.js sites met this goal, as compared with 8% of Angular sites.
I'm definitely interested (and I say as much) in how this would change when you define the baskets in different ways, which is why I included the code, to make it easy for others to improve upon. But I don't really care about synthetic tests or micro benchmarks.
Ultimately my main interest was to figure out whether it might make sense to rewrite our site. But if our site is already faster than every site I can find that uses Next.js, which was legitimately very surprising, then frankly it doesn't even make sense to consider further. Especially since I already have three or four different things I can do to significantly improve our FCP without rewriting the site, where by far the most expensive of these options is maybe 10% the time and cost of a rewrite.
Your headline is comparing frameworks, while your basket is arbitrarily chosen based on a Next.js's showcase page.
On the sites I've been working pages that have been server rendered work mostly perfectly with javascript disabled.
1) The server generates html (a string).
2) Browser receives html and builds DOM just like in any static website
3) Javascript downloads and react sees the DOM already exists and does nothing