I can't quite repeat that slow an LCP (even with 20x slowdown) but I do see a lot of style and layout causing a good bit of render delay. Here's an example with just a 6x slowdown on an M1 max:
I can't quite figure out why this is. The page is a little complex—hence why Lighthouse warns about an excessive DOM size but that's only a little over the 800 elements recommended so I'd be surprised if that was causing such an issue. I've definitely seen much more complex pages layout a lot quicker.
It would be worth trying to remove chunks of the page (or CSS) to see if you can narrow down while this is the case.
While on the subject of CSS, I've only had a brief look though it and with "Enable CSS Selector Stats" on but CSS like this could be improved:
.catalog-product-view .product-info-right .fieldset .field.qty .control .increase-qty {
box-shadow: none;
border-color: #e9eef0;
background: 0 0;
border-radius: 0;
width: 25px;
height: 46px;
padding: 5px;
color: #ccc;
border-left: none
}
This requires every element with a class of increase-qty to check if it's a child of any element with a control class, which then requires checking if it's a child of any element with a field and qty class, which...etc. That's all very expensive to figure out for style and layout! Do you need all that, or could this be massivelt simplified to:
.increase-qty {
box-shadow: none;
border-color: #e9eef0;
background: 0 0;
border-radius: 0;
width: 25px;
height: 46px;
padding: 5px;
color: #ccc;
border-left: none
}
And similarly for all other long class names. Overall I count over 6 and a half thousand lines of CSS (after pretty printing), which is quite a lot. And some of the rules are quite complex (like the above example). So I suspect that's the main reason for the long layout. It would be worth seeing if that could be simplified. Or even narrowed down to see which lines are causing the most issues (by experimenting with removing them and re-profiling).
Not sure if anyone else on the group has any better ideas to narrow this down?