Bug 264235 – REGRESSION (Safari 15)?: Appending img elements to the DOM is slow when 1Blocker is enabled

• Component: DOM
• Status: NEW

Since iOS 15 was released (Safari 15), I have observed that Safari has gotten far slower at inserting many images into a page. Where it was previously nearly instantaneous, it now can take several seconds for the "img" elements to be added to the page, during which the browser is completely frozen. This has persisted ever since and is still the case with Safari 17.

Setting a height/width on the element, or setting loading="lazy" does not help.

We have worked around it by transitioning most of our images to be background-images, which does not display the same issue, but this is inconvenient. 

I have reproduced this in a CodeSandbox here: https://56f8f3.csb.app/ - click the "Do It" button and you will see the browser freeze for a couple seconds before the images display. The timer shows that the JS event loop was blocked for that time. In other browsers (e.g. Chrome, Firefox), the images can be appended in a few milliseconds.

Had a few more people check this out and they didn't have the same issue. I figured out that this only happens when content blockers are enabled - I'm using 1Blocker for content blocking.

I *also* have a similar level of content blocking enabled on Chrome, so I would still consider this a performance issue.

[Radar WebKit Bug Importer]

<rdar://problem/118003576>

Hi there, any update on this one? It's a pretty sizeable performance tax on anyone using content blockers.

[Simon Fraser (smfr)]

Would it be possible for you to collect some performance data using the `sample` command line tool, with and without 1Blocker enabled?

Absolutely, I’ll do that soon. 

In the meantime, it seems likely that what’s happening is that the list of content blocking rules is being evaluated synchronously, on the main thread, when the element is inserted into the DOM, rather than checking during the download of the image which would presumably happen in a separate thread. 

An interesting side effect of this performance issue is that a page can pretty reliably detect when a user has content blockers enabled in Safari.

Created attachment 471232 [details]
Sample of loading https://56f8f3.csb.app with 1blocker enabled

Created attachment 471233 [details]
Sample of loading https://56f8f3.csb.app with content blockers disabled

[Simon Fraser (smfr)]

Sorry I was going to give more instructions once you said sampling was OK.

WebKit uses a multi-process model so you need to find the appropriate web content process using Activity Monitor or `top` (quit Mail and close other Safari tabs to reduce the count). You can see which is the right process by looking to see which com.apple.WebKit.WebContent process uses CPU when interacting with the page.

Then run `sample` with the PID of that webcontent process, while doing the image loaded.

Created attachment 471282 [details]
Sample of https://56f8f3.csb.app with 1Blocker enabled

Created attachment 471283 [details]
Sample of https://56f8f3.csb.app with content blockers disabled

Let me know if there's any more I can do to help out with this.

Were those traces helpful?

This is still a pretty bad performance bug for users with content blockers enabled, and it may also enable fingerprinting and detection of content blockers.  Is there anything else I can provide to help?

Safari 18 makes no improvement to this problem.