cms
cms copied to clipboard
craftcms
[5.1.5]: Very noticeable slowdown in element indexes introduced in 5.1.5
What happened?
Description
Something changed in 5.1.5 that causes extreme (well, at least very noticeable) slowness in the element indexes.
Source with just 68 entries:
(Just for kicks, I'm including measurements from older Craft versions on the same element source)
| Version | LCP |
|---|---|
| Craft 3.7.59 | 0.64s |
| Craft 4.9.3 | 1.07s |
| Craft 5.1.4 | 1.69s |
| Craft 5.1.5 | 6.08s |
I also tested 5.1.6, and even 5.2.x-dev, and the results are more or less the same.
That's more than triple delay for Largest Contentful Paint, that is when the actual entries are rendered in the table, when going from 5.1.4 to 5.1.5. That's surely a bug of some sort.
What's interesting is that v5 in general seems slower than v4, and v4 slower than v3. I'm somewhat sensitive to performance, and this gradual degradation is in line with my impression as a daily user of Craft. I don't know if it's DB related or JS related, but it is there. I know you have been working on some performance optimizations, so maybe these observations will come in useful.
Craft CMS version
Craft 5.1.5
PHP version
8.3.7
Operating system and version
No response
Database type and version
MySQL 8.0.33
Image driver and version
No response
Installed plugins and versions
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
:hasselector 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 https://github.com/craftcms/cms/issues/14713). I'm guessing maybe the fix for https://github.com/craftcms/cms/issues/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.
Hmm… all d58eec0451ccf4aa3a304f807612f5529e0bc8fd 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).
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 😜
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?
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.
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?
Ooookay! I tried comparing various commits going from 5.1.4 to 5.1.5 and:
- Tracked the performance hit to https://github.com/craftcms/cms/commit/dac89c8858d46e1f958c5a2d1d07374df1e93158
- 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. 🙂
