Why Facebook Like buttons account for 16% of an average website’s code
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:
Of the sets of features, three stand out the most:
“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.
On a very new smartphone (Google Pixel), the JS execution time is doubled, now taking over 1/10th of a second:
When looked at in context, this is a tiny fraction of the total code execution time on the page. But it adds to the amount of time during which scrolling or otherwise interacting with the page can be a choppy and unpleasant experience. And this gets at an important point: this particular SDK has a marginal cost, but modern websites — especially media sites — often include similar code from a large number of third parties (this example I captured from Gawker before it was killed by a billionaire vampire shows just how many such requests there can be).
Even setting aside the privacy impact of sending some user information to each of these third parties, the cost of all these features adds up quickly. Each third-party script that a site adds comes at a cost, both in terms of performance and in helping to rationalize the addition of the next “relatively harmless” chunk of third-party code later on. Besides the immediate performance impact of the additive cost of all of this code, this impacts developer morale: imagine working for days to shave off 10% of your own code’s load time, only to see a giant block of third-party code added that dwarfs the impact of that painstaking effort. And then (if you work for a media site), seeing this same pattern repeat itself over and over again every few months.
Should you include it?
If you need to use a feature like Facebook Comments, there’s no getting around the need to load the Facebook SDK. But depending on how your site is structured, you may be able to limit the SDK’s performance impact by only loading it when needed (e.g. once the user has scrolled down to the point where comments should become visible).
If you want to use the Like button, stop and reconsider. Facebook no longer displays Likes of a page prominently (or, in most cases, at all) on user timelines. It’s better to use a simple custom Share button or link, and as a side benefit, doing so will prevent Facebook from tracking all visits to your page and interfering with the privacy of your users. Sites that have eliminated the Like button have failed to identify any negative impact of doing so when it comes to Facebook traffic referrals.