►
From YouTube: Keynote: Production Loading Performance 10 Years Later-Nicole Sullivan and Shubhie Panicker, Google
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
I
met
Ruby
years
ago
when
she
came
to
speak
at
a
conference
that
I
founded,
called
CSS
conf,
and
we
bonded
over
production
quality
loading
performance,
then
because
we
both
deeply
cared
about
it
and
it
turns
out
we
both
still
care
about
it
now.
So
we
thought
that
we
would
do
this
talk
about
we're
loading
performance
has
been
and
what
we
see
in
it
10
years
later,
and
hopefully
a
little
bit
wiser.
B
Thanks
Nicole,
so
yeah,
Nicole
and
I
are
once
again
finding
ourselves
working
on
learning
performance
and
this
time
its
performance
of
open
source
powered
ecosystem
apps
six
or
seven
years
ago.
I
was
working
on
solving
these
same
problems
for
google
internal
frameworks,
and
since
then,
there
have
been
big
strides
and
technology
advancements.
For
instance,
for
instance,
we
have
HTTP
2
and
now
HTTP
3.
We
have
great
primitives
like
payload
preconnect.
B
Still
a
lot
of
the
web
is
not
meeting
loading
performance.
Metrics
boom
recently
announced
the
web
viral
metrics.
It's
this
set
of
three
metrics
that
we
have
high
conference
impacts
user
experience
during
page
loads.
We
want
a
lot
more
of
the
web
meeting.
These
metrics
brick
buyers,
my
manager
on
the
back
platform
tweeted.
This
interesting
bit
of
data
Chrome's
usage
is
about
evenly
divided
between
sites
that
are
in
the
head,
in
the
torso
and
in
the
tail,
and
this
essentially
breaks
down
into
these
numbers.
B
We
have
a
small
number
of
head
size
about
a
hundred
sites,
a
medium
number
of
tarsus
I
lost
ten
thousand,
and
then
the
web
has
a
very
long
tail
three
million-plus
sites.
So
this
might
give
us
a
clue
into
the
UX
problems.
Are
we
reaching
each
of
these
different
audiences
with
our
work?
First,
the
best
practices
tend
to
make
it
into
well
resourced
head
sites.
They
might
even
have
teams
of
dedicated
performance
engineers,
but
we
aren't
missing
out
on
reaching
the
torso
and
tail
sites,
and
that
is
a
bulk
of
the
web.
B
So,
to
reach
more
of
the
web,
we've
realized
that
we
should
be
looking
and
developers
to
link
and
these
sites
are
often
built
using
client-side
frameworks
or
static
generators,
CMS's
or
website
builders
and
looking
further
down
the
stack.
We
see
that
a
lot
of
the
web
is
powered
by
these
open
source
ecosystem
tools
like
web
pack,
babel
npm
typescript.
B
So
now
we
have
this
new
surface,
a
full
stack.
You
consider
when
thinking
about
UX,
then
loading
performance,
but
how
and
what's
the
problem
with
loading
anyway?
Do
you
answer
this?
My
team
has
spent
a
lot
of
time
over
the
last
six
months,
looking
at
performance
of
real
Production
apps
and
all
of
those
four
apps
were
powered,
that
open
source
ecosystem
feels
like
backpack,
Babel,
NPM
and
react,
and
at
a
high
level
we
have
the
same
problem
that
I
saw
six
or
seven
years
ago.
B
It's
still
not
easy,
and
it's
a
scheduling
problem
of
proper
ordering
prioritization
pipelining
optimizing
for
metrics
in
the
correct
order.
First
FCP,
then
LCP,
then
F
ID,
the
assets
Huckabee's
Jagger's,
so
it's
ready
by
the
time
the
metric
should
trigger
based
on
who's
our
expectation.
This
means
figuring
out
which
assets
are
most
relevant
to
which
metrics
are
in
them
appropriately.
B
First
get
the
fonts
and
CSS
in
time
for
FTP
then
get
the
hero,
image
ready
for
largest
content.
Full
paint
and
I
also
see
that
time
where
the
CPU
on
the
CPU,
while
reading
on
the
network
and
vice
versa,
so
pipelining
is
important.
It
keep
the
network
and
CPU
fully
utilized,
there's
also
specific
problems
for
every
metric.
So
here's
a
couple
examples
and
other
and
I'm
too
much
into
this
for
largest
content,
full
paint,
fonts
and
CSS
critical
and
often
problematic.
They
might
be
loaded
from
a
different
domain
or
not
be
self
hosted.
B
Another
metric
example
is
first
interaction,
delay
the
most
common
culprit
here
is
large
JavaScript
or
non-critical
third-party
JavaScript.
That's
sneaking
up
ahead
of
the
primary
JavaScript
so
getting
ahead
on
the
network
or
getting
ahead
on
the
main
thread
and
causing
additional
style
and
layout
work.
B
So
I
definitely
learned
a
lot
of
lessons
along
the
way
and
the
key
theme
here
is
rounding
with
real-world
apps
and
proving
things
out
in
production.
So
the
first
lesson
is
using
production
apps
to
find
problems
and
opportunities
and
getting
to
the
ground
truth
early
on
in
the
project.
We
didn't
spend
enough
time.
Looking
at
production
apps,
we
would
ask
developers
what
their
problems
were
instead
of
looking
at
their
apps
and
understanding
and
fighting
the
problems
themselves
and
we've
definitely
been
guilty
of
looking
at
simplistic
apps
versus
full-featured,
Production
apps.
B
The
second
lesson
was
validating
designs
and
solutions.
Early
like
lab
metrics
and
a
lab
methodology
are
really
important
here
and
also
we
need
to
track
movement
in
real
world
metrics,
as
features
learned
so
some
early
features.
We
had
some
trouble
with
early
validation
when
we
implemented
you
know
serving
a
modern
JavaScript
to
modern,
browsers,
using
modular
module.
B
We
didn't
see
expected
size
equivalents
in
real
apps.
It
was
too
complicated.
There
were
too
many.
There
was
too
much
third-party
NPM
packages.
There
was
four
were
compilation,
issues
with
Babel;
sometimes
the
coal-based
didn't
have
a
ton
of
water
and
JavaScript
to
leverage
another
feature,
granular
chunks
and
we
reduced
hours
for
it,
bundles
by
30%,
but
it
didn't
move
the
web
idle
metrics.
We
didn't
have
a
good
set
up
for
real
world
measurement
or
daily
testing,
and
perhaps
javascript
size
was
on
the
best
proxy.
B
A
Could
solve
all
of
these
problems
yourself,
but
I
think
like
us,
you'd
find
that
it
was
two
steps
forward
and
one
step
back.
What
we've
realized
is
that
the
web
has
a
lot
of
really
great
raw
materials,
but
there's
some
assembly
required
and,
if
we're
being
honest,
its
massive
amounts
of
assembly
required
and
at
its
worst
it's
massive
amounts
of
assembly
required
by
every
dev
on
every
project.
Some
devs,
absolutely
love
infrastructure,
I'm,
not
one
of
them.
Others
love
building
features.
A
Sdks
are
absolutely
key
to
making
this
happen
next
next
and
Gatsby
wrap
their
respective
frameworks
and
provide
a
lot
of
things
out
of
the
box
that
the
framework
doesn't
necessarily
come
with.
They
provide
client
server
integration,
absolutely
essential
for
good
perf
outcomes
and
many
already
improved
performance
over
using
a
framework
alone.
What's
better,
there's
room
to
make
them
even
stronger
performance
wise?
A
What
sorts
of
things
goes
into
a
web
sdk,
it
might
be
back-end
server,
logic,
unit,
integration,
testing,
translations,
encapsulation
security,
image
handling,
and
the
list
goes
on
and
on
essentially
we're
trying
to
help
a
dev
to
be
as
productive
as
they
possibly
can
be
they're
building
a
production
app.
It
has
so
many
moving
parts
and
it
can
be
really
difficult
to
reason
about
how
to
string
those
together
and
how
all
the
tiny
decisions
you
make
lead
up
to
performance
outcomes.
A
So,
if
you're
thinking
this
would
bog
me
down,
I
want
minimum
opinions
and
maximum
flexibility.
I'd
love
for
you
to
turn
that
around
and
imagine
your
entire
team
with
minimum
opinions
and
maximum
flexibility
and
think
how
that
would
turn
out
often
the
sort
of
guardrails
that
keep
people
from
making
mistakes
and
the
helping
teams
work
better
together.
A
We
believe
that
most
developers
want
to
you
and
should
focus
on
building
features.
So
that's
why
Google
and
chrome
are
investing
in
jeaious
and
react.
I
want
to
be
super
clear.
We
want
all
of
the
frameworks
and
all
of
the
SDKs
to
be
successful,
but
we
did
realize
that
we're
a
small
team
and
we
needed
to
invest
in
one
set
of
stack
tools
in
order
to
have
the
biggest
impact
that
we
could.
A
That
said,
we're
very
careful
to
look
at
the
whole
stack
and
to
realize
that
each
piece
that
we
can
put
lower
down
in
the
stack
means
that
those
those
changes
that
we've
made
will
be
easier
to
pick
up
for
other
stacks.
If
we
make
a
change
in
webpack,
then
everybody
that
uses
webpack
can
leverage
that,
as
opposed
to
simply
building
it
into
next
itself.
A
We've
had
some
initial
perf
winds
that
were
pretty
happy
about
improved
chunking,
reduced
bundles
by
25
to
75
percent,
improving
caching
and
faster
navigations,
particularly
happy
to
see
that
ship
in
in
Gatsby.
That's
the
sort
of
ecosystem
benefit
where,
when
we
will
all
work
together
in
the
Commons,
we
see
greater
outcomes
than
any
of
us
could
get
alone.
We
also
shipped
a
polyfill
chunk
in
version
9.3.
A
It
reduced
about
16
K
from
the
baseline
of
an
XJS
hello
world
app,
and
we
ship
chat
CSS
prioritized
over
javascript
in
9.2
that
reduced
FCP
by
up
to
40%
in
our
partner
apps.
We're
really
excited
to
see
that
filter
out
to
the
rest
of
the
next
j/s
ecosystem,
so
that
we
can
find
out
if
it
has
similar
effects
on
other
web
sites.
A
We
also
added
out-of-the-box
perf
metrics
should
be
talked
to
you
a
lot
about
the
web,
vital
metrics
that
have
been
recently
released.
We
added
them
to
next
jeaious
out
of
the
box,
so
an
application
that
wants
to
measure
their
performance
doesn't
have
to
actually
do
it
individually.
They
have
it
baked
in
and
they
just
need
to
turn
it
on
and
point
those
metrics
where
they'd
like
to
get
them.
A
The
other
piece
of
that
is
that
we
added
a
couple
new
metrics
time
to
hydration
which
measures
something
like
interaction,
readiness
and
time
to
route
render,
which
is
sort
of
like
an
SP,
a
navigation
metric.
Those
are
two
areas
where
we
hope
that
what
vitals
metrics
can
grow
in
the
future
and
so
we're
testing
them
out
ahead
of
time
in
next
j/s
apps.
A
We
also
tested
reax
concurrent
mode
with
a
partner
app
for
SEL,
and
we
found
a
fifty
to
seventy-five
percent
improvement
in
interaction,
readiness
for
the
first
interaction,
and
we
found
similar
improvements
in
total
blocking
time
and
also
saw
improvements
in
lighthouse
score
and
metrics.
But
we
realized
as
well
that
the
upgrade
path
is
non-trivial
for
apps.
Our
hope
is
that
we
can
make
the
upgrade
smoother
by
baking
in
some
defaults
into
the
SDKs,
so
that
other
developers
benefit
from
our
experience,
upgrading
to
concurrent
there's
a
trade-off
between
developer
experience
and
user
experience.
A
In
a
lot
of
cases,
it's
hard
to
fix
loading
performance
wholesale
without
a
significant
change
to
developer
experience.
When
should
be
made,
these
changes
at
Google,
they
were
able
to
make
the
head
completely
declarative
and
configuration
driven.
That
means
that
any
change
to
the
head
was
explicitly
declared
in
a
manifest
file
and
the
configuration
had
defaults,
for
example,
for
fonts
and
CSS.
It
also
had
an
ordering
and
loading
strategy
that
was
controlled
by
the
framework
developers
like
writing
code
and
they
really
don't
like
updating
config
files.
A
A
The
lesson
we
take
from
that
is
that
it's
important
to
maintain
that
developer
experience
and,
at
the
same
time
improve
user
experience.
Developer
experience
is
gold
for
the
web.
It
means
that
developers
will
choose
to
and
want
to
work
on
the
web,
we'll
continue
working
on
the
web
once
they've
gotten
started
and
it
gets
new
dos
up
and
running
and
building
great
features
faster.
It's
also
important
for
content
diversity
so
clearly
compromising
developer.
Experience
is
a
risk
to
the
web
as
a
platform,
and
it
has
to
be
very
thoughtfully
considered
for
one.
A
So
what's
next
in
2020
for
our
project,
we're
gonna,
look
at
critical
inlining
of
CSS
we're
going
to
look
at
font,
optimizations
and
third-party
script,
scheduling
we're
also
looking
at
screaming
streaming
and
more
developer
time,
guardrails
that
are
built
into
web
pack,
es
lint
and
probably
into
other
bits
of
the
stack
as
well
we're
looking
at
images
around
sizing
and
scaling
and
image
placeholders.
Also
polyfill
delivery
data,
fetching
and
reax
concurrent
mode,
we'll
be
digging
into
that
further.
A
Will
all
of
that
work
almost
certainly
not,
but
we're
excited
to
see
some
of
it
turnout
performance
improvements
through
the
end
of
the
year.
So
when
I
go
back
to
this,
we
really
think
that
we
can
get
to
a
place
where
much
less
assembly
is
required
for
a
developer
on
the
web
and
all
different
kinds
of
developers
can
produce
great
user
experience
thanks
so
much
for
having
us
here
today.
These
are
our
twitter
handles
and
we'd
love.
To
talk
to
you
more.