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.