Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

medium.com

Post reply on HN
Print view View original

1–10 of 54 posts

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

#2

Post by 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.

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

#3

Post by benregenspan »

seanwilson wrote: post #2

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.

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

#7

Post by derefr »

benregenspan wrote: post #3
seanwilson wrote: post #2

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 on…

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

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

#9

Post by [deleted] »

seanwilson wrote: post #2

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.

[deleted]

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

#10

Post by 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.

Post reply on HN