Comment by djeric3 | Hacker News Reader

Comment by djeric3 | Hacker News Reader

Parent Full thread

Facebook already only ships code that is needed to render the current page. It even goes further and it streams the code in phases so that the browser renders the UI incrementally and the page becomes interactive as soon as possible. It then pulls in code dynamically for any secondary feature only if the user interacts with that feature.

Some of the design is documented here https://www.facebook.com/notes/facebook-engineering/bigpipe-...

Facebook has done a TON of optimization. The fundamental issue is that Facebook is not a webpage, it's a full application. And the Web as an application platform lags behind native platforms with respect to startup performance.

I explained why Facebook.com is really an app in this comment https://news.ycombinator.com/item?id=14912393

Now compare the functionality of the Facebook Android app vs Facebook desktop webpage (nearly identical) and look at their respective installed sizes (~7MB vs ~180MB).

This proposal will benefit both web apps and web documents. And more importantly, it will allow people to build richer, more sophisticated applications on the web without sweating over extra kilobytes in their JS code size.

Most of the code doesn't have to be loaded immediately. For example, you write in your comment, that Facebook can play 360 degrees videos, but the player doesn't have to be loaded until the user tries to play such a video.

I decided to look at Facebook code more closely. It is modular and contains several thousand of small modules. For example, on a news feed page the browser has loaded 66 JS files with total size of 5.7Mb containing 3062 modules [1].

But it is clear that many of those modules are not necessary to display a page. For example, a module with a name "XP2PPaymentRequestDeclineController" that is probably related to payments is not necessary. Or a module with a name "MobileSmsActivationController". Obviously Facebook preloads a lot of code for different dialogs that might be unused most of the times the page is loaded.

Of course I understand that it is very difficult to optimize code when a large team is contantly writing new code and everybody has strict deadlines so there is no time for optimizations, especially if they require serious refactoring.

[1] https://gist.github.com/codedokode/cb506cee367bdb9e1071bc186...

Facebook.com today loads functionality dynamically. Open the Network panel, interact with a secondary feature, and you will see it load code on-demand.

With respect to your example of unnecessary modules, sometimes the dependency trees between modules are non-obvious. But more to the point, the code served to a user is NOT personalized for each individual user and to their specific newsfeed and UI contents. This is actually a performance optimization. Facebook looks at which modules are most commonly required across most users based on their recent activity, and then bundles those common modules into large packages and pushes them aggressively to the browser. This actually results in a very large loading-time win, but ends up overserving some % of extra modules that are not needed by a specific user.

Reply on news.ycombinator.com