Adjust accessibility delay [chromium/src : main]
chromeperf@appspot.gserviceaccount.com (Gerrit)
Message from chrom...@appspot.gserviceaccount.com![]( "Open in Gerrit")
📍 Job mac-m1_mini_2020-perf/speedometer3 complete.
See results at: https://pinpoint-dot-chromeperf.appspot.com/job/1458aae4110000
Related details
- Philip Rogers
Code-Coverage
Code-Review
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Aaron Leventhal (Gerrit)
Aaron Leventhal added 1 comment![]( "Open in Gerrit")
This is a great start, thanks for working on it.
- In this CL, let's focus on before page load.
- I think it's fair to wait at least 3, maybe even 4 seconds between updates before page load. I think this will really help speed up first paint.
- For now, I don't think we should adjust the delay after page load, because I've been told that by a screen reader user that even the 150ms delay sometimes shows when they are operating in their screen reader's virtual buffer. Also, I don't think that it will have as much benefit as the before-page load, when the renderer is hyper-busy.
- In a future CL, if we want, we can use the presence of a screen reader via `GetAXMode().has_mode(ui::AXMode::kScreenReader)`. This is something that became accurate in the last month or so. We didn't have access to this info before and are only now starting to optimize based on it.
So my suggestion for now is to just change the before page load to something like 3500.
Related details
- Philip Rogers
Code-Coverage
Code-Review
No-Unresolved-Comments
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Aaron Leventhal (Gerrit)
Aaron Leventhal added 1 comment![]( "Open in Gerrit")
This is a great start, thanks for working on it.
- In this CL, let's focus on before page load.
- I think it's fair to wait at least 3, maybe even 4 seconds between updates before page load. I think this will really help speed up first paint.
- For now, I don't think we should adjust the delay after page load, because I've been told that by a screen reader user that even the 150ms delay sometimes shows when they are operating in their screen reader's virtual buffer. Also, I don't think that it will have as much benefit as the before-page load, when the renderer is hyper-busy.
- In a future CL, if we want, we can use the presence of a screen reader via `GetAXMode().has_mode(ui::AXMode::kScreenReader)`. This is something that became accurate in the last month or so. We didn't have access to this info before and are only now starting to optimize based on it.
So my suggestion for now is to just change the before page load to something like 3500.
Also, do you think it's worth finching it so we can see the benefit clearly?
chromeperf@appspot.gserviceaccount.com (Gerrit)
Message from chrom...@appspot.gserviceaccount.com![]( "Open in Gerrit")
📍 Job mac-m1_mini_2020-perf/speedometer3 complete.
See results at: https://pinpoint-dot-chromeperf.appspot.com/job/1110269d110000
Philip Rogers (Gerrit)
Philip Rogers added 1 comment![]( "Open in Gerrit")
Aaron LeventhalThis is a great start, thanks for working on it.
- In this CL, let's focus on before page load.
- I think it's fair to wait at least 3, maybe even 4 seconds between updates before page load. I think this will really help speed up first paint.
- For now, I don't think we should adjust the delay after page load, because I've been told that by a screen reader user that even the 150ms delay sometimes shows when they are operating in their screen reader's virtual buffer. Also, I don't think that it will have as much benefit as the before-page load, when the renderer is hyper-busy.
- In a future CL, if we want, we can use the presence of a screen reader via `GetAXMode().has_mode(ui::AXMode::kScreenReader)`. This is something that became accurate in the last month or so. We didn't have access to this info before and are only now starting to optimize based on it.
So my suggestion for now is to just change the before page load to something like 3500.
Also, do you think it's worth finching it so we can see the benefit clearly?
Sorry to waste your time; this is just a test to see if we have any headroom on speedometer. I noticed we run a11y updates during the scoring phase, and I am wondering if we can avoid that in a way that would benefit both speedometer and real users. Speedometer has an iframe where the real test runs, so it may be possible to adjust the delay parameter to be based on if any frame is loading, rather than just the top frame. Another idea is to use idle time signals.
Related details
- Aaron Leventhal
Code-Coverage
Code-Review
No-Unresolved-Comments
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Aaron Leventhal (Gerrit)
Aaron Leventhal added 1 comment![]( "Open in Gerrit")
Aaron LeventhalThis is a great start, thanks for working on it.
- In this CL, let's focus on before page load.
- I think it's fair to wait at least 3, maybe even 4 seconds between updates before page load. I think this will really help speed up first paint.
- For now, I don't think we should adjust the delay after page load, because I've been told that by a screen reader user that even the 150ms delay sometimes shows when they are operating in their screen reader's virtual buffer. Also, I don't think that it will have as much benefit as the before-page load, when the renderer is hyper-busy.
- In a future CL, if we want, we can use the presence of a screen reader via `GetAXMode().has_mode(ui::AXMode::kScreenReader)`. This is something that became accurate in the last month or so. We didn't have access to this info before and are only now starting to optimize based on it.
So my suggestion for now is to just change the before page load to something like 3500.
Philip RogersAlso, do you think it's worth finching it so we can see the benefit clearly?
Sorry to waste your time; this is just a test to see if we have any headroom on speedometer. I noticed we run a11y updates during the scoring phase, and I am wondering if we can avoid that in a way that would benefit both speedometer and real users. Speedometer has an iframe where the real test runs, so it may be possible to adjust the delay parameter to be based on if any frame is loading, rather than just the top frame. Another idea is to use idle time signals.
Oh, not a waste of time at all. This is low hanging fruit we haven't gotten to. Would love your help.
IMO for any child document we can set the delay as high as you want, e.g. MAX_INT . This won't actually delay it forever -- once load complete occurs it will force an immediate serialization anyway. That happens here: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/accessibility/ax_object_cache_impl.cc;l=5021;drc=38d9cb6a0e0827c80d56549450d84a621480a5af
I love the idea of using idle time signals. I didn't really know about them when I implemented this. I suppose if we see there is idle time we can commence doing our work, which means less work later when we might not be idle. How would that implementation look?
Related details
- Philip Rogers
Code-Coverage
Code-Review
No-Unresolved-Comments
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
chromeperf@appspot.gserviceaccount.com (Gerrit)
Message from chrom...@appspot.gserviceaccount.com![]( "Open in Gerrit")
📍 Job mac-m1_mini_2020-perf/speedometer3 complete.
See results at: https://pinpoint-dot-chromeperf.appspot.com/job/149caae4110000
chromeperf@appspot.gserviceaccount.com (Gerrit)
Message from chrom...@appspot.gserviceaccount.com![]( "Open in Gerrit")
📍 Job mac-m1_mini_2020-perf/speedometer3 complete.
See results at: https://pinpoint-dot-chromeperf.appspot.com/job/1062aae4110000
Related details
- Philip Rogers
Code-Coverage
Code-Review
No-Unresolved-Comments
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
chromeperf@appspot.gserviceaccount.com (Gerrit)
Message from chrom...@appspot.gserviceaccount.com![]( "Open in Gerrit")
📍 Job mac-m1_mini_2020-perf/speedometer3 complete.
See results at: https://pinpoint-dot-chromeperf.appspot.com/job/1472e9ad110000
Related details
- Philip Rogers
Code-Coverage
Code-Review
No-Unresolved-Comments
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |