Bug 264235

Summary:

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

Product:

WebKit

Reporter:

ben

Component:

DOM

Assignee:

Nobody <webkit-unassigned>

Status:

NEW ---

Severity:

Normal

CC:

bfulgham, simon.fraser, webkit-bug-importer, zalan

Priority:

Keywords:

InRadar

Version:

Safari 17

Hardware:

iPhone / iPad

OS:

iOS 17

URL:

https://56f8f3.csb.app/

Attachments:

Description	Flags
Sample of loading https://56f8f3.csb.app with 1blocker enabled	none
Sample of loading https://56f8f3.csb.app with content blockers disabled	none
Sample of https://56f8f3.csb.app with 1Blocker enabled	none
Sample of https://56f8f3.csb.app with content blockers disabled	none

Description ben 2023-11-05 18:09:16 PST

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.

Comment 1 ben 2023-11-05 18:29:05 PST

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.

Comment 2 Radar WebKit Bug Importer 2023-11-06 09:31:32 PST

<rdar://problem/118003576>

Comment 3 ben 2024-04-27 21:20:49 PDT

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

Comment 4 Simon Fraser (smfr) 2024-04-29 10:26:30 PDT

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

Comment 5 ben 2024-04-29 23:44:40 PDT

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.

Comment 6 ben 2024-04-30 23:31:33 PDT

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

Comment 7 ben 2024-04-30 23:32:00 PDT

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

Comment 8 Simon Fraser (smfr) 2024-05-01 12:54:56 PDT

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.

Comment 9 ben 2024-05-04 09:39:20 PDT

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

Comment 10 ben 2024-05-04 09:39:44 PDT

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

Comment 11 ben 2024-05-13 13:20:43 PDT

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

Comment 12 ben 2024-06-18 21:57:40 PDT

Were those traces helpful?

Comment 13 ben 2024-07-21 11:54:01 PDT

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?