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