Large portions of the profile are spent in SVG parsing and painting and then destroying the prescontext for that again. I suspect what's happening is that we've got icons for some of the bookmarks that are large SVG files (e.g. if you bookmark a large SVG image itself, I expect the icon will just be the same SVG...), and we try to render all of that in the parent and it causes jank.

This would also explain why this happens for some people and not others, and suggests that although our sync places APIs may be unfortunate, they're not really the primary cause here. A reasonable fix would probably be to ensure that page-icon protocols and various other favicon handling APIs use and store normalized-to-max-128x128px icons or something like that. This would also address other issues that can arise due to favicons being loaded and painted in the parent... Marco, do we already have a separate bug for this that we can link this one to?

It would still be useful to have a more recent profile than one from 5 years ago to confirm this is still the issue.

(In reply to :Gijs (he/him) from comment #7)

This would also explain why this happens for some people and not others, and suggests that although our sync places APIs may be unfortunate, they're not really the primary cause here. A reasonable fix would probably be to ensure that page-icon protocols and various other favicon handling APIs use and store normalized-to-max-128x128px icons or something like that. This would also address other issues that can arise due to favicons being loaded and painted in the parent... Marco, do we already have a separate bug for this that we can link this one to?

We do already normalize non-vector icons to specific sizes (that goes up to 192px).
We also have a maximum size limit set to 65536 bytes.

For vector icons we only respect the size limit and throw the icon away if it's larger than that. We don't try doing any resizing and I'm not sure that is possible for our image tools?

I'm also adding a link to https://bugzilla.mozilla.org/show_bug.cgi?id=1772264, because today sometimes we return rich icons when we should prefer non-rich ones, rich icons (like apple-touch) are usually larger.

(In reply to Marco Bonardo [:mak] from comment #8)

For vector icons we only respect the size limit and throw the icon away if it's larger than that. We don't try doing any resizing and I'm not sure that is possible for our image tools?

Not while keeping them as vectors, I imagine, but I still wonder if normalizing to a pixel version would be better. There'd be artifacts if we picked a size that then didn't fit the display size neatly, I suppose...

We are tracking the same performance issue in another issue so duping it