Slow https requests

Discussion of Chrome Browser and its add-ons.
Locked
millerbean
New Member
New Member
Posts: 4
Joined: Mon Apr 16, 2018 9:07 am

Slow https requests

Post by millerbean »

Hi

I work for a company where we develop a product running in Chrome.

Typically our customers have adblock with easylist installed.

This slows some of our https requests down with ex. 7 seconds.

As an example the following url is called /Planning/ReadLimited
With easylist enabled: 10,5 seconds (average)
With easylist disabled: 1,2 seconds (average)

This has been tested on several computers.

How can we fix this issue ?
intense
Contributor
Contributor
Posts: 10494
Joined: Wed Mar 27, 2013 9:56 am

Post by intense »

Provide all the info to reproduce the issue:

- adblocker version
- browser version
- all the lists enabled in your adblocker
- page example, test account(if needed)
- what to click to trigger such behaviour (or indicate if it's about the loading time of a specific page)
User avatar
LanikSJ
Site Owner
Site Owner
Posts: 1806
Joined: Thu Feb 15, 2007 7:44 am
Location: /dev/null

Post by LanikSJ »

EasyList is a text based file. I would be looking at the type of blocker your users are using instead.
"If it ain't broke don't fix it."
millerbean
New Member
New Member
Posts: 4
Joined: Mon Apr 16, 2018 9:07 am

Post by millerbean »

Google Chrome
Version 65.0.3325.181 (Officiel version) (64-bit)

It affects adblock, adblock plus and ublock with Easylist installed (all newest versions)
I have only Easylist enabled

Test account info
user: devaccount
password: devaccount

Open developer tools
Go to https://dev2017-6-1.e-komplet.dk/Planning/CalendarPlanning#timelineWorkWeek

Look at the following request
https://dev2017-6-1.e-komplet.dk/Planning/ReadLimited

It takes 8 seconds when Easylist is enabled and 1,6 seconds when disabled.
intense
Contributor
Contributor
Posts: 10494
Joined: Wed Mar 27, 2013 9:56 am

Post by intense »

Try this filter

Code: Select all

@@||e-komplet.dk^$generichide
see if still getting the issue
intense
Contributor
Contributor
Posts: 10494
Joined: Wed Mar 27, 2013 9:56 am

Post by intense »

from uBo developer (gorhill / R. Hill)
Their code is causing a whole lot of browser style recalculation as per performance pane. I suspect they are querying style properties related to geometry (ex.: width, height, position), and some generic cosmetic filter is getting in the way of an efficient recalc.

Really I think their code can be improved a lot. They are repeatedly querying/modifying DOM geometry properties such that the browser is forced to recalculate layout non-stop within that loop. In any case, the proper solution is to disable the blocker or use the generichide exception.

They have code to query/modify the display styles on many elements in an array -- this is their weak point, as this causes the browser constant layout recalculation, this is what I would fix if I was them.
[mention]fanboy[/mention] could you add the generichide filter above to easylist ?

[mention]millerbean[/mention] You could try improving your code (see gorhill above)

similar issue:
https://github.com/gorhill/uBlock/issues/3645

It seems the generic filters using id^="..." or id*="..." directive in them are causing such behaviour.

Code: Select all

##aside[id^="div-gpt-ad"]
##div[id^="ADV-SLOT-"]
##div[id^="MarketGid"]
##div[id^="YFBMSN"]
##div[id^="acm-ad-tag-"]
##div[id^="ad-div-"]
##div[id^="ad-server-"]
##div[id^="ad_script_"]
##div[id^="adrotate_widgets-"]
##div[id^="ads120_600-widget"]
##div[id^="ads250_250-widget"]
##div[id^="ads300_100-widget"]
##div[id^="ads300_250-widget"]
##div[id^="ads300_600-widget"]
##div[id^="advads-"]
##div[id^="advads_"]
##div[id^="block-views-topheader-ad-block-"]
##div[id^="cns_ads_"]
##div[id^="crt-"][style]
##div[id^="dfp-ad-"]
##div[id^="dfp-slot-"]
##div[id^="div-adtech-ad-"]
##div[id^="div-gpt-ad"]
##div[id^="div_ad_stack_"]
##div[id^="div_openx_ad_"]
##div[id^="dmRosAdWrapper"]
##div[id^="google_ads_iframe_"]
##div[id^="google_dfp_"]
##div[id^="lazyad-"]
##div[id^="proadszone-"]
##div[id^="q1-adset-"]
##iframe[id^="google_ads_frame"]
##iframe[id^="google_ads_iframe"]
##p[id^="div-gpt-ad-"]
##[id*="MGWrap"]
##[id*="MarketGid"]
##[id*="ScriptRoot"]
##div[id^="mainads"]
##div[id^="zergnet-widget"]
millerbean
New Member
New Member
Posts: 4
Joined: Mon Apr 16, 2018 9:07 am

Post by millerbean »

intense wrote: Wed Apr 18, 2018 11:43 am Try this filter

Code: Select all

@@||e-komplet.dk^$generichide
see if still getting the issue
This filter solves the issue, but we still need to apply this to our 230+ customers filters.

Is there any way to solve this from our side ?
intense
Contributor
Contributor
Posts: 10494
Joined: Wed Mar 27, 2013 9:56 am

Post by intense »

Who is using uBo (ublock origin) should be ok (after updating the filters)
https://github.com/uBlockOrigin/uAssets ... d861487b13

For other adblockers I notified (see above) an easylist maintainer

On your side you should send gorhill considerations to kendo staff
millerbean
New Member
New Member
Posts: 4
Joined: Mon Apr 16, 2018 9:07 am

Post by millerbean »

Is it possible for EasyList to Add

Code: Select all

@@||e-komplet.dk^$generichide
globally to all users ?
intense
Contributor
Contributor
Posts: 10494
Joined: Wed Mar 27, 2013 9:56 am

Post by intense »

I already told you (about notifying as you can see).

And don't ignore what I said about the kendo bad code triggering such behaviour.
Locked