Opened on 05/31/2017 at 07:22:40 AM

Closed on 06/06/2017 at 12:54:30 PM

Last modified on 06/17/2017 at 06:37:37 AM

#5284 closed defect (duplicate)

ABP causes big lags and makes Mozilla Firefox 53 very slow

Reported by: mariusica77 Assignee:
Priority: Unknown Milestone:
Module: Unknown Keywords:
Cc: trev, mapx, arthur Blocked By:
Blocking: Platform: Firefox
Ready: no Confidential: no
Tester: Unknown Verified working: no
Review URL(s):



Win 10 Home (up-to-date)
Mozilla Firefox 53.0.3
Adblock Plus 2.9
Filters: Adblock Warning Removal List, EasyList, EasyPrivacy, Malware Domains

How to reproduce

  1. Go to e.g.
  2. Attempt to scroll thru the home page

Observed behaviour

Images load slow, everything lags, whole browser becomes blocked until I close the tab.
While Netflix homepage is unusable, other sites are affected by slowness (Twitter, YouTube, etc) and it's very slow to scroll in them. Clicking on links or videos is also slow until mouse is ready,.

Expected behaviour

The sites with more content than usual work as before (Mozilla Firefox 52 or 2-3 weeks ago)


  1. With ABP disabled, all works like before under this default profile.
  2. I created an empty profile, made sure Firefox (last version) works fine, then as soon as I installed ABP (with default filters, so only EasyList), it went downhill, everything was slow. Not as slow or blocking as the default Firefox profile, but a lot slower than before.
  3. I deleted storage.js (was 39MB, now it's 13MB), patterns.ini, patterns-backup5.ini, then restored the filter backup (like suggested in ABP forum). No change.

Attachments (0)

Change History (10)

comment:1 Changed on 05/31/2017 at 02:57:30 PM by mapx

  • Cc trev mapx added

comment:2 follow-up: Changed on 06/01/2017 at 12:46:26 PM by trev

The file size is expected given that it now contains both the filters themselves and the backups. Also, processing storage.js isn't terribly efficient - I notified Mozilla about that a while ago but didn't get any response so far. This isn't going to affect your regular browsing however, mostly showing on startup.

What you might be seeing is - does the issue disappear if you go into Firefox preferences and uncheck "Enable multi-process Firefox"? Note that I'm not proposing this as a solution, merely trying to understand the issue.

comment:3 in reply to: ↑ 2 Changed on 06/01/2017 at 01:29:57 PM by mariusica77

Replying to trev:
Yes, it all started with netflix homepage not working at all (same as that ticket, version and time period matches), then talked to someone from Mozilla and he suggested removing extensions until multi-process is enabled, also updating graphics driver and nvidia driver. Did all that and stayed with the setting on since. So the issue was present with multi-process disabled too..

comment:4 Changed on 06/01/2017 at 10:57:26 PM by harryray2

Latest version causing severe lag on page scrolls etc and constant severe freezes...Issue solved by reverting back to 2.8.2 (or disabling 2.9)

comment:5 Changed on 06/01/2017 at 10:59:43 PM by harryray2

this is happening on all sites....

comment:6 Changed on 06/03/2017 at 07:35:56 PM by mapx

comment:7 Changed on 06/06/2017 at 08:05:36 AM by arthur

  • Cc arthur added

comment:8 Changed on 06/06/2017 at 11:38:04 AM by arthur

This is on Windows 10, Firefox 53.0.3 (32 bits, new profile), ABP 2.9, EasyList+EasyList Germany, EasyPrivacy, Fanboys Social Blocking List and Acceptable Ads (intentionally added some more lists). In both reports I opened the main page of Multi-process was enabled.

Last edited on 06/06/2017 at 11:40:48 AM by arthur

comment:9 follow-up: Changed on 06/06/2017 at 12:54:30 PM by trev

  • Resolution set to duplicate
  • Status changed from new to closed

Thank you, I can actually confirm the issue myself on We have indeed a write being triggered by filter hit changes, so #5298 will solve the issue for the majority of users. The reason why this is coming up now: API that we are using right now seems to be extremely inefficient when saving data. There is but even without sanitization - my performance log shows 2.3 seconds (!) being spent serializing JSON data. Without filter hit counting we will only need to save data rarely and this will be much less of an issue.

Resolving this as a duplicate of #5298.

comment:10 in reply to: ↑ 9 Changed on 06/17/2017 at 06:37:37 AM by mariusica77

Replying to trev:
Could you also test on ? Open main page, scroll a bit, try to use a different tab. The fix helped a lot with all other sites, but not With ABP disabled completely, it works fine (similar performance with Chrome).

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.