5 ms·

These are great, but increasingly none of our web app's performance issues relate to any of these metrics. Memory leaks, slow typing, UI interactions like open

These are great, but increasingly none of our web app's performance issues relate to any of these metrics. Memory leaks, slow typing, UI interactions like opening a modal that shouldn't be taking 8s+, where's the literature on how those affect user satisfaction?

dflock 6y ago
There is copious, voluminous literature stating that users hate slowness in all it's forms?
- compacct27 6y ago
  I believe it, but I mostly hear about how user retention drops off if the website takes more than 1s to load. And while I believe other types of slowness make users unhappy without seeing the literature, the people driving our priorities don't see the $ impact at all
  - gumby 6y ago
    I hate slow sites and am pretty aggressive about bailing on anything that I consider slow. But speed is a visitor's feature, not a benefit. The benefit (to the web site operator) of an ecommerce site is $ spent by visitor. So for example yes, the Amazon site feels slow and bloated, but they've been doing live A/B testing for over 20 years and I'm pretty sure they don't care about speed unless it affects conversion; they'll be happy to cram something in even if it slows the site down, if it increases revenue.
    - SamReidHughes 6y ago
      Amazon seems pretty darn fast to me. You click and stuff happens. It's faster than Twitter or Github (the first two sites I compared it with).
superkuh 6y ago
Your site is already unhealthy no matter what because it's not a website. It's an application that just happens to also use http and browsers.
- coldtea 6y ago
  >If you require executing javascript to display things you've already lost and your site is already unhealthy no matter what because it's not a website. That ship has sailed, nobody cares if it's not a "website" as in HTTP only, including 99% of users...
  - henriquez 6y ago
    You say “nobody cares,” but I and many people I know and work with do care! I understand your point of view but maybe you should try to understand where others are coming from.
    - SketchySeaBeast 6y ago
      > I understand your point of view but maybe you should try to understand where others are coming from. Can you make an argument for it? It kind of feels like a movie critic trying to explain why the Transformers are bad, even though they still rake in billions. If the Transformers changed to make the critic happy, it at best would have no impact on the billions, in all likelihood it would cause a regression, and so the critic needs an incredibly compelling argument.
      - henriquez 6y ago
        I wrote a (lengthy) post on this: https://www.obsessivefacts.com/blog/2020-04-04-the-javascript-black-hole.html https://www.obsessivefacts.com/blog/2020-04-04-the-javascrip... In the language of your analogy it would be "Transformers are unethical!" Our collective obsession with making billions is ruining entertainment media / the Internet / everything unfettered capitalism touches ;)
Jaygles 6y ago
I think those metrics aren't brought up as much in the blogosphere because they are harder to measure. Those metrics will be unique to the context of the app they're measured in. The metrics talked about in the article are ones that can be determined easily in the context that Chromium is working in.
dfabulich 6y ago
> slow typing, UI interactions like opening a modal that shouldn't be taking 8s+, where's the literature on how those affect user satisfaction? That's right there in the post. Google calls these things "input delay." One of the three primary metrics called out in Google's post is FID, "first input delay," which is the delay on the first user interaction. (Subsequent input delays are also bad for users, but subsequent input delays are usually only as bad as the first input delay.)
- kaycebasques 6y ago
  > (Subsequent input delays are also bad for users, but subsequent input delays are usually only as bad as the first input delay.) I'm not sure about this statement. It sounds reasonable but I can't recall seeing any research about FID being a proxy for all input delay throughout the entire duration of a session. I would hypothesize that optimizations that improve FID would also tend to improve input delay in general. My main message here is just that I haven't seen that research.
  - igrigorik 6y ago
    Input delay is bad, period. It's not a matter of first vs rest but observation that input while the page is loading is, often, where most of the egregious delays happen: the browser is busy parsing+executing oodles of script, sites don't chunk script execution and yield to the browser to process input, etc. As a result, we have FID, which is a diagnostic metric for this particular (painful) user experience problem on the web today. Note that Event Timing API captures all input: https://github.com/WICG/event-timing https://github.com/WICG/event-timing. First input is just a special case we want to draw attention to due to the reasons I outlined above. That said, we encourage everyone to track all input delays on their site, and it's definitely a focus area for future versions of Core Web Vitals -- we want to make sure users have predictable, fast, response latency on the web.
kaycebasques 6y ago
> where's the literature on how those affect user satisfaction? As someone else mentioned, it seems like all the issues you mentioned ultimately create user dissatisfaction because of input delay. In which case FID seems like it'd be a good metric for you to target. I'm not sure about the claim that if you improve FID then all input delay will be reduced for the entire duration of a person's session with your site, but I imagine that FID and general input delay are directly correlated. This is just conjecture however and is not a statement backed by research. Here's a summary of some general research on how users perceive input delay: https://developers.google.com/web/fundamentals/performance/rail#ux https://developers.google.com/web/fundamentals/performance/r... (Tangentially related) The new performance.measureMemory() API may help you correlate memory leaks with business metrics: https://web.dev/monitor-total-page-memory-usage/ https://web.dev/monitor-total-page-memory-usage/

