16% of the code on the average site belongs to Facebook | Hacker News Reader

16% of the code on the average site belongs to Facebook

medium.com

190 pointsTazeTSchnitzel51 comments

I've built my service 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.... Remember: Even if you don't mind the transfer of 200kB, that volume of JavaScript will take some time to parse, especially on mobile.

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

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.

the configurator on that page generates: 1/ sdk+like button or 2/ just an iframe with no sdk

1/ is better (proper resizing in different locales) but 2/ is always an option and it saves 60K of JS

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.

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

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?

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

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.

> 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.)

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).

Turing incomplete code (sql, bpf, agda) is code. ergo markup is code. imo, ymmv.

html not code. css maybe. the pedant has spoken, so it shall be, in my mind

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.

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, 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.

> 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.)

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

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).

This "likegating" is against the terms of use

There's a certain amount of legacy code, because the SDK supports old browsers. Therefore it needs polyfills. And it cannot rely on, say `if ('JSON' in window){}` because there are buggy polyfill implementations out there. So the SDK needs to bring its own polyfills.

Additionally it cannot just do `Array.prototype.map = ...` because fiddling with the host page's globals is a sin. Hence every post-ES3 method call is wrapped in a local `ES()` function. Oh the joys of third-party javascripting :)

You should check out Google's homepage sometime. One wouldn't expect that such a simple front would hide so many k of Javascript, but I guess it does a lot.

On my 2016 MBP Google keeps a constant 20% load on a single core. Sometimes it's even up to 60%. I really don't know what Google is doing there.

Mining bitcoins? :-D

Well, there is that instant search feature that starts showing results once you start typing.

That's gone actually, they removed it a few weeks ago IIRC. I don't use Google though, not sure if it's still enabled in some places. In fact, I'm not really sure what ktRolster is talking about; it is 150KiB, but honestly that's pretty small for a page these days, especially one with any images (today it's a google doodle, so normally it would be about 24KiB smaller).

Here you go, I uploaded an image of the file transfers showing just the html and javascript:

https://imgur.com/a/aTpj2

Ahh, now I see. I had cookies disabled, which apparently changes everything. It's something more like 480KiB for me now. Yikes, such a simple page.

I wonder how much is in a typical person's cache though.

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.

Makes zero difference to any visitor what that number is.

The overall number may have no value (although social capital theory would suggest otherwise), but when a user looks at a Facebook page and sees "5 of your friends Liked this page" with a list of who they are, that has a huge impact on how they think. It's like having a personal recommendation. That's worth a lot. Likes do have value.

That information is better kept within Facebook. If you're already on the page, why does it matter to notice only then that some of your friends like it?

Your point is not entirely accurate though. The likes get displayed and used on Facebook which can help and your post to the top of other people's feeds.

I don't like them either but you'd be crazy by not integrating it on a website that you're trying to funnel organic, social traffic to.

It's not the website's job to host Facebook-exclusive functionality.

By all means have the basic FB share link, as found on every Youtube video, along with other social media services. But the actual Facebook widget is not what should be installed on websites, and FB should kill it dead.

Sounds like you need a browser extension to handle "liking" the current page you're on. Not all websites have the Like button, so it makes no sense to assume a website Like button is "plan A" in any social traffic strategy.

Further more, websites have many pages. It's impractical to install a Like button for every discrete piece of content everywhere on the site, and everywhere on the Internet.

Facebook Like buttons DO NOT belong on every web page of every site on the Internet, and the widget should go the way of Flash. (I'd sooner keep Flash than FB javascript).

I get you but that’s just idealistic. Today you have to do it to help your social engagement. Every opportunity you can get to gain more likes you have to take to get your social postings to rank higher.

I'm sure spammers apply same logic.

> 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?

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.

That's a slight chicken/egg problem. Most websites don't have like buttons with counters, so most people probably aren't going to use it as a signal anyways. If you do have a high amount of likes there may be some benefit to using it, but how are you going about getting those likes without the button there in the first place?

> Website 'Like' buttons on the other hand, are useless, tacky, cheap and chunky.

I disagree. Remember those visitor counters on most hobbyist websites from back in the day? Facebook likes are, are their core, that.

It's basically herd mentality.

The old counters recorded every visitor. FB likes record only FB users who are logged in, wish to share the page, and bother clicking the button. Huge difference, no correlation.

As a final thought... At least Twitter invented a word for their sharing action, "retweet". Facebook just stole "like" and "thumbs up". I don't remember those things being up for sale.

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.

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

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

https://decentraleyes.org/

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

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?

Same here... We can probably add another 5% to account for that

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

It does if you subscribe to the tracker list.

> "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.

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

Pretty click bait.

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.

Reply on news.ycombinator.com