Оценка производительности бразуерных дополнений для блокировки рекламы
Рассмотрев критику, касающуюся изменений в третьей редакции манифеста Chrome, которые нарушат работу многих дополнений для блокирования нежелательного контента и обеспечения безопасности, разработчики из компании Google подытожили свою позицию по данному вопросу. Утверждается, что в реализации нового API declarativeNetRequest будут учтены все пожелания и замечания авторов дополнений, в том числе будет расширен лимит на число правил блокировки. Тем не менее, как и раньше разработчики Chrome намерены ограничить старый API webRequest режимом только для чтения (неблокирующим режимом), что позволит только отслеживать запросы, но не даст изменять их.
Отсутствие блокирующего режима в API webRequest потребует портирования большинства дополнений для блокирования рекламы на новый API declarativeNetRequest, который самостоятельно применяется предоставленные дополнением правила фильтрации. Одним из основных аргументов против API webRequest называется замедление отображения контента, так как данный API работает в блокирующем режиме и перед выводом страницы браузер ожидает полного завершения обработки данных дополнением.
Авторы сервиса WhoTracks.Me и разработчики блокировщика рекламы Ghostery решили проверить насколько данные заявления соответствуют действительности и провели масштабное тестирование производительности фильтрации контента дополнениями uBlock Origin, Adblock Plus, Brave, DuckDuckGo и Cliqz/Ghostery. Для проведения теста была организована симуляция обработки большого числа запросов в рассматриваемых дополнениях, для чего с использованием Node.js были подготовлены тесты, прогоняющие через движки блокировщиков 250 тысяч запросов (случайные страницы 500 самых популярных сайтов), 19% из которых приводили к блокировке. В блокировщика использовался набор правил Easylist, включающий 38978 записей.
Измерение показало, что все рассмотренные блокировщики работают очень эффективно - задержки на применение фильтров, блокирующие вывод на этапе использования API webRequest, пренебрежимо малы на общем фоне. В среднем применение блокировщика замедляет выполнение запроса лишь на доли миллисекунд, что никак не может рассматриваться как повод для отключения поддержки блокирующего режима работы API webRequest.
В общем зачете наибольшие задержки были зафиксированы для дополнения DuckDuckGo, которое замедляло каждый запрос в среднем на 8 мс. Для Ghostery, uBlock Origin, Adblock Plus и Brave среднем составили 0.007мс, 0.017мс, 0.019мс и 0.041мс соответственно. Разница обработки запросов подлежащих и не подлежащих блокировке оказалась минимальной: Ghostery (0.007/0.006 мс), uBlock Origin (0.016/0.018 мс), Adblock Plus (0.014/0.020 мс), Brave (0.062/ 0.038 мс) и DuckDuckGo (8.31/6.78 мс).
Дополнительно была измерена производительность кода для кэширования (сериализации и десериализации) внутреннего представления данных для ускорения загрузки базы правил. Данные операции приводят лишь к задержкам на этапе запуска и не влияют на производительность работы дополнения. Размер кэша c сериализированной базой правил для всех дополнений составляет примерно 2 Мб.
При сравнении потребления памяти наибольшую эффективность продемонстрировали дополнения Ghostery и uBlock Origin, требующие для работы 2-3 Мб ОЗУ. Потребление памяти Adblock Plus и DuckDuckGo составило приблизительно 15-16 Мб.
При измерении времени на разбор списка правил блокировки из общей массы выделился блокировщик из браузера Brave, которым потратил на разбор в 20 раз больше времени, чем остальные блокировщики. Наиболее быстрыми в этом тесте оказались Adblock Plus и uBlock Origin.
