
Making Netflix.com Faster - joubert
http://techblog.netflix.com/2015/08/making-netflixcom-faster.html
======
brianstorms
The code may be faster but the user experience continues to get slower, i.e.,
it takes more time than ever to find something worth watching. The recent UI
changes simply disguise the fact that there are less titles available.
Especially movies. Lots of filler, straight-to-video content that never got
theatrical exhibition because the content sucked. No way to filter it out. No
way to tell Netflix I really do NOT want to see this, I will never watch it, I
really am not interested. Netflix will continue showing these unwanted titles
to you. This is not speeding up a user experience. This is not making Netflix
faster. And the user experience is really the only thing that matters.

~~~
onewaystreet
The lack of titles is the fault of the studios. Not much netflix can do about
it. Which is why they are increasing production of their own content. From a
UI/business perspective many people have argued that it's always better to
show a user something than nothing. "We don't have the movie you are looking
for but here are some you might like" is better than "We don't have the movie
you are looking for."

~~~
zatkin
For anyone curious as to why "the studios" are not giving their titles to
Netflix is because they are developing their own, independent Netflix's (i.e.
Comcast is has internet TV at tvgo.xfinity.com).

~~~
eikenberry
Comcast makes the mistake of using their online streaming as leverage to tie
people to their cable subscription model. I wouldn't mind looking into
subscribing to their streaming, but I'm not interested in cable TV so they're
out of luck. IMO this gives Netflix the advantage for now at least.

~~~
timje1
Comcast can charge a crapload of money for cable.

If they offer internet services at netflix prices and are highly successful
(lots of signups) - if this allows a small fraction of their cable customers
to cut ties, Comcast loses money.

------
ericfrederich
They need to make Netflix work first otherwise it'll just fail faster. Netflix
has been broken on the Nexus Player for a long time. Let any show run to the
end and it logs you out.

~~~
andrewguenther
Another Google platform with little to no support only a year after its
release? I am shocked, _shocked_. This has _never_ happened before! /s

In all seriousness though, have you contacted Netflix support? They have
seemed really responsive in the past.

------
wereHamster
Kudos for not using the word 'isomorphic'. Most people use it (in the context
of JavaScript) without understanding what it really means:
[https://en.wikipedia.org/wiki/Isomorphism](https://en.wikipedia.org/wiki/Isomorphism).

~~~
timdorr
"Universal" is the new "isomorphic": [https://medium.com/@mjackson/universal-
javascript-4761051b7a...](https://medium.com/@mjackson/universal-
javascript-4761051b7ae9)

~~~
wereHamster
> a word that describes the same code but running in a different environment

Uhm, that's a wrong way to think about it. The same code can't run in a two
different environments. If it does then it means that the environment is the
same! The question then becomes what is an 'environment'.

Once you start explicitly tracking what the dependencies of your code are, in
terms of language/runtime support, external libraries etc, it becomes very
clear what the 'environment' is (though JavaScript as a language is
exceptionally bad at expressing these dependencies). If your code runs in
Node.js and latest Chrome, then the 'environment' is ES5 or even ES6. If it
also runs in IE7, then the environment likely is ES3. If your code also needs
access to the DOM and WebWorker APIs, as well as underscore, then the
environment is ES3+DOM+WebWorker+underscore.

If only we had support in the language and/or tooling around it to express
these dependencies and warn us if we try to use some code in an environment
that is unsuitable for it...

------
omarforgotpwd
Great example for why you might actually want to use node.js: being able to
ensure your rendering code runs identically on the client and the server.
That's something no other language can offer as cleanly or natively for the
next few years.

~~~
brianwawok
scala + scalaJS IMHO does it better right now (with a lot more type safety and
a lot more performance on the server)

~~~
ken47
You can't actually run a JS framework faster from within the JVM than you can
in V8. And if you're writing all your code in Scala, then you're losing the
productivity benefits of having a real UI framework written in JS.

~~~
brianwawok
I think you are missing the point.

My server code is running Scala on the JVM on the server, which is JITted down
with all the magic of the JVM into native, and running full steam.

My client code is cross compiled javascript that the browser does it's thing
client side.

The magic is:

1) Both parts are the same codebase, I can share data objects and logic
between platforms

2) I get actual static typing on everything. Not some kind of fake static
typing like coffeescript. So just the fact that my code compiles makes my code
roughly equal to a mess of Javascript with a bunch of tests hitting the happy
path.

3) I get to write in an actual decent language, not Javasript, the worse
language to ever write in.

Javascript is the new assembly. It's great, but I never want to touch it! If I
can touch a higher level language, why wouldn't I?

------
dikaiosune
I'd be interested in seeing some actual numbers for their "time to
interactive" metric. As far as I can tell, this article just says that they're
monitoring it, not what x% improvement they've seen.

