3 ms·

These scores seem not to be well targeted for what's being measured. For example it clearly penalises the number of requests made. All things being equal more r

These scores seem not to be well targeted for what's being measured. For example it clearly penalises the number of requests made. All things being equal more requests is certainly more wasteful, but there's always more context. QUIC/HTTP3 are very good at multiplexing requests, smaller requests for single entities can mean improved caching, and global CDNs reduce the impact of requests anyway. Add to this the fact that almost all usage of apps like GitHub/Lab/etc are _warm-starts_ with filled caches, and these numbers start to feel quite divorced from the reality of the user experience. It doesn't help that the repository being used is essentially a toy repository with very little code or history, so it's hard to get a sense of how these systems scale. My experience on a ~1m line, ~150k commit repo on GitHub was absolutely fine for example. This is all just Lighthouse under the hood, which is great for SEO optimisation – it's all about first-landing, cold-start, and ideal if you're running landing pages. But a lot of Lighthouse isn't designed for web apps, with long lived sessions, where the majority of usage takes place with warm caches or uses local navigation with API requests. This feels like both a case of results being taken out of context, and using the wrong tool for the job.

arghwhat 4y ago
> It doesn't help that the repository being used is essentially a toy repository with very little code or history, so it's hard to get a sense of how these systems scale. That is the "best case" benchmarks. The "worst case" benchmarks are of the Linux kernel repository. "It's usually cached" is not an excuse for excessive traffic, especially as a lot of it is dynamic content in the first place.
- BobbyJo 4y ago
  > "It's usually cached" is not an excuse for excessive traffic, It does redefine what "excessive" means though. If 10 independent requests makes the code easier to maintain, an the performance hit is a few Ms on average, I wouldn't consider that excessive. If, under the same circumstances, the performance hit was a few hundred ms, it would indeed be excessive. It's not making excuses so much as pointing out a potential discordance between what is measured and what is assumed based on that measurement.
  - danpalmer 4y ago
    Further, 10 requests where 8 can be more aggressively cached, may well be better than 4 requests where none can be cached. Separating out requests isn't just about maintainability, it's also about separating entities with different caching behaviour. We could just do one big request for HTML, but if there's a lot of the page that doesn't need to change, that's wasteful.

arghwhat 4y ago

> It doesn't help that the repository being used is essentially a toy repository with very little code or history, so it's hard to get a sense of how these systems scale. That is the "best case" benchmarks. The "worst case" benchmarks are of the Linux kernel repository. "It's usually cached" is not an excuse for excessive traffic, especially as a lot of it is dynamic content in the first place.

BobbyJo 4y ago
> "It's usually cached" is not an excuse for excessive traffic, It does redefine what "excessive" means though. If 10 independent requests makes the code easier to maintain, an the performance hit is a few Ms on average, I wouldn't consider that excessive. If, under the same circumstances, the performance hit was a few hundred ms, it would indeed be excessive. It's not making excuses so much as pointing out a potential discordance between what is measured and what is assumed based on that measurement.
- danpalmer 4y ago
  Further, 10 requests where 8 can be more aggressively cached, may well be better than 4 requests where none can be cached. Separating out requests isn't just about maintainability, it's also about separating entities with different caching behaviour. We could just do one big request for HTML, but if there's a lot of the page that doesn't need to change, that's wasteful.