dflock 6y ago

There is copious, voluminous literature stating that users hate slowness in all it's forms?

compacct27 6y ago
I believe it, but I mostly hear about how user retention drops off if the website takes more than 1s to load. And while I believe other types of slowness make users unhappy without seeing the literature, the people driving our priorities don't see the $ impact at all
- gumby 6y ago
  I hate slow sites and am pretty aggressive about bailing on anything that I consider slow. But speed is a visitor's feature, not a benefit. The benefit (to the web site operator) of an ecommerce site is $ spent by visitor. So for example yes, the Amazon site feels slow and bloated, but they've been doing live A/B testing for over 20 years and I'm pretty sure they don't care about speed unless it affects conversion; they'll be happy to cram something in even if it slows the site down, if it increases revenue.
  - SamReidHughes 6y ago
    Amazon seems pretty darn fast to me. You click and stuff happens. It's faster than Twitter or Github (the first two sites I compared it with).

superkuh 6y ago

Your site is already unhealthy no matter what because it's not a website. It's an application that just happens to also use http and browsers.

coldtea 6y ago
>If you require executing javascript to display things you've already lost and your site is already unhealthy no matter what because it's not a website. That ship has sailed, nobody cares if it's not a "website" as in HTTP only, including 99% of users...
- henriquez 6y ago
  You say “nobody cares,” but I and many people I know and work with do care! I understand your point of view but maybe you should try to understand where others are coming from.
  - SketchySeaBeast 6y ago
    > I understand your point of view but maybe you should try to understand where others are coming from. Can you make an argument for it? It kind of feels like a movie critic trying to explain why the Transformers are bad, even though they still rake in billions. If the Transformers changed to make the critic happy, it at best would have no impact on the billions, in all likelihood it would cause a regression, and so the critic needs an incredibly compelling argument.
    - henriquez 6y ago
      I wrote a (lengthy) post on this: https://www.obsessivefacts.com/blog/2020-04-04-the-javascript-black-hole.html https://www.obsessivefacts.com/blog/2020-04-04-the-javascrip... In the language of your analogy it would be "Transformers are unethical!" Our collective obsession with making billions is ruining entertainment media / the Internet / everything unfettered capitalism touches ;)

Jaygles 6y ago

I think those metrics aren't brought up as much in the blogosphere because they are harder to measure. Those metrics will be unique to the context of the app they're measured in. The metrics talked about in the article are ones that can be determined easily in the context that Chromium is working in.

dfabulich 6y ago

> slow typing, UI interactions like opening a modal that shouldn't be taking 8s+, where's the literature on how those affect user satisfaction? That's right there in the post. Google calls these things "input delay." One of the three primary metrics called out in Google's post is FID, "first input delay," which is the delay on the first user interaction. (Subsequent input delays are also bad for users, but subsequent input delays are usually only as bad as the first input delay.)

kaycebasques 6y ago
> (Subsequent input delays are also bad for users, but subsequent input delays are usually only as bad as the first input delay.) I'm not sure about this statement. It sounds reasonable but I can't recall seeing any research about FID being a proxy for all input delay throughout the entire duration of a session. I would hypothesize that optimizations that improve FID would also tend to improve input delay in general. My main message here is just that I haven't seen that research.
- igrigorik 6y ago
  Input delay is bad, period. It's not a matter of first vs rest but observation that input while the page is loading is, often, where most of the egregious delays happen: the browser is busy parsing+executing oodles of script, sites don't chunk script execution and yield to the browser to process input, etc. As a result, we have FID, which is a diagnostic metric for this particular (painful) user experience problem on the web today. Note that Event Timing API captures all input: https://github.com/WICG/event-timing https://github.com/WICG/event-timing. First input is just a special case we want to draw attention to due to the reasons I outlined above. That said, we encourage everyone to track all input delays on their site, and it's definitely a focus area for future versions of Core Web Vitals -- we want to make sure users have predictable, fast, response latency on the web.

kaycebasques 6y ago

> where's the literature on how those affect user satisfaction? As someone else mentioned, it seems like all the issues you mentioned ultimately create user dissatisfaction because of input delay. In which case FID seems like it'd be a good metric for you to target. I'm not sure about the claim that if you improve FID then all input delay will be reduced for the entire duration of a person's session with your site, but I imagine that FID and general input delay are directly correlated. This is just conjecture however and is not a statement backed by research. Here's a summary of some general research on how users perceive input delay: https://developers.google.com/web/fundamentals/performance/rail#ux https://developers.google.com/web/fundamentals/performance/r... (Tangentially related) The new performance.measureMemory() API may help you correlate memory leaks with business metrics: https://web.dev/monitor-total-page-memory-usage/ https://web.dev/monitor-total-page-memory-usage/