<story><title>Ad Blocking Extensions Tested for Performance</title><url>https://www.raymond.cc/blog/10-ad-blocking-extensions-tested-for-best-performance/view-all/</url></story><parent_chain></parent_chain><comment><author>emn13</author><text>The methodology is questionable on several fronts:&lt;p&gt;- you can&amp;#x27;t use the load event to compare advert-heavy vs. advert-free load times.  The load event does &lt;i&gt;not&lt;/i&gt; fire when the page is usable by the viewer, it fires when every last request is done, in particular even requests fired from various advert iframes.  However, those requests may not impact page usability.  The load event may even never fire - any offscreen 1px spacer gif that times out will cause that! I don&amp;#x27;t think there is a built-in event for &amp;quot;done-enough&amp;quot;, but the load event is certainly misleading.&lt;p&gt;- opening the developer tools causes various side-effects; those can cause the page to load more slowly than usual.  You shouldn&amp;#x27;t benchmark with developer tools open (unless you&amp;#x27;re explicitly targeting usage with devtools open...)&lt;p&gt;- comparing load times across browsers as reported by the browsers themselves &lt;i&gt;may&lt;/i&gt; be valid, but it&amp;#x27;s not obvious.  You definitely want to check that carefully.&lt;p&gt;- Measuring &amp;quot;peak&amp;quot; CPU usage is almost meaningless without considering how long the CPU is used.&lt;p&gt;- Measuring the chrome extension process CPU usage and memory usage isn&amp;#x27;t very helpful, because running this kind of extension causes CPU usage and memory usage in every content tab.  Both of these statistics for chrome in this use-case are meaningless.  You&amp;#x27;d need to measure the memory usage and CPU-time of the entire chrome process tree to get meaningful results.  Even in Firefox without e10s it&amp;#x27;s not valid to measure just the main process CPU and memory usage because plugins are in separate processes (and things like flash or h264 decoding can definitely use CPU and memory).&lt;p&gt;The only thing this page really makes a decent case for is that Chrome loads pages faster than Firefox - but even there, it&amp;#x27;s not clear we&amp;#x27;re dealing with an apples-to-apples comparison.</text></comment>
<story><title>Ad Blocking Extensions Tested for Performance</title><url>https://www.raymond.cc/blog/10-ad-blocking-extensions-tested-for-best-performance/view-all/</url></story><parent_chain></parent_chain><comment><author>aidos</author><text>So it looks like about 1&amp;#x2F;4 of the time spent loading a page these days is spent on the page and the remaining 3&amp;#x2F;4 are waiting for ad networks. There&amp;#x27;s got to be an opportunity there.&lt;p&gt;I previously worked at a digital agency and one of my final projects was building the website for a large TV channel. At one point I had to have a meeting with the ad network to go through the integration.&lt;p&gt;The technical people involved didn&amp;#x27;t know anything about how their products worked or the implications of integrating them. No idea if they were blocking or async.&lt;p&gt;At one point I was trying to understand what, if any, changes I might need to make to handle their ads that did full background take overs. &amp;quot;No no no, it&amp;#x27;s an &lt;i&gt;expanding mpu&lt;/i&gt;&amp;quot; - sure, fine, what does that even mean!?&lt;p&gt;(Don&amp;#x27;t get me started on having to swap using js for switching images in the gallery for using individual pages because the onmiture page tracking numbers were the metric that everything was measured by for selling ad space)&lt;p&gt;&amp;#x2F;rant&lt;p&gt;You&amp;#x27;d think with all the smart people that have put their minds to ads on the internet, there would be lightning fast, targeted ads that actually worked by now.</text></comment>