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