In many ways the ease with which one can include third-party libraries in a web page is a testament to both the design of the web and extraordinarily rich and open ecosystem around it. With a few third-party services you can transform a static HTML page into a rich interactive experience with comments, media, analytics, feedback and so on. As a result, use of third-party libraries is now nearly ubiquitous—almost every website you visit today links to external libraries.
Third-party libraries, when implemented well, are also a nice example of how a distributed network of loosely connected components can work well together to build something greater than the sum of the parts. When a given library is unavailable, the linking page typically remains functional. Browser and network-willing, pages are progressively enhanced with additional functionality such as comments and embedded media.
Unfortunately it is the very ease of use of third-party libraries that makes them such an insidious enemy of web performance.
The icebergs of the web
Third-party libraries are the web performance equivalent of icebergs. They look light thanks to single-line copy and paste embed codes but their performance-sinking bulk comes afterwards as they drag in countless additional resources. Just how bad is the problem? Pretty bad.
Note how the YouTube embed increases in size on mobile.
The net effect is that any page that includes the above three services already has a page weight of 1.6 MB on desktop or 1.1 MB on mobile before any site content is included. This is an borderline-unacceptable for any page, let alone an empty one.
An inexperienced developer might not notice just how much impact these included libraries are having. Yoav Weiss of Akamai recently showed that visiting The Verge required the browser to download, unzip, parse and run 7 MB of JavaScript, a startling number. Ironically the page in question was entitled “Why the Mobile Web sucks” and laid blame for this situation squarely at the browsers’ door.
Misaligned incentives & a tragedy of the commons
Third-party includes become a problem when the incentives of the website and library provider are misaligned. This is often the case with service providers whose business models are rarely aligned with those of the sites they are embedded in. Typically a website seeks additional functionality such as comments or embedded media, but the library provider has a business model centered around user data and advertising.
Seen through the lens of parasite and host, it normally makes no sense for the parasite to kill the host but in this case no one library is solely responsible for the impact, leading to a a classic tragedy of the commons problem where the user’s browser is the commons and each third-party library is acting as if they are the only one grazing. The web user suffers and ultimately the website too as people get so turned off with performance that they stop visiting.
"If these idiots would just take the bus, I could be home by now."
aka: You're not stuck in traffic, you are traffic. pic.twitter.com/2Vo2p2TcG5— Taras Grescoe (@grescoe) October 30, 2014
What to do about it?
First off, it’s worth noting that third-party libraries are not all created equal—some services pay more attention to their impact on the host page than others. As an example, the impact of embedding a Vimeo video is about 1/2 that of YouTube at the time of writing; sharingbuttons.io are a much lighter set of sharing buttons than AddThis—so choose your libraries carefully and keep an eye on their impact.
Secondly, it’s worth considering if items really need to be embedded on the same page. Perhaps users would be better served by links to the content rather than embedded content. Some sites now link the the comments page rather than inlining them to keep load times low.
Setting a performance budget for sites is another approach to help keep things in check. Frameworks such as AMP may also help if only to remind people that it is possible to build a rich web experience while staying fast and light.
For our part we’re going to shine a light on this issue by tracking just how big these libraries are getting with the hope of raising awareness. Since June we’ve been tracking a few of the bigger libraries and will maintain a live database of their performance. You can see the data here.
UPDATE 1: The irony of talking about the impact of third-party libraries on a site that uses third-party libraries is not lost on us. We do try to keep things light here at mobiForge. For example, our sharing buttons are home-grown and add about 13KB to the page between the two sets at the top and bottom of the page. Our biggest sin is our use of Disqus which accounts for 292KB of our 647KB transfer weight before you scroll down to the comments. One you reach the comments section it rises to 800KB. The Tweet embed on this page is relatively costly too at about 136KB. Taken together, our use of Disqus and embedding a single Tweet has about doubled the page size. It’s a sobering thought, though in this case I think that the benefits outweigh the cost.
UPDATE 2 : Our “empty” page has put on some weight in August. YouTube has added 26KB on desktop, more than offsetting slight reductions by Disqus and AddThis. The net result is that our empty page now weighs in at 1.6MB on desktop, or 1.2MB on mobile.
UPDATE 3 (June 2017): While YouTube and AddThis have made slight improvements, Disqus reversed recent gains, resulting in a net page weight gain.
Leave a Reply