
Netflix: Removing client-side React.js improved performance by 50% - pjmlp
https://twitter.com/NetflixUIE/status/923374215041912833
======
clarle
Hey, I work on the team at Netflix that gave the talk on React in the signup
flow in the tweet.

The full talks are available here if people want to watch them:

[https://www.youtube.com/watch?v=V8oTJ8OZ5S0&t=11m30s](https://www.youtube.com/watch?v=V8oTJ8OZ5S0&t=11m30s)

Thought I'd also provide some more context on some common questions that
people have asked.

### Why are you using React to render a landing page?

The Netflix landing page is a lot more dynamic than most people think it is.

It's our most heavily A/B-tested page in the signup flow, with even some
machine learning models being used to customize the messaging and imagery that
you get depending on location, whether or not you were a previous Netflix
member, device type, and a lot more. Even beyond that, Netflix supports almost
200 countries now, and there's a different combination of localization, legal
challenges, and value messaging for each one. We end up sharing a lot of the
logic and UI for these A/B testing and localization challenges throughout the
signup flow, mainly through React components.

The example I always love to give is the <TermsOfUse/> component that we have,
which to a Netflix customer signing up is literally one or two checkboxes on
the UI, but has some of the most complicated logic in the codebase due to the
vast number of countries and user states we support. Because of all this, it's
more valuable for us to share these common React components across the entire
signup process, both the landing page and the rest of the flow, which is a
single-page React and Redux application.

We've seen a lot of conversion value though in improving the performance of
the landing page, especially in countries with slower connections, but we
don't also want to re-duplicate a lot of the shared UI logic that we have.

The tradeoff that we decided to make is to server-render the landing page
using React, but also pre-fetching React / Redux / the code for the rest of
the signup flow while on it. This optimizes first load performance, but also
optimizes the time to load for the rest of the signup flow, which has a much
larger JS bundle size to download since it's a single-page app.

### What's the performance metric that's being used?

It's TTI (Time to Interactive), when the user can fully interact with the
page. This is different than TTR (Time to Render) for us, when the user can
fully view the page. There's more information in the talk about the
differences.

### Why not Service Workers or some other pre-loading / caching mechanism?

We have been experimenting with it, but it's mainly the lack of some browser
support - Safari is the main one. Generally the Netflix signup flow needs to
have more legacy browser support than the Netflix member experience. Lots of
people sign up on a pretty old browser, but only ever watch Netflix on the
native mobile apps or a TV device.

#####

Feel free to comment here or tweet at Tony
([https://twitter.com/tedwards947](https://twitter.com/tedwards947)) or me
([https://twitter.com/clarler](https://twitter.com/clarler)) if there's any
other questions that we can help answer.

Though from a lot of experience, 140 characters isn't always enough to provide
enough context for JavaScript framework discussions. ;)

If these sort of performance and UI challenges seem interesting to you, our
team is also hiring for UI engineers and an engineering manager!

* Senior Software Engineer (React, Node): [https://jobs.netflix.com/jobs/864767](https://jobs.netflix.com/jobs/864767)

* Senior Software Engineer (Android): [https://jobs.netflix.com/jobs/864766](https://jobs.netflix.com/jobs/864766)

* Engineering Manager: [https://jobs.netflix.com/jobs/865119](https://jobs.netflix.com/jobs/865119)

Cheers!

~~~
spicyj
I work on React. We’d love to hear from your team sometimes and collaborate on
this sort of thing. We’re solving many of the same problems but I rarely hear
from Netflix engineers except at talks when announcing they’re avoiding React
or have forked it, often for reasons we weren’t even aware of.

~~~
error54
Hey spicyj!

I'd love to sit and talk React with you and your team. We're always
particularly interested in performance optimizations so maybe we can swap some
knowledge.

Not aware of any team that is actively avoiding React but we're a fairly
prolific bunch when it comes to public speaking and knowledge sharing so
perhaps I missed some announcement from another UI team. A few of my
colleagues will be speaking at the SFHTML5 meetup[1] in a few weeks if you'd
like to come hang out and talk shop or feel free to drop me a line at
jem@netflix.com :).

1 -
[https://www.meetup.com/sfhtml5/events/244074642/](https://www.meetup.com/sfhtml5/events/244074642/)

------
christophilus
I was at the All Things Open conference this week, and Yehuda Katz gave a talk
on Glimmerjs[0].

It was enlightening. The size of your front-end application is generally
dominated by view code. So, they precompile views into a super simple set of
binary VM instructions (making your views very compact). These views don't go
through the JS compile / parse phase on the client (saving hundreds of ms, up
to seconds on slow devices). They are instantly executable by a small VM
written as a JS library, and can be streamed in and rendered as they arrive
(the way plain ol' HTML pages do). Turns out to be hella fast, but still gives
the benefit of rich client-side rendering capabilities.

[0] [https://glimmerjs.com/](https://glimmerjs.com/)

~~~
alessioalex
If I'm not mistaken Angular 2+ also has this. It's named AOT compilation
(ahead of time).

Edit: so does Vue if you're using vueify
([https://github.com/vuejs/vue/issues/4272](https://github.com/vuejs/vue/issues/4272)).

~~~
christophilus
It's not the same, though. Those are compiling textual templates into
executable JavaScript. React/Preact do this automatically, too.

What Glimmer does is it converts your views into bytecode (not JavaScript)
which can be streamed and run without a JavaScript compilation / parsing phase
in the browser. Vue, React, and Angular views all ultimately are translated
into JavaScript which has to be compiled / parsed in each browser.

~~~
1_player
I'll have a look at Glimmer later, but who executes this bytecode?

~~~
dean
> They are instantly executable by a small VM written as a JS library

Guess you have download the VM on initial page load.

~~~
christophilus
Yes. It's about 18KB of JavaScript.

------
33degrees
It's worth watching the video to understand the context:
[https://youtu.be/V8oTJ8OZ5S0?t=1012](https://youtu.be/V8oTJ8OZ5S0?t=1012)

~~~
cptaj
Definitely worth it just to learn about the prefetch API and the XHR prefetch
technique

------
throwaway2016a
Sounds like form the comments they still use React they just defer loading it
until after the page is otherwise usable.

I think this is a fairly common use case for server-side rendering in React
and I wonder how much of this improvement they would have seen just by SSRing
the page and putting the React scripts at the end instead of the header (or
using defer). This is the strategy I use with any React marketing type pages.

Edit:

Just to give more detail incase anyone is wondering, usually marketing pages
are relatively the same for every user (unless you are doing identity based
personalization or a/b testing) so often you can get away with pre-rendering
all the HTML generated by the React. Then you don't even need to load React
server side, you just serve up a static file.

~~~
devrandomguy
Yep, and personalization and A/B testing can be accommodated with query
params. By whitelisting those AB params in the caching layers, you can mostly
prevent a performance difference between A and B, something that may have
messed up our results with a 3rd party AB testing service.

------
zengid
Even facebook acknowledges that React should only be used when complex
interactivity is more important than initial load-times:
[https://youtu.be/TMun9g5o7OA?t=47m28s](https://youtu.be/TMun9g5o7OA?t=47m28s)

------
Raphmedia
Well, of course it will. You are trading loading an entire application for
loading a static page.

I'm always amazed at those devs who load entire applications framework when
their end goal is to have a slider at the top of a page.

~~~
Radle
"static page"

~~~
Raphmedia
You are very much right:
[https://news.ycombinator.com/item?id=15568305](https://news.ycombinator.com/item?id=15568305)

------
dustingetz
If you get your SSR right, you can just not serve javascript for landing pages
and readonly dashboard type things. This is what Hyperfiddle does - all
readonly things work 100% with javascript disabled (try disabling it in the
dev tools)

[http://hyperfiddle.net](http://hyperfiddle.net)

------
mosselman
I like how the people in replies to the top tweet seem to get angry at someone
implying that React is not great.

~~~
detaro
For me they mostly show people asking for numbers and people making fun of
them for using React for a boring landing page.

~~~
nindalf
You find what you expect to find.

------
FLGMwt
From the slides, it looks like the performance metric in question was TTI
(Time to Interactive).

------
positivecomment
Today we learned: Removing an advanced library from a simple project increases
performance.

Sorry for being sarcastic but don't you also find this too obvious?

~~~
danvasquez29
I think it's the 50% part that we're meant to pay attention to. For me that's
a pretty drastic, "why would you ever put this on the client side now that you
know this" kind of thing.

~~~
brokentone
Because it provides a robust, consistent, isomorphic framework which many
people have decided that certain benefits (for us common tooling, maintenance,
consistent implementation across the org, write once run twice isomorphism)
outweigh the costs (interactable time, download size, etc). Everyone has to
make their own choices, but this news was not surprising and did not change
our opinion.

~~~
falcolas
Playing devil's advocate for a moment:

So, the developer experience trumps the user experience, in an industry where
fractions of a second of load time can cost a company customers and
conversions?

~~~
cynicalreason
'premature optimization', build it first, optimize later, react helps a lot
with the first part

~~~
agentultra
There is such a thing as _premature pessimization_ : making choices based on
intuition about productivity benefits or personal taste that force you down
the road to poor performance.

I think it's smart to include performance requirements in your specifications
before starting a project (or when taking on the maintenance of one too). Set
an upper limit on your TTI or server response times. Turn it into a budget.
That's not optimization that's just engineering.

------
drinchev
> ...improvement on our landing page

React on a landing page sounds like an overkill to begin with.

~~~
tyingq
In the talk they say they are still using react server side to make this
mostly static page. I suppose with some cache in front of it though.

~~~
romanovcode
So basically they write React in front-end, then use react-renderer to
generate static HTML and then serve it from back-end?

Seems like with this speed JS frameworks are going full-circle back to back-
end rendering soon enough.

~~~
megaman22
Everything is a circle in web development. It appears to take about five to
ten years for developer personnel to turn over close to 100%.

And so the cycle continues, with old ideas dusted off or rediscovered, the
original flaws in them rediscovered, the reaction to those flaws, traveling
well-trodden paths, then the reaction to the reaction, "best practices"
shaking out, an explosion of complexity, and then someone burns down the
baroque cathedral of ideas with, if we're lucky, a slightly less flawed
version of the original old idea.

I've now done ASP.NET long enough to see WebForms come in, reach high tide,
recede before the new hotness of MVC, MVC decline in favor of WebApi with
monstrosities of JS frameworks in front of it, and now Razor Pages are coming
back in as a simpler alternative, with concepts that an old WebForms developer
from fifteen years ago wouldn't raise an eyebrow at.

~~~
romanovcode
Actually that is exactly what I thought when they introduced RazorPages as
well.

I really like .NET Core but this RazorPages is just single worst "improvement"
for the .NET Core platform.

I even remember watching the presentation on BUILD conference and nobody
applauded at this "feature" when they graciously introduced it and you could
feel the cringe. Scott even had to say "Isn't this awesome!?? Come on!".

No, Scott, it's not awesome. It's going backwards.

------
thosakwe
This is what we need for LinkedIn. I am yet to see a slower site.

~~~
zengid
I think they use Ember:

[https://engineering.linkedin.com/blog/topic/ember](https://engineering.linkedin.com/blog/topic/ember)

------
retrac98
Yup, the Twitter replies are pretty much what I expected. This tit-for-tat JS
pissing contest is so old. Just use what makes sense for your project, there
are no silver bullets.

~~~
davidpatrick
Everyone uses these types of headlines to justify their positions.

The statement was meant to provoke people, and honestly if it wasn’t Netflix
nobody would give a damn. Because the real headline is “We chose the wrong
tool for the job! Even pros make mistakes”.

------
techaddict009
We learned this hard way :P

We avoid fancy tools as much as possible and use basics as much as possible.

Laravel + Bootstrap + JQuery + MySQL works pretty well then this modern stuff.

Easy to implement, deploy and manage.

P.S. Use knife which you really need. Try to use simple knife as much as
possible.

~~~
maxhallinan
> Laravel + Bootstrap + JQuery + MySQL works pretty well then this modern
> stuff.

It's interesting to remember that Facebook started out as a PHP application. I
imagine that Facebook's original tech stack closely resembled the stack you're
recommending. And scaling that stack is what led to the creation of React. If
you choose to build a rich user interface (like Facebook or Netflix) on top of
that stack, you will likely find yourself creating abstractions to manage the
complexity. Those abstractions will be equivalent in their utility to React,
Ember, Angular, etc.

I agree that a website does not always need or benefit from a React or an
Ember. Small dynamic behaviors behaviors can be implemented with less powerful
tools. But, the power of your abstractions will need to scale with the
complexity of your UI behavior. That's why, at a certain point, the
abstractions provided by React _are_ the right choice and jQuery is not.

Regardless, the slide featured in this tweet does not comment on React working
or not working well. As they say in a reply to that tweet, the application
still loads React and renders React components. What they are presenting is an
interesting optimization that has to do with the unique performance
constraints of Netflix's UI.

~~~
bigmanwalter
That's completely untrue.

I've built both SPA and traditional fullstack applications similar to the
mentioned architecture (although I prefer Python over PHP).

Fullstack is a fraction of the complexity, with much more power. You can even
use a simple library like PJAX to get all the same speed boosts an SPA offers
without introducing any of the additional complexity.

To be honest, I don't see what React offers beyond what you get with a
templating language like Handlebars, and a few lines of jQuery for
initializing components.

This is, of course, for database heavy applications where each action requires
the backend. If you're building a game, or an app that's mostly offline, SPA
can be helpful.

~~~
always_good
I have a hard time believing that you built a non-trivial SPA that you
consider easy to maintain without an abstraction beyond jQuery.

There's just inherent complexity in software, so it's like suggesting that you
built an application without ever writing code outside of main() (functions
are for hipsters).

~~~
bigmanwalter
I mean, you're welcome to have a look at it
[https://github.com/IEMLdev/Intlekt-
editor](https://github.com/IEMLdev/Intlekt-editor)

An example of how I put together a component is here
[https://github.com/IEMLdev/Intlekt-
editor/blob/master/src/sc...](https://github.com/IEMLdev/Intlekt-
editor/blob/master/src/scripts/actors/glossary-panel.js)

\- My "view" function takes a template string and replaces the node's content
whenever "render" is triggered.

\- I create a "model" object which triggers a "render" event anytime it
changes. You can also give the model object methods which act as Redux-style
reducers.

\- The controller method is a shorthand for registering multiple jQuery events
at once.

That's pretty much all you need for a complex app. It's the entire React-Redux
architecture à la jQuery + ES6.

~~~
always_good
That's quite a complicated, embedded framework.

If that's "just jQuery", then React is "just ES6". I don't understand the
distinction. Every abstraction is built on the layer below. You just rolled
your own bespoke one instead of using one that already existed.

> I don't see what React offers beyond what you get with a templating language
> like Handlebars, and a few lines of jQuery for initializing components.

You say that like that's all your framework does, but I see more than that.

Seems you're mistaking different trade-offs for objective improvements,
something that almost rarely exists in software despite what you read in HN
comments.

~~~
bigmanwalter
The idea behind React is pretty cool, that all DOM transformations happen in
the template. But that's all it is.

There's no need for a vdom for the most part, template strings and innerHTML
are fast enough on their own.

I just find React to be an overly complicated way to achieve its goals.

    
    
       var model = { text: '' }
    
       var component = $( '.component' ).on( 'render', function() {
           $(this).html( `<div>${ model.text }</div>` )
       })
    
       update( 'text', 'Hello world' )
    
       function update( key, val ) {
           model[ key ] = val;
           component.trigger( 'render' )
       }
    

That's React in 8 lines of jQuery. My framework is just a minor extension to
this concept.

~~~
tomasroggero
> That's React in 8 lines of jQuery

No sir, that doesn't include server side rendering or diff rendering either
(meaning changing a bit on the top component would re render all markup, not
just what has changed)

Stop trying to over-simplify. The problem being discussed here is not React vs
jQuery. It's what we do and the decisions we make as engineers to provide a
good experience based on performance which is OUR side of UX.

~~~
bigmanwalter
I mean, you can use either the of the morphdom or setdom libraries to do the
diffing if you don't want to replace all the HTML, but the concept remains the
same.

I'm not convinced by arguments such as "when you're a large team it's
necessary". Scaling teams has more to do with project structure than what
rendering library you use.

Likewise, it's much easier to tweak performance when you aren't depending on a
monolith like React or Angular.

------
jordache
"resulted in a 50% performance improvement on our landing page"

What constitutes their landing page? The un-authenticated page or the
authenticated page? If the latter, is the page with all the title art cards?

------
polskibus
Was performance measured against fiber or the old rendering engine?

------
sandGorgon
How are they doing this ? This sounds surprisingly similar to Gatsbyjs
...Except it's real-time .

Anybody know how drop-in this is for existing react code ?

------
baxtr
Wow, this is crazy. As a huge vue.js fan I'd argue that the percentage value
would be much lower with vue. But, I’m not totally sure.

~~~
ukulele
I'm also a big fan of Vue, but why would it be different in this instance?

~~~
wolco
Quicker load time but a landing page can be more static. No framework needed.

~~~
ukulele
I meant why would it be different than React.

------
programminggeek
The irony is that React was supposed to make everything faster...

~~~
solidr53
Actually you are incorrect, not everything, but the most important part,
development time.

------
thrownaway954
did the same thing by removing ckeditor from a page it wasn't being used on.
we all go through this at one point when taking another look at something with
fresh eyes.

------
amsheehan
_rolls eyes so hard he falls over_

Not a chance that they were just, you know, using it wrong?

~~~
dang
Please don't comment like this here.

If you have a substantive point to make, make it thoughtfully; if you don't,
please don't comment until you do.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

------
MentallyRetired
Duh.

------
wintorez
In other news, 1 cubic meter of air is lighter than 1 cubic meter of water.
WHO KNEW?!

------
_reaction_
My experience with React has not been good. A gullible manager bought into
"react everywhere" hype, flew in consultants for training and then proceeded
to have a dozen pages on the website written in React. It's important to note
that all but one was either completely static or a simple form with less than
5 fields.

This project did not go well. It took months to develop, has 0 test coverage,
numerous bugs and doesn't work on edge or IE and isn't rendered on the server
so it's a bad experience.

Everyone on the team was either fired or quit less than 6 months after it
launched.

After evaluating the level of effort it would take to get the code base in a
maintainable state, it was decided to migrate it over to a more traditional
stack (plain js, static html, html forms) and that was completed in less than
2 weeks. Customer metrics across the board also improved.

The lesson here is to use the appropriate technology for the appropriate
problem. Unless your application is very complex, requires real-time updates
and you can afford the extra maintenance costs -- react is probably the wrong
choice.

~~~
jinfiesto
Don't mean to be rude, and it certainly seems like React was overkill for your
project, but 6 months to generate a react site like you're describing seems
like the problem might not have been react. Maybe it was engineering, or maybe
it was management, but cranking out a react app that's "completely static or a
simple form with less than 5 fields" is something one developer should be able
to do in a day or two after reading a basic react tutorial (assuming there are
design guidelines)...

Which is not to say I'm not sympathetic to bandwagoning having a negative
impact on engineering teams. Just that in this case, I find it hard to believe
that react specifically was the problem.

~~~
shepardrtc
> cranking out a react app that's "completely static or a simple form with
> less than 5 fields" is something one developer should be able to do in a day
> or two after reading a basic react tutorial

I've only done very basic web development during my career, and absolutely no
javascript. But, I've been learning React for a week or so and that's
something I could do in a few minutes. 6 months is insane, hyperbolic, and
probably untrue.

~~~
jinfiesto
Yeah, or something other than react is seriously screwed up. I said a couple
of days just to have time to do styling (assuming design is already done.)

