According to data collected by BuiltWith.com, 6% of the top 10,000 most high-traffic sites load content from Facebook’s servers. For the vast majority of them, that content is likely Facebook’s Javascript SDK, a huge block of code that is needed to display such features as the Like button (as seen on many media sites) and Facebook comments widgets (also used on many big media sites, Buzzfeed among them).

This SDK code is so big that it represents about 16% of the total size of all JavaScript on the average web page.

One of the culprits behind modern websites taking so long to download

As a sizable and widely-used software library, the Facebook SDK is a nice way of illustrating some of the answers to the questions: just why is the average site today so big? And how much does size actually matter?

Why so big?

The Facebook SDK is very full-featured, duplicating many of the tools the average site is likely to already include for its own developers’ use: methods for retrieving data from other sites, for determining which browser and device the user is using so as to target specific features to them, and for displaying UI elements (like confirmation dialogs and buttons). If we categorize all of the pieces of the SDK, the breakdown looks like this:

The amount that each set of features in the SDK contributes to total filesize. (Note that this is the size of the file before it has been compressed; the final package will be smaller.) [Source data, methodology, and more screen-reader-compatible data table]

Of the sets of features, three stand out the most:

The three sets of features in the SDK that are completely irrelevant to the vast majority of users on most sites. Eliminating them — if it were possible to do so — would shave off roughly 20% of the SDK filesize. [Source data, methodology, and more screen-reader-compatible data table]

“Canvas” is Facebook’s system for apps that are intended to be loaded within Facebook (Facebook made a major push in the past to encourage developers to build apps that lived within Facebook; I’m not entirely sure how widely such apps are used today, but either way, a regular website does not use any of the Canvas-related features.) The cost of including them in the SDK is pretty marginal: only 1.5% of total size.

After that, we have legacy feature support. This reflects the fact that an API will accumulate multiple interfaces for handling the same features over time. For example, developers can write code that calls either FB.getLoginStatus() (the legacy approach to requesting the user’s current Facebook login status) or Auth.getLoginStatus() (the new, encouraged approach). The way to get around needing to include both sets of methods is releasing them in separate versions of the SDK, but Facebook opted not to do this, likely to simplify the experience for developers and to maximize the number of sites using the exact same file (to increase the likelihood that the average user already has it downloaded). This decision comes at a small cost: roughly 3.5% of the SDK code is for handling features that are explicitly marked as “legacy” (and it’s quite possible that there are many more “legacy” features that just aren’t explicitly marked as such).

Most significantly, the SDK includes a number of polyfills and polyfill-like utilities, which make up over 15% of its code. Polyfills are used to supply features that are found in newer browsers to older browsers, and sometimes also to supply newer features that are upcoming but haven’t been added to any browsers yet. Most of the polyfills included by the Facebook SDK are for features that are already included in browsers used by the vast majority of internet users. They serve only to make the SDK work for the < 1% of global internet users who are using old browsers like Internet Explorer 8, which many (if not the vast majority of) major sites have given up on supporting.

Of the remaining ~80% of the SDK, it’s a bit more difficult to untangle which features are needed for which purpose. This is because it is written such that, to use a simple feature like the Like button, one must also include code that is used only for comments, video embeds, login buttons, and other unrelated features. Facebook could have opted to distribute much smaller files for including only single features such as Like buttons, but has a business goal of encouraging sites to use as many FB-provided features as possible.

Does size matter?

Due to the widespread use of Facebook’s SDK, and the fact that it changes relatively infrequently, many users are likely to have already downloaded it before they load a site. In fact, this is a big part of the rationale for why Facebook would distribute such a huge file, rather than smaller ones for specific features such as Like buttons. And on most users’ network connections — at least those in developed countries — the time it takes to download the file is marginal.

But regardless of whether the user’s browser already has the SDK downloaded, there is still overhead involved in running a large block of Javascript, especially on mobile devices. On the relatively new MacBook Pro I’m writing this on, Facebook’s SDK takes around 50ms (1/20th of a second), to run on a site like Buzzfeed. Not bad — especially when taken in context with the rest of the JS code, including ad-related code that takes far longer to execute — but still a non-trivial cost for something that is only used to display comments on the very bottom of the page.