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

Netflix: Removing client-side React.js improved performance by 50%

twitter.com

Post reply on HN
Print view View original

51–60 of 172 posts

Re: Netflix: Removing client-side React.js improved performance by 50%

#51

Post by megaman22 »

falcolas wrote: post #48
mattdeboard wrote: post #29

Earlier quoted context omitted.

Calm down. This is for a single, static landing page.

> Calm down. A rather unnecessary statement, don't you think? > This is for a single, static landing page. Which at one point wasn't a static landing page. Netflix has something of a captive market at this point in time; but could a newer startup scrambling to gain users afford to make the same choices?

I would hope that a startup scrambling to gain users would be able to explain in a simple static html site why their service is worth bothering with.

If I'm not particularly interested, I'm not going to wait around for mountains of JS to download and execute, and the typical content-free startup landing page full of hero images, stock photos, and vague bullet points to load up.

Re: Netflix: Removing client-side React.js improved performance by 50%

#52

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

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 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) or me (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

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

* Engineering Manager: https://jobs.netflix.com/jobs/865119

Cheers!

Re: Netflix: Removing client-side React.js improved performance by 50%

#53

Post by cptaj »

buchanaf wrote: post #22
danvasquez29 wrote: post #14

Earlier quoted context omitted.

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.

The caveat is that this is in reference to a _landing page_ only. If you try to write an advanced application with vanilla.js and you aren't some Javascript guru, then you are going to really hate yourself later on -- I guarantee it. Also, that 50% is only measuring the time to interactive on what I imagine is the first page visit. After everything becomes cached, I would think that the the benefit is dramatically lo…

FYI, vanilla.js is a thing now. Some asshole made it a thing.

http://vanilla-js.com

Re: Netflix: Removing client-side React.js improved performance by 50%

#54

Post by agentultra »

cynicalreason wrote: post #30
falcolas wrote: post #27

Earlier quoted context omitted.

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?

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

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.

Re: Netflix: Removing client-side React.js improved performance by 50%

#55

Post by jinfiesto »

shepardrtc wrote: post #34
jinfiesto wrote: post #24

Earlier quoted context omitted.

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…

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

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

Re: Netflix: Removing client-side React.js improved performance by 50%

#56

Post by homero »

christophilus wrote: post #31

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…

Wow that site loads instantly

Re: Netflix: Removing client-side React.js improved performance by 50%

#59

Post by jonkoops »

christophilus wrote: post #31

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…

Tom Dale recently did a a great talk at ReactiveConf about Glimmer that I can highly recommend watching: https://youtu.be/62xd25kEZ3o?t=7h40m

Re: Netflix: Removing client-side React.js improved performance by 50%

#60

Post by nindalf »

akerro wrote: post #18
romanovcode wrote: post #17

Earlier quoted context omitted.

Go next level: Remove the whole browser and make a native application - gain even more performance!

I just use lynx to browse and block downloading js files by default. I wrote this comment using ed and curl.

I don't know why you'd use such heavy duty applications for such a simple use case. I merely use a butterfly to induce cosmic rays to flip the bits of memory needed to send a http request.
Post reply on HN