Opened on 05/23/2016 at 07:30:43 AM

Closed on 08/29/2019 at 05:48:47 PM

#4060 closed defect (rejected)

Adblock Plus for Chrome adds 50ms to DOMContentLoaded

Reported by: skillbill Assignee:
Priority: Unknown Milestone:
Module: Platform Keywords: closed-in-favor-of-gitlab
Cc: sebastian, kzar, mapx Blocked By:
Blocking: Platform: Chrome
Ready: no Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description (last modified by kzar)

How to reproduce

  1. Create a file index.html with the following contents:
  1. Launch a webserver python -m SimpleHttpServer
  2. Browse to http://localhost:8000/
  3. Open the dev tools, on the Network tab
  4. Refresh the page

Observed behaviour

A delay of around 50ms between localhost returning the document and DOMContentLoaded.

Expected behaviour

No such delay, as when Adblock Plus is uninstalled.


The delay seems to be the same when Adblock Plus has EasyList enabled as when it has no filters or subscriptions. The delay also seems the same before the changes we made for #235. The delay is present quite far back in the code (tested back to Adblock Plus 1.9), it does not seem to be a recent regression.

Attachments (0)

Change History (14)

comment:1 Changed on 05/23/2016 at 07:38:06 AM by mapx

  • Cc sebastian kzar trev added

comment:2 Changed on 05/23/2016 at 07:38:38 AM by mapx

  • Cc mapx added

comment:3 Changed on 05/23/2016 at 08:39:57 AM by kzar

I just tried to reproduce this, hosting the following page using python -m SimpleHttpServer:


My results:

Around 10ms with no extensions
Around 60ms with EasyList before #235 changes
Around 60ms with EasyList after #235 changes
Around 60ms with no filters/subscriptions after #235 changes

FWIW I had something like 150ms with all the extensions I normally have enabled.

According to the Chrome dev tools Network tab the response returning index.html took 4ms and then DOMContentLoaded was at 57ms, with nothing showing in between.

I was using Chrome Version 50.0.2661.94 (64-bit) on Debian Stretch.

comment:4 Changed on 05/23/2016 at 08:47:01 AM by kzar

  • Component changed from Unknown to Platform
  • Description modified (diff)
  • Summary changed from 100ms + to dom content loaded to Adblock Plus for Chrome adds 50ms to DOMContentLoaded

comment:5 Changed on 05/23/2016 at 08:48:49 AM by kzar

  • Description modified (diff)

comment:6 Changed on 05/23/2016 at 08:53:55 AM by mapx

comment:7 Changed on 05/23/2016 at 09:02:03 AM by kzar

No, does not seem to be caused by #3699. I get pretty much the same delay before that change and indeed way before then. I tested up to 1.9, does not seem to be a recent regression.

Not to say that it's impossible to improve, perhaps there is a way. I think Sebastian is more likely to have some ideas there though.

comment:8 Changed on 05/23/2016 at 09:07:39 AM by kzar

  • Description modified (diff)

comment:9 Changed on 05/23/2016 at 10:03:16 AM by sebastian

I can confirm that Adblock Plus is adding some overhead to page load, even with no active filters or even when commenting out the element hiding code. However, this behavior isn't specific to Adblock Plus but all extensions that use content scripts seem to cause a delay. For reference I get ~15ms with no extension, ~100ms with Adblock Plus and ~60ms with uBlock.

However, the reason Adblock Plus is causing more delay than other extensions might be that we have 3 content scripts that run at document_start. And there is certainly some overhead per script regardless of the code that the script runs. For reference, when I remove any code from all of our content scripts it still takes ~35ms to load the page. So perhaps we can reduce the overhead by bundling all 3 content scripts into a single file.

Besides that, we can also try moving include.postload.js from document_end to document_idle. Theoretically, this shouldn't have any effect on DOMContentLoaded, but in my tests the code in that script was repsonsible for ~10ms of the delay. And having that code run a little later if the browser is busy shouldn't hurt.

Last edited on 05/23/2016 at 10:06:26 AM by sebastian

comment:10 Changed on 05/23/2016 at 01:36:34 PM by mapx

probably the impact of the 3 content scripts is why on chrome start ABP is not able to act before the home page loading (I mean the page / pages are loaded with ads). In ubo (at least on 1 home page) the ads are correctly blocked / hidden.

comment:11 Changed on 05/23/2016 at 04:23:21 PM by kzar

So perhaps we can reduce the overhead by bundling all 3 content scripts into a single file.
Besides that, we can also try moving include.postload.js from document_end to document_idle.

I tried doing both by just manually editing the extension after it was built, didn't seem much/any difference in the delay :(

comment:12 Changed on 10/19/2016 at 04:02:04 PM by mapx

comment:13 Changed on 12/21/2017 at 11:27:49 AM by fhd

  • Cc trev removed

comment:14 Changed on 08/29/2019 at 05:48:47 PM by sebastian

  • Keywords closed-in-favor-of-gitlab added
  • Resolution set to rejected
  • Status changed from new to closed

Sorry, but we switched to GitLab. If this issue is still relevant, please file it again in the new issue tracker.

Add Comment

Modify Ticket

Change Properties
as closed .
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from (none).
Note: See TracTickets for help on using tickets.