What they fail to realise is that people who work in dev rel jobs are paid to promote a product. I have a theory that pretty much every developer saying "X is best for Y" is simply believing what a developer relations engineer or evangelist has said to them at a conference (or they read on a blog post, or heard 5th hand from a dev they know).
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.
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. Ultimately my main interest was to figure out whether it might make sense to rewrite our site. But I don't really care about synthetic tests or micro benchmarks. 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. In this particular run, 1% of Next.js sites met this goal, as compared with 8% of Angular sites. 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. I actually think this is a strength of the methodology. It compares the speed of a basket of sites that happen to use Angular in some capacity with a separate list of sites that happen to use Next.js and makes a broad sweeping conclusion about framework speed?
0 kommentar(er)
