3 ms·

I agree with some of the conclusions, namely that many people use Ad Block to avoid the slowness that downloading and executing oodles of JavaScript can create.

I agree with some of the conclusions, namely that many people use Ad Block to avoid the slowness that downloading and executing oodles of JavaScript can create. The methodology here suffers from an apparent lack of insight into what a 'library' is. Note that tech savvy companies such as Facebook and Twitter are low on the list with only a few 'libraries', while media sites have many listed. All this proves is possibly that Facebook and Twitter have less external JavaScript, and are savvy enough to combine files to reduce HTTP requests. Listing the total KB of JavaScript executed could help clarify the matter. But then, it would also give advantage to those who minify vs those who don't. Fair enough as download time is part if the issue - though the article does not mention that file size plays a role as well as number if http requests. To accurately portray who is using the most JavaScript, you'd have to count opcodes, and combine that with http request count and total download size.

dangoldin 13y ago
Yea - this was more of a quick write up and this is a good excuse to jump into the PhantomJS world to see what's actually happening. Once I get to that I'll do a follow up post.
1337p337 13y ago
Definitely performance is a nice benefit. I don't use AdBlock; I have a few thousand lines in my /etc/hosts that map various bad actors (vast chunks of Javascript that doesn't do anything useful, 1x1 .gifs, ads, annoying widgets, etc.) to 255.255.255.255 (NXDOMAIN), and use dnsmasq on that machine to get that benefit across to the rest of the local network, regardless of browser. The thing that usually triggers another bout of "block these hosts" is if I notice that my ostensibly idle browser is burning CPU. I don't want to wait several seconds for a page to render, and I certainly don't want to waste laptop battery time on refreshing an iframe with "what people are saying about this on Twitter" or feeding someone's analytics server. Half the time a site runs really slowly, it's usually doing some nonsense that I'd be happier without, or my browser is waiting to download something that I don't need to see. The total amount of Javascript in kB is one issue, but you don't need to hit the level of opcodes, I think. Counting the nodes in the parsetree would be useful, as well as measuring the amount of memory that is allocated by the Javascript, determining whether it runs once or continuously or on some trigger (e.g., scrolling, hovering, mouse movement). If you ran a profiler and measured the amount of time spent in the Javascript bits of your runtime (e.g., how long to parse the JS, how long to eval it, how often it runs, throw in some memory profiling) you could probably get some interesting numbers.

dangoldin 13y ago

Yea - this was more of a quick write up and this is a good excuse to jump into the PhantomJS world to see what's actually happening. Once I get to that I'll do a follow up post.

1337p337 13y ago

Definitely performance is a nice benefit. I don't use AdBlock; I have a few thousand lines in my /etc/hosts that map various bad actors (vast chunks of Javascript that doesn't do anything useful, 1x1 .gifs, ads, annoying widgets, etc.) to 255.255.255.255 (NXDOMAIN), and use dnsmasq on that machine to get that benefit across to the rest of the local network, regardless of browser. The thing that usually triggers another bout of "block these hosts" is if I notice that my ostensibly idle browser is burning CPU. I don't want to wait several seconds for a page to render, and I certainly don't want to waste laptop battery time on refreshing an iframe with "what people are saying about this on Twitter" or feeding someone's analytics server. Half the time a site runs really slowly, it's usually doing some nonsense that I'd be happier without, or my browser is waiting to download something that I don't need to see. The total amount of Javascript in kB is one issue, but you don't need to hit the level of opcodes, I think. Counting the nodes in the parsetree would be useful, as well as measuring the amount of memory that is allocated by the Javascript, determining whether it runs once or continuously or on some trigger (e.g., scrolling, hovering, mouse movement). If you ran a profiler and measured the amount of time spent in the Javascript bits of your runtime (e.g., how long to parse the JS, how long to eval it, how often it runs, throw in some memory profiling) you could probably get some interesting numbers.