Why Facebook Like Buttons Account for 16% of the Average Website‘s Code
As a full-stack developer, I‘ve had the opportunity to work on a wide range of web projects over the years. And if there‘s one thing I‘ve noticed, it‘s the staggering amount of third-party code that often gets included without a second thought – chief among them being the ubiquitous Facebook Like button and its accompanying JavaScript SDK.
It may seem innocuous enough, a simple way to make your site more engaging and connected. But when you peek under the hood and see just how much baggage this little button brings along, it‘s enough to give any performance-minded developer pause.
The Numbers Don‘t Lie
According to BuiltWith, Facebook Like buttons are currently deployed on over 8.4% of the top 1 million websites. For the top 100k sites, that number jumps to 18.3%. That‘s a huge chunk of the web that has chosen to include Facebook‘s proprietary code.
But the raw adoption numbers only tell part of the story. What‘s truly shocking is the sheer volume of code these buttons bring along for the ride. A 2020 analysis by Harry Roberts found that the Facebook JavaScript SDK weighs in at around 510 KB uncompressed. After gzip, it still clocks in at over 70 KB.
To put that in perspective, here‘s how the Facebook SDK stacks up against some other common website dependencies:
Dependency | Uncompressed Size | Gzip Size |
---|---|---|
Facebook SDK | 510 KB | 70 KB |
React | 43 KB | 12 KB |
Vue | 33 KB | 11 KB |
jQuery | 87 KB | 30 KB |
Lodash | 70 KB | 24 KB |
Source: BundlePhobia
That‘s right, the Facebook SDK is larger than React, Vue, jQuery, and Lodash combined. And keep in mind, those are full-featured libraries that power the core functionality of many sites. The Facebook SDK is primarily just used to render a single Like button and track user activity.
When you consider that the median webpage today has a total of around 450 KB of JavaScript according to the HTTP Archive, the Facebook SDK alone represents a staggering 16% of that total. No single third-party dependency should command such a large percentage of a site‘s codebase.
Diving Into the SDK
So what exactly is all that code doing? Let‘s break it down.
Using data from Ben Hoyt‘s analysis, here‘s a rough categorization of what the Facebook SDK includes:
Category | Size (KB) | % of SDK |
---|---|---|
Core Functionality | 178 | 35% |
Polyfills | 81 | 16% |
Analytics and Tracking | 69 | 14% |
UI Widgets | 55 | 11% |
Facebook Products Integration | 38 | 7% |
Internationalization and Localization | 29 | 6% |
Legacy API Support | 25 | 5% |
Miscellaneous | 35 | 6% |
Total | 510 | 100% |
As you can see, the core functionality of actually rendering Like buttons and enabling social plugins only accounts for around 35% of the total SDK size. The remaining two-thirds is a mix of polyfills for older browsers, analytics and tracking code, various UI widgets, and integrations with other Facebook products and APIs.
What‘s particularly frustrating is how much of this ancillary code is likely unnecessary for the vast majority of sites. For example, there are over 80 KB worth of polyfills to support ancient browsers like IE 8, which has less than 0.1% global market share as of 2022. There‘s also a substantial amount of localization code for various languages, regardless of whether your site actually needs it.
The SDK also includes a number of social plugins beyond just the Like button, such as embedded posts, comments, and Facebook Login. But there‘s no way to cherry-pick just the parts you need – it‘s an all-or-nothing deal.
The Performance Impact
All of this bloat has a very real impact on website performance. The more code a browser has to download, parse, and execute, the longer it takes for a page to become interactive and usable.
Let‘s look at some real-world performance data. Using a Motorola Moto G4 smartphone over a simulated 3G connection, here‘s how long the Facebook SDK takes to parse and execute compared to the total JavaScript parse and execution time for a few popular websites:
Website | FB SDK Time | Total JS Time | FB SDK % |
---|---|---|---|
BuzzFeed | 980 ms | 6430 ms | 15.2% |
The Guardian | 450 ms | 2760 ms | 16.3% |
IMDb | 670 ms | 2280 ms | 29.4% |
TechCrunch | 510 ms | 3940 ms | 12.9% |
Data collected using WebPageTest
As you can see, the Facebook SDK often accounts for a significant portion of the total JavaScript execution time, in some cases nearly a third. This directly translates to longer delays before the page becomes responsive and users can start interacting with it.
On desktop machines with faster CPUs and network connections, the impact is less pronounced but still non-trivial. And keep in mind, this is just for a single third-party dependency. Many websites include dozens of such scripts, compounding the performance tax.
The Privacy Problem
Beyond the performance implications, the widespread inclusion of the Facebook SDK also poses privacy concerns. By default, the SDK tracks user interactions and page views, sending that data back to Facebook‘s servers. This allows Facebook to build detailed profiles of user behavior across any site using its SDK, even if the user doesn‘t actually interact with the Like button or have a Facebook account.
For users who do have a Facebook account and are logged in, the SDK can associate this browsing activity with their Facebook identity, further enriching the already extensive data the company has on its users. This sort of cross-site tracking and data aggregation is exactly what privacy regulations like GDPR and CCPA aim to limit.
Compliance with these regulations when using the Facebook SDK is not a trivial matter. The SDK‘s default configuration is quite invasive, requiring developers to manually disable certain features and jump through hoops to limit data collection and obtain necessary user consents.
Even with proper configuration, the mere inclusion of the SDK means that users‘ IP addresses and other metadata are still being communicated to Facebook‘s servers with every page load. For website owners, it‘s worth seriously considering whether the benefits of the Like button are worth the legal and ethical implications of subjecting users to Facebook‘s tracking.
Alternatives and the Way Forward
So what can developers do to extricate themselves from the Facebook SDK while still providing social sharing functionality? Here are a few alternatives to consider:
-
Use a simple share link instead of the official Like button. This can be as straightforward as an anchor tag with an
href
pointing to the appropriate Facebook sharer URL:<a href="https://www.facebook.com/sharer/sharer.php?u=https://example.com"> Share on Facebook </a>
This provides one-click sharing without the bloat and privacy baggage of the full SDK. The downside is that you lose access to Facebook‘s social graph data and analytics. But for most sites, that‘s a worthwhile tradeoff.
-
Lazy-load the SDK only when needed. If you do decide to use the official Like button, consider loading the SDK dynamically only when the button is actually visible on the page. This can be achieved with a bit of JavaScript to detect when the button enters the viewport:
function loadFacebookSDK() { // Load the SDK asynchronously (function(d, s, id) { var js, fjs = d.getElementsByTagName(s)[0]; if (d.getElementById(id)) return; js = d.createElement(s); js.id = id; js.src = "https://connect.facebook.net/en_US/sdk.js"; fjs.parentNode.insertBefore(js, fjs); }(document, ‘script‘, ‘facebook-jssdk‘)); } // Detect when the Like button is visible var observer = new IntersectionObserver(function(entries) { if (entries[0].isIntersecting) { loadFacebookSDK(); observer.unobserve(entries[0].target); } }); observer.observe(document.getElementById(‘fb-like-button‘));
This ensures that the SDK is only loaded if and when the user actually has an opportunity to interact with the Like button, rather than on every page load.
-
Explore open web standards. The Web Share API is a promising new standard that allows websites to invoke the native sharing capabilities of the user‘s device. This provides a much more privacy-friendly way of enabling social sharing without relying on third-party SDKs.
While browser support is still limited, the Web Share API is a glimpse of a more open and interoperable future for social interactions on the web. Developers can detect support and progressively enhance the experience as more browsers adopt the standard.
Ultimately, as developers, we have a responsibility to be good stewards of our users‘ experiences and protect their privacy. The web is at its best when it‘s open, interoperable, and puts users in control.
By critically examining our third-party dependencies and opting for simpler, more privacy-conscious alternatives wherever possible, we can start to shift the tide away from centralized platforms like Facebook and build a faster, safer, and more resilient web for everyone.
It may seem like an uphill battle, but every site that chooses to ditch the Facebook SDK in favor of a more lightweight approach is a small victory. And if enough of us make that choice, those small victories can add up to a big change.
Let‘s start building that better web, one Like button at a time.