EDIT: Forgot about this at the top:

"The impact of this effort netted a 70% reduction in startup time" \-- So is
this the same metric?

~~~
travjones
Eh... I think they're different. The startup time is probably the most-
improved metric that's why they dropped the 70% figure. Maybe they hint at the
"time to interactive" measure as a concern for the future for practical
reasons. For example, startup time is probably way before the page is ready
for user interaction (video playing, buttons clickable, etc.), yet the "time
to interactive" is probably the most important metric to the everyday user.

~~~
kristoferbaxter
Hi, author here.

Apologies for not making this more clear in the post. The 70% reduction is for
time to interactive (tti).

~~~
travjones
Got it. Thanks for following up.

------
JupiterMoon
I love Netflix but hate using their website. It's a constant experience in
annoyance. It's slow, buggy and gets in the way of discovering new content.
(Chrome on Linux on an older Atom processor -- yes I know that this is a
rubbish spec but other non-webapp media consuming methods work just fine.)

What about a cross platform libnetflix and let us build our own native apps?
(Like spotify do.) Or even allow integration into e.g. Kodi media centre.

~~~
swah
Even with a gaming PC, anything graphical on Linux doesn't feel as snappy as a
Windows PC, with a fresh install. (OTOH on Linux, every filesystem operation
feels 10x as fast..)

~~~
JupiterMoon
I think my problem is more netflix.com or possibly web app specific. Desktop
apps work just nicely.

------
erichmond
For all the people complaining about the UI on netflix, there is a great
alternative interface @ www.instantwatcher.com . Site is written in Haskell,
and is quite snappy.

------
darkmarmot
And yet they still fail to address the most irritating aspect of their video
UI -- all too often the video timeline controls remain visible while movies
are playing and don't go away. This has been going on for _years_. They seem
incapable of combining the mousemove event and a timer to automatically hide
the controls...

~~~
mattkrea
Across various browsers and operating systems I have never encountered this...
As long as my mouse isn't hovering over the controls they work perfectly for
me.

------
ohitsdom
Probably not the place to bring this up, but I am having so many issues with
Netflix app on xbox 360 lately. I'll hit play on a title, it'll load to about
15%, then stop and take me to the "choose profile" screen. Anyone else seeing
this?

~~~
justwannasing
You're right. This is not the place to bring this up.

EDIT: OK. I guess this is the right place so, my son's XBox hangs when
switching between game playing and watching Netflix. Does anyone know how to
fix that?

------
jebblue
So node.js can replace Java/Tomcat? I guess I'll have to pinch my nose and
somehow start liking JavaScript. Typescript looks good, that might make it
palatable.

~~~
Wintamute
I imagine a common architecture for universal apps will be to just use some
sort of thin Node.js app to perform the actual app rendering, and have it
communicate with a separate API app written in whatever language is most
appropriate. Static files could either be served by the Node.js app, or even a
different source.

And these days ES6/ES7 makes Javascript very palatable indeed. Check it out
:-)

~~~
madeofpalk
That's exactly how you do it :)

You have one 'Universal Application', and then you have two small entry
points: \- server.js is a small (express) server to send a HTTP response to
the client (server bootstrapping) \- client.js renders a page and the mounts
it onto a DOM node.

To get around the issues of database access, it makes it a lot easier to put
all of that into an API that can be accessed by the server and the client.

Here's a very small project I build (and am continuing to build) to learn
about this architecture
[https://github.com/joshhunt/reactapus](https://github.com/joshhunt/reactapus)

~~~
jebblue
For a non-signed in session I can see some advantage in improving the
swiftness of implementing supporting changes on the server for the client
developers. For signed in sessions, you can't get around the database and an
API update for it when the client needs some new feature or access so in the
signed in case; I think the benefits of this nodejs part would be diminished.

~~~
madeofpalk
I'm not sure if I quite understand your comment.

You can still use authentication with an API... You don't need direct access
to the database to do that.

------
tylermauthe
Beautiful use of modern JS development techniques: client-side rendering,
isomorphic JavaScript and smaller more-efficient libraries.

Even better to see these techniques applied appropriately, instead of
slathered on to the point of being detrimental.

Also, +1 for using jQuery and being proud of it! :)

~~~
code_sterling
> Also, +1 for using jQuery and being proud of it! :)

That wasn't the takeaway some of us read here, and honestly, that's just
foolish. Take pride in your craftsmanship, never take pride in your tools. I
love my hammer, but when I need a screwdriver, it's a stupid choice.

~~~
ProCynic
On the other hand, don't be ashamed of using a tool that works for the job,
even if it isn't the latest or coolest thing. jQuery is no longer the best
choice for a lot or circumstances, but if it is for yours, go for it.

