Having considered the criticism concerning changes in the third edition of the Manifesto of Chrome, which will break many add-ons to block unwanted content and security, the developers of Google summed up its position on this issue. It is argued that the implementation of the new API declarativeNetRequest will take into account all wishes and remarks of the authors of the amendments, including expanded limit on the number of blocking rules. However, as before, the developers of Chrome are going to restrict the old webRequest API mode read-only (non-blocking mode) that will only allow you to track the requests, but will not change them.
The absence of blocking mode in the webRequest API will require porting of most of the add-ons to block ads on the new API declarativeNetRequest, which itself is applied provided by the addition of filtering rules. One of the main arguments against the webRequest API is the slowing down of display content, as this API works in blocking mode and before rendering of the page, the browser waits for completion of the processing addition.
The authors of the service WhoTracks.Me and the developers of ad block, Ghostery decided to check whether these statements are true and conducted extensive performance testing of content filtering additions Origin uBlock, Adblock Plus, Brave, DuckDuckGo and Cliqz/Ghostery. The test was organized a simulation of handling a large number of queries in the add-ons to use Node.js was prepared tests, forced through the engines of blockers 250 thousand queries (a random page 500 of the most popular sites), 19% of which led to the lock. In blocker used Easylist rule set that includes 38978 records.
The measurement showed that all the blockers are very efficient – delays in applying filters, blocking the output stage using the webRequest API, negligible against the background. On average, the use of blocker slows down the query only by a fraction of milliseconds that should never be viewed as an opportunity to disable the blocking mode API webRequest.
In the overall standings, the highest delay was recorded for the DuckDuckGo extension, which slowed down each request, on average, 8 MS. For Ghostery, uBlock Origin, Adblock Plus and Brave and average of 0.007 MS, MS 0.017, 0.019 0.041 MS and MS, respectively. The difference of query processing subject to and not subject to lock was minimal: Ghostery (0.007/0.006 MS) uBlock Origin (0.016/0.018 MS), Adblock Plus (0.014/0.020 MS), Brave (0.062/ 0.038 MS), and DuckDuckGo (8.31/6.78 MS).
Additionally, we measured the performance of the caching code (serialization and deserialization) the internal representation of data to speed up loading the rule base. These operations lead only to delays in the start-up phase and do not affect the performance of the Supplement. The size of the cache c of the serialized base rules for all the additions is about 2 MB.
When comparing memory consumption, the greatest efficiency is demonstrated by the add-on Ghostery and uBlock Origin, which requires 2-3 MB of RAM. The memory consumption of Adblock Plus and DuckDuckGo was approximately 15-16 MB.
When the time dimension to the analysis of the list of blocking rules from the total mass of the separated blocker from your browser Brave who spent parsing 20 times longer than other blockers. The fastest in this test turned out to be Adblock Plus and uBlock Origin.
According to the materials: www.opennet.ru