[5.1.5]: Very noticeable slowdown in element indexes introduced in 5.1.5

[thupsi]

[5.1.5]: Very noticeable slowdown in element indexes introduced in 5.1.5

[brandonkelly]

Interesting. Thanks for tracking it down!

[angrybrad]

@thupsi impressive debugging either way!

[thupsi]

I have been diggin some more, and it has been a weird debugging journey, but I don't want to waste your time with irrelevant details, so I'll try to stay on point:

• I finaly disabled all plugins (I should have done this from the start), and I saw that the loading of indexes improved when I disabled the Control Panel CSS plugin.
• I tested some more and I discovered one :has selector in my custom css that apparently was having a negative impact (I'm noting here that this custom css has been there a long time, from earlier versions.).
• Having removed that selector the LCP went down to 5.1.4 levels.

My conclusion is that there is a JS issue that has to do with event listeners, or DOM manipulation, or something of that ilk, that causes a bottleneck in the page rendering (see also #14713). I'm guessing maybe the fix for #15047 was a bit "heavy handed"? I think it added some event listener, and maybe that is the culprit? I could be wrong, but I can't think of anything else.

[brandonkelly]

Hmm… all d58eec0 does is remove a DOM element and disconnect a mutation observer when the view class is getting destroyed (which happens whenever you change sources). Hard to imagine that having a noticeable performance impact, especially for CSS. You could confirm though, by changing your craftcms/cms requirement to 5.x-dev#d58eec0451ccf4aa3a304f807612f5529e0bc8fd and make sure you’re seeing the performance bug, and then compare that to 5.x-dev#d56b167b1e27304cee6ef93469051d97d820df73 (its parent commit).

[thupsi]

Well, nope, that's not it! Haha, that would be too easy right? Try the below, as a reduced test case:

Add this CSS (maybe with the CP CSS plugin? Dunno if that makes a difference):

body:not(:has(.test)) {
  #system-name {
    background-color: red;
  }
}

And then just this:

body:not(.test) {
  #system-name {
    background-color: red;
  }
}

On my end the first snippet affects the performance. The second is fine. And when I go back to 5.1.4, both are fine.

Crazy 😜

[brandonkelly]

Just tested the first snippet in Firefox, Safari, and Edge (Chrome) and didn’t notice a difference in CP performance between 5.1.4 and 5.1.7. In both cases it was snappy. Maybe it’s in combination with some custom/plugin JS that is also getting added?

[thupsi]

Was your testing on Mac or Windows?

• I disabled all Craft plugins, and also used incognito mode to disable the browser's plugins.
• I tested on 3 windows machines with similar (not good) results.
• I don't have a Mac, but tested on my iPad, on Safari, and there the performance seems OK.

[thupsi]

In addition to being on Windows, you have to:

• Test with a decent amount of entries. Not much, let's say 60-70?
• Add some columns. In the source I'm testing now I have two relational fields, two number fields and the post date.

But, really, I don't want you to jump through hoops to try to replicate. Do you prefer me to send a DB backup with composer files?

[thupsi]

Ooookay! I tried comparing various commits going from 5.1.4 to 5.1.5 and:

• Tracked the performance hit to dac89c8
• Tracked the impacting file change to cp.css
• Tracked the "guilty" selector to .element-index.main .inline-editing .flex:has(input[type=text][inputmode].fullwidth)
• This only has a negative impact if I add my custom css snippet with :has
• This is only is an issue in Windows Chrome and Windows Edge (Chrome). Firefox is OK.
• Obviously it's a Chrome bug, so you can't/shouldn't do anything about it!
• What a waste of time, haha 😿

Thanks @brandonkelly for taking a look, I'm closing this now! Here's hoping I won't be back soon with obscure Windows bugs for you Mac people. 🙂