
16% of the code on the average site belongs to Facebook - TazeTSchnitzel
https://medium.com/@BenRegenspan/why-16-of-the-code-on-the-average-site-belongs-to-facebook-and-what-that-means-68956cd731be
======
heipei
I've built my service [https://urlscan.io](https://urlscan.io) to some extent
to be able to track the impact of certain scripts / hosts on the overall size
of the website. You can find the breakdown by hostname under "Request Stats"
on the right. But, for this use case, it would be perfectly sufficient to use
the Chrome Devtools and filter by "facebook" for example.

Here is a scan where the 200KB Facebook sdk.js is being transferred (62KB
gzipped) just to display some like buttons. Repeat for other networks like
Twitter (114KB) and Google:
[https://urlscan.io/result/fa422ac0-3b2c-4ba7-a182-31921cc61e...](https://urlscan.io/result/fa422ac0-3b2c-4ba7-a182-31921cc61ea6).
Remember: Even if you don't mind the transfer of 200kB, that volume of
JavaScript will take some time to parse, especially on mobile.

~~~
onion2k
Facebook's like button code generator tool[1] includes the entire SDK even if
you configure it to _only_ show a like button with no other social graph
features. I guess there is an argument that having every site that uses
Facebook's API having the same .js file will take advantage of browser caching
better but it's still irritatingly wasteful.

[1] [https://developers.facebook.com/docs/plugins/like-
button](https://developers.facebook.com/docs/plugins/like-button)

~~~
eknkc
The caching argument is solid though. I think it's the best cached piece of js
after google analytics.

Should still affect the parse time and overall responsiveness of pages though.

------
personjerry
That title is misleading, the article clearly says "The SDK code is so big
that it represents about 16% of the total size of all Javascript on the
average web page." which is clearly not 16% the total site.

~~~
mercer
Was the title changed? As it is, it clearly says '16% of the code', and to me
that does imply only the javascript.

~~~
hn_throwaway_99
I think most people would consider HTML and CSS "code", too. Why would you not
count HTML if it's in its own file, but assuming you would count it if it was
JSX returned from a React component?

~~~
colejohnson66
Probably because technically HTML isn’t so much code as it is a markup
language

~~~
igravious
This seems intuitively to be the case but I wonder what others think. Neither
HTML not CSS have your regular programming language constructs like loops and
state and what have you. I sometimes teach very basic web tech to
arts/humanities students and I tend to make a static versus dynamic
distinction for them between HTML/CSS on the one hand and JS on the other
because to them it's all "codey stuff" but to me there's an important
distinction. I'm happy to take on board other perspectives here.

~~~
SyneRyder
_> This seems intuitively to be the case but I wonder what others think._

I've not clicked through the article, but before I saw any comments here, I
thought it was claiming that 16% of the HTML on the average site was devoted
to Open Graph Stories markup, like / share buttons, and other embedded FB
widgets.

(But that was already primed in my mind, as a couple of days I'd been
examining the source of a website that had a ludicrously huge Head section,
and it was filled with Facebook sharing markup.)

~~~
mercer
Interesting. I would have never assumed as you did precisely because 16% of
markup is a drop in the bucket compared to 16% of code (or CSS, even).

------
seanwilson
Is there a good reason Facebook's JavaScript file for websites is 400K? Is it
unoptimised? Is this just what happens in large companies? Does it do more
than you'd think? I would have thought they'd have an incentive to make it
fast and lean so people could comment and like faster.

~~~
benregenspan
It's 200KB minified, 60KB gzipped, so not quite that bad but still quite
large. It definitely does more than you'd expect from the documentation on a
page like [https://developers.facebook.com/docs/plugins/like-
button](https://developers.facebook.com/docs/plugins/like-button), and then
there's all the other stuff I noted in OP like it including a ton of polyfills
and legacy code.

An example feature the SDK gives you is the ability to subscribe to an event
that's triggered once the user successfully adds a Like, there's all kinds of
extra stuff like that buried in there that you wouldn't expect when you just
want to add a Like button.

~~~
derefr
> subscribe to an event that's triggered once the user successfully adds a
> Like

A.K.A. the "like this page in order to enable the download link below" API. I
wish they'd never made it; it has so many evil use-cases and I can't think of
a single non-evil one (that wouldn't be better served by just async querying
aggregate data.)

~~~
eknkc
I don't think that you can easily check if the user already liked your page so
that approach would not work.

~~~
derefr
Right, that was my point—if only an async+aggregate-statistical API for likes
to a page was exposed, you wouldn't be able to implement [accurate] like-
gating in terms of that (i.e. you wouldn't be able to be Evil), but you'd
still be able to do most other things people use the like-button API for, like
showing current number of likes (i.e. not Evil).

------
exodust
I just use open graph tags on websites, which are more useful, lightweight and
makes the link presentable and customisable when shared around Facebook.
There's no downside to open graph tags.

Website 'Like' buttons on the other hand, are useless, tacky, cheap and
chunky. Nobody cares how many likes your webpage has. The number means nothing
because your website might be one month old with '2k likes', or two years old
with '500 likes'. Makes zero difference to any visitor what that number is.
It's not any measure of performance or anything.

This is what I tried telling the project managers at my previous work, but of
course such advice fell on deaf ears, and in went the FB crap.

~~~
seanwilson
> Website 'Like' buttons on the other hand, are useless, tacky, cheap and
> chunky. Nobody cares how many likes your webpage has.

Google have said Facebook likes aren't treated as a ranking signal but your
page showing up on newsfeeds will bring in more likes and more backlinks.

> Makes zero difference to any visitor what that number is. It's not any
> measure of performance or anything.

You don't think a large number of likes makes a page look more newsworthy than
a page with zero likes?

~~~
exodust
But what is a "large number"? Not all FB users will click the like button on a
website, or expect it to be there, because the website is not a Facebook page.
The number of likes is not a traffic measurement, it doesn't represent the
website popularity.

I completely understand the newsfeed point, which is why I have no argument
against social sharing buttons on websites - the non-scripted kind that link
to various services from Twitter to Reddit to FB. If the user wants to share
the site, they will use this method, or they may copy the link, or have some
other way to like the page such as a browser extension.

"Like us on Facebook" is what Likes are about. You go to Facebook, and you
Like something - a post, page or item. It's a Facebook thing, not a
"everything in the universe" thing.

------
apostacy
I noticed that when I tried ordering food off www.seamless.com, I could put
together an order, but the checkout process would fail in the final step.

It turns out, it was because I had blocked *.facebook.com.

I do not like that major websites will break, if Facebook is blocked. My
business with Seamless had nothing to do with Facebook. Facebook does not need
to know that I am ordering food. Especially if I am not even logged in.

Why can't I simply say "no" to all interaction with Facebook?

Also, try firewalling Google Analytics, and see how much of the web breaks.

------
spraak
The author's avatar as a gif is very distracting :/

------
fencepost
Possibly of interest though not of much use to your end users: Decentraleyes
local CDN emulation

[https://decentraleyes.org/](https://decentraleyes.org/)

------
tyscorp
I mistakenly assumed this was going to be about the React PATENTS file.

~~~
ballenf
I, too, expected to read about all the open source projects from FB.

Always surprises me how often the React devtools icon lights up indicating a
React-based site. Maybe there are false positives, never investigated.

I don't really follow who's using React, but was surprised to see it on
Dropbox.com.

Wonder how high the percentage would be if it included the library code for
all FB projects?

------
dingo_bat
So I just wanna know if ublock origin blocks all this or not.

~~~
wodenokoto
It does if you subscribe to the tracker list.

------
em3rgent0rdr
> "If you need to use a feature like Facebook Comments, there’s no getting
> around the need to load the Facebook SDK."

Actually, you can import facebook comments directly into your sites internal
commenting system. There's an opensource plugin in wordpress to do this. Then
visitors aren't bogged down by loading facebook comments, since those are
already integrated in.

------
benlorenzetti
An excellent data point for the argument toward ending ``Net Neutrality''

------
jordan801
Pretty click bait.

------
mdekkers
I stopped reading after about 30 seconds. "Ben Regenspan" \- the author of the
piece didn't get the memo that the <blink> tag was removed from the HTML spec
because _it annoyed the hell out of every single person on planet earth_ and
decided that some annoying little blinking gif was the right profile picture
on Medium. Distracting and annoying as anything, so stopped reading.

