DAVID EAST: You know what was funny?
I was thinking to myself, I was like, I'm nailing this take.
And then it caused me to say the wrong thing.
[MUSIC PLAYING]
Hey, everyone.
David here, and welcome to the very first video
in the Server-Side Rendering with JavaScript Frameworks
Series.
In this series, we're going to be using Cloud Functions
and Firebase Hosting to build fast-loading server-side
rendered JavaScript framework apps.
I'll be covering how to use React, Angular, Preact, Vue.js,
Ember, and Next.js for React.
We're going to be releasing new videos every single week,
so make sure to subscribe to stay up to date.
So you're probably wondering, what is server-side rendering,
and what is the real benefit?
Server-side rendering is the process
of taking a client-side JavaScript framework website
and rendering to static HTML and CSS on the server.
And why is this important?
Well, we all want fast-loading websites,
and server-side rendering is a tool
to help you get your website rendered faster.
So lets take a moment to talk about the critical path
in your website's first render.
So the critical path is a reference
to the process of delivering the most important pieces
of content to the browser so it can render your page.
If we can deliver the most important assets quickly,
then the browser can do its job and render the page quickly
to the user.
The delivery of your website is well-handled by Firebase
Hosting.
Firebase Hosting is HTTP 2-enabled,
and it's also backed by a CDN for fast delivery
around the world.
However, how fast the browser renders
your app depends on how you build it.
The first thing the browser receives is an HTML document.
This document contains references to other assets,
like images, CSS, and JavaScript.
And the browser knows to go fetch and download these assets
when it parses this document.
So even though the browser has your HTML,
it can't render the website until its corresponding CSS
has finished parsing.
But once that done, the browser goes ahead
and renders the page.
That means that with just HTML and CSS,
the browser can render the page.
And the browser's really, really good at this,
so it actually does it very fast.
Now, the last part of this process is JavaScript.
After the HTML document is parsed,
the browser will go and download your JavaScript files.
And the download time of a JavaScript file
can be significant if the file is large
and the network is poor.
And the browser needs to parse the JavaScript,
and on devices with low-powered hardware,
this can take quite a bit of effort and time.
And you could really see some slow load times
if your first render is dependent on JavaScript.
If you want a fast, first render of your website,
you will need your site to have a meaningful HTML
and CSS for the user.
JavaScript should be considered as an enhancement of that HTML
and CSS since its loading can be deferred.
However, it's not always that simple.
Some types of websites need complex features that
rely heavily on JavaScript.
These kind of websites use JavaScript frameworks,
like Angular, React, Preact, Vue.js.
But there's an inherent problem when
it comes to these frameworks.
They tie up your rendering code in JavaScript,
and on poor networks, this can be a disaster
for your first render.
It's not all doom and gloom, though.
As my friend Adi Asmadi once said,
"JavaScript frameworks can be fast
if you're willing to put in the work."
And we can put this work in with server-side rendering.
Because with server-side rendering,
we can generate the HTML on the server
and send that down to the browser.
So the user will see the HTML version of your app
almost immediately as the JavaScript app boots up
in the background.
And so while this may not make your page load faster
than a non-server-side rendered version,
it does give the user something to see as the JavaScript
downloads in the background.
So while this is a really nice benefit,
there is a cost to server-side rendering.
First of all, server-side rendering isn't free.
There's time and effort that's needed on the server
to generate these documents.
So if it takes you a while to view this generation,
then you're not going to have a fast page load.
However, Firebase Hosting is really well-suited for this.
We can dynamically generate our content with Cloud Functions,
and then Firebase Hosting will let you
store that in the CDN cache.
So that means when the next user visits the website,
it won't do the generation again.
It'll just serve it from the local CDN edge.
And this has a great benefit when it comes to performance,
and it takes a lot of effort off of the server.
Secondly, after the browser has finished processing your HTML
and CSS, it will still need to parse and execute
your JavaScript, and this can be really heavy on the browser's
main thread.
And so while the user will be able to see your application,
it will be in this frozen state where they actually
can't interact with it.
And so it's only after this JavaScript
has finished parsing and executing
that the application will be interactive to the user.
And this can be tracked through a metric known
as time to interactive.
And time to interactive is when a user requests your website
to when they can actually use it.
And we'll actually be covering in this series
how we can track and improve time
to interactive using server-side rendering.
This video series is a bit of a choose-your-own-adventure book.
We're going to be covering how to implement
server-side rendering through various frameworks
so you can pick the frameworks that you're interested in.
But we're also going to be releasing a companion
video to each one of the implementation videos,
where we'll be profiling a non-server-side rendering
version versus a server-side rendered.
And we're going to be using the Chrome DevTools to inspect
the critical path and the network time line,
but we're also going to be using another great tool called
WebPagetest.
And with WebPagetest, we can test
on real devices on throttled network
to help simulate a real-world use case.
We're going to be releasing new videos every week,
so make sure to subscribe to the Firebase YouTube channel
to stay up to date.
So that's all for this video.
If you liked it, we'd appreciate you
hitting that thumbs up button.
And if I didn't name your framework of choice,
please leave that in the comments below so
we can cover it in a future video.
And I hope to see you in the next video.
Now it's going to come back up.
So that's all for this video.
If you liked it, we would sure appreciate a thumbs up--
clicking it.
But you could just thumbs up us.
Just giving a thumbs up, that's good, too.