►
From YouTube: WASM and Core Web Vitals - Jozi.js March
Description
A Whimsical Walkthrough of Wasm Proposals
Duncan Dean (@dunxen)
We'll take a little stroll through what WebAssembly is and why we might want to use it in the browser for the unacquainted. Then we'll focus on recently standardised features of Wasm and more proposals to come. We'll be discovering problems along the way and how these features and proposals can help us overcome them. It'll also become clear that JavaScript and Wasm are friends after all!
Core Web Vitals
Mike Geyser (@mikegeyser)
📢Submit a talk: https://goo.gl/forms/66MrplT1FogDX88Q2​
💛Code of conduct: https://docs.google.com/document/d/1j-OfcTwYejEj-WiQq9F9AcVv2L-Ki81RuhFTjquDJyk/edit?usp=sharing
Meetup: https://www.meetup.com/Jozi-JS/events/276828228/
A
So
today
is
march,
so
march
is
about
a
quarter
of
the
way
through
the
year,
which
is
quite
terrifying,
because
it's
going
so
quickly
march
is
also
the
month
of
international
pie
day,
which
excites
me,
because
I
like
pie,
I
also
like
the
leprechauns
and
so
happy
happy
houston,
paddy's
day
to
everybody
who
celebrated
that
yesterday.
I
hope
that
you
had
fun
and
also
social
distance
yeah.
So
this
is
a
picture
of
not
social
distancing
at
all.
This
is
how
we
used
to
run
this
thing
in
the
before
times.
A
We
have
a
code
of
conduct.
This
code
of
conduct
is
quite
straightforward
and
obvious,
really,
basically
just
be
a
good
person
just
be
kind
to
each
other.
If,
like
just
keep
in
mind
the
fact
that
people
are
here
to
learn
and
grow,
so
yeah
respect
that
if
anybody
gives
you
trouble,
if
anybody
isn't
performing
like
according
to
our
code
of
conduct,
then
please
feel
free
to
reach
out
to
one
of
our
wizards.
A
So
anyone
on
this
page
here
is
willing
and
able
to
help
and
will
be
receptive
to
your
your
issues.
If
you
have
any,
we
are
real
wizards,
even
though
our
hats
are
not
so
real.
I'd
also
like
to
thank
our
sponsors,
so
we
have
two.
You
know
this
sponsors,
the
stream.
So
thank
you
and
the
other
one
is
microsoft
azure
and
they
sponsor
our
meetup.
A
A
So
if
you,
if
you're
new-
and
you
don't
know
if
you
like-
if
you
can
do
a
good
talk-
just
chat
to
us
about
it
and
if
you
need
help
developing
your
idea,
if
you
want
to
run
through
your
talk
ahead
of
time,
to
make
sure
that
it's
cool
like
new
and
experienced
talkers,
are
welcome
and
we'll
we'll
help
you
out
and
you
can
watch
all
our
old
talks
right
here
on
youtube.
So
that's
pretty
easy
and
that's
it.
I'm
over
to
our
first
speaker
duncan
dean.
Welcome
duncan.
B
Thanks
so
much
so
hey
everyone.
This
is
my
first
time,
speaking
at
josie.js,
actually,
first
time,
speaking
anywhere,
I'm
going
to
be
talking
about
some
wasm
stuff
and
I
thought
the
best
way
to
get
everyone's
attention
for
talk.
Title
is
to
use
alliteration
yeah,
so
we
went
with
that.
A
whimsical
walkthrough
of
wasm
proposals,
so
just
a
bit
more
about
me,
is
that
I'm
a
web
tech
lead
at
luno.
B
If
you
haven't
heard
of
luno,
I
can
show
it
at
the
end
yeah.
So
a
few
more
things.
This
is
my
debut
talk,
as
I
mentioned,
outside
of
luno,
so
other
than
a
few
lunch
lectures
and
internal
talks.
We
do
within
the
company.
This
is
my
very
first
talk.
I
have
a
background
in
physics,
bachelors
in
physics
and
major
to
maths.
B
Usually,
my
spare
time
is
filled
with
playing
around
with
bitcoin
and
the
lightning
network
setting
up
nodes.
If
you
want
to
talk
to
me
about
bitcoin
and
scaling
off
chain
and
transactions
on
the
lightning
network,
then
yeah
I'd
really
love
to
do
that
and
then
also
wasm.
But
today
we'll
just
talk
about
wasm
and
maybe
I'll
show
some
bitcoin
in
between.
B
So
also
a
disclaimer
and
a
few
things
about
this
talk
we're
staying
in
the
shallow
end
of
the
pool
going
slightly
deeper,
there's
lots
of
in
progress
and
standardized
features
for
wesm
already,
but
I'm
only
going
to
talk
about
four
and
these
four
I'm
kind
of
partial
to
because
they
they're
my
favorites
yeah
and
I
think
I'm
the
most
excited
about
them.
But
there's
a
whole
bunch
of
other
proposals
out
there.
I'll
mention
them
at
the
end
and
then
you
can
just
dive
into
them.
In
your
own
time.
B
B
And
what
might
be
interesting
to
you
is
that
although
webassembly
has
its
own
human
readable
format
that
you
can
write
in,
usually
you
want
to
use
it
as
a
compilation
target.
So
it
supports
well
a
wide
variety
of
languages
already
supported
as
a
compilation
target
from
c
plus
plus
rest
assembly
script,
which
supports
it.
I'd,
say
the
most
have
the
best
support
for
it.
So
far,
then
you've
got
go
and
your
swiftwasm
projects,
many
languages
with
llv
backends,
already
supported
natively,
so
yeah.
B
B
B
B
So
that's
sort
of
the
human
readable
format
and
if
you
use
a
tool
from
webbit,
it's
wabt
there's
a
tool
called
what
to
asm
or
wet
to
asm
and
it
takes
your
wet
code
and
it
compiles
it
into
a
wesm
binary
module.
And
so
this
is
just
a
hexadecimal
representation
of
it.
We're
not
going
to
go
into
the
encoding
at
all,
but
it
is
very
interesting.
So
I
definitely
I
definitely
recommend
going
going
through
that
in
the
spec
there's
a
lot
of
videos.
B
So
if
you
don't
know,
figma
is
a
design
interface
editor
for
the
web,
it's
written
in
c
plus
originally,
and
it
was
compiled
to
asm.js,
which
is
a
basically
a,
very
restricted
subset
of
javascript
that
can
be
compiled
quite
that
can
be
optimized
quite
easily
by
browser
engines.
So
so
obviously
they
wanted
to
bring
their
tooling
that
was
written
in
c
plus
plus
to
the
web.
B
B
But
actually
it's
expected
because
javascript
number
has
limitations.
The
spec
is
basically
double
precision
floating
point
numbers
that
it
uses
and
it
can
represent
integers
with
that
spec
in
binary
representation.
So
there
is
a
very
specific
limitation.
Is
that
max,
safe
integer,
so
the
maximum
integer
that
you
can
safely
represent
in
that
binary
format
is.
B
Is
that
integer
on
screen?
So
it's
it's
funny
enough
that
the
odd
integers
after
this
integer
you
cannot
represent
at
all
and
then
things
start
to
break
down
further
down
the
line.
You
can
read
this
book
about
floating
point
arithmetic
and
representing
binary
numbers,
but
we're
not
going
to
go
too
much
into
that
because
because
me,
but
now
we
have
biggins,
of
course,
and
it's
very
widely
supported,
we'll
just
ignore
internet
internet
explorer
because
insert
internet
explorer
jakir,
I'm
not
going
to
make
my
own.
B
B
So
this
is
an
example
of
a
wesm
function
where
you'd
use
it,
and
I
said
I
wouldn't
be
shelling
bitcoin,
but
I
thought
it
would
you
know
it
wouldn't
be
my
talk
if
I
didn't
so
so.
This
is
a
wes
module,
we've
defined
a
function
and
it's
export's
name
is
checknet
millisats,
so
sats
are
satoshi's,
it's
the
smallest
units
of
a
bitcoin,
but
on
the
lightning
network
you
can
actually
go
smaller
than
a
than
that
because
it's
off
chain,
so
you
can
get
miller
satoshi's.
B
B
B
The
input
amounts
and
your
third
parameter
would
be
your
output
amounts
in
a
bitcoin
transaction
and
then
the
results
would
be
the
remaining
amounts,
because
bitcoin
transactions,
the
inputs
amounts
added
up,
must
be
greater
than
or
equal
to
the
output
amounts.
The
difference
is
minor
fees.
So
if
you
have
no
difference
in
the
inputs
and
outputs,
then
your
transactions
probably
not
going
to
go
through
because
you've
got
no
fees.
B
So
what
we
do
here
is
we'd
add
the
first
two
parameters
to
the
stack.
So
this
takes
the
zeroth
and
first
parameter
and
then
puts
it
on
the
stack.
We'd
call
the
i64.ad
instruction
and
then
that
would
push
the
result
of
the
ad
onto
the
stack
and
now
we'd
get
local.get2,
which
is
our
third
parameter
and
that
would
get
pushed
onto
the
stack.
B
B
So
at
the
time
of
nvp
wasn't
functions
could
consume
multiple
values,
so
they
still
can
consume
multiple
values
as
operands,
but
they
can
only.
They
could
only
return
a
single
value-
and
I
mentioned
before
I'll-
explain
the
only
four
types
that
you
can
consume
as
values
and
return
as
values
are
the
integer
and
float
type
so
i32
i64
and
then
the
corresponding
f32
f64
types,
so
they
they
can
be
written
as
a
result.
B
So
so,
let's
say
pre-multi-value
you'd
have
you'd
have
to
do
some
trickery.
You'd
have
to
set
some
global
variables,
so
we
just
initialized
them
at
zero,
we're
just
using
i32s
here
we're
not
worried
about
big
numbers
or
overflows
or
anything
like
that,
and
then
you
define
a
function.
Op
swap.
So
this
is
something
you
see
in
a
lot
of
stack
interpreters.
It
will
swap
the
two
values
on
the
top
of
your
stack.
B
So
if
we
take
in
two
parameters,
i32
both
i32
types
and
we'll
add
them
to
the
stack,
local.get1
and
local.get0,
so
we
adding
the
second
one
to
the
stack
and
then
the
the
first
one
will
be.
On
top
of
that
because
each
item
we
push
it
onto
the
stack.
So
it's
the
last
item
that
you
push
that's
at
the
top
and
then
we'll
do
global
dot,
set
0
and
global
dot
set
1
and
then
outside
of
the
function,
you'll
figure
out
which
globals
to
access.
B
And
it's
it's
some
it's
extra
code,
it's
a
little
bit
messy.
It
increases
your
bundle,
size,
your
where's
and
module
size,
and
it's
a
little
bit
slower
because
of
the
global
variables,
but
with
multi-value
this
actually
becomes
a
lot
smaller.
It's
up
swap!
Then
you
still
have
two
input
parameters,
but
this
time
you
can
have
two
results.
B
Two
result
values,
so
you
can
have
so
then
you
do
the
same
thing
you
you
add
the
second
parameter
to
the
stack
and
then
the
first
parameter
to
the
stack
and
then
it
will
just
return
just
like
that.
So
you've
basically
swapped
it.
So
you
don't
need
to
do
anything
further.
Those
values
on
the
stack
will
return,
so
that's
pretty
cool.
That
makes
a
lot
smaller
and
more
efficient.
B
So
currently
there
are
two
ways
to
get
wasm
into
js
land
and
it
either
involves
using
webassembly.instantiate
streaming
and
then
you'll
use
a
streaming
source
like
fetch
and
then,
where
I've
cut
out
that
object.
You'd
have
your.
That
would
be
your
import
object.
So
if
you
create
memory,
then
you'd
have
you'd.
Add
it
to
that
object
and
then
your
webassembly
module
can
can
use
that
as
an
import
or
you
can
actually
add
functions
there.
That
can
be
imported.
B
B
The
other
way
is
compile
streaming.
This
is,
if
you
want
to
first
pre.
First,
compile
your
wasm
module
in
case.
You
want
to
pass
around
or
do
some
other
things
before
instantiating
it
before
having
the
cost
of
instantiating
it
with
memory
and
other
things
like
that.
So
you
can
see
that
at
the
instantiate
step,
that's
where
you'd
actually
give
your
import
objects.
You
wouldn't
do
it
in
compile
streaming
because
that's
not
part
of
instantiation
and
then
the
same
way
to
access
your
exported
function.
B
There
are
non-streaming
equivalents
to
instantiate
streaming,
compile
streaming,
but
they're
not
really
recommended
because
they're
less
efficient,
for
example,
instantiate
streaming
streaming,
does
not.
If
you
look
at
just
instantiate
that
uses
an
array
buffer
as
an
overload
in
the
middle
and
instantiate
streaming
doesn't
so
it
hasn't
got
this
extra
overhead,
but
now
wouldn't
it
be
nice
to
just
get
that
exported
function
straight
as
if
you're
importing
it
straight
from
your
wesm
file.
B
B
So
another
thing
that
this
proposal
would
enable
is
weapon
modules
to
be
able
to
take
part
in
js
module
dependency
graphs.
So
if
you
had
a
js
module
counselor.js,
so
this
is
not
really
doing
anything
specific.
It's
it's
just
returning
a
defined
variable
and
you
exported
git
counts.
You
could
actually
import
directly
in
a
similar
way
within
your
wasm
module
without
creating
a
whole
instantiate
streaming
and
import
object,
and
so
this
is
a
lot
smaller
and
a
lot
more
succinct,
and
I
think
it's
also
more
maintainable.
B
B
So
if
we
look
at
how
to
create
a
new
wasm
memory
within
javascript,
so
this
is
even
for
non-shared
memory.
You'd
use,
webassembly.memory,
constructor
and
you'd
give
it
an
object
with
initial
and
maximum
page
values.
So
webassembly
memory
is
measured
in
pages
which
are
64
gigabits,
each
or
cubic
bytes.
Each
and
the
this
proposal
adds
a
shared
property
that
you
can
set
to
true,
telling
it
to
use
a
shared
array
buffer
under
the
hood
and
then
what
you
can
do
is
each
webassembly
module
that
you
instantiate.
B
You
can
supply
it
with
that
very
same
memory
handler
so
that
they
can
all
access
that
same
shared
array
buffer
and
how
you'd
import
it
from
wasm
land.
Is
that
you'd
use
an
like
an
import
statement
from
that
environment
property?
Then
you
get
your
memory
out
of
there
and
then
it's
also
like
a
signature
that
you
give
memory
one
one.
It's
the
same
initial
maximum
and
then
shared
declaring
it
as
shared,
and
why
would
you
want
to
do
this
well
or
how
would
you
actually
accomplish
using
threads
in
webassembly?
B
Is
that
you'd
need
to
instantiate
a
webassembly
module
in
different
web
workers
or
in
your
host
in
your
main
thread
and
then
share
that
memory
with
web
worker?
So
I
call
it
wasmizing
your
web
workers
and
that's
instantiating
webassembly
modules
within
different
web
workers
and
the
way
you
would
get
the
memory
over
to
the
the
shared
memory
over
to
the
web
worker.
Is
you
just
use
post
message?
Obviously
this
just
sends
the
wrapped
object.
B
B
I
think
since
2.23
version
2.23
or
something
they
did
some
tests
with
mobile
net
v2,
so
they
had
some
d,
which
is
also
another
wisem
proposal
and
threads
enabled
for
webassembly
across
webworkers
versus
webgl,
and
it
actually
performed
web
outperformed
webgl
for
for
inference
on
mobile
net
v2
yeah.
So
there's
a
google.
B
So
also
a
bit
of
warning
around
using
this
okay.
First
of
all
not
mentioned
here
is
that
it
doesn't
like
it
might
not
fit
your
use
case
to
use
it.
There
is
an
upfront
cost
to
instantiating
modules
and
web
workers,
so
you
just
got
to
make
sure
on
the
clients
you're
targeting
and
your
actual
application
if
it
makes
sense
for
you.
But
if
you
do
want
to
use
webassembly
threads
browsers
now
require
cross-origin
ice
to
be
cross-origin,
isolated,
so
you'll
need
your
code
and
co-op
headers.
You
can
see
more
about
this
at
web
dot.
B
Devslash
co-op
dash
code,
so
chrome
actually
currently
allows
shared
array
buffers
by
default,
so
the
use
of
shader
buffer
by
default,
but
from
chrome
91.
You
must
opt
in
with
to
be
cross.
Origin
isolated,
like
above
that's
just
to
make
sure
that
everyone's
going
according
to
the
same
spec,
and
then
they
had
side
isolation
before,
but
so
so
that
you
know,
that's
fixed
some
of
the
problems
with
spectre
and
meltdown,
but
I
think
everyone
decided
decided
on
one
spec
and
yeah
went
for
that.
B
B
So
I'd
see
the
current
states
of
proposals.
Actually,
so
we
didn't
go
through
all
of
these,
but
you
can
see
that
there's
there's
been
a
lot
of
standardized
features.
Kroman's
firefox
seemed
to
support
most
of
them.
Some
some
might
be
behind
feature
flags
safari,
still
a
little
bit
behind
with
the
standardized
features
in
progress
proposals.
B
So
that's
still
like
you
know
here
be
dragons,
things
might
change,
but
there
are
some
interesting
things
coming
up
and,
as
you
can
see,
there's
also
wasm
time
in
westmore,
so
those
are
out
of
browser
land
so
that
they
own
webassembly
runtimes,
not
in
the
browser.
So
it's
for
other
applications,
even
server
side.
B
B
So
this
is
better
for
users
at
the
end
of
the
day,
because
they
need
to
download
the
wasm
modules
and
then
also
instantiate
them.
And
then
you
know
you
can
reduce
the
runtime
cost
of
functions
and
it's
just
all
around
good
news
yeah.
So
that's
me.
Actually,
thanks
for
listening
and
yeah
I'll
go
ahead
for
any
questions.
If
you
have.
A
Oops,
thank
you
yeah.
So
there
aren't
any
questions
yet,
but
we
have
recently
changed
how
we
receive
questions,
so
it
might
just
be
because
of
that
new
new
weirdness.
I
figured
let's
go
on
to
the
next
talk,
but
everyone
is
watching.
You
can
ask
questions
for
mike
or
duncan
just
in
the
youtube
chat
as
we
go
along
and
we
can
just
tackle
them
all
right
at
the
end.
So
next
up
is
my.
A
B
So
so,
within
our
own
company,
unfortunately
not
but
there
there
are
actually
some
plans
to
use
it
for
our
new
sort
of.
How
can
I
describe
it,
presentational
state
machine
so
that
we
can
so
that
we
can
also
deploy
it
to
mobile
apps,
as
well
as
our
websites
yeah,
but
I
wouldn't
say
we're
not
using
anything.
Currently.
A
C
Hi,
suddenly
I'll
stop
asking
questions
as
you
as
you
may
have
guessed.
We
are
new
to
this
streamyard
streaming
service,
we're
trying
to
figure
out
who
clicks
which
buttons,
so
I
apologize
for
accidentally
clicking
buttons
a
little
bit
earlier
duncan
duncan's
talk
was
amazing.
I
learned
so
much
about
webassembly
from
it
and
I
have
even
more
questions
but
I'll
leave
them
for
the
moment.
C
C
Why
is
it
so
cold,
but
in
this
particular
one
we're
going
to
be
asking?
Why
do
we
care
about
the
core
web
vitals
now,
as
those
of
us
who
work
in
the
web,
no
or
in
any
software
know
that
performance
is
seldom
prioritized
as
a
feature
until
it's
way
too
late
right
until
everything's
on
fire,
and
we
have
problems
and
the
web
vitals
are
a
part
of
changing
that
culture,
specifically
in
the
web.
Now
as
to?
Why
you
should
care
particularly
about
performance
and
performance
on
the
web?
C
Maybe
you
or
your
users
or
you.
You
feel
that
your
users
have
a
desire
not
to
be
bombarded
by
moving
parts
that
are
ancillary
to
the
experience,
that
sort
of
interrupt
your
users
and
get
them
away
from
the
content
that
you're
trying
to
show
them
or
the
the
the
path
that
you're
trying
to
take
them
down.
C
Or
maybe
you
know,
maybe
you
you
care
about.
You
know
the
impact
of
ads
and
unexpected
shifts
where
you
know
you've
been
there
there,
where
there's
suddenly
a
big
stinking
ad
that
loads
on
something
and
you
click
a
button.
You're
like
wait.
No,
I
didn't
mean
that
I
clicked
on
the
ad
instead
and
it's
awful
or
maybe
it's
one
of
those
websites
where
it
looks
like
it
should
be
doing
something,
and
then
you
click
and
you're,
not
sure
and
you
click
click,
click,
click
and
then
suddenly.
C
C
We
can
build
experiences
that
we
can
consume
ourselves,
or
maybe
maybe
you're
just
a
business
and
you
care
about
the
the
ransom
sense
of
the
situation,
and
there
are
compelling
reasons
as
to
why
you
should
care
about
performance
from
those
perspectives.
Maybe
you
care
about
having
competitive
advantage
over
your
competitors.
C
Now.
The
one
thing
that
I
will
mention,
particularly
in
context
of
core
web
vitals,
is
why
you
should
care
is
because
there
is
actually
a
big
deadline
looming
for
anybody.
That
knows
anything
about
about
search.
You
would
know
that
google
intends
on
using
the
call
web
vitals
that
we're
going
to
talk
about
in
their
search
engine
up
search,
ranking
algorithm
as
a
part
of
something
called
page
experience.
C
There
are
three
core
web
vitals
that
are
currently
in
the
the
stable
now
those
are
firstly
largest
contentful
paint,
which
is
essentially
how
long
it
takes
for
the
largest
image
or
piece
of
text
or
heading
to
appear
on
the
page
and
is
used
as
a
user-facing
metric
for
how
long
the
page
is
perceived
to
load
initially
and
they
trialed
a
whole
bunch
of
different,
more
complicated
metrics.
But
this
one
finding
the
single
html
element
on
the
page
that
loads
that's
biggest
and
how
long
that
takes
to
load
is
a
very
simple
thing
to
calculate.
C
Then
something
else
called
first
input.
Delay
is
effectively
how
long
it
takes
for
the
user
to
be
able,
or
for
the
page,
to
be
able
to
respond
to
user
input
as
a
sort
of
understanding
of
interactivity
and
how
quickly
the
page
is
interactive
or
like
lag
in
other
terms.
Measuring
this
can
be
complicated,
but
first
input.
Delay
is
the
simplification
on
other
lab
metrics
that
we'll
talk
about
a
little
bit
later
and
then.
C
C
We
know
that
because
it's
such
an
interesting
and
innovative
metric
layout
shift
will
be
weighted
more
than
it
is
currently
in
other
tools
which
we'll
talk
about
again
a
little
bit
later,
and
an
outstanding
problem
is
trying
to
figure
out.
What
is
what
does
that
layout
shift
mean
when
you
get
to
sites
that
are
more
than
just
a
content,
page
that
loads
that
you
interact
by
scrolling
up
and
down
when
it's
a
single
page
application
that
you're
going
to
interact
with
for
a
long
period
of
time
or
it
represents
an
infinite
scroll.
C
C
That
is
these
call
way
vitals
and
what
is
the
relationship
between
them?
How
do
you?
How
do
you
measure
apples
with
apples
across
the
two
so
to
explain
this?
We
need
to
talk
about
run
and
no,
I
don't
mean
that
kind
of
rubbing.
I
mean
real
user
metrics,
so
measuring
actual
data
from
actual
people
in
the
field,
so
to
understand
the
the
important
difference
between
lighthouse
and
the
core
vitals,
you
need
to
understand
the
difference
between
lab
data
versus
field
data.
C
So
importantly,
if
you
take
a
look
at
any
data,
so
let's
say
this
is
first
input
delay.
For
example,
your
data
is
not
a
single
point:
it's
not
a
single
number,
it's
a
histogram
that
represents
a
range
of
different
possible
first
input
delays
or
loading
times
or
whatever
the
case
may
be,
some
of
which
is
good
in
the
front
of
the
graph
and
some
of
which
is
bad
near
the
back
of
the
graph.
Now
that
is
your
field
data.
C
Typically,
the.
What
we
do
is
we
use
percentiles
to
figure
out
so
like
the
50th
percentile
would
be
not
the
average.
It
means
that
50
of
your
users
have
this
experience
or
better
95th
percentile
would
mean
that
95
of
your
users
have
this
experience
or
better
and
75th
percentile,
which
is
the
one
that
we
commonly
use
when
talking
about
the
stuff
means
that
75
of
your
users
will
have
this
experience
or
better.
C
C
It
is
the
average
of
those
runs
or
even,
if
you
do
whatever
you
end
up
doing
in
terms
of
statistically
figuring
out
what
you
think,
though,
your
your
metric
looks
like
in
the
lab
lighthouse
is
going
to
sort
of
approximate
the
75th
percentile
result.
Okay,
so
lighthouse
tries
to
reflect
the
worse
end
of
your
statistics,
won't
be
accurate,
it
won't
ever
match
up,
but
the
idea
is
that
your
75th
percentile
core
web
vitals
should
be
close
to
your
lighthouse
results.
C
C
So
if
we
take
a
look
at
light
us-
and
this
is
where
light
us
comes
in
it
lets
you
iterate
really
really
rapidly,
you
can
do
it
on
your
local
machine.
You
can
run
a
couple
things.
It
gives
you
really
really
good
actionable
feedback
and
stuff
that
you
can
do
right
now,
but
it
doesn't
necessarily
represent,
what's
actually
happening
in
the
wild.
C
So
if
we
take
a
look
at
the
individual
metrics
that
represent
lighthouse,
firstly,
when
we
look
at
cumulative
layout
shift
lighthouse
only
measures,
the
layout
shift
on
page
load
above
the
fold,
so
the
second,
the
user,
scrolls
down
any
shifts
that
happen
underneath
that
are
on
top
of
it.
So
if
you
take
a
look
at
cls
in
the
wild,
it's
going
to
be
higher
than
your
lighthouse
score
almost
guaranteed.
C
First
contentful
paint
should
be
very
similar
because
your
first
contentful
paint
could
be
above
the
fold,
but
keeping
in
mind
that
if
people
are
deep
linking
to
a
big
long
document
and
they're
going
to
a
specific
item
on
that
document,
your
first
contentful
paint
might
actually
be
halfway
down
the
page
right
if
you've
got
a
hyperlink.
That
goes
straight
into
an
anchor
tag
there
and
then
for
first
input.
C
Delay
first
input
delay
are
I
have
two
proxy
metrics
that
get
used
in
conjunction
in
lighthouse
data,
and
those
are
total
blocking
time
and
time
to
interactive
now.
Total
blocking
time
is
the
amount
of
time
that
javascript
blocks,
execution
or
queuing
of
tasks
on
the
main
thread
and
time
to
interactive
is
how
long
it
takes
for
there
to
be
a
five
second
gap
of
silence
in
your
cpu
data
or
your
cpu
usage.
C
Now
those
should
match
and
those
those
are
similar,
so
they
should
be
close
results,
but
in
practice
that
could
vary
quite
dramatically.
So
it's
just
something
to
keep
in
mind
that
the
lab
dates
and
the
field
data
don't
necessarily
align
completely
because
you're
measuring
two
different
things
and
you're
building
an
association
between
them.
C
C
C
So,
let's
pivot
a
little
bit
and
let's
talk
about
what
tooling
is
available
to
help
you
in
this
endeavor
right,
so
we're
going
to
start
off
with
chrome
dev
tools.
Now
this
is
very
specifically
the
performance
panel
in
chrome,
dev
tools
and
I'm
just
going
to
focus
on
a
couple
small
elements
that
are
relatively
new
or
relatively
good
to
look
at
for
the
stuff.
C
To
start,
we
can
see
that
they
surface
things
like
the
lcp,
fcp
and
layout
shift
events
as
a
part
of
the
timing
section.
So
there
is
a
little
tag
that
you
can
click
on
that
says
lcp
and
it's
going
to
show
you
well.
This
is
when
your
largest
contentful
paint
happened
and
at
the
bottom
there
it's
going
to
tell
you
exactly
which
item
it
picked
up
as
your
largest
contentful
paint,
which
is
super
useful.
C
The
for
fid
or
first
input
delay.
You
can
see
all
of
the
tasks
that
are
that
are
cued
and
the
fact
that
they
they're
queued
end
to
end
and
that
there
are
no
gaps
in
between
them.
That
means,
from
this
point
onwards,
it's
very
difficult
for
a
user
event
to
wait
for
javascript
to
finish
running
before
it
itself
executes
and
can
be
acted
upon.
C
C
Google
information
about
what
my
load
time
is,
so
that
we
can
make
the
web
faster.
Now.
Currently,
the
the
crux
data
set:
has
the
top
8
million
origins
available
in
it,
and
you
can
query
it
directly
in
bigquery,
if
you're
one
of
those
people,
you
can
use
the
crux
dashboard
or
you
can
use
the
the
crux
rest
api,
which
is
exposed
and
on
the
right
hand,
side.
You've
got
an
example
of
a
very
simple
sort
of
high
level
chart.
That's
been
created
using
the
rest
api.
C
C
How
many
users
have
a
good
experience
versus
an
experience
that
needs
improvement
versus
a
poor
experience,
and
you
can
figure
out
based
of
your
usage
statistics,
how
big
their
problem?
Demographic
is
as
well
as
what
the
75th
percentile
of
that
data
looks
like,
which
is
really
really
useful,
and
it
looks
like
it's
free.
I
don't
understand.
It's
amazing.
C
Back
to
chrome
in
the
browser
there
is
work
being
done.
Obviously,
the
the
core
web
titles
can
be
surfaced
straight
from
chrome.
You
can
in
your
dev
tools
you
you
can
in
canary,
but
soon
you
will
in
chrome,
proper
you're
able
to
show
a
small
hud
that
shows
what
the
core
web
vitals
are
for
any
given
given
page
and
if
you're
impatient
like
me,
you
can
just
go
and
download
this
extension.
C
That
does
literally
the
exact
same
thing,
and
it
gives
you
the
web
titles
for
every
single
page
that
you
want
it's
backed
by
essentially
the
same
code.
There's
no
real
difference,
the
one's
just
going
to
be
built
into
chrome,
so
you
don't
need
a
separate
extension
for
it,
which
is
cool
so
how
I've
shown
you
the
tools.
I've
shown
you
the!
What
showing
you
explain
to
you
the
what
whatever?
C
How
do
we
go
about
optimizing
these
things?
Well,
let's
tackle
them
one
at
a
time
and
we're
going
to
do
this
at
a
very
high
level,
because,
unfortunately
the
devil
is
in
the
details,
but
if
we
take
a
look
at
lcp
and
how
one
optimizes
for
it,
basically,
we
want
to
optimize
how
quickly
the
user
sees
the
primary
page
content,
which
means
that
anything,
that's
blocking
the
critical
render
path.
We
need
to
get
out
of
the
way
now,
there's
two
large
camps
as
to
how
to
do
that.
C
C
So
that's
one
school.
The
other
one
is
to
just
speed
up
the
content,
download
itself
to
prioritize
that,
so
you
can
pre-connect
and
pre-download
critical
content
so
that
as
soon
as
we
hit
that
in
the
html,
it's
immediately
visible
and
that
improves
lcp
and
that
score.
And
if
you
like,
if
you
can,
I
can
strongly
urge
that
you
consider
pre-rendering
or
at
least
server-side
rendering
as
much
content
as
possible,
because
if
you
can
deliver
all
of
the
html
without
needing
to
create
it
using
a
javascript
library,
it
will
be
immediately
visible.
C
That's
what
the
browser's
designed
to
do,
and
if
you're
digging
through
stuff
and
trying
to
figure
out
what
to
do.
I
would
caution
you
to
be
careful
with
isomorphic
or
universal
javascript,
because
it
matters
the
water
as
to
what's
a
server-side
concern
versus
what's
a
client-side
concern
and
becomes
difficult
to
optimize.
C
Moving
on
to
cls
layout
shift
is
really
really
hard
and
every
single
ux
pattern
that
we
use
that
might
be
intentional
or
unintentional.
Cynical
or
not
has
a
different
case
around
it.
But
the
one
thing
that
I
can
definitely
say
is
that
you'll
benefit
from
inlining
critical
styles.
So
the
things
that
handle
where
stuff
is
on
the
page
so
that
the
content
blocks
be
that
images
or
be
their
pieces
of
text,
don't
move
around
on
page
load.
C
Fonts
are
another
example,
so
you
can
use
font
display
optional
to
when
you're
downloading
a
font
not
wait
for
it
and
block
rendering,
but
give
it
a
finite
amount
of
time
to
download
and
then
just
ignore
it
and
use
a
base
system
font
and
then
importantly,
like
defer
css.
If
you
can,
if
you
don't
need
it
on
page
load,
don't
load
it
on
page
load
and
don't
send
down
styles
that
you
don't
need
for
that.
That
page
view
and
then
finally
optimizing
for
fid
or
first
input
delay.
C
C
C
A
C
C
I
think,
obviously,
obviously
it
depends.
It
depends
on
the
use
case
and
it
depends
on
what
you're
building.
But
I
think
that
simplistically,
the
answer
is
yes,
because,
if
you're
building
a
whole
bunch
of
pages
that
the
user
may
or
may
not
visit
and
you're,
sending
them
all
down
to
that
user
before
they've
had
the
choice
of
where
they
want
to
visit.
C
The
way
that
we
used
to
build
client-side
experiences
like
desktop
applications
and
the
way
that
we
build
mobile
applications,
which
is
to
separate
the
concept
of
the
the
the
sort
of
container
and
frame
that
the
application
runs
in
and
the
stuff
that
it
executes
like
individual
pages
and
only
load
those
pages
as
and
when
they're
needed
and
we've
got
the
ability
to
on
on
click
event.
First
download
the
code
then
execute
the
code
and
then
show
the
user
a
new
screen.
C
C
Yeah,
so
that's
that's
an
interesting
question
and
the
answer
is
obviously
going
to
be.
It
depends.
It
depends
on
which
frameworks
you're
using
and
it
depends
on
the
constraints
that
you've
got.
I
think
that
there
is
a
justifiable
there's,
a
justifiable
use
case
for
doing
it
and
often
what
you'll
find
is
that
older
applications
don't
have
the
same
problem.
So
if
you're
talking
about
legacy
as
like
10
years
or
older
or
anything
running
jquery,
it's
actually
probably
going
to
be
far
better
than
the
things
running
reactor
four
years
ago.
Right.
C
Those
are
a
bigger
issue,
so,
in
terms
of
in
terms
of
optimizing
legacy
apps,
I
think
that
there
are
a
couple.
There
are
a
couple
things
that
you
can
do
so.
The
first
thing
is
that,
historically,
we
would
ship
es5
and
es5
only
that
was
uglified
or
minified,
and
we
don't
have
to
ship
all
of
that
code
anymore.
We've
now
got
native
imports.
We've
got
tersa
language
constructs,
we've
got,
we
don't
need
polyfills.
We've
got
good
support
for
modern
language
features.