►
From YouTube: TPAC WebPerfWG 2021 10 26 - SPA reporting
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
Okay,
so
I
wanted
to
talk
about
measuring
sbas,
because
soft
navigations
are
hard
and
I've
been
thinking
of
a
lot
about
measuring
self
navigations,
and
there
are
a
few
inherent
problems
there
that
I
think
I
may
have
tackled,
but
I
wanted
to
share
that
with
you
all
and
get
your
opinions.
A
First
of
all,
some
a
little
bit
of
an
explanation
on
what
soft
navigations
are,
because,
apparently
some
folks
are
not
familiar
with
that
term.
I'm
not
sure
if
this
is
like,
I
think
it's
a
term
you
use
often
in
the
working
group,
but
they're
also
called
same
document
navigations
and
with
the
history
api.
The
way
that
they
typically
work
is
a
user
clicks
on
something
that
is
that
click
event
is
typically
cancelled,
typically
results
in
fetching
of
content.
A
At
some
point,
a
push
state
may
happen
to
modify
the
url
that
is
presented
to
the
user
and
then
dom
modifications
happen
to
show
the
user.
The
new
page
that
presents
that
content.
There
are
a
lot
of
typically
here
and
it
is.
It
is
a
very
unorganized
and
not
well
structured
process
that
is
implemented
differently
in
different
frameworks,
as
well
as
in
vanilla
javascript
for
developers
who
just
implement
those
transitions
on
their
own.
A
There
is
a
new
proposal
for
an
app
history,
api
that
is
triggering
a
navigate
event,
either
from
a
user-initiated
click
on
links
or
forms,
so
essentially
on
semantic
elements
or
through
a
javascript
api
app
history
navigate.
That
gives
essentially
tells
the
browser
you
need
to
navigate
to
this
url
and
then
the
transition.
A
The
dom
modifications
part,
as
well
as
the
fetching
happens
as
part
of
a
transitions
transition,
while
method
that
is
on
the
event,
navigate
event
itself
and
the
developer
passes
that
transition
ma
wild
call
with
the
promise
that
promise
typically
has
calls
to
fetch
the
content
and
modify
the
dom
to
present
the
new
page
to
the
user,
and
when
the
promise
is
resolved,
that's
when
the
transition
is
done
and
the
new
same
document
navigation
is
committed,
yeah.
A
So
what's
hard
about
soft
navigations
for
once,
there
is
no
clear
start
point,
and
I'm
talking
here
mostly
about
the
history
api
model.
We
don't
really
know
when
that
navigation
has
started
it's
hard
to
link
that
final
result,
that
navigation
to
the
initial
user
click
event.
A
If
one
even
happened,
it's
hard
to
distinguish
url
changing
interactions
from
navigations,
there
are
a
lot
of
small
page
interactions
that
maintain
state
as
part
of
the
url,
so
call
the
push
state
api
and
then
it's
very
hard
to
distinguish
them
from
soft
navigations
that
modify
large
parts
of
the
dom.
A
Arguably,
and
it's
a
very
touchy
subject,
and
a
lot
of
people
have
different
opinions
about
what
is
a
navigation
and
what's
an
interaction
and
yes,
michael
and
and
finally,
there
is
no
like
it's
very
hard
to
correlate
the
pain
operations
that
happen
after
soft
navigation
happened
to
the
actual
soft
navigation,
so
it
there
could
be
pain
operations
that
happen
automatically
over
time
so
like
periodically,
and
they
can
happen
right
after
the
user,
clicked
on
the
link
that
resulted
in
soft
navigation.
A
But
that
doesn't
mean
that
that
paint
is
the
first
paint
of
that
new
soft
navigation.
It's
very
hard
to
correlate
the
two.
So,
regarding
the
no
clear
starting
point,
the
f
history
api
that
I
mentioned
earlier,
they
came
up
with
the
concept
of
a
user-initiated
navigation.
That
is,
a
navigation
that
is
triggered
by
the
user,
clicking
on
an
actual
semantic
element,
either
an
an
anchor
or
a
form,
and
that
is
resulting
in
a
navigation.
A
So
a
navigation
where,
if
the
app
history
wouldn't
be
there
and
javascript
is
not
supported,
it
will
just
happen
as
a
multi-page
app.
That
seems
like
a
good
direction
to
steer
developers
towards.
A
It
also
gives
us
a
very
clear
start
point
for
such
navigations
and
while
app
history
solidified
that
concept,
maybe
it's
a
concept.
We
can
also
borrow
for,
like
traditional
history,
api
navigations,
potentially
then
for
interactions
versus
navigations.
That
is
a
rabbit
hole.
I
spent
a
lot
of
time
on
and
a
few
ideas
were
to
detect
paints
to
the
main
event,
and
then
there
were
concerns
that
people
will
just
add
like
what
happens
with
multiple
main
events,
which
is
a
possibility.
A
What
happens
when
the
main,
like,
not
event,
main
elements?
What
happens
when
the
main
element
is
on
a
small
part
of
the
screen,
or
would
that
result
in
you
know
incentivizing
developers
to
misuse
maine
in
weird
ways
and
that
didn't
like
there
were
a
lot
of
ques
questions
raised.
A
Then
another
thought
was
to
look
at
the
percentage
of
the
screen
painted,
but
that
naturally
creates
weird
clips
where,
if
you
paint
48
of
the
screen,
that
is
not
a
navigation,
but
if
you
paint
49,
that
is
suddenly
becoming
a
navigation
and
that
causes
weird
bimodal
effects
and
then,
finally,
with
the
help
of
a
few
folks
who
helped
me
and
reviewed
my
work,
we
realized
that
we
can
essentially
filter
interactions
based
on
past
hard
navigations
and
avoid
falling
into
that
trap.
A
So,
essentially,
a
way
for
us
to
distinguish
distinguish
interactions
from
navigations
would
be
to
say:
navigations
are
ones
that
we've
seen
past
hard
navigations
for,
and
that
can
help
us
in
the
wrong
case
to
say:
okay,
these
are
potentially
like
interactions,
so
we
don't
group
them
into
the
navigations
group
when
collecting
statistics,
because
presumably
those
are
like
they
can
be
infinitely
fast.
They
don't
necessarily
have
to
fetch
content
where
navigations
typically
do
yeah
and
regarding
pain,
correlation.
That
is
a
very
similar
problem
to
the
responsiveness
problem.
A
I
borrowed
nicholas's
diagram
for
this,
where
we
have
like
for
responsiveness.
We
currently
know
to
keep
track
of
the
events
between
the
input.
Like
the
user
has
clicked
on
a
thing.
Then
the
renderer
received
the
input
event,
the
renderer
start,
processing
the
the
event
handlers
and
then
was
done,
processing
the
event
handlers
and
then
right
now
we
just
showed
the
next
frame
painted
on
screen
as
a
potential
result
of
that
responsiveness.
A
But
this
exact
same
problem
that
we
have
for
soft
navigations
exists
for
responsiveness
where
we
don't
know
like.
We
don't
know
that
that
next
frame
is
indeed
related
to
that
user
action
and
there
is
potentially
async
work
that
can
happen
and
need
to
be
completed
before
an
actual
related
frame
is
presented
on
screen.
So
we
have
a
similar
problem
here
for
both
responsiveness
and
soft
navigations.
A
So
I
looked
into
that
from
the
angle
of
the
app
history
api
and
that
helps
for
soft
navigations,
because
it
limits
the
needed
task
tracking
to
only
promise
chains,
because
the
developers
pass
along
the
promise
to
transition
while
and
then
that
promise
is
eventually
at
some
point
modifying
the
dom
and
that
results
in
the
pain.
So
any
promise
that
dirty's
the
dom
is
paint
causing,
and
we
can
track
that
back
to
the
navigation.
If
we
can
track
promise
chains.
A
That
led
me
to
look
into
promise
hooks,
which
is
an
interesting
v8
internal
api.
But
unfortunately
it
has
some
performance
implications
that
made
the
v8
folks,
not
not
like
me
so
much
when
I
proposed
to
use
that
for
promise
hook
tracking.
At
the
same
time,
they
suggested
that
I
will
try
to
look
at
tracking
tasks
from
the
renderer
side.
A
A
A
A
chromium
build
where
I
can
see
the
different
tasks
and
essentially
provide
them
with
a
number
and
keep
track.
Each
task
has,
I
can
keep
track
of
its
parent
task
and
that
way
we
can
essentially
keep
around
the
dependency
graph
of
four
tasks
that
enables
us
to
know
that
a
task,
specific
paint
inducing
task
was
triggered
by
a
navigation
event.
So
here
I
have
the
essentially
the
app
history
demo
page
and
if
I'm
clicking
on
this
sub
page,
I
made
a
soft
navigation,
and
here
maybe
you
can
even
see.
A
Essentially,
I
can
see
that
the
task
that
resulted
in
a
layout
is
yeah
a
child,
a
descendant
task
of
the
task
that
induced
the
navigation,
and
we
can
also
go
up
the
tree
and
see
that
task.
495
was
triggered
by
488,
which
was
triggered
by
480,
which
is
the
task
that
was
dispatched
from
the
navigate
event
and
resulted
in
fetch
and
yeah,
and
eventually
that
layout
operation.
A
Yeah
so
essentially.
A
I
think
that,
like
it's
far
from
done-
and
there
is
still
a
bunch
of
problems,
for
example,
my
current
prototype
doesn't
handle
well
user
usual
user
lens
promises,
so
promises
that
are
created
in
javascript
are
not
well
handled
right.
Now
I
have
a
plan
on
handling
them.
I
need
to
actually
implement
that,
but
essentially
it
seems
like
there
is
a
path
to
enable
paint
correlation
between
the
navigate
event
or
click
events
and
the
dom
operations
that
that
triggered
them
there.
A
The
implications
for
that
is
that
we
may
not
have
to
rely
on
f
history
for
pain
correlation
as
well
as
for
a
starting
point.
Maybe
we
can
like
mimic
the
same
semantics
for
history.
Api
svas
responsiveness
could
potentially
use
the
same
mechanism
and
then
maybe
this
has
implications
on
long
task
attribution
assuming
we
can
translate
task
names
from
the
random
numbers
that
I
gave
them
into
actual
names.
That
mean
something
to
someone
a
few
caveats
here.
We
cannot
track
all
tasks.
A
For
example,
if
there
are
data
cues
and
certain
like
for
both
like
for
any
kind
of
task
tracking,
if
people
are
putting
data
into
a
queue
and
then
reading
it
later
after
a
time
out
from
a
separate
task,
we
don't
have
a
way
to
correlate
those
tests
and
say
these
are
like
you
know.
Those
tasks
are
a
continuation
of
one
another.
I
think
that
from
at
least
from
a
navigation
perspective,
I
think
this
is
fine.
A
I
think
that
we
can
essentially
tell
developers
that
if
they
want
to
be
able
to
track
soft
navigations,
this
is
not
something
they
should
be
doing
as
part
of
their
navigation
flow.
I'm
not
sure
that
this
is
similarly
fine
for
responsiveness
as
well
as
long
tasks.
This
could
interrupt
the
task
chain
we
need
to
like,
and
we
this
requires
some
more
thinking
it.
A
So
the
approach
I'm
taking
is
not
revolutionary,
but
it
might
be
easier
to
implement
when
task
scheduling
is
centralized.
A
I'm
not
sure
that
this
is
something
that
is
true
for
all
tasks
like
render
based
tasks,
implementations
in
all
browsers,
so
feedback
on
that
would
be
useful
and
interesting
and
then,
finally,
if
we
wanted
to
expose
paint
events
as
a
result
of
this
paint
correlation
tracking
for
those
soft
navigations,
there
may
be
security
restrictions
on
the
number
of
pain
events
we
can
expose
at.
A
You
know
a
certain
amount
of
time
to
avoid
developers
gaming
this
somehow
and
trying
to
get
more
paint
events
than
they
should
in
order
to,
for
example,
sniff
out
the
visibility
not
like
visited
that
is
visited
links,
it's
possible
that
the
requirement
for
like
a
user
user
initiated
navigations,
would
make
it
so
that
this
throttling
is
not
needed,
but
I'm
not
sure
I
have
not
run
this
with
security
folks,
okay,
so
if
we
can
detect
soft
navigations,
what
do
we
do
with
that?
A
A
They
include
an
end
point
which
is
currently
the
point
in
time
in
which
the
developer
resolved
the
promise
pass
along
to
transition
while-
and
there
is
an
ongoing
discussion
on
the
api
shape
for
both
yeah
for
both
same
document
entries
as
well
as
for
other
navigation-like
entries
one
result
of
past
discussions
for
from
this
is
that
we
need
a
navigation
id
that
will
help
us
to
correlate
other
performance
entries
with
that
navigation,
so
resource
timing,
entries
user
timing,
entries,
etc
and
will
enable
us
to
group
them
per
navigation,
and
that
will
help
us
with
both
like
with
real
navigations
and
then
bf
cache,
navigations
and
soft
navigations.
A
So
the
plan
here
is
to
increment
that
navigation,
id
per
soft
navigation
that
will
enable
us
to
keep
track
of
those
other
entries,
and
that
is
also
like,
doesn't
necessarily
require
a
pain,
correlation
and
app.
History
can
do
that
with
a
clear
starting
point.
Maybe
we
can
adopt
the
same
for
for
history,
api,
sbas,.
A
Potentially,
but
the
paint
correlation
bit
enables
us
to
expose
paint
timing
for
those
same
document
navigations,
so
we
would
be
able
to
just
fire
new
paint,
timing
entries
and
the
navigation
id
will
help
us
correlate
them
with
the
relevant
navigation
and,
like
I
said
this
may
or
may
not
depend
on
app
history.
It's
still
a
subject
to
be
explored,
so
essentially
I'd
love
to
hear
your
thoughts
on
this
subject.
I
know
that
nick
brought
up
sbas
is
a
huge
pain
point.
A
So
this
is
me
trying
to
fix
this,
and
I
can
I'll
now
stop
the
recording
and
we
can
discuss.