Hacker News Reader

Comment by seanwilson | Hacker News Reader

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.

View on HN

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.

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.

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

Reply on news.ycombinator.com