►
From YouTube: Optimized Hydration via Compile Time Static Analysis - Michael Rawlings & Dylan Piercey, eBay
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
The
optimizations
were
about
to
dig
into
do
not
necessarily
apply
to
all
applications.
Our
primary
focus
for
these
optimizations
is
multi-page
applications,
but
that's
not
to
say
that
there
aren't
learnings
to
be
had
either
way,
specifically
we're
going
to
talk
a
lot
about
hydration.
If
you
haven't
heard
the
term
before
or
just
need
a
quick
refresher.
Hydration
is
a
term
for
the
process
by
which
modern
frameworks
allow
you
to
mount
your
application
on
a
top
of
a
page
that
was
initially
rendered
on
the
server.
A
So
hydration
has
been
around
for
quite
a
while
now
and
it's
been
popularized
by
modern
frameworks
such
as
react
exists,
primarily
because
we've
shifted
from
building
websites
with
a
sprinkling
of
JavaScript,
on
top
of
a
mostly
server
rendered
application
to
our
modern
frameworks
which
allow
us
to
specify
the
view
as
a
function
of
our
application.
State
we've
grown
accustomed
to
the
declarative
and
expressive
templates,
and
it
also
means
we
get
to
shift
the
work
of
attaching
to
and
updating
the
Dom
to
our
favor
good
choice.
A
A
A
set
of
metrics
called
web
vitals,
which
focus
on
three
aspects
of
delivering
a
great
user
experience,
loading,
interactivity
and
visual
stability.
Visual
stability
is
largely
determined
by
the
application
logic,
but
loading
and
interactivity
are
heavily
impacted
by
your
framework
of
choice.
So
these
are
the
metrics
we'll
focus
on
today.
B
With
loading,
its
largest
content,
full
paint
or
LCP
LCP
measures,
the
render
time
of
the
largest
content
element
visible
within
the
viewport.
This
is
notably
different
than
similar
methods,
like
first
content,
full
paint
which
just
measure
the
first
time
anything
is
visible
on
the
screen.
The
goal
of
LCP
is
to
identify
when
the
main
content
of
a
page
is
visible
to
the
user.
B
A
Primary
metric
for
interactivity
is
first
input,
delay
or
F
ID,
f,
ID
measures
the
time
from
when
a
user
first
interacts
with
a
page
to
the
time
when
the
browser
is
actually
able
to
respond
to
that
interaction.
We
care
a
lot
about
the
first
input
from
the
user,
because
the
biggest
interactivity
issues
we
see
on
the
web
today
occur
during
page
load,
largely
due
to
modern
hydration.
A
F
idea
is,
what's
known
as
a
field
metric
measures,
real
user
interactions,
as
this
is
what
ultimately
matters.
But
when
comparing
approaches
from
a
framework
perspective,
synthetic
metrics
are
typically
more
helpful.
We'll
take
a
look
at
total
blocking
time
and
total
time
to
interactive,
which
correlate
closely
with
F
ID.
B
Looking
first
at
LCP
and
how
quickly
we
can
get
content
visible
to
the
user,
HTML
is
the
absolute
fastest
way
to
do
this
on
the
web.
Html
is
able
to
be
parsed
and
rendered
as
the
browser
receives
it.
However,
one
common
problem
with
modern
frameworks
is
they
have
a
subpar
solution
when
it
comes
to
rendering
on
the
server
in.
A
B
Cases
this
unoptimized
rendering
means
that
a
server
can
easily
get
overloaded,
causing
a
significant
amount
of
time
between
the
requests
coming
into
the
server
and
the
server
responding
with
any
HTML.
This
can
end
up
negating
all
performance
benefits,
making
it
actually
faster
to
just
serve
an
empty
page
and
let
the
browser
do
the
rendering,
which
was
really
unfortunate.
A
Other
two
metrics
TB
T
and
TT
I,
don't
fear
much
better
in
the
current
web
dev
world,
modern,
hydration
approaches
requiring
same
amount
of
JavaScript
and,
unfortunately
Java
scripts,
not
cheap.
Besides
downloading
the
Jas,
we
also
have
to
parse
it
and
execute
it,
and,
unlike
HTML
execution,
can't
happen
as
it's
being
downloaded.
This
is
especially
troublesome
for
lower
end
devices,
but
it's
actually
not
that
uncommon
to
find
sites
that
are
taxing
even
our
most
maxed
out
developer
machines.
B
B
Believe
this
poor
first
load
experience
is
what
is
called
single
page
applications
or
spas
to
become
so
popular.
The
idea
is
even
if
the
first
load
is
terrible.
At
least
subsequent
loads
will
be
fast
because
the
code
has
already
been
loaded
and
can
be
displayed
without
another
round-trip
to
the
server.
Spas
do
have
some
benefits,
but
they
actually
further
increase
the
amount
of
j/s
needed
in
the
browser
and
come
with
a
new
set
of
challenges
which
are
outside
the
scope
of
this
talk.
B
B
A
Optimization
through
static
analysis
is
really
appealing,
because
it's
something
that
can
happen
automatically
from
the
application
developers
perspective
using
information.
That's
already
present
within
the
code
that
the
writings
the
compiler
can
put
in
the
extra
work
at
Build
time
to
make
things
faster
and
even
eliminate
code
altogether.
B
A
Also
worth
pointing
out
that
we're
going
to
primarily
be
looking
at
these
optimizations
from
the
perspective
of
a
multi-page
app
or
what
you
might
call
a
traditional
website.
That
said,
many
of
these
ideas
can
help
improve
the
first
load
experience
of
any
website
when
it
comes
to
LCP.
The
question
is:
how
can
we
optimize
server
rendering,
so
we
can
consistently
deliver
content,
Flay
HTML
to
the
user's
browser
in
a
timely
manner,
some
frameworks
out
there
recommend
using
a
headless
browser
on
the
server.
A
This
is
obviously
expensive,
but
even
frameworks
that
create
video
on
the
server
aren't
ideal
on
the
server.
The
end
goal
is
always
going
to
be
building
an
HTML
strings.
These
additional
abstractions
don't
help
us
here
at
all
and
just
end
up
consuming
additional
memory
and
CPU
cycles.
The
templates
associated
with
their
frameworks
already
closely
mirror
that
HTML
we
need
to
generate.
We
shouldn't
need
to
spin
up
a
browser
or
create
a
bunch
of
objects
representing
the
Dom
just
to
generate
some
HTML.
B
Are
actually
a
few
frameworks
out
there
that
are
already
compiling
server
optimized
versions
of
their
templates,
including
Mark
Owens
felt
and
in
Martha's
case
we
even
compile
these
to
writing
to
a
stream.
This
allows
us
to
flush
out
partial
HTML,
while
the
certain
parts
of
the
page
may
be
waiting
on
data
from
an
async
service.
Compiling
the
strings
has
the
benefit
that
certain
work,
like
escaping
content,
happens
at
compile
time
for
static
values.
When
HTML
generation
happens
at
runtime
from
an
object
tree,
there's
typically
no
differentiator
between
static
values
and
potentially
unsafe,
dynamic
values.
A
A
When
we
compile
for
the
server,
we
can
see
that
we've
got
string,
concatenation
and
some
utilities
are
pulled
in
to
handle
escaping
dynamic
content
in
the
browser,
compilation
looks
a
little
different.
Marco
creates
a
feed
on
in
the
browser
similar
to
other
frameworks.
To
do
lightweight
comparisons
across
renders
that's
not
to
say
that
Marco
is
outputting,
the
absolute
best
performance
in
either
environment,
but
it
is
pretty
close
on
the
server,
but
Marco
is
not
artificially
bottlenecking
in
either
environment
either.
B
This
has
a
huge
impact
on
ben-gurion
performance
on
the
server
still
there's
room
for
improvement
for
most
components,
written
in
modern
frameworks.
There
is
this
exist
code.
That's
only
ever
going
to
run
in
a
single
environment.
Here
are
some
examples.
Events
never
need
to
be
called
on
the
server
creating
the
functions
there
is
wasteful.
There
usually
exists
lifecycle
events
as
well
that
only
ever
happened
in
the
browser
or
effects
if
you're
using
hooks.
These
also
should
be
stripped
from
the
server-side
code.
A
A
The
exact
process
for
hydration
varies
from
framework
to
framework,
but
at
a
high
level,
all
modern
frameworks
require
three
main
elements:
hydration,
the
HTML
markup,
which
is
rendered
from
the
server
or
served
statically
the
JavaScript
necessary
to
build
the
initial
application
state
and
to
mount
on
top
of
this
HTML.
Finally,
any
data
that's
needed
to
create
the
initial
application
state.
This
is
often
serialized
as
JSON.
B
Looking
at
some
code
will
probably
help
here
and
make
it
more
obvious
where
the
duplication
exists.
In
our
example,
you
can
see
that
a
lot
of
static
contents
could
exist
in
at
least
two
of
them
elements
of
hydration
we're
just
talking
about
for
the
most
part,
static
content
such
as
such
as
the
Dom
structure
is
represented
in
both
the
HTML
and
the
JavaScript,
also
the
dynamic
content.
Typically,
the
initial
input
to
the
view
is
represented
in
both
the
HTML
and
the
data.
Maybe
in
our
example,
world
may
only
ever
render
on
the
server.
B
A
Let's
quickly
take
a
look
at
a
very
simple
hypothetical
template
in
it.
We
can
see
that
there
is
some
stateful
value
denoted
by
the
dollar
sign,
which
is
used
to
update
some
text
below.
First
we'll
look
at
how
much
static
content
exists
here
you
can
see
that
all
of
the
Dom
structure
for
the
page
is
actually
static,
as
well
as
some
text
content
and
attributes.
Taking
this
a
step
further,
though,
we
can
see
that
the
footer
element
contains
some
text
which,
although
dynamic,
is
not
tied
to
any
state.
A
That
content
also
cannot
be
updated
by
the
browser
and
we
consider
it
immutable.
Most
multi-page
applications
have
a
bunch
of
content
on
the
page
that
once
initially
rendered
is
immutable
for
this
content.
It
should
be
possible
to
completely
skip
the
hydration
process,
meaning
that
rendering
logic,
data
etc
is
not
duplicated.
One
of
the
best
ways
to
improve
time
to
interactive
is
to
skip
hydrating
unnecessarily.
B
Okay,
so
we
can
skip
hydrating
the
immutable
parts
of
their
page,
but
how
can
we
optimize
the
dynamic
parts?
Looking
at
the
simplest
case,
you
might
have
some
dynamic
text
and
attribute
grievant
just
an
event
handler
that
needs
to
be
attached.
There
would
be
nothing
too
fancy
about
if
you're
hooking
up
the
code
yourself,
you
probably
write
a
solution
that
you
would
use
order
of
magnitudes
less
JavaScript
than
any
modern
hydrated
framework
would
for
this
simple
case,
the
key
is
that
the
layout
of
the
template
is
still
a
mutable
once
rendered
from
the
server
meaning.
B
No
new
elements
are
added,
moved
or
removed.
Since
the
layout
is
immutable,
we
should
be
able
to
avoid
send
in
any
layout
to
the
browser.
The
server
has
already
done
that
work,
text,
content,
attributes
etc
may
still
be
updated.
But
to
do
that,
you
do
not
need
to
necessarily
render
a
full
section
of
layout
in
the
browser
just
to
hydrated.
You
might
be
thinking
well.
What
about
events
well
hydration
as
it
stands,
is
far
from
the
simplest
approach
to
attaching
events
to
the
Dom.
B
A
much
simpler
approach
for
both
of
these
would
be
to
simply
mark
our
elements
with
some
kind
of
identifier.
Then
we
can
easily
grab
a
reference
data
element
adding
under
the
event
handlers
and
also
updated
its
attributes.
In
text
content,
we
can
actually
represent
the
required
JavaScript.
For
the
example
template
on
screen
pretty
easily
in
just
a
few
lines
of
code,
we
got
a
reference
to
the
Dom
notes
that
we
need
first,
the
search
input,
then
the
dynamic
search
text.
Finally,
we
add
an
event
listener
and
update
the
text
content
as
the
input
value
changes.
A
Another
way
we
can
reduce
the
impact
of
hydration,
especially
during
the
page
load,
is
by
deferring
as
much
of
the
hydration
work
as
possible.
Ideally,
elements
would
be
hydrated
in
batches,
reducing
their
total
blocking
time
and
allowing
for
the
user
to
interact
with
the
page
during
the
hydration
process.
A
few
frameworks
are
already
doing.
This.
Also
content
could
be
hydrated
and
even
download
lazily
families
can
take
on
part
of
this
work
for
us
automatically,
although
in
many
cases
it
will
be
a
manual
process
either
way
it's
important
for
you
to
keep
in
mind.
A
You
can
also
a
lazily
hydrate
content
based
off
various
user
interactions
or
even
just
by
simply
detecting
if
the
elements
in
the
viewport
everything
we've
mentioned
so
far
can
be
manually
optimized,
but
it
probably
already
sounds
like
a
lot
of
work.
Ideally,
our
frameworks
need
to
start
picking
up
the
slack
here.
So,
whatever
frameworks
doing
today,
one.
B
Project
that
has
taken
a
stab
at
this
issue
is
next
super
performance.
This
module
is
a
community
plugin
for
next,
yes,
which
uses
pre-act
and
exposes
some
api's
that
optimize
the
hybrid
hydration
process.
Pre-Act
itself
offers
respectable
performance
on
the
server
side
and
the
client
side,
while
having
a
significantly
smaller
bundle
size.
This
plugin
uses
an
approach,
they
call
partial
hydration.
In
essence,
it
allows
developers
to
explicitly
mark
a
subset
of
components
as
hydrate
able.
A
Another
interesting
project
in
this
space
comes
from
the
view
community.
It
is
called
you
lazy,
hydration
and,
as
you
probably
can
guess,
just
based
off
the
name.
It
provides
a
nice
component
based
api
to
explicitly
configure
what
a
component
should
be
hydrated.
It
also
lets
you
skip
hydration
for
a
section
of
code,
but
more
interestingly,
it
allows
you
to
explicitly
define
when
that
code
should
hydrate.
You
can
opt
into
hydrating
when
a
component
is
interacted
with
when
it's
visible
or
even
when
the
browser
is
idle.
B
In
Marco
work,
we
maintain
we've
put
a
lot
of
thought
into
the
hydration
process.
Ebay
itself
is
a
multi-page
application,
and
the
performance
of
our
pages,
while
not
perfect,
is
extremely
important
to
us.
Marco
is
the
only
framework
that
implements
some
of
these
hydration
specific
optimizations
out-of-the-box
it
ships
with
support
for
partial
hydration,
but
it
goes
one
step
further
and
automates
the
process.
Marco
components
actually
take
the
entire
pages
component
rate
into
account
when
bundling
and
rendering
it
uses
this
information
to
determine
where
the
top-level
components
which
are
stateful
exist.
B
If
a
component
does
not
contain
stable,
walking
the
components
on
the
page,
it
can
safely
be
omitted,
since
it
will
always
render
an
immutable
HTML
structure,
because
this
is
all
handled
by
the
framework.
It
has
some
unique
advantages
over
other
solutions.
If
two
hydrated
components
share
serialized
data,
it
dee,
doop,
Marko's
api's
are
designed
to
avoid
creating
input
which
is
not
serializable,
for
example,
passing
a
function
as
input
which
is
typically
used
for
event.
Handlers
would
not.
B
A
Marco
currently
automates
a
fair
amount
of
what
is
being
done
by
add-ons
and
other
communities,
thanks
in
part
to
its
compiler.
We
believe,
without
this
automation,
maintaining
which
components
need
to
be
hydrated
becomes
a
headache
since
developers
typically
like
to
avoid
headaches.
It
typically
means
that
they're
avoiding
doing.
B
A
A
One
issue
is
that
all
of
these
solutions
treat
components
as
the
source
of
truth
for
hydration,
although
in
some
cases
that's
going
to
get
you
quite
far
for
most
applications,
the
top-level
immutable
content
doesn't
stop
at
component
boundaries,
let's
think
more
about
where
the
truly
immutable
content
is
for
a
page,
ignoring
component
boundaries.
Ultimately,
it
boils
down
to
this.
Can
this
section
of
the
template
be
rendered
in
the
client-side,
ignoring
hydration?
The
only
way
10th
will
need
to
be
rendered
from
scratch
in
the
browser,
as
if
it's
conditionally
displayed
in
practice.
A
B
Ultimately,
if
the
content
is
out
full
outside
stateful
control
flow,
then
it
can't
be
rendered
from
scratch
in
a
hydrated
application.
That
is
a
much
more
granular
boundary,
then
relying
on
components
since
with
components.
Even
if
a
single
piece
of
the
template
is
dynamic,
the
whole
thing
becomes
dynamic.
B
So
now
that
we
know
where
the
hard
stop
is
for
things
that
need
to
be
able
to
render
on
the
client-side,
how
can
we
determine
it
exactly
where
a
stateful
control
flow
exists,
static,
analysis?
This
is
easier
done
in
some
templating
languages
and
others.
Essentially,
it
means
tracking
where
the
stateful
data
within
the
template
is
used
and
ultimately,
if
it
ends
up
either
directly
or
indirectly,
as
a
part
of
some
computed
data
used
by
a
control
flow
in
practice.
A
When
analyzing
a
template,
you
can
tell
which
parts
of
the
template
will
be
updated
as
they'll
be
tied
to
some
state
by
tracking.
If
a
state
is
used
to
update
X
content
or
an
attribute,
we
can
have
our
framework
inline
code
to
perform
targeted
updates
just
for
that
value.
Much
like
you'd
write
yourself
by
also
tracking
state
that
makes
its
way
to
the
control
flows.
That
is
the
if
statements
or
the
for
loops.
We
can
use
this
as
our
new
full
hydration
boundary.
B
Another
technique,
yet
to
be
explored
would
be
to
use
static
analysis,
potentially
across
templates,
determining
which
included
props
can
actually
be
used,
essentially
running
dead
code
removal
in
the
data
that
is
serialized
for
each
component.
The
most
frameworks,
client-side
logic,
is
clearly
separate
from
server-side
logic
and
it's
possible
to
determine
which
part
of
the
templates
can
be
updated
and
which
input
data
is
needed
for
the
client
that
is
used
by
events
for
lifecycle
events.
B
Previously
we
mentioned
that
we
can
use
this
to
advantage
simply
to
remove
code
that
will
never
run
in
our
target
environment
and
object,
optimized
hydration
for
immutable
content.
However,
we
can
also
use
this
to
track,
which
input
is
actually
needed
to
be
serialized
for
hydrated
components
for
all
immutable
components,
it's
possible
to
check
which
inputs
are
used
in
events
or
life
cycles
or
effects.
Every
other
input
is
actually
not
needed
on
the
client-side,
which
I've
tracked
correctly,
it
allows
to
prune
the
serialized
data
even
further.
A
Hopefully,
all
of
this
has
helped
show
just
how
much
dead
code
and
extra
work
their
modern
framers
currently
do
when
it
comes
to
hydrating.
These
optimizations
are
just
a
sample.
One
of
the
best
features
of
the
web
platform
is
its
ability
to
provide
an
instant
experience
to
our
users,
and
we
think
that
is
time.
Our
modern
frameworks
once
again
start
competing
on
this
fundamental
feature
of
the
web.
It's
time
to
ask
our
frameworks
to
produce
optimized
applications
across
the
stack,
and
this
time
we
finally
outperform
that
old,
WordPress
blog.