6 ms·

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

190 points by TazeTSchnitzel 9y ago

seanwilson 9y ago
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 9y ago
  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 9y ago
    > 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 9y ago
      I don't think that you can easily check if the user already liked your page so that approach would not work.
      - derefr 9y ago
        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).
    - ssttoo 9y ago
      This "likegating" is against the terms of use
  - ssttoo 9y ago
    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 :)
- deleted 9y ago
  [deleted]
- ktRolster 9y ago
  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.
  - colejohnson66 9y ago
    Well, there is that instant search feature that starts showing results once you start typing.
    - microcolonel 9y ago
      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).
      - ktRolster 9y ago
        Here you go, I uploaded an image of the file transfers showing just the html and javascript: https://imgur.com/a/aTpj2 https://imgur.com/a/aTpj2
        microcolonel 9y ago
        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.
  - foepys 9y ago
    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.
    - 9y ago
spraak 9y ago
The author's avatar as a gif is very distracting :/
personjerry 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      Probably because technically HTML isn’t so much code as it is a markup language
      - igravious 9y ago
        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 9y ago
        > 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.)
dingo_bat 9y ago
So I just wanna know if ublock origin blocks all this or not.
- wodenokoto 9y ago
  It does if you subscribe to the tracker list.
jordan801 9y ago
Pretty click bait.
exodust 9y ago
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.
- BinaryIdiot 9y ago
  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.
  - exodust 9y ago
    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).
    - BinaryIdiot 9y ago
      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.
fencepost 9y ago
Possibly of interest though not of much use to your end users: Decentraleyes local CDN emulation https://decentraleyes.org/ https://decentraleyes.org/
heipei 9y ago
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-31921cc61ea6 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.
- onion2k 9y ago
  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 9y ago
    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.
  - ssttoo 9y ago
    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
tyscorp 9y ago
I mistakenly assumed this was going to be about the React PATENTS file.
- ballenf 9y ago
  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?
- coding123 9y ago
  Same here... We can probably add another 5% to account for that
em3rgent0rdr 9y ago
> "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.
mdekkers 9y ago
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.
benlorenzetti 9y ago
An excellent data point for the argument toward ending ``Net Neutrality''
apostacy 9y ago
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.

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 9y ago
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 9y ago
  > 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 9y ago
    I don't think that you can easily check if the user already liked your page so that approach would not work.
    - derefr 9y ago
      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).
  - ssttoo 9y ago
    This "likegating" is against the terms of use
- ssttoo 9y ago
  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 :)
deleted 9y ago
[deleted]
ktRolster 9y ago
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.
- colejohnson66 9y ago
  Well, there is that instant search feature that starts showing results once you start typing.
  - microcolonel 9y ago
    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).
    - ktRolster 9y ago
      Here you go, I uploaded an image of the file transfers showing just the html and javascript: https://imgur.com/a/aTpj2 https://imgur.com/a/aTpj2
      - microcolonel 9y ago
        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.
- foepys 9y ago
  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.
  - 9y ago

spraak 9y ago

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

personjerry 9y ago

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 9y ago
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 9y ago
  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 9y ago
    Probably because technically HTML isn’t so much code as it is a markup language
    - igravious 9y ago
      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 9y ago
        > 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.)

dingo_bat 9y ago

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

wodenokoto 9y ago
It does if you subscribe to the tracker list.

jordan801 9y ago

Pretty click bait.

exodust 9y ago

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.

BinaryIdiot 9y ago
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.
- exodust 9y ago
  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).
  - BinaryIdiot 9y ago
    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.

fencepost 9y ago

Possibly of interest though not of much use to your end users: Decentraleyes local CDN emulation https://decentraleyes.org/ https://decentraleyes.org/

heipei 9y ago

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-31921cc61ea6 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.

onion2k 9y ago
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 9y ago
  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.
- ssttoo 9y ago
  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

tyscorp 9y ago

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

ballenf 9y ago
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?
coding123 9y ago
Same here... We can probably add another 5% to account for that

em3rgent0rdr 9y ago

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

mdekkers 9y ago

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.

benlorenzetti 9y ago

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

apostacy 9y ago

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.