Hi, I'm Alex Nicksay, a senior engineer at Google.
I lead the front ends team at YouTube.
Over 6 billion hours of video are watched each month
on YouTube.
That's almost an hour for every person on earth.
At YouTube, we want to get that video to you
as fast as possible.
Since last year, we've reduced the time
to start video playback by over a second.
That's 40% faster.
So where did we start in this optimization?
We analyzed data from our real user monitoring,
and we broke down the time it takes
to start playback into critical stages.
And we realized that one of those stages
is the same for every playback-- initializing the player.
So we asked ourselves, what if we reuse the same player?
The answer?
It's faster.
By maintaining a persistent player,
we're doing less work on each navigation.
And by doing less work, we're making each playback start
sooner.
So how did we do it?
We built a new JavaScript framework for page navigation.
Structured page fragments, or SPF for short,
is a lightweight framework that handles navigations and updates
to page sections.
When someone first arrives at the site,
the content is sent from the server and rendered normally.
We call this static navigation.
But when going to the next page, only document fragments
are sent and page sections are updated accordingly.
We call this dynamic navigation.
So what does this give us?
It gives us the fastest possible rendering time
for that first page, leveraging all of our existing performance
techniques.
And it additionally allows us to maintain
a persistent responsive interface using
the same rendering code as before.
This all creates a better user experience.
No one is staring at a blank white screen waiting for a page
to load.
But what about the developer experience?
This framework allows us to maintain productivity
by using the same code for both static and dynamic rendering.
And it gives us the flexibility to use any server side language
and template system we want.
It also supports sending data for use
in client side templating.
So let's take a look at how it's implemented.
We'll start with requesting content.
Here's a link.
Clicking it will trigger a static navigation request.
Here's that same link using SPF.
Clicking it will trigger a dynamic navigation request.
As you can see, we use progressive enhancement
and a simple syntax to enable SPF for supported browsers.
Now let's look at sending that content back.
Here's the HTML of a response for static navigation.
In this example, we use a common layout
of upper masthead, middle content, and lower footer.
Here's that same response using SPF.
Only the fragment for the middle content
is sent because the masthead and the footer
don't need to change.
JSON is used for transport during dynamic navigation.
As you can see, the fragments for static navigation
map directly to those for dynamic navigation.
And this makes the implementation very easy.
Now we won't cover them in depth,
But SPF has several optional features
that can help you improve your site.
In some web apps, HTTP caching is inappropriate,
but SPF allows you to cache responses in client memory
according to your application specific parameters.
SPF can also prefetch responses automatically or manually
to predictively boost performance.
And SPF supports streaming multipart responses in chunks
to enable on the fly processing.
This speeds up navigation by starting the rendering early.
Now let's take a brief look at when YouTube launched
these features, and how they each impacted performance.
Here's real data from YouTube's real user monitoring.
I've graphed the median time to start playback
for both HTML5, Flash, and the traffic
weighted composite of both.
But for clarity, we're going to focus
on the five day moving average of the composite.
Now when we first introduced dynamic navigation
between consecutive video pages, we
didn't have a persistent player yet.
And we only saw a minor reduction in overall time
to playback.
Despite this, users reported that the site felt faster.
This showed us that there were some very real user perceived
performance gains that dynamic navigation brings.
Now when we added that persistent player
between consecutive video pages in Chrome,
we reduced the overall time until playback by 8 and 1/2%.
Expanding all supported browsers was another 9% improvement.
And enabling on the fly processing over HTTP chunking
yielded a 5% speed up.
By defaulting supported browsers to our HTML5 player,
we reduced our overall player initialization time
and generated an 8% improvement.
And then by dynamically navigating
between all pages on the site, not just
consecutive video pages, we were able to preemptively create
a persistent player before it was even used.
And this reduced our overall time until playback
by 7 and 1/2%.
When we expanded our default HTML player to both videos
with and without ads, we yielded a 2% improvement.
And finally, enabling on the fly processing over SPDY
yielded a 4 and 1/2% speed up.
And that's how we made it 40% faster
to play a video on YouTube.
So what's next?
The great news is that we've open source the framework so
you can use SPF on your site.
Check out our project page on GitHub to learn more.
Thanks for watching.