all right thanks for the wonderful
introduction Cassidy and Jenna there's
one other fun fact that they did not
mention which they couldn't have
possibly known the talk I'm giving today
progress surrendering I rehearsed it at
least five times just in the last two
days when I rehearsed it last night I
gave the top two my shampoo bottle it
took thirty five minutes whoa that's ten
minute beyond the limits of time went to
bed woke up today morning got ready gave
the talk are going to another shampoo
water
I finished the talk in 20 minutes oh
that's a bit too fast I need five
minutes time to need Phyllis I think
that's what I'm doing right now all
right so my name is Dinesh Pandiyan I
flew all the way from Sydney Australia
to meet you all beautiful people here
boy am I excited to be here I work at a
company called pink well we are a team
of JavaScript developers we work on a
lot of JavaScript stuff we invest
heavily in open-source if you are using
react there's a good chance you're using
one of the lips either built by the or
someone I think Moe or is currently
maintained by someone I think mother and
the most important part I go by the
Twitter handle flex Dinesh so I tweet
about web dev web performance and
recently I've been blabbering a lot
about progress surrendering all right
today we will be looking a lot about how
a web page renders we'll start with the
basics of what happens when a web page
renders and we will look into the
different strategies of loading webpages
client-side rendering server-side
rendering and there are two different
types of service at rendering you either
render it completely on the server are
you partially render it on the server
and but the most important part of all
we will be looking into progress of
server-side rendering and progress of
client-side hydration let's get a high
if you take any web site the simple
would end up the render process is
pretty simple your browser makes a
request your server has the HTML your
server sends a response back you see the
little flashing there that is what where
your browser passes the HTML and paints
the content on the screen it straight to
straightforward HTML comes from the
server your browser takes the HTML
passes
the prints it on the screen as easy and
as simple as a sound we are living in
2020 now we are building feature-rich
dynamic applications wave the content is
generated by making API calls so
rendering is not as simple as that we
need to make API calls we use a
frameworks like react to generate the
content so essentially there is no empty
content or we are not building static
sites anymore we are using frameworks to
iterate quickly the whole website is
built using javascript so in this case
we had different strategies to run our
website using JavaScript first one is
clients they don't drink that is this is
the most straightforward approach and
probably you will see a lot of simple
applications using client-side rendering
what happens in client-side rendering us
when the browser makes the request the
server sends an empty empty body to a
client so here in the head we have the
script to download The Pajama script
bundle but you can see in the body that
is only empty root element so once the
browser parses it there is nothing to
show on the screen so you just have an
empty content the browser then downloads
your javascript bundle once the download
completes your reactor Water Framework
uses high shows the content on the
screen so this is client side rendering
your whole JavaScript executes get the
content ready puts it on the browser and
everything happens only on the client
side nothing happens on the server this
has a serious drawback so if you are
usually on slower and mobile network
sauce I mean even if the network are
slower if your bundle file is pretty big
even if it's find at Kb sometimes no not
kidding bundle says can go up to even 1
MB if that happens it will take at least
10 to 20 seconds for your browser to
download the bundle so for 10 to 20
seconds users are sitting ducks they
just watch a blank screen there there is
no update on what's happening so this is
where we follow an approach called
server-side rendering in server-side
rendering when the browser makes the
request the HTML is generated on the
server so here frameworks like react
they're capable of running Java when you
use a node.js server we can execute the
whole react application on the server
generate the content that needs to be
shown to the user on the server so here
the HTML that comes back to the user is
not just an empty empty root element it
comes back with the content so the
browser's they can pass it and show that
content firsthand as soon as they passed
now the browser starts downloading your
bundle so what since the while the
browser is downloading your sister users
still sees content on the screen but
that content is not interactive yet only
after your bundle is downloaded the
content becomes interactive so this
process what's happening here is called
hydration hydration is nothing but your
react library whatever his stimulus on
the Dom react once again on the browser
and make sure the content is the same
attaches even to listeners and makes it
a dynamic but again as simple as the
sounds the primary content secondary
content we have here they not instantly
generated on the server we have to make
API calls to generate content so in
reality this is all server-side entering
will look if we render the whole content
on the server browser makes a request
so you see initially there is an empty
HTML on the server now on the server
your application makes an API request
now the header portion is rendered on
the server rendered in the sense the
HTML string is generator now the rest of
the portion our app your server will
make another API request again the rest
of the portion is again rendered on the
server so this goes on until your whole
site destined the content for your
entire application is generated on the
server only after it is done you can
send the response back to the browser if
if you look at you look at it here the
time taken to generate the whole content
is pretty high it can get really really
high if the API calls take a longer time
so your users they are still waiting
now's the time taken to at the time that
takes to send the first there our
response back to the client is pretty
high here it can easily take proper
tween one or two seconds and that is not
a small number but once the response
comes back you can show it to the the
browser parses it paints the content on
the screen and starts downloading your
or bundle javascript file and once the
file is downloaded your browser
react library runs on the client and
hydrates your content and makes it
interactive here the the drawback we
have here is the time that's taking to
generate the whole server content it is
usually the strategy we opt for
counteracting that this rendering
placeholders on the server if you look
at this approach instead of generating
the whole content on the server we just
generate the primary content on the
server the non-critical content is not
generated on the server we just send
placeholders from the server so you see
when the response goes back to the
client
instead of rendering the whole page you
render the primary content and put in
place holders for your secondary content
and now your once your browser completes
downloading your bundle file your
browser will react will take care of
making the API calls on the client and
hydrate the whole portion of your site
so you see in in full service and ring
we get to generate all the content on
the server but we cannot send the
response immediately using placeholder
approach we get to send the response
immediately as soon as possible but we
still make a certain portions of their
app this rendered on the client and the
API calls are made on the client the
real burn is if we find a middle ground
between full server-side rendering and
rendering placeholders from the server
and that is exactly what we are going to
do with progressive rendering before we
head into progressive rendering the
whole idea and concept of progressive
rendering was with this concept of HTML
streaming this is not something new if
we don't need the latest browsers for
HTML streaming to work this has been
around for decades even if you take the
oldest of browsers in the early days
most of the websites work based on the
concept of customer streaming now we can
bring it back to the latest frameworks
like react so this is what happens in
when you stream your HTML content to the
browser the browser makes a request you
can see the server sense doesn't send
the whole history it's just sending the
first part of your head similar it
sliced it up to the header as soon as
the browser receives it your browser can
paint it on the screen
now the connection is open the server
can send the second chunk the other
other portion of the HTML as soon as
your browser receives it the browser can
paint it on the screen this goes on
until the last HTML it is C so this is
streaming of content from the server the
idea is your browser doesn't have to
wait for the entire history ml to be
downloaded and your server doesn't have
to send the whole content in the first
response it can send it responses in
chunks predictably in streams now
looking at how it works with progress of
rendering your browser makes a request
your server first time it sends a place
or the like what we did for server and
drink placeholder you just put in the
primary content and placeholder on the
screen now we don't have now JavaScript
starts downloading in the background and
your server can send the second chunk we
can show the secondary content on the
browser before your JavaScript bundle
download completes and when the third
chunk comes in we just send us kiss this
is basically a concept of stitching we
send a script that stitches the content
on HTM that's already on the client
now once the bundle download completes
so because since everything is happening
in the background it happens
asynchronously once the bundle download
completes you can just hydrate your
content nothing fancy here so if we get
the benefits of both
using Play server under placeholders at
the same time rendering all your content
on the server so while I wrote the stock
if we originally planned only to talk
about progress of server rendering but
the amazing react team recently released
the experimental concurrent mode and
with the concurrent mode we have this
beautiful progress of hydration so the
concept is simple crowd react concurrent
mode is not just asynchronous updating
the Dom it is not data bus performance
it also has a progressive hydration
around suspense boundaries what that
means is whatever the surface boundary
it is just plain old promises under the
hood so when a chunk comes from the
server we can declarative till react of
a hydrate this portion only when this
chunk comes out
and we can also tell react hey if the
chance takes a longer time to come in
you can have you render the content on
the client don't worry about it for the
server so we have granular control over
how a suspects boundary is rendered so
you see when you if you look at progress
of hydration you render the placeholder
first and the server sends the chunk in
the background your bundle file starts
getting downloaded but here before the
third chunk comes in don't bundle
download completes so you hydrate
whatever that's left on your client and
when the rest of the chunk comes in
react and hydrate that portion in the
suspense boundary this is pretty
fantastic alright those are all
theoretical
now I built a sample app to see how it
works take a look
let's assume this is an average website
the content you see in darker shades
those are going to be our primary
content and the content you see in
lighter shade that's going to be a
secondary content which means secondary
content is not critical you don't need
to show it to user as soon as possible
now if we render the app in client-side
rendering mode I'm going to assign let
the network speed to Wi-Fi this is
pretty quick right because Wi-Fi is
pretty fast well you usually we develop
using a faster internet so you won't see
much difference between client set and
ring and server-side rendering in Wi-Fi
mode so you see when you serve a render
you have the content here but that
bundle downloads pretty quickly and you
hydrate the content pretty quickly but
you you can see the real benefit and
difference when you start simulating in
the network mode so in mobile mode so if
you render it using client-side
rendering in the mobile mode see it
takes a while just a white screen
there's nothing to show to the user it
takes about five six so there's one MB
of bundle being downloaded for the sake
of example and it took six seconds to
show the first content of the user and
it's not really good six seconds is
really really slow if you render and
server under more so you can see primary
content comes in as soon as possible but
secondary content you can show the
secondary content only after the bundle
downloads so still it's good that
primary content shows as soon as
possible but it takes time to show the
secondary content if there is a way we
could get the secondary content to the
user as soon as possible then that's
definitely waiting for everyone I'm
going to show it one more time it's
going to take six seconds here to show
the secondary content oops yeah
now if you read now what let's see what
happens if we render this in progress
surrender mode primary content is their
second thing cotton gets stitched from
chunks and so once your bundle
javascript your bundle fat download
completes you just need to hydrate so
you have the capability to show the
secondary content you are rendering your
secondary content on the server chunking
it to your client and just stitching it
to your HTML so you don't have to rely
on your client to download and show
secondary content things get really
crazy when you opt for a slow mode you
can see there are just difference or
obvious difference here I see let's
render it on full client-side okay there
we go so we have white screen I know how
long this is gonna take because I've
done this before but let's wait I think
I can just walk out get a coffee and
come back before we see something on the
screen 20 21 22 yes
so it takes 25 seconds to show any
content for the ER to the user in slower
mobile networks and if if the research
shows that if you have a global user
base there really lot of people are
there on slower networks it's not just a
marginal amount of people lot of people
are there on slower networks fellow
Australians will relate Internet in
Australia is really really slow and so
if you're under the same thing in super
slow network in server and are more so
you see it's good that we have content
on the screen we have the primary
content it's not really visible on the
screen I but I am too proud of it the
section right and left section you see
they have similar views they are shining
and there to show that content is
loading yeah it'd be gone we have to
wait 25 seconds to show the secondary
content to the user it's better than
prime side rendering but still you know
it's going to take that long to show any
content is not good at all but if you
want to progressively render your app
see you have the content here already
you have to wait 25 seconds to hydrate
but still all the content is here you
might wonder why the secondary counter
immediately loaded that is because the
time it takes for the chunk to reach
your user is really slow and slow
network mode so when the first chunk was
coming back the rest of the chunks were
generated from the server and sent
immediately so that's why you know chunk
1 2 3 4 already loaded before the first
response came to the browser you can if
we can simulate the network latency a
bit more you can see that in progressive
rendering you have placeholders second
chunk comes in you stitch it to the dom
another term comes then you are going
stitch it to the dom and now you can sit
and wait until your whole bundle
downloads you don't have interactivity
here but still in all other modes you
don't have interactivity either it's
better to show content rather than show
no content at all 23:25 there we go
alright so if you want to take a look at
how this is done in code wise I will
briefly walk it through
I remember what max said in his talk
great abstractions are making the
complete removing the complexities and
reducing it to simple reusable steps
that is one complication with the
progress of rendering there is no
reusable API since it's an experimental
mode you are going to have to write
really hacky code to get it done but it
works nevertheless the benefit the users
have the benefit not the devs though I
mean come on if you are having a mobile
phone and if your site can load really
fast you're going to be super happy
about it all right
so in the server you're rendering so
this part is where progress render
happens so whenever there's a response
right you render the first chunk and you
have an await you wait for the response
for the second chunk and then you write
that you wait for the response for the
further chunk and then you write it once
everything is returned to the stream you
close the stream it is as simple as that
as to how we are rendering these
progressive components I wrote a simple
year tell it's pretty straightforward so
we just need to tell the util how to
from where we are rendering and we need
to give an ID for the placeholder and
with that placeholder you know the
scripts that are coming through the
chunks will know where to replace the
content on the browser and if you are
rendering on the client we wrap it in a
lazy component if not we just use a
normal component to render a server
component it's as simple as that all
right going back
quickly recapping what all we saw here
in client-side rendering no content
comes from the server not your primary
content not your cycling cotton only an
empty dough comes from the server but
and once you bundle downloads the
latency to fetch data the API calls is
going to be really high
the reason being your API calls travel
all over the world to your server there
and the latins is high your ap the you
service the urea pickles may correct was
there not co-located and when we just
saw what happened comes slow and
networks so when your bundle size is
pretty high your user satisfaction is
going to take a huge hit in slower
networks but the benefit is they're just
HTML flights we can host them statically
NAT will fly so we can host them
statically in any of the static hosting
sites in server rendering the benefit we
have is primary content comes from the
server we can send the secondary content
as well but it's going to really slow
down your response time so what we do
instead we load the secondary content on
the client we wait for the bundle to be
downloaded so in slower networks it's
better than prior client-side rendering
but still it is not as good as
progressive rendering but advantage
though if you're the content on the
you're showing on your web page it is
not asked dynamically if there is going
to be a part of the application that's
common for all the users you can pre
render them on yours during build time
and then post it statically that's one
of the advantages but when we opt for
progressive server rendering coupled
with progress behind client hydration
you have a primary content from the
server you have your secondary content
from the server data fetch latency is
super low the reason being your API
calls happen in the server and most of
the time arguably don't put me there but
most of the time your APS are co-located
with your server that means your EAP
responds to super damp quick and it
doesn't matter how fast or how slow your
mobile network is even if on faster
networks just once time is pretty much
the same even on slow one networks time
is poor depends the same because all the
content is rendered on the server just
time to hydrate is going to change one
of the advantage here especially this
applies only to react with the suspense
boundaries you can build your own
strategies what if your user is on a
faster network what if your the bundle
downloads quicker than the stream
completes or what if your stream
completes before you bundle download
complex you have granular control over
what to do when that happens whether to
use the content from the server or just
discard the chunk and just load it on
the client you can do all kinds of fancy
things with progressive memory one
downside though you cannot pre render
the reason being your server has to be
dynamic and send stuff down the stream
but it's ok I think about all the
benefits we have here we can totally
ignore that we cannot clear under your
site that will be all my name is Dinesh
Pandiyan thank you so much you are all
awesome
[Applause]