Drowning in JavaScript
dangoldin.com
dangoldin.com
Is it? 39 libraries that are 35 lines of code each or just define a bunch of functions that your code can then call optionally may well not take that long to parse. How many gems does the typical Rails application use? Libraries are the equivalent on the web, only someone else doesn't resolve the dependencies; you have to include the dependencies manually. Is it that surprising that people are using a variety of helper libraries to do ads, analytics, DOM manipulation, etc, etc? That's fairly standard for development.
I think saying we're “drowning in JavaScript” because we've gotten a lot better at modularizing our code instead of copy-pasting it from everywhere seems like lamenting the wrong part of the problem by far. I would rather every site include Google Analytics, DoubleClick, jQuery, and 10 jQuery UI plugins than be subjected to the cascade of security and functionality bugs folks would run into if everyone was trying to roll their own solution for everything. There are already enough with the use of common code.
Using libraries for third party code is good, and the fact that we're doing it is a step forward, not a step back. Now, there may be room for folks to choose the third party code more wisely, but that's a perennial problem when you're willing to use code that's already been written.
Trust me on this I spent my last 3 years doing analysis on a large number of sites for one of the worlds major publishers.
Right now, JS apps are often just serving the latest version of libraries for things like DoubleClick and Google Analytics. Google can update what they're serving at any time without letting you know. If you use a build system to bundle the library into your code, you lose the benefits the user could get from already having the library cached. If you don't, you're exposed to someone else's whims on library updates, and you add HTTP requests to boot.
The same goes for bundling something like jQuery into your app. You can bundle it in, but that data has to be sent downwire to the client when the JS goes down, even if it is just in one HTTP request. Or you can include it via CDN and a lot of users won't have to download it again, despite having to do an HTTP request. So it's all about choosing the right tradeoffs.
Also, JavaScript runs as it downloads, in page order. So you don't have to wait for all 30/X round trips, though you may have to wait for X round trips for the last file (in page order) to run. Then it becomes a matter of prioritizing what needs to load first. Naturally this is stuff we wish we didn't have to worry about, but worrying about bandwidth and latency and how and when and in what order things download has always been necessary for network applications, and I don't see that need going away anytime soon. I'd love to be proven wrong though :)
Which is 1.
This is javascript here, not CSS or images. The default behaviour is to stop everything, download the script file (synchronously) then execute it (also synchronously) then resume. This means the default is to download then execute one JS file at a time (which is why you should always put your CSS files before your JS files).
Concurrent download (let alone out-of-order execution) have to be opted-in via specific attributes:
@async will queue script download (asynchronously) and execute it whenever it can once downloaded. Multiple @async scripts may be executed in any order, depending how fast they arrive and when the browser finally decides to exec them. It is supported in webkit-ish browsers, Firefox (>= 3.6) and MSIE >= 10
@defer will also queue script download but it guarantees the scripts will only be executed 1. between parsing and end DOMContentLoaded triggering, 2. in order. It is suported in webkit-ish browsers, Firefox (>= 3.5) and MSIE >= 10 (MSIE has had it since ~IE5, but as usual its behavior tends to be ill-defined and buggy)
(note: this is for <script src> tags in the downloaded source, not when they're dynamically inserted)
It makes sense since the HTTP fetch order doesn't affect semantics as long as you obey the execution order from the page. Unless you're doing something very contrived, such as serving them as no-cache and generating different js dynamically from server side if a previous script has been requested...
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.
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.
As for why publishers use more JavaScript than tech companies, it comes down to the amount of technical talent. Maybe 10% of a digital publisher's employees work on the tech team, as opposed to ~50% for a tech company. Given these resource constraints, JavaScript requests proliferate due to two reasons:
1. With less time, engineers turn to external libraries more often to get things done even when they could address the problem with less code if they wrote it themselves.
2. We can't necessarily spend the time to tune everything and combine/minify libraries for peak performance.
That being said, I'm sorry performance sucks. I'm working on it. Can anyone recommend good tools for analyzing performance bottlenecks on the web?
For a barely six-paragraph article...
I have a site that logs AJAX requests to Google Analytics (since that's essentially the only "page views" on the particular site). I was doing a test for if (_gaq) before trying to push into the array, because I wasn't more concerned with giving the users a good experience than tracking page views, and that did work if Google Analytics was being blocked from loading at all. Unfortunately, I eventually learned that Disconnect was causing that test to throw a JavaScript exception instead of just blocking GA from loading and leaving _gaq undefined. As you can imagine, narrowing down that it was Disconnect causing the problem from a few random users' "the site isn't working" complaints was a lot of fun...
It's not a huge site, but I do spend a couple thousand dollars a year keeping it online. I'll be damned if I'm going to spend that to keep a free site online and then feel bad about running some advertising and analytics to make sure it doesn't end up in the red.
Some find it to be more transparent, and in many ways it is, but really you won't see much of a difference between the function of the two. I personally use Disconnect, and have yet to find it break any sites. I find setting Flash to ask before being enabled on web pages tends to break more sites than anything else.
Unlike the author, it's not the amount of JS that bothers me, but the amount of trackers involved. Companies you never hear about collecting loads of data on your online activity.
I was looking for shoes on one site then days later visited a totally unrelated resource. They showed me ad with the exact boots I viewed. Thankfully, with Ghostery this doesn't happen.
I just tried Forbes' front page, and I got 108 scripts being pulled + [all inline JS of top page combined] = 109 scripts.
Just for ad.doubleclick.net, it's 30 external javascript files pulled.
And I got this result without the 19 iframes which were blocked, and which certainly would have raise further the script count.
"Five of the 13 publishers I looked at included at least 20 JavaScript libraries while the most libraries included by a social network was 4, which was Pinterest"
For example, he claims 4 on Pinterest, but I quickly looked and one of those files, called: bundle.e3e1df0f.js which has compressed MANY LIBRARIES IN IT (975 KB worth, without gzipping), like JQuery, underscore, backbone, require.JS, Google closure, etc...
Just because a site is packaging up 30 JavaScript libraries into one file, doesn't mean it's not using all these libraries.
I'll also add, that I think a lot of the 3rd party tracking libraries don't really work if you bundle them up and deliver them with your own code, which is why they're usually referenced separately.
Sure, despite the best efforts of the industry, performance improvement will sneak in here or there. Things probably will trend upwards. But so, so much slower than they could.
Bandwidth is well and good, but latencies are non-fungible, as are other overheads.
Am I right?
I'd rather sites explicitly set scripts so that I can cherry-pick what to block.
[Previous post made from my phone.]
Oh come on. Practically speaking, "most people" don't care about the "degradation" of a site due to Javascript. Most people wouldn't even know what that meant.
In any event, MrPleb's dismissive response is unwarranted.
And they're right. Ads slow things down, especially because many ad networks are still using archaic JavaScript. (Lots of document.write...)