4 ms·

What's funny about this is that client-side "performance metrics" scripts is really close to the definition of malware (only the data points gathered differ wit

What's funny about this is that client-side "performance metrics" scripts is really close to the definition of malware (only the data points gathered differ with an actual tracker), doesn't work in all cases (older browsers, NoScript..). But what's really hilarious about it all is that in my experience this kind of sites doing metrics gathering are the worst offenders in terms of performance. Please, just do what you need to do and don't add more bloat in the name of performance. If you need to do tests, setup a test VM with 512MB RAM, 1s artificial latency and 20% packet loss. By testing for the "worst" case (which is close to the reality of many people) you ensure the average case is great.

gherkinnn 5y ago
> doesn't work in all cases (older browsers, NoScript..) And that is fine. Even if old browsers and noscript were supported, it's usually a small percentage. > kind of sites doing metrics gathering are the worst offenders in terms of performance. You have a point. I have a feeling it's an org problem, bloated org builds bloated products, but struggle to articulate it further. > setup a test VM with 512MB RAM, 1s artificial latency and 20% packet loss. A synthetic approach will get you a long way already. Though I would like to see it as part of the CI/CD pipeline. Testing perf has to be passive and continuous or it's useless.