4 ms·

You don't need to track users to track performance. You only need to know that a page/feature took X ms to load, there is no user-related data there. If you wan

by scinos 5y ago

You don't need to track users to track performance. You only need to know that a page/feature took X ms to load, there is no user-related data there. If you want to add other dimensions like user agent or country, then you may step a bit into user data, but it's as easy as avoid those metrics.

onion2k 5y ago
Once you have tracking code in the client the temptation to use it to answer problems will be very tempting, and the pressure from other stakeholders to add 'useful' data will pile on. If your product manager wants to know user screen resolutions it's much harder for them to argue "We track nothing, we need to implement tracking to get screen resolutions." than it is for them to say "We already track loading times; it's a few additional lines of code to add screen resolutions".
southerntofu 5y ago
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.
sokoloff 5y ago
Taking what I think is a pretty white hat use case here: suppose the site is slow for 5% of users. Knowing that a disproportionate number of those getting a slow experience came from country X would be really helpful to diagnosing and fixing. (The point of tracking performance from real users is to improve performance for real users, not to draw pretty graphs.)

by scinos 5y ago

onion2k 5y ago

Once you have tracking code in the client the temptation to use it to answer problems will be very tempting, and the pressure from other stakeholders to add 'useful' data will pile on. If your product manager wants to know user screen resolutions it's much harder for them to argue "We track nothing, we need to implement tracking to get screen resolutions." than it is for them to say "We already track loading times; it's a few additional lines of code to add screen resolutions".

southerntofu 5y ago

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.

sokoloff 5y ago

Taking what I think is a pretty white hat use case here: suppose the site is slow for 5% of users. Knowing that a disproportionate number of those getting a slow experience came from country X would be really helpful to diagnosing and fixing. (The point of tracking performance from real users is to improve performance for real users, not to draw pretty graphs.)