Page timeouts for users with editoria11y permission when using the new branch

Which site is this for? I'd like to look at the markup. Also, could you send me → a copy of your config settings? I have seen some situations where certain settings can add up to a lot of drag.

I performance test on synthetic pages with hundreds of issues and a literal copy of Moby Dick, so if you are having any performance issues it is a bug, and I would like to troubleshoot. 2.2.x should not be slower than 2.1.x. The one thing I can think of that has changed are some mutation observers -- if you have mouse hover based attribute changes in the DOM it is possible something is thrashing....

Thank you so much for looking into this!

The site is https://www.cms.gov/ and I'll just go ahead and include our config below; this isn't sensitive. We've also tried setting assertiveness to "polite" (Never)

content_root: '#main, .block-system-main-block'
assertiveness: smart
no_load: .moderation-dashboard-block
ignore_all_if_absent: '.ds-c-tabs__item[href*="/edit"], .contextual-region a[href*="/edit"], .tabs__link[href*="/edit"]'
ignore_elements: ''
panel_no_cover: ''
embedded_content_warning: ''
download_links: ''
link_strings_new_windows: ''
ignore_link_strings: ''
link_ignore_selector: ''
hidden_handlers: ''
ed11y_theme: sleekTheme
shadow_components: ''
disable_sync: false
preserve_params: ''
redundant_prefix: ''
custom_tests: 0
disable_live: false
live_h_inherit: ''
live_h2: 'form[id^="node-"] #edit-body-wrapper .ck-content'
live_h3: ''
live_h4: ''
hide_edit_links: ''
ignore_containers: ''
allow_overflow: ''

Hmmph. That config should be fine.

I was able to grind my browser to a halt on one page on the frontend. I don't know if it's the same cause, but there it seemed that Editoria11y and Qualtrics were fighting with each other -- page interactions were causing Qualtrics to tie up the main thread, right when Editoria11y was trying to run. And since Editoria11y was asking for animationFrames to try to move its tips to sync with page scrolls, this was leading to more than one second of jank:

Are you perchance running Qualtrics metrics on the backend as well as the frontend? If so, do the problems go away if you set it to only render for anonymous users? Editoria11y 2.1 did not have the mutation observers to check for changes to the page, so it would not have been trying to run at the same moment during page interactions.

I can remove the animationFrame requests and see if it improves anything, but since JS is singlethreaded I doubt that will make a difference; any activity ties up the thread. I think something bizarre is going on, like a memory leak of some sort. I'm very puzzled, because my browser would still be lagging heavily even though the performance monitor was not showing any JS activity.

I have to set this aside for the moment because I am not sure what to do next, but I am going to keep this bug open until we figure it out.

@itmaybejj your last comment got me thinking so I started looking at the waterfall in the inspect tool while the pages were loading.

The problem seems to be an interaction with the LastPass browser extension. Editoria11y and LastPass battle it out and it severely delays page loading.

Unfortunately most of our team uses that extension. There's probably not anything you can do, but I thought I'd report back. We found that when we used browsers that did not use lastpass we did not experience the same lag.

Oh that's very helpful. We all run LastPass too. I'll see if I can figure out how to record and trigger that.

Slight edit: it may not entirely be the LastPass extension.

We weren't seeing the page timeouts in Firefox where we don't have the extension enabled. But - we're still seeing them in Chrome even after disabling the LastPass browser extension.

Almost all of the page resources load by around 5000ms (not great but ok).
The editoria11y css loads at 30,000ms.
The request to editoria11y/api/results/report is around 55,000ms and the page is unusable until after that.

Some additional data: when we disabled the mega menu at the top, the performance improved drastically. Note, based on the settings, the mega menu is not in the area to be scanned.

Attaching a screenshot of the network results I outlined above.

Oh that makes me want to cry. I used to inline all my CSS until the CSP module folks ✨ Support Content Security Policy (csp) Needs review asked me to abstract it out, and remote CSS calls are thread locking. But still; those late CSS requests should be served from cache, so only the first should slow you down, which makes me wonder if something is running for 55 seconds before the locking request is made. What I really want to see is the JS stack chart for those 55 seconds.

eeeeven more diagnostic questions:
Do you see the same problems while editing pages (backend theme) or only frontend pages?
On the frontend when you are seeing issues, what is the value of Ed11y.options.inlineAlerts?

Oh and -- config: content_root: '#main, .block-system-main-block' -- I'm looking at your site and those selectors are nested. Editoria11y does not like content roots being nested within each other. Can you knock one of those out?

Let me ask - #main isn't present in our admin theme (Claro) which is why I added the system main block. Will the ckeditor alerts still work if the admin theme doesn't contain the content root?

We haven't noticed the problem with the admin theme. I'll get back to you on the other questions Monday :)

Oh yes -- don't worry about selectors for the admin theme. If Editoria11y detects editable content it swaps out that parameter for its hard-coded selectors for CKEditor and Gutenberg instances...and it doesn't render on admin pages if it doesn't detect editable content.

Ok, went ahead and removed that extra class for the admin theme; thanks!

Ed11y.options.inlineAlerts is generally undefined

I looked at the JS Stack, and I think the issue may be all the forced reflows coming from our mega menu JS calling height(). What's odd is that we AREN'T seeing this same issue in Firefox.

I'm attaching a number of screenshots.

The menu seems possible. And it is outside main, so hopefully Editoria11y's mutation observers are ignoring all those changes.

The one clear takeaway I see so far is that I should make Editoria11y inherit the query token from Drupal for the CSS file rather than using its own version number; that should guarantee that the CSS preloads with the document before initial paint, so there is no second network call.

After some more thought and testing, I think what I'm going to do is add some config for whether Editoria11y should watch the page for changes, and wrap most of the new code into that. That should give 2.2 a static running mode that performs like 2.1.

That sounds awesome!

As a followup, we were able to get the new branch of editoria11y to not time out by reworking the mega menu JS (and probably improved site performance along the way!)

oh that's GREAT to hear! I'll keep focusing on general performance improvements then and not worry so much about testing against this site in particular.

Switching this to Fixed because I think 2.2.5 → will prevent future folks having the same headaches.