►
From YouTube: WebPerfWG TPAC 2020 meetings - October 20 - part 2
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
A
Okay
and
we're
back
for
sba
reporting,
so
michael,
do
you
want
to
present
I'm
assuming
that
people
are
here
will
be
here
shortly?
I
don't
know
if
we
should,
I
think
we
can
probably
get
started
and
people
will
show
up.
B
All
right
well,
thanks
for
the
opportunity
to
present
this
initially,
this
session
was
scheduled
for
half
an
hour,
and
I
thought
there
was
no
way
in
heck
that
we
would
cover
all
the
content.
I'm
happy
to
see
it
move
to
one
hour,
but
I
had
cut
aggressively
on
these
slides
and
frantically
re-added
some
things
this
morning.
So
apologies
if
something's
out
of
place
all
right
so
single
page,
app,
spa,
metric
reporting.
B
So
as
a
quick
intro
for
anyone
who
is
unaware
single
page
applications
are
sites
which
dynamically
rewrite
the
current
page
content.
Instead
of
loading
a
new
page
using
the
browser
and
on
naming,
I
will
tend
to
use
spa
navigation,
but
that
is
just
one
type
of
this
problem,
and
so
soft
navigations
is
also
used
somewhat
interchangeably
to
more
broadly
be
applicable
to
all
of
these
types
of
sites.
These
are
commonly
built
using
frameworks
like
angularjs,
ember,
backbone
or
react.
B
Some
of
these
frameworks
are
sort
of
fully
featured
where
they
include
support
for
this
type
of
routing
and
url
changing
and
all
this
other
stuff.
Others,
like
react,
have
common
components
like
react:
router
that
are
used
to
add
this
type
of
functionality.
B
It's
also
very,
very
common
to
use
the
hash
fragment
portion
of
the
url
or
the
history
api
to
keep
the
sort
of
serializable
state
of
the
page
in
sync,
with
the
page
content,
so
that
you
can
copy
and
paste
and
that
sort
of
thing
there
are
many
common
problems
that
we've
known
about
for
years
and
we've
talked
about
for
years.
B
You
know
many
rum,
metrics
and
tools
are
written
to
measure
traditional
page
load
performance
and
there's
a
general
lack
of
synthetic
testing
for
any
type
of
post
load
performance,
which
includes
all
post
load
like
client
side
transitions
like
spawn
outs,
and
because
of
that
spas
tend
to
have
more
blind
spots
in
measurement,
and
you
know
at
best
this
just
leaves
us
in
the
dark
on
a
large
part
of
ux.
B
But
at
worst
and
and
this
is
increasingly
common,
we
tend
to
measure
some
of
the
worst
cases
of
interactions
and
this
paints
an
entirely
inaccurate
picture
of
overall
performance.
And
so
the
the
measurement
reports
don't
match
the
the
real
world
experiences
and
we
get
this
feedback
all
the
time,
but
just
filling
the
gap.
The
wrong
way
risks
painting
an
inaccurate
picture
in
the
opposite
direction.
So
it's
not
quite
as
simple
as
just
do
this
right.
B
B
Just
gonna
check
to
see
if
folks
are
still
here,
all
right,
so
types
of
spawn
abs.
So
we
often
talk
about
this
as
if
it
was
just
one
thing:
that's
easy
to
paint
with
a
single
brush
and
easy
to
identify,
but
the
reality
is.
There
are
plenty
of
variants.
B
From
the
ux
perspective,
there
are
sites
that
will
do
full
page
recreations
that
look
to
the
user
almost
exactly
like
a
traditional
navigation.
You
know
the
site
will
almost
go
blank
first
and
then
repaint
with
totally
new
content.
B
B
You
can
imagine
like
a
financial
website
with
individual
instruments
that
are
updating
every
second
or
something
like
that,
all
the
way
to
infinite
scrollers,
where
they
might
not
even
be
updating
the
url
and
as
you're
as
you're
scrolling
you're,
just
getting
new
content
loaded
in
and
each
piece
is,
as
as,
if
it
was
its
own
little
portion
of
content
and
then
the
weight
loads
are
actually
implemented
varies
quite
a
bit
as
well.
B
You
also
have
large
portions
of
common
code
and
common
templated,
but
still
loading
dedicated,
distinct
views
as
needed
all
the
way
to
just
pre-load
everything
you
know
take
everything
you
might
possibly
need,
including
some
menu
that
might
occasionally
be
open
and
still
pre-load
it
just
in
case
just
so
that
the
transition
is
instantaneous
and-
and
you
know
this
could
be
anywhere
in
between
this
preload.
Everything
seems
to
be
especially
true
for
the
for
javascript
and
then
for
initial
load.
B
There
are
pages
that
will
use
client-side,
rendering
even
for
the
initial
load,
so
you
get
almost
a
blank
canvas
and
then
gets,
which
is
the
the
traditional
load
type
and
then
you'll
get
client-side
rendering
to
server-side
rendering,
which
is
a
a
typical
dynamic
preview
of
a
page
which
follows
up
with
hydration,
which
upgrades
the
site
from
like
a
static
page
to
a
sort
of
client
side
up
and
then
for
support
subsequent
loads
like
within
the
client
for
soft
navs.
B
Some
of
them
are
in
response
to
interactions
that
the
users
clicked
on
things,
and
some
of
them
are
automatic,
like
youtube,
will
auto
advance
to
the
next
video
when
you're
done
watching
the
current
video
all
right.
So
with
that
in
mind,
there
are
some
patterns
that
exist
already
and
some
strategies
we
might
adopt
in
the
future
for
classifying
spa
navigations.
B
So
the
most
popular
are
to
rely
on
developer
hints,
so
many
frameworks
already
have
clear
signals
for
the
start
of
a
route
or
transition,
as
well
as
for
any
view
update.
But
it's
not
necessarily
clear
when
all
of
the
relevant
view
updates
have
finished
applying
for
any
given
route
start
or
end.
B
There
has
been
some
good
work
in
the
past,
including
things
like
zone.js
from
angular,
which
attached
sort
of
a
context
across
async
work,
and
this
almost
gave
you
out
of
the
box
the
ability
to
track
the
last
piece
of
work
that
was
sort
of
completed
in
response
to
some
some
task.
That
was
started,
but
this
doesn't
actually
work
with
modern
js.
B
There's
a
bunch
of
things
that
broke,
I
think,
with
the
async
and
away
patterns,
don't
work
with
zone.js
strategies,
although
yesterday
we
heard
about
scheduling
with
post
task
and
the
ability
to
add
potentially
some
sort
of
context
that
persists
across
async
work
or
async
tasks
and
then
maybe
long
task
attribution,
which
I
think
patrick
will
talk
about
tomorrow.
These
are
all
things
that
could
help
here
in
terms
of
automatically
tracking,
as
well
as
some
of
those
responsiveness
works.
That
nicholas
talked
about
yesterday.
B
Some
rum
frameworks
today,
already
annotate
pages,
so
they'll
ask
the
developer
to
provide
the
hint
of
when
the
the
sort
of
soft
nav
started
and
then
they'll,
listen
to
network
usage
and
dom
updates,
using
invitation,
observer
and
ad
hooks
for
tracking
all
this
work
completion,
and
I
think
I
linked
to
boomerang
on
some
documentation
about
what
they
have
there
and
then
I've
previously-
and
I
think
this
has
been
discussed
for
a
while
talked
about
adding
developer
hints
via
user
timings.
B
So
rather
than
each
framework
and
each
rum
platform
re-implementing
the
wheel
and
doing
it
a
different
way.
We
already
have
an
api
for
developer,
hints
through
user
timings,
and
maybe,
if
we
relied
on
a
convention,
then
we
can
hook
on
the
same
signals.
So
I
linked
to
a
previous
presentation
on
that
here.
I
think
a
little
bit's
been
evolved,
but
this
is
still
work.
We
hope
to
do.
B
Ideally
in
the
future.
We
could
perhaps
automatically
track
soft
navs
using
heuristics.
B
So
perhaps
something
like
if
there
was
a
recent
input
and
the
history
change
and
network
and
cache
was
just
used,
and
there
was
a
dom
update.
Something
like
that.
B
But
it's
really
hard
to
get
this
right,
especially
with
what
I
said
earlier,
which
is
there
are
so
many
different
types
of
navigations
and
how
they're
kicked
off
and
what
they
actually
tend
to
do.
However,
if
we
had
really
trustworthy
and
widespread
user
timing
hints,
then
maybe
we
could
do
more
experimentation
here
to
test
against
heuristics
and
find
what
exactly
correlates
the
most.
B
Finally,
there
is
some
work
towards
possibly
adding
a
dedicated
client-side
nav
api,
so
there's
ongoing
work
around
the
html5
history
api
because
of
to
fix
various
flaws
that
exist
already,
and
there
are
complaints
from
framework
authors
about
like
history,
state
disappearing
or
changing
or
various
workarounds
that
you
have
to
do
to
make
sure
that
it
works
correctly,
and
so
there
are
proposals
to
fix
these
flaws,
but
one
of
them
would
be
to
provide
an
api.
B
That's
like
a
well-lit
path,
just
to
do
the
all
of
the
right
things
that
most
frameworks
have
to
do
manually
today
automatically-
and
this
could
be
also
used
by
us
to
to
be
a
clear
signal.
It
might
not
help
with
measurement
directly,
but
it
would.
It
would
at
least
give
us
something
to
hook
on
to
reliably.
B
All
right,
so,
if
we
had
these
signals,
what
goes
actually
into
measuring
a
single
page
navigation,
so
first
off
responsiveness.
B
So
we
have
event
timing
which
not
only
gives
info
about
the
first
input,
but
also
all
long
duration,
events,
post
load
and
ideally
we
would
use
something
like
this
to
track
the
whole
antenna.
Duration
of
the
spa
navigation
itself,
especially
if
it
was
due
to
a
user
interaction,
so
nicholas,
presented
yesterday
about
what
goes
into
end-to-end
duration,
including
the
async
portions
of
work,
and
we
talked
about
various
strategies.
We
might
use
to
track
that
and
if
we
had
this,
this
could
be
the
equivalent
perhaps
of
an
on
load
for
a
spawn
ave.
B
But
beyond
just
the
transition
itself.
We'd
probably
want
to
track
the
next
input
after
a
spawn
off
to
again
to
the
the
first
input
after
a
page
load
and
right
now,
event.
Timing
will
only
report
this
if
you
have
a
long
duration.
So
if
you're,
if
you
only
care
about
input
delay,
you
could
polyfill
this
by
registering
handlers
and
we
there's
a
similar
problem
here
with
bf
cache,
which
I
think
is
going
to
be.
The
next
talk.
B
After
this,
but
we
might
want
to
have
even
for,
like
relatively
short
duration,
have
more
information
about
end-to-end
responsiveness,
so
it'd
be
neat
to
sort
of
reset
event
timing,
to
say
at
least
for
the
next
input,
I'm
interested
in
it,
no
matter
how
fast
or
slow
it
is,
and
then
with
responsiveness,
perhaps
moving
beyond
first
load
towards,
like
all
inputs
across
the
page.
The
new
issue
that
comes
up
is
attribution,
which
we'll
discuss
shortly.
B
Okay
paint
paint
is
often
the
the
most
troubling
thing
to
measure,
so
we
can
of
course,
track
the
very
next
paint
you
get
this
both
with
event
timing
via
the
duration
to
the
next
paint,
as
well
as
just
by
calling
a
request
animation
frame.
But
what
we're
really
more
interested
in
is
the
next
content,
full
paint
or
the
next
largest
content
for
paint.
B
So
for
spa
navs
that
are
a
full
page
recreation.
This
seems
possible
to
define-
and
maybe
we
can
even
just
reuse,
first
contentful
paint
or
largest
content,
full
paint
and
just
have
multiple
entries
for
the
same
entry
type,
but
it
definitely
gets
more
problematic
with
partial
updates,
which
I
think
tend
to
be
more
common.
B
B
For
visual
stability,
I
mean
layout
shifts
already
do
get
reported
for
full
page
lifecycle,
which
is
good.
However,
cls
today
is
accumulated
and
reported
for
the
initial
page
load
only
so
I'll
get
into
attribution
in
a
moment.
One
difference,
though,
between
page
load
and
soft
navigation
is
that
layout
shifts
that
happen.
B
Post
load
will
get
this
signal
about,
have
recent
input,
because
we
want
to
make
sure
to
ignore
shifting
for
things
disappearing
or
moving
in
response
to
content
like
after
interaction,
which
makes
sense,
but
for
new
content
that
was
added
during
a
soft
navigation
and
then
shifted.
It
really
is
similar
to
during
page
load,
where
it
gets
added
early
on
in
the
page
and
then
still
shifts
so
with
even
within
the
first
500
milliseconds
for
new
content
that
was
added
and
then
shifted
it.
B
It
would
be
more
equivalent
to
page
load
if
you
did
count
that
that
shift
so
food
for
thought.
I
think
this
is
a
trivial
issue.
I
just
wanted
to
call
it
as
a
difference,
all
right
and
perhaps
the
the
most
interesting
part
and
one
that
I've
been
trying
to
think
about
a
lot
recently
is
just
both
transitioning
from
multi-page
up
to
single
page
app,
as
well
as
like
thinking
through
issues
and
differences
between
them.
B
So
some
common
patterns
in
feedback
that
we
hear
often
are
when
you
move
from
an
mp8
spa,
you
all
of
a
sudden
measure,
many
more
page
views
as
identified
by
your
own
analytics,
which
include
spawn
apps
if
you're,
if
you're,
counting
them
yourself
but
you're,
seeing
fewer
reported
page
loads
as
identified
by
most
analytics
tools,
including
things
like
crux
and
then
for
things.
You're
measuring
yourself,
you're,
typically
seeing
faster
transitions
between
page
views,
even
though
you're
seeing
slower
reported
initial
page
loads.
B
So
there
are
these
conflicting
reports
and
then,
of
course,
some
metrics
just
don't
make
sense
for
spa
and
there
are
things
to
improve
there,
and
so,
when
you're
doing
a
big
transition
from
mp
mpa
to
spa,
there's
a
lot
of
things
that
change
at
once,
which
makes
it
really
hard
to
measure.
B
And
then
I
talked
already
a
little
bit
about
problems
with
metrics
like
cls
and
and
blind
spots
and
measuring
all
right.
So
in
terms
of
attribution,
ideally,
there
would
be
no
reporting
difference
between
a
traditional
multi-page,
app
page
load
and
a
spa
south
nav.
B
B
Some
considerations,
though,
is
that
you
can't
necessarily
report
the
exact
same
metrics
for
page
load
and
self
nav,
especially
for
things
like
paint,
and
then
the
performance
of
transitions
depends
also
on
the
previous
route.
B
So
if
you
imagine
product
pages
switching
from
product
to
product,
you
might
have
most
of
the
template
already
loaded
where
just
a
few
assets
are
changing,
whereas
if
you're
on
a
settings
page
and
then
moving
to
the
main
page
or
something
like
that,
it
might
be
a
full
page,
reload,
and
so
the
referrer
route
will
impact
the
performance
of
the
load
and
then,
of
course,
with
client-side
routing.
We
sometimes
see
an
explosion
of
urls,
which
is
a
lot
more
things
getting
considered
a
transition.
B
And
so
to
me,
this
is
sort
of
the
biggest
open
question
is
how
do
we
take
these
metrics
and
do
we
blend
them
with
page
load
equivalents?
So
there's
definitely
a
huge
advantage
in
terms
of
simplicity
to
just
blend
everything
together
based
on
its
url.
You
know,
users
don't
care
how
it
was
built.
They
can't
tell
the
difference
sometimes
how
navigation
was
implemented.
B
So
if
the
overall
time
spent
is
the
same,
but
it's
more
front
loaded,
is
that
really
equivalent
initial
impressions
and
bounce
rates
are
really
affected
by
the
first
load,
far
more
than
by
just
the
average,
and
so
I
think
in
the
previous
talk
on
preload,
we
heard
that
they
both
consider
the
performance
of
the
preload,
as
well
as
the
ux
of
the
transition
as
being
distinct
things
to
measure,
and
then
distribution
of
overall
load
performance
is
likely
to
change.
B
If
you
just
blend
everything
to
perform
together,
especially
if
you
have
total
number
of
reports
that
increase
you
might
want
to
look
at
higher
percentiles,
and
so
the
actual,
where
you
cut
the
line
and
what
you
look
at
might
might
change
all
right.
So
that
was
a
a
long
spew
and
that's
all.
I
have.
A
C
Yes
completely
sorry,
I
realized
that
I
knew
when
I
made
that
response
like.
Actually,
I
totally
agree
with
you
that
was
going
to
be
my
point.
You
know
like
as
an
analytics
vendor
performance
is
a
distribution,
and
we
see
it
all
the
time,
and
we
see
that
you
know
whether
we're
looking
at
a
full
page
load
or
multiple
page
load.
It's
always
going
to
be
a
distribution.
C
I
think
how
you
slice
and
dice
it
tends
to
be
how
developers
and
users
of
our
tools
like
to
be
able
to
look
at
the
data,
whether
they
create
a
custom
dimension
or
whether
tools
like
impulse
and
others
like
do
that
automatically
for
them.
Or
you
know
we
allow
them
to
do
that.
It's
about
kind
of
segmenting,
your
data,
so
a
spa
load
is
not
the
same
as
a
as
a
full
page
load.
C
I
liked
a
lot
of
what
you
said
and
I
think
I
had
some
questions,
maybe
for
pat
meenan,
if
he's
on
the
call
still
about
synthetic
and
how
they
do
this,
because
when
you
script
something
in
web
page
test,
I
think
there's
in
some
cases
you
know
things
like
lcp
still
being
reported
for
spot
navigations
and
I
don't
know
if
that's
intended
or
not
or
if
that's
a
byproduct
or
if
it's
not
always
going
to
be
the
same.
But
I
think
some
of
those
paint
metrics
do
make
sense.
C
I
was
actually
just
on
a
call
this
morning
with
a
customer
walking
through
this,
where
they
had
a
whole
product
details
listing
page
and
they
are
moving
to
a
spa
and
they
have
a
load
more
button
at
the
end
of
the
page,
which
basically
does
a
soft
refresh
loads.
Everything
in
but
they're
very
interested
in
when
the
largest
contentful
paint
or
the
the.
I
guess,
the
first
product
image
paints
so
they're,
relying
on
things
like
element,
timing,
they're,
relying
on
things
like
glass
painted
hero
and
other
metrics,
which
I
guess
resemble
an
lcp.
D
And
so
at
least
on
webpagetest,
the
only
reason
lcp
would
still
get
reported
is,
if
whatever
paint
in
those
further
navigations
happens
to
be
larger
than
whatever
happened
to
load
in
the
first
part
of
the
navigation
right,
because
it's
still
using
chrome,
candidate,
lcp
events
and
they
accumulate
right,
and
so
it
happens
to
just
be
luck,
there's
no
reset
the
lcp
state
without
a
navigation
bit
that
can
be
twiddled.
As
far
as
I
know,
and
so
yeah
element
timing
is
the
the
only
real
way
to
instrument
what
you
care
about.
D
The
visual
metrics
web
page
test
does
is
like
the
hero
image
stuff.
That
speed
curve
does
where
the
render
metrics
will
be
relative
to
the
state
of
the
spa,
at
which
point
you
started
doing
the
new
action,
and
so
it's
whenever
something
on
the
screen
changed
from
that
or
the
speed
index
is
relative
to
the
the
start
and
end
state
of
that
activity.
But
the
chrome
reported
metrics
don't
have
a
way
to
reset
awesome.
E
B
A
transition
unless
it
was
an
automatically
generated
one
like
the
initial
one
during
load,
which
does
happen.
I.
F
D
You
can,
but
all
of
the
routing
is
going
to
be
triggered
through
javascript
right.
It's
not
actually
going
to
be
input,
events
to
the
screen
or
fake
keyboard
inputs,
or
anything
like
that.
So.
C
B
So
cls
is
not
actually
reported
through
performance
observers,
just
individual
layout
shifts,
and
so
you
have
to
calculate
it
yourself
and
there's
libraries
like
web
vitals.js
that
that
will
calculate
it.
The
way,
the
same
way
that
chrome
does
as
an
aside,
there's
there's
ongoing
work
to
to
think
through
cls
and
what
it
means
and
perhaps
better
ways
to
to
sort
of
normalize.
B
The
individual
layout
shift
data
just
because
for
very
long
pages
just
endlessly
accumulating
and
especially
for
single
page
apps
across
routes
it
it
just
doesn't
do
that
well
and
so
so
that
strategy
might
change
over
time.
However,
like
if
we
start
cutting
and
attributing
to
url,
we
would
want
to
reset
basically
the
accumulated
value
for
cls.
E
C
I'm
not
sure
that
we're
doing
that
what
we
should,
if
we're,
not
okay,
interesting.
B
B
To
go
to
you
have
to
back
to
your
question
and
cliff,
followed
up
in
terms
of
comparing
initial
load
to
subsequent
page
loads.
There's,
certainly
a
difference
in
performance
and
so
reloads
will
have
a
different
performance
than
the
initial,
very
first
initial
load
or
the
first
load
of
a
session.
After
a
long
while
that
sort
of
thing,
I
expect
that
spot
transitions
will
have
a
much
even
bigger
difference,
and
so
cliff
you
answered
that
you
do
separate
it
out
and
then
you
do
dig
deep,
but
then
I
I
didn't
follow.
C
I
guess
it
kind
of
depends.
I
mean
what
we've
seen
when
people
are
migrating
to.
Spas
is
oftentimes.
You
know
those
are
replacing
traditional
page
views,
those
navigations
are
so.
If
you're
looking
at
an
overall
number
and
trying
to
improve
user
experience,
I
think
it
does
help
to
kind
of
look
collectively
at
it.
You
know
we
don't
always
see
increased
page
views
just
because
it's
a
spa.
Those
are
still
transitions
that
are
happening.
Just
like
you
would
see
with
traditional.
You
know
full
page
loads
in
a
lot
of
cases.
C
In
some
cases
no
like
when
partial
content
is
changing
and
things
like
that,
it's
kind
of
hard
to
call
that
a
new
product
details
page
or
something
so
the
answer
isn't
annoying.
It
depends,
but
I
think
that's
having
the
ability
to
separate
it-
and
I
think
you
know
nick-
has
done
a
ton
of
work
here
and
I
think
you
know
the
model.
How
would
how
to
do
it
really
well
in
terms
of
being
able
to
separate
between
hard,
dabs
and
softness,
but
still
being
able
to
look
at
that
entire
distribution?
B
G
Need
to
measure
both
like
when
you,
when
you
want
to
understand
like
the
business
and
the
effect
impact
of
a
slow
loading.
You
want
the
first
load
and
when
you
want
to
understand
more
stuff
about
your
performance
unit,
you
want
the
subsequent
load.
G
A
Yeah
also,
I
have
to
say
so,
theoretically
the
path
of
let's
preload,
all
like
prefetch,
all
possible
things
that
the
user
can
do
on
the
very
first
page
and
then
have
everything
else
be
instant
is
something
you
can
also
do
with
the
mpas
and
prefetch
or
you
know
any
other
means
of
getting
content
into
your
cache
and
pre-rendering
and
whatnot.
A
So
these
are
all
things
that
you
can
do,
regardless
of
architecture
and
whether
it
makes
sense
or
not
is
something
you
want
to
measure
either
way,
and
I
think
what
I'm
hearing
both
cliff
and
I'm
saying
is
that
you
want
to
be
able
to
measure
like
you
want
to
be
able
to
distinguish
the
first
load
from
the
rest,
and
then
you
want
to
be
able
to
either
look
at
first
loads
individually
or
blend
them
with
the
rest.
And
basically
you
want
to
slice
and
dice
your
data
in
order
to
extract
insights
from
it.
A
C
Yep
agreed
it's
kind
of
issuing
because
you
think
about
cold
versus
warm
cash,
and
we
don't
really
do
do
much
of
that
with
with
with
rom
today,
where
we
can
kind
of,
I
mean
we
can
infer.
C
C
Well,
if
those
are
already
in
cache
as
well
you're
getting
a
soft
transition
or
spot
transition
which
is
different
than
the
full
page
load,
but
it's
also
going
to
be
different
from
someone
who
viewed
that
transition
before
so
I
think
you
still
got
that
dimension
to
think
about
which
again
lends
itself
to
sort
of
looking
at
performance
as
that
distribution,
as
we
talked
about,
but
it
is
important,
I
think,
to
be
able
to
distinguish
the
different
kind
of
page
load
types
so.
B
F
I
just
wanted
to
say
that,
thanks
for
the
talk
and
like
we've
always
discussed
spas
like
literally
every
tea
pack
or
something
like
that
along
those
lines,
so
from
my
perspective,
it's
super
clear
that
this
is
something
that
is
needed
and
there
is
a
lot
of
demand
for
monitoring
space.
So
my
my
main
question
would
be
well.
I
guess
two
questions
one
would
be.
How
do
you
determine
when
dsp
happens?
F
F
What
are
the
metrics
that
you
would
like
to
surface,
at
least
as
a
starting
point
like?
Would
you
like
to
surface
basically
everything
again
like
first
paint,
first
content
for
paint
lcp
fit,
or
what
are
your
thoughts
on
that.
H
I
can
answer
from
salesforce
hi.
This
is
steven,
so
we've
been
working.
I
mean
I've
been
working
at
salesforce
with
spa
for
five
years
now,
and
I
think
what
I
need
from
the
web
platform
is
an
api
to
say:
hey.
We
are
doing
a
soft
navigation
so
internally
we
have
that
and
so
internally
we
reset
everything.
Every
time
we
doing
our
softnav
but
it'd
be
nice.
H
If
we
could
tell
the
browser
by
the
way,
we're
doing
a
soft
knife
right
now
and
therefore
all
the
performance
metric,
we
would
reset
and
we
would
be
able
to
access.
You
know,
largest
content,
full
plans.
You
know
everything
so
to
me
because
today
the
browser
when
you're
not
in
a
spa,
he
knows
when
you're,
navigating
because
you
reload.
H
H
So
you
know
everything
would
reset
and
nikola
to
answer
your
question.
Yes,
we
would
have,
would
love
everything
to
reset
so
when,
when
one
of
our
page
in
spa
is
slow,
we
can
actually
talk
to
the
developer
to
to
make
it
faster,
because
we
know
that
this
specific
page
that
we
want
to
improve.
H
We
are
not
today
today
we,
we
have
our
own
library,
and
you
know
when
we,
when
we
call
our
own
internal.
You
know
move
to
this
page.
You
know
our
internal
instrumentation
gets
reset,
but
not
the
instrumentation
provided
by
the
browser
do
you're
doing
it
on.
H
H
F
Yeah,
okay,
so
in
that
case
it
wouldn't
be
in
event,
timing.
This
requires
really
something
that
actually
changes:
the
url
for
example.
So
that
would
be-
I
don't
know.
If
I
think
michael
mentioned,
there
has
been
some
discussions
at
least
internally
in
chrome,
about
brainstorming,
about
a
new
navigation
api
that
can
both
fix
the
existing
problems
with
the
existing
history.
Api,
as
well
as
perhaps
allow
us
to
finally
enable
monitoring,
sps
but
yeah.
C
F
B
Yeah
some
of
the
issues
there
are
certain
issues
about
like
ux.
First
of
all,
the
history
api,
you
can
easily
shoot
yourself
in
the
foot
if
you
use
it
wrong
like
if
anybody
taps
a
fragment
url
the
history
states
gets
overwritten,
so
it's
kind
of
unusable,
and
so
you
tend
to
have
to
have
frameworks
that
completely
abstract
away
browser's
notion
of
history.
So
these
types
of
things
are
being
worked
on
to
perhaps
fix,
but
separate
from
that.
B
If
you
want
to
support
things
like
open
in
new
tab
by
default,
but
also
support
client-side
routing
in
the
common
case,
you
need
to
sort
of
intercept
all
clicks
on
links
and
handle
them
manually
and
stuff
like
that.
So
there's
an
upcoming
there's
some
work
about
perhaps
creating
a
proposal
that
would
just
simplify
the
default
to
make
it
work
out
of
the
box.
B
Where
you
get
an
update
to
the
url,
it
falls
back
to
same
behavior,
with,
like
top
level
navigation,
that
sort
of
thing
it
wouldn't
measure
in
on
it
in
and
of
itself.
So
if
you
have
access
to
client-side
hints
and
you're
already
using
a
framework
that
already
fixes
history
problems
it
it
would
just
get
you
to
that
state,
quicker
or
or
more
reliably,
perhaps,
but
we
still
have
to
answer
these
questions
about
measurement.
So
I
think
that
layout
shift
is
the
the
in
the
best
state
input.
B
I
think
we
need
to
do
this
resetting
for
next
input
if
it's
important
to
make
sure
we
track
even
that-
and
that
seems
plausible
for
me
to
get
a
signal
to
reset
the
next
input,
no
matter
how
fast
it
is,
I
don't
know
if
there's
like
security
or
whatever
implications,
if
folks
reset
too
often,
so
maybe
it
needs
to
be
tied
to
an
interaction.
I'm
not
sure
the
the
hardest.
One
for
me
to
to
think
through
is
paint
because
is
next
contentful
paint
and
largest
contentful
paint.
B
G
I
think
that
if
we
go
with
the
approach
of
the
application
clearing
some
of
those
one-time
metrics
like
first
content
on
full
plans,
etc,
the
application
can
is,
is
best
suited
to
decide
whether
to
use
those
metrics
or
to
use
element,
timing
or
something
or
user
timing,
or
something
more
finer.
And
it's
actually
not
up
to
the
web
platform
to
decide
that,
like
it
and
and
we
can
cannot
rely
on
the
history
api,
because
maybe
everything
happened
and
then
javascript
called
push
state.
C
Couldn't
we
tell
like,
during
that
navigation
state,
you
know
again,
just
in
the
example
of
comparing
layout
shift
timestamp
of
when
you
know
you
started
the
event
when
the
last
layout
shift
happened,
similar
to
lcp,
ignore
it.
If
the
time
stamp
was
before
the
start
of
the
navigation
with
the
spa
like
I
guess
it
wouldn't
require
clearing
anything,
it
wouldn't
require
anything
special.
You
could
still
institute
a
next
contentful
paint,
which
I
think
is
kind
of
an
interesting
idea
or
next
largest
contentful
painter.
C
B
Yeah,
I
think
you're
absolutely
right
that
you
don't
need
to
reset
anything
for
layout
shift.
You
could
just
use
timestamps
and
then
the
nav
timestamps
to
slice
a
session
and
then
for
responsiveness.
You
would
do
that
as
well,
provided
that
there's
this
like
signal
for
the
thing
for
paint
it's
different,
because
you
need
a
new
signal
that
you
need
to
ask
for.
B
The
thing
is
that
if
we
are-
and
no
my
I
like
your
suggestion,
but
now
you
have
two
different
ways
to
measure,
and
it
even
further
complicates
this
idea
of
like
how
do
you
blend
initial
page
load
with
subsequent
mode
with
spa
soft
and
like
hard
navigations,
because
now
you're
measuring
different
things.
G
I
just
wouldn't
call
it
first
contentful
paint,
that's
why
we
have
entry
names,
for
it
is
a
contentful
paint,
but
we
can
use
entry
names
to
the
or
all
kinds
of
things
inside
the
entry
to
differ
between
those
things.
F
Right
but
like
technically,
it's
like
the
first
contentful
paint
after
the
spa
navigation.
A
I
don't
know
one
of
them
yeah,
but
we
could
like,
even
without
changing
the
name,
we
could
easily
distinguish
between
one
and
the
other.
I
mean
you
have
the
first
paint
entry
in
the
that
was
reported,
and
then
others,
following
that,
like
we
could
easily
like
also
based
on
time,
stamps
or
whatnot.
I
think
that
the
main
open
question
here
with
the
with
paint
metrics
is
whether
we
can
report
them
for
arbitrary
things
from
a
security
perspective.
A
J
We've
had
an
ongoing
conversation
with
our
security
folks.
One
one
issue
can
be
same
process
iframes
same
process,
cross-origin
iframes
where
they
exist
can
leak
stuff.
But
this
is
a
discussion
that,
from
my
perspective,
we
we
still
haven't
gotten
to
the
bottom
of
on
our.
F
End
one
potential
problem
that
comes
to
mind
is
say:
you
have
a
an
image
that
you
want
to
get
some
information
from,
and
then
you
just
add
it
and
time
the
first
paint
remove
it
and
add
it
so
like
it
lets,
you
basically
get
a
much
more
granular
and
better
estimate
of
the
the
time
it
takes
to
render
which
could
leak.
Some
information
potentially.
F
C
Trying
to
go
all
the
way
back,
but
it
was
the
was
the
idea
here.
The
fact
that
hey
we
want
to.
We
want
to
do
something
that
requires
as
little
work
as
possible
for
the
developers
that's
more
sort
of
out
of
the
box.
If
you
will
or
is
it,
we
just
want
to
have
a
common
way
of
doing
it
like
developer,
hence
that
we
could
all
hook
into,
and
you
could
report
in
crux
and
you
could
report
in
impulse
and
in
lux
and
everything
else.
B
Yeah,
I
think
there
were
separate
ideas
limped
into
one
one
was
the
user
timing
hints
and
so
basically
every
it's
a
free-for-all,
everybody's
doing
it
themselves.
The
frameworks
are
trying
to
get
it
done,
but
they
don't
have
clear
signals
of
end
points.
The
analytics
providers
are
trying
to
do
everybody's
trying
to
do
it,
and
so
why
don't
we
just
come
up
with
a
convention.
B
There's
already
a
standard
for
like
developer,
hints
around
timing,
around
user
timings,
and
so
then
maybe
we
could
get
the
best
of
breed
into
the
frameworks
themselves
and
you
get
it
out
of
the
box
for
every
new
application
built
on
a
given
framework
and
and
then
we
hook
into
that,
because
you
could
listen
to
these
events
and
do
whatever
you
will,
and
so
you
could
still
measure
different
things,
one
of
the.
B
So
that
has
many
advantages,
but
it
still
relies
on
developer,
hints
and
like
these
things
can
happen
very
frequently
and
the
notion
of
a
navigation
changes
from
framework
to
framework
and
app
to
app.
And
so
you
know
it
doesn't
necessarily
mean
that
every
single
one
of
these
hints
is
like
a
top-level
transition
that
you
want
to
blend
with
your
page
load
metrics,
so
we'll
have
to
see,
but
I
think
the
first
step
is
to
add
those
and
to
start
looking
and
then.
The
second
thing
I
I
proposed
was
like.
B
Maybe
this
informs
better
heuristics
where
you
can
use
this
plus
other
signals
to
say
really.
This
is
a
a
proper
transition.
You
know,
am
I
hopeful
I
I
don't
know,
but
until
we
see
it,
we
won't
know
and
then,
finally,
with
this
navigation
proposal,
you
know
it's
really
nascent
right.
B
So
it
would
only
be
used
in
places
where
top
level
navigations
are
used
today,
basically,
and
so
it
would
be
a
useful
hint
to
hook
into
that.
We
could
trust.
This
is
a
good
reset
point
again.
You
still
have
all
the
measurement
issues,
but
but
this
would
be
a
good
integral
and
we'll
see
how
that
moves
forward.
B
And
so
distinct
from
just
identifying
we,
I
think
we
still
want
to
have
answers
as
to
like
what
exactly
we
measure
and
then
once
we
measure
it.
Where
does
it
go
and
what
do
we
do
with
it?
And
so
I
I
enjoyed
hearing
that
folks
agree
that
you
want
both
perspectives.
You
want
the
blended
perspective,
because,
ultimately,
that's
what
you're
striving
to
trade
off
for
your
users.
If,
if
you
do
have
lots
of
post
load
interactions,
you
have
a
sticky
site
that
does
well
keeping
users
on
the
site.
C
I
I
will
say
that
it
has
come
up
like
with
web
vitals
and
customers
that
are
saying
hey.
This
is
awesome,
like
we've
got
this
insanely
fast
lcp
or
something,
and
but
why
is
it
saying
something
different
again
and
prop
certain
lighthouse?
So
I
do
think
we
are
going
to
hear
more
of
it
and
I
think
we're
going
to
have
more
people
wanting
to
differentiate
or
at
least
be
able
to
see
what
chrome
sees
or
other
things.
So
I
do
think
it's
important
and
crumb
bottles
are
sorry.
C
E
And
just
echo
that
from
for
our
customers
as
well,
we
we
already
segment
our
data
or
allow
our
customers
a
segment
by
whether
it's
a
hard
navigation
or
soft
navigation,
as
well
as
whether
it's
a
landing
page
or
non-landing,
page
etc,
and
it's
very
obvious
when
you
start
segmenting
by
soft
navigation
or
not
that
a
lot
of
the
metrics
that
we've
been
talking
about
are
just
not
there
at
all,
and
so
it
comes
up
very
frequently
with
our
customers
as
well
as
like
what.
Why
can't
we
track
large
temple
painters
off
something
else.
E
We
have
to
go
through
the
education
process
of
the
data,
that's
just
not
there
yeah
so
yeah.
I
I
just
from
a
consistency,
point
of
view-
and
you
know
I
know
every
person-
that's
measuring
single
page
episode-
is
probably
doing
it
slightly
differently,
but
the
more
apps
that
are
being
built
this
way,
the
more
important
it
is
to
be
able
to
to
track
it.
B
Yeah,
perhaps
one
concrete
takeaway
is,
if
you
just
do
the
default
of
reporting
all
page
loads
for
multi-page
apps.
The
default
you
get
is
a
blended
metric
and
for
single
page
app,
the
default
you
get
is
a
segmented
metric
and
just
making
it
obvious.
The
distinction
could
go
some
other
way
towards
like
surprises
when
comparing
the
two
as
you
migrate
between
one
and
the.
C
C
A
A
Cool,
so
I
believe
we're
that
time
is
that
correct,
yep,
okay
or
even
five
minutes
over,
because
we
skipped
a
break,
do
folks
want
to
take
another
break
or
shall
we
just
okay?
So,
first
of
all
any
any
last
questions
urgent
issues
regarding
sba
reporting,
I'm
just
really.
A
Talked
about
it,
I
think
it's
important
michael.
What's
the
best
place
for
people
to
provide
feedback
and
check
on
status?
Is
there
a
public
repo
or
something
in
the
works.
B
No
there's
no
public
repo
on
me.
That's
a
good
question.
I
forgot
to
think
through
it,
so
we
don't
actually
have
a
very
good
umbrella.
Catch
like
there
are
a
couple
of
issues
that
are
open
where
there's
been
lots
of
discussion
on
this
topic,
but
I
think
we
are
looking
for
a
good
umbrella
placeholder
for
all
things
related
here.
I
don't
know
if,
like
the
user
timing,
repo
is
useful
around
the
next
concrete
step
of
getting
these
hints
or,
if
I'm
not
sure,.
A
K
Because
there's
not
really
a
list
of
concrete
use
cases
that,
like
we're
trying
to
satisfy
right,
I
think
it'll
be
really
used
to
have
like
okay,
here's
like
react,
app,
here's
this
you
know
and
like
twitter
or
something
you
know
and
and
then
study
what
they're
doing
and
whether
we
can
satisfy
those
cases.
It
would
be
very
useful
thing
to
do
here.
Like
I
mean
all
these
discussion
about.
Oh,
like
you
know,
we
can
do
this
and
that
using
this
api
is
like
super
vague.
K
B
Yeah,
that
sounds
good.
We
could
do
a
deep
dive
on
a
couple.
Big
apps
I've
certainly
taken
a
long
look
at
facebook
and
twitter
and
youtube
and
a
slew
of
them
not
always
knowing
how
they
themselves
measure,
but
but
certainly
like
the
behavior
from
a
user
perspective.
What
what
the
frameworks
do
yeah.
Maybe
we
need
a
session
at
one
of
the
working
groups
just
to
go
over
an
example
in
detail
or
some
examples.
K
Yeah,
I
think
I'm
also
curious,
like
there
there's
quite
a
few
like
people
from
who
maintain
a
large
website
like
a
salesforce
who
would
probably
be
able
to
like
you
know,
we
are
probably
doing
some
kind
of
measurement
right
now
and
it'll.
K
The
going
to
the
router
place
and
then
on
the
page
yeah,
so
so
it's
to
me
I
mean
so.
Another
thing
is
like
it's
unclear
to
me
right
like
what
would
it
be
a
page
navigation,
because
in
some
cases
it's
page
page
navigation
in
spa
is
really
partial
navigation.
It's
already
a
whole
page
too.
K
So
I
I
don't
think
we
really
discuss
those
examples,
but
it
will
be
really
interesting
to
learn
more
about
what
are
the
set
of
navigations.
You
know
what
what?
What
are
the
things
that
ma
various
apps?
Consider
as
navigation?
You
know
like
list
of
ways
the
navigation
is
achieved
and
what
what
what
they
really
are
considered
to
be
a
navigation,
because
I
don't,
I
don't
even
think,
there's
an
agreement.
You
know
across
all
the
apps
and
the
flameworks.
B
Yeah,
I
attempted
to
sort
of
showcase
just
how
much
variance
there
is
here
and
but
I
did
it
in
in
slides
and
text
instead
of
visual
examples.
So
that's
that's
good
feedback
and-
and
yes,
history,
updating
is
a
a
single
moment
in
time.
Whereas
a
transition
is
a
span
of
time
and
different
sites,
do
it
differently.
Some
update
the
url
instantly
at
the
beginning
of
a
transition.
Some
will
update
at
the
very
end
when
everything's
finished,
others
commonly
will
kick
off
a
bunch
of
work.
K
And
I
think
there
are
some
cases
where
they
do
some
sort
of
a
like
in-app,
pre-render
kind
of
thing
where
they
think
the
user
will
load
this
next
thing,
so
they
would
like
to
fetch
the
data
and
jsons
right
and
then
they
will
just
basically
render
that
content.
In
that
case,
navigation,
like
you,
almost
have
some
sort
of
like
a
it's
a
bro.
It's
like
a
browser
within
the
browser
right
in
that
like
it
has
all
these
features
to,
like
fetch
the
content
and
the
render
content,
and
then
it.
K
Yeah,
but
we
don't
want
to
get
you
know,
start
thinking
about
the
pre-render
in
a
single
page,
app
and
stuff
like
that
too.
So
I
think
there's
something
that
we
might
need
to
do
specific
to
sba
where
we
need
to
be
able
to
measure
things
that
are
like
that
happen
before
navigation.
You
know,
does
that,
like
it's
sort
of
like
oh
date,
the
things
okay
like?
I
actually
did
this
other
thing
before
you
know
we
started
this
sp
navigation.
B
Yeah,
so
I
I'm
not
sure
if
I'm
hearing
what
I
want
to
hear,
but
the
previous
conversation
about
pre-rendering,
I
think
dominic
pointed
out
that
they
want
to
measure
the
performance
of
the
pre-render
and
the
performance
of
the
ux
to
show
to
move
to
visible
or
whatever
it
is,
or
transition
to
the
main
content,
and
I
hadn't
previously
thought
about
attributing
the
performance
cost
of
the
pre-render
to
the
future
route
right
now.
If
we
report
it
the
way
we're
doing
it,
you
actually
would
get.
You
know
the
thing
that's
doing.
B
The
pre-rendering
is
the
thing:
that's
loading
because
it's
not
nicely
segmented
and
so
you'll
have
correctly
pointed
out,
like
you
could
use
modern
browser
features
even
in
an
mpa
to
have
these
patterns,
and
maybe,
in
those
cases
it's
easier
to
attribute
like
forward
the
cost
of
this
pre-render
was
attributed
to
that
so
anyway,
it
is,
it
does
get
complicated.
I
will
agree
with
that.
A
So
so
maybe
a
right
action
item
here
would
be
to
kick
off
some
repo
around
the
problem,
maybe
more
than
the
solution
so
just
repo
to
collect
use
cases,
and
then
we
can
have
stephen
and
others,
and
you
know
large
properties
contribute
from
their
experience
as
to
what
they
are
trying
to
measure,
and
we
could
try
to
summarize
that
into
something
that
can
guide
what
we
are
trying
to
expose
along
with
all
the
questions
that
we
already
know
that
we'll
need
to
answer.
K
I
think
the
understanding
the
model
or
like
documenting
the
model
will
be,
I
think,
useful,
because
if
whatever
the
like,
I
mean
for
the
web,
half
walking
groups
purposes
just
understanding
the
metrics
would
be
useful,
but
I
think
if
we
had
this
document
of
like
okay,
this
subject
do
this
kind
of
navigation.
I
think
it'll
be
useful
for
discussion
for
other
working
groups
as
well.
A
Yeah,
okay,
so
shall
we
move
on
to
the
different
yet
somewhat
related?
Subject
of
bf
cache
reporting.