►
From YouTube: WebPerfWG call - 2022 10 13 - Soft Navigation Heuristics
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
So,
on
the
let
me
try
to
okay,
okay,
it
works
and
I'll
paste
the
slides
link
into
the
chat
right
now:
yeah
cool
yeah,
so
I
wanted
to
talk
to
you
all
about
stop
Navigation
heuristics.
This
is
a
left
over
topic
from
tea
bag
that
we
didn't
get
time
for.
At
the
same
time,
it
was
good
because
I
didn't
actually
wrote
my
slides,
then
I
just
wrote
them
today,
but
so
it
all
worked
out
for
the
best.
A
Basically,
this
is
a
continuation
of
a
conversation
we
started
last
year,
if
not
before
at
TPAC.
Last
year
we
talked
about
measuring
Spas
what
it
would
mean
why
it's
hard,
yada
yada,
and
then
this
year
we
talked
a
bit
about
task
attribution,
which
is
infrastructure
that
is
needed
in
order
for
those
heuristics
to
work
properly,
and
now
we're
gonna
talk
about
the
heuristics
themselves.
So
there's
an
explainer
up
on
GitHub
there's
a
ycg
proposal.
A
I
have
a
chromium
prototype
that
is
implemented
behind
a
flag
and
I'm
planning
to
go
for
an
origin
trial
to
enable
folks
to
try
it
out
soon.
That's
the
like
the
high
level
overview.
But
what
are
we
talking
about?
We're
talking
about
self-navigation
heuristics,
we're
talking
about
SBA
navigations
that
are
JavaScript
driven
and
the
use
case
to
enable
developers
to
measure
that
is
to
enable
developers
to
correlate
their
performance
entries
of
various
types
to
the
corresponding
soft
navigations?
A
And
so
that
is
true
for
all
existing
performance
entries
for
load,
related
entries,
so
pain
time
me
so
first
paints,
first
contentful
paint
and
largest
contentful
paint
at
the
very
least.
It
might
be
interesting
to
re-trigger
those
in
the
you
know,
in
the
case
of
soft
navigation,
and
be
able
to
measure
the
impact
of
those
paints
on
those
soft
navigations.
A
So
what
are
the
heuristics
we're
talking
about?
They
are
relatively
simple
ones:
I
started
with
more
complex
heuristics
and
then
trimmed
them
over
time.
A
When
you
know
when
life
convinced
me
that,
in
order
to
increase
to
actually
cover
most
existing
sbas
I
need
to
simplify
that,
so
the
current
heuristics
are
based
on
a
user
initiated
click
for
some
definition
of
click
that
we'll
talk
about
in
a
bit
that
is
resulting
in
both
a
URL
modification,
a
user,
visible
URL
modification
to
the
history
API
or
the
navigation
API,
and
then
a
Dom
modification
both
of
those
are
the
direct
result
of
the
user,
initiated
click
and
for
to
be
able
to
say
that
one
is
a
result
of
another.
A
This
is
why
we
needed
task
attribution
for
that
and
the
reason
the
reason
I
have
a
an
asterisk
on
click.
Is
that
Michael
pointed
out
that
some
click
events
are
like.
We
need
to
account
for
accessibility
as
well,
and
click
events
won't
always
cover
it,
and
this
is
another
part
where
I'll
need
to
expand
the
heuristic
a
bit
to
cover
keyboard,
driven
navigations
or
yeah
keyboard,
driven
interactions
with
the
with
the
page
and
navigation
to
the
next
page.
A
The
next
intense
of
paint
will
trigger
an
FCP
and
all
the
largest
contentful
paints
from
that
point
on
will
trigger
FC
LCP,
where
we're
restarting
the
size
of
what
largest
means
and
resetting
the
fact
that
we're
stopping
to
re.
We
stop
recording
lcps
after
an
interaction,
and
this
will
continue
up
until
the
next
interaction,
at
least
that's.
What's
what
I
currently
have
in
mind,
we'll
also
talking
about
triggering
a
new
entry
that
will
be
a
soft
navigation
entry.
A
It
doesn't
include
a
lot
of
a
lot
of
attributes
on
its
own.
It
has
the
navigation
ID
attribute
that
we
already
talked
about
that
Ian
talked
about
previously
about
the
a
way
for
us
to
designate
different
Navigation
types
and
and
know
that
another
navigation
app
and
that
we
can
correlate
perform
other
performance
entries
too.
It
includes
the
start
time,
which
is
the
time
where
the
click
when
the
click
event
started,
and
the
name
has
the
soft
navigation
URL
entry
type
is
soft.
A
Navigation
and
duration
is
currently
being
discussed
and
we'll
talk
about
it.
At
the
end,
there
are
multiple
options:
there
some
code
examples
on
how
people
will
actually
use
this.
So
if
you,
just
as
a
developer,
want
to
collect
a
list
of
the
soft
navigation,
the
stuff
navigations
that
happened
at
the
sessions
end,
you
can
just
use
performance,
Observer
the
buffered
flag
and
just
collect
those
entries,
as
you
normally
would
no
surprises
there.
If
you
want
to
create
a
list
over
time,
as
the
page
is
loading.
A
Similarly,
you
will
create,
like
add,
create
an
array
and
then
push
entries
to
that
array
as
a
performance.
Observer
gets
fired
over
time
and
with
yeah
and
and
then,
if
you
want
to
correlate
entries
with
those
navigations,
you
can
similarly
collect
those
entries
in
this
example.
It's
LCP,
but
it
could
be
any
other
kind
of
entry,
and
then
you
can
take
your
for
each
one
of
those
entries.
A
Take
your
list
of
self
navigations
filter
them
to
find
the
soft
navigation
entry
with
that
navigation,
ID
and
then
you
know,
apply
the
duration
based
on
the
entries
start
time
and
navigation
like
the
entry
start
time
minus
the
navigation
start
time
would
be
your
entries
duration
compared
to
the
soft
navigation
reading
out
that
code
out
loud
I
realized
that
this
is
not
like.
This
is
Owen
Square.
Don't
do
that.
I
will
fix
my
examples
and
yeah
bad
bad
bad.
A
A
This
relies
on
task
attribution,
which
is
also
completely
unspecified
and
will
need
to
be
specified
to
some
extent,
at
least
in
order
for
those
heuristics
to
be
interoperable
and
then
finally,
we,
like
this
imagines
pain,
timing
and
LCP
modifications
that
will
yeah
need
to
happen
in
order
to
specify
everything.
I
just
said
in
chromium,
we
have
somewhat
working
prototype.
It
is
like
it's
working
well
enough.
A
A
There
are
a
bunch
of
issues
on
the
GitHub
repo
if
you
have
ideas
or
thoughts,
please
file
more
and
finally,
folks
here
could
chime
in
on
the
ycg
proposal.
In
order
for
us
to
be
able
to
take
the
repo
from
my
own
personal
repo
and
move
it
over
to
the
ycg,
there
are
a
bunch
of
open
questions.
One
is
what
should
the
duration
be?
There
is
a
one
of
the
issues,
discusses
that,
and
it's
like
right
now.
It
seems
like
a
good
option.
A
There
would
be
the
time
in
which
so
the
end,
we
know
what
the
start
time
is.
What
would
be
what
should
be
the
end
time,
and
then
one
option
is,
for
the
end
time
to
be
the
time
in
which
we
realized
or
that
the
heuristic
realized
that
a
soft
navigation
has
happened
so
a
time
after
the
user
clicked
where
the
Dom
modification
happened
and
the
URL
was
changed.
A
That
could
be
one
option.
I
am
open
to
other
suggestions.
Another
open
question
was
around
the
FCP
and
LCP
definition
right
now:
I'm,
not
necessarily
considering
the
FCP
or
LCP
to
be
ones
that
are
a
direct
result
of
the
user
interaction,
so
I'm
stopping
the
task
attribution
part
at
the
at
the
point
where
we
decide
that
the
self
navigation
has
happened,
but
not
taking
it
further.
A
Maybe
we
should.
It
would
be
interesting
to
gather
opinions.
It
would
also
be
interesting
to
gather
data
once
we
have
people
trying
this
out
in
production
using
the
origin
trial
same
for
the
third
question
here,
maybe
we
need
more
complex
heuristics.
Maybe
there
are
some
false
positive
or
some
false
negatives,
and
these
are
things
that
I
think
will
be
answered
in
the
field,
and
with
that,
let's
start
the
discussion
portion
I
will
stop
recording.