►
From YouTube: WebPerfWG call 2021 01 21
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).
B
Awesome
thanks
for
starting
it
out.
So
today
we
have
a
couple
topics:
we
have
resource
timing
tests
from
tom,
a
bf
cache
proposal
from
yov
and
layout
shift
normalization
from
annie.
B
A
So
essentially,
I
think
the
web
performance
industry
is
long
overdue
to
have
a
an
open
conversation
about
client-side,
a
b
testing.
It's
unique
benefits
and
it's
similarly
unique
unique
downsides
and
try
like
basically
get
everyone
together
in
the
room
or
as
close
as
we
can
get
these
days
and
and
hash
it
out.
So
I'm
basically
proposing
that
in
a
two
weeks
so
on
thursday,
but
a
bit
later
to
also
accommodate
for
folks
that
will
be
calling
in
from
japan.
A
We'll
talk
about
that.
I
sent
out
the
agenda
yesterday.
We
already
have
around
25
to
30
people
who
sign
up.
A
lot
of
them
are
working
group
members,
but
a
lot
of
them
are
also
not
folks.
We
regularly
see
here,
which
is
great,
I'm
also
talking
to
a
few
a
b
testing
providers
that
will
also
be
present,
and
hopefully
also
cdn
folks.
A
So
on
that
front
andrew,
if
you
can
be
there
and
potentially
bring
folks
from
the
edge
computing
side
of
the
of
cdns,
I
think
that
we
could
potentially
find
some
of
the
solution
space
to
be
in
that
area.
A
Yeah,
so
basically,
I
posted
a
link
to
the
agenda
to
the
agenda.
Please
sign
up.
Signing
up
is
just
like
adding
your
name
on
the
agenda
and
then
I'll
and
I'll.
Send
you
an
invite,
but
there's
also
like
a
link
to
to
the
meeting
and
the
in
the
agenda
itself
and
yeah.
I'm
looking
forward
to
that
conversation.
B
Sounds
great
and
just
to
be
clear,
we
will
not
be
having
the
regular
this
call
that
way
in
two
weeks
and
yo.
If
you
want
to
cancel
that
particular
meeting
as
well,
just
to
clear
it
up,
and
then
the
next
version
of
this
call
would
then
be
two
weeks
after
that
which
would
be
february
18th.
It
looks
like
at
the
same
time,
unless
there
are
any
objections
we
will
plan
on
that.
B
C
Sure,
I'm
tom
I
work
for
google
with
annie,
yohab
and
nicholas
and
the
other
speedmetrics
folks,
so
we
noticed
that
resource
timing
has
some
wpt
tests,
but
we're
actually
getting
some
bugs
filed
security
bugs
in
fact
about
cross
origin
information
leakage.
So
the
idea
here
is
we're.
C
Gonna
touch
up
the
tests,
make
sure
we
increase
our
coverage
so
that
we
catch
these
bugs
before
we
ship
them
and
hopefully
make
it
a
little
bit
easier
and
more
consistent,
because
if
you
actually
do
look
at
the
tests,
they're
they've
been
kind
of
contributed
to
by
a
bunch
of
different
folks
at
a
bunch
of
different
times.
So
it's
kind
of
you
know
a
lot
of
cognitive
overhead
to
understand
every
style
and
all
that,
so
we
thought
we'd
at
least
drop.
C
A
line
here
in
case
folks
are
interested
for
maybe
they
want
to
contribute.
Maybe
they
have
questions.
Maybe
they
have
their
own
resource
timing,
bugs
that
they'd
like
to
see
covered
in
these
tests
feel
free
to
give
me
a
shout,
I'm
just
tom
mckee
at
google.com
or
you
can
get
a
whole
eof
and
he
knows
how
to
get
in
touch
with
me.
B
And
tom
is
the
goal
to
have
a
proposal
for
replacing
the
current
test
at
all,
or
this
would
be
just
like
a
new
superset
of
more
standard
tests
covering
a
broader
area
or.
C
It
just
really
patches
to
the
the
tests
we
do
have
things
like
file
renaming
things
like
we're
using
a
bunch
of
asic
test
calls
when
we
should
be
doing
like
promise
test
calls
stuff
like
that,
but
also
once
we
have
it
organized
we're
gonna
work
to
make
sure
we
are
covering
all
the
edge
cases.
There's
a
lot
of
edge
cases
around
tommy
allow
origin
header,
you
know
matching
and
all
that
stuff.
So
once
it's
in
kind
of
a
consistent
state,
that's
when
we
can
extend
it
with
more
coverage.
C
Yeah,
I
think
we
have
a
doc
on
the
go
yoav,
I'm
not
sure
if
it's
public
or
not,
but
certainly
that'd,
be
a
great
place
to
start,
and
I
think
opening
a
github
issue
on
the
resource
timing.
Repo
would
be
a
good
way
to
collaborate.
Does
that
make
sense.
B
It'd
be
a
good
place
to
kick
it
to
start
it
out
at
least
like
a
starting
point,
and
then
people
can
find
other
documents
from
there
or
figure
out
how
to
get
a
hold
of
you
and
everything
so
yeah.
If
you
want
to
file
a
github
issue,
and
we
can
always
include
that
in
the
meeting
agenda
notes,
afterward
as
well,
and
so
people
are
that
are
interested
to
pay
attention
to
that
awesome
sounds
great.
B
Okay,
why
don't
thank
you
tom?
Why
don't
we
move
forward
to
y'all
for
a
proposal
that
he
has
on
bf
cash
sure
and
I
will
take
over
scribing.
Thank
you.
A
Okay,
so
essentially,
we've
discussed
this
at
tpack,
and
this
is
so.
We
discussed.
Multiple
options
picked
one
of
them,
and
this
is
a
more
concrete
version
of
that
same
proposal.
A
That
is
something
that
I
it's
been
on
my
mind
for
a
while.
So
previously
we
talked
about
the
fact
that
we
want
to
align
our
metrics
with
user
experience,
and
that
includes
bf
cache
navigations,
which
right
now
are
more
or
less
invisible,
and
we
want
to
make
them
visible
to
rum.
That
means
firing
new
entries
for
navigation
timing
and
other
other
timing
rather
than
overriding
them,
which
we
briefly
discussed
and
excluded.
A
We
want
to
have
single
time,
origin
for
all
navigations,
and
we
agreed
that
refiring
new
navigation
timing,
entries
and
adding
more
entries
to
the
buffer
is
the
right
way
to
go.
So
I
thought
a
bit
about
what
those
new
navigation
timing
entries
may
look
like,
and
it
seems
like
the
best
path
forward
would
be
a
new
navigation
type.
We
already
have
a
few
of
them,
adding
a
new
one
shouldn't
be
too
much
of
a
concern
from
a
compat
perspective.
A
A
Yeah
so
yeah
the
the
way
that
we
I
thought
of
extending
the
navigation
type
would
be
to
simply
add
another
value,
so
back
forward
cash
to
distinguish
it
from
the
current
back
forward
value,
which
is
defined
as
a
history
navigation.
That
is
not
a
bf
cache
navigation.
A
Ideally,
we
would
have
slightly
diff
different
names,
but
I'm
reluctant
to
rename
the
backboard
one.
So
I
think,
like
adding
the
cache
adding
cash
to
the
name
will
enable
people
to
distinguish
between
those
two
cases.
But
I'm
happy
to
hear
more
opinions
on
that
and
by
chatting
around
that
in
terms
of
spec
changes,
it
seems
like
for
that
particular
part.
A
We
would
need
to
cue
a
performance
navigation
timing,
entry
from
html's
history,
traversal
algorithm,
but
not
a
whole
lot
more
than
that,
and
then
that
particular
navigation
timing
entry
will
be
assigned
with
that
particular
type
and
yeah,
and
we'll
also
need
to
define
what
that
new
type
is
so
new,
so,
okay
and
and
then
there's
the
subject
of
adding
a
new
paint
timing
entry,
because
on
top
of
just
knowing
that
navigation
happened,
we
want
to
know
when
content
was
painted
on
screen.
A
After
that,
so
what
I
was
thinking
there
is
to
add
a
new
entry
name,
so
we
have
first
paint
we
have
first
contentful
paint
and
now
we'll
have
a
back
forward
cache
paint
and
again
this
is
very
much
open
to
bike
shedding.
This
will
be
cued
when
a
first
paint
occurs.
After
a
bf
cache
navigation
happens
and
in
terms
of
spec
changes,
we
will
probably
need
to
add
an
extra
flag
on
the
document
that
is
set
to
true
in
the
history
traversal
algorithm.
A
That
is
indicating
that
a
bf
cache
paint
should
be
reported
and
then
add
a
step
to
mark
pain,
timing
in
the
pain
timing,
spec
that
will
cue
that
entry
when
that
flag
is
set
and
unsaid
the
flag.
A
So
how
will
developers
be
able
to
use
this?
This
is
an
example
that
is
identical
to
the
one
I
showed
at
tpac
essentially
will
have.
A
Navigation,
multiple
navigation
entries
and
developers
can
pick
up
the
start
and
end
time
for
the
navigation
from
those
multiple
entries
and
then
figure
out.
The
paint
entries
that
are
related
to
a
particular
navigation
by
filtering
on
them.
Basically
filtering
between
that
start
and
end
time
for
those
bf
cache
navigations
they'll
be
able
to
pick
up
the
relevant
df
cache
paint.
B
And
in
that
example,
you're
picking
up
the
paint
from
the
first
navigation
or
the
first
time,
the
first
time
through
you'd,
be
picking
up
the
paint
from
the
first
navigation.
Okay,
I
see
it's
in
the
loop
now
sorry.
A
Yeah
yeah,
essentially,
this
is
the
broader
outline
like
here,
I'm
yeah,
essentially
filling
out
the
the
paint
for
yeah.
A
Yes,
yeah
and
it's
true
that
we
can
filter
it
down
to
bf
cache
paints
or
something
along
those
lines:
yeah,
okay
on
so
on
top
of
that,
there's
also
the
subject
of
first
input
delay
and
there
are
multiple
options
there,
so
one
which
I
tend
to
favor
the
most
is
to
fire
those
entries
so
the
first
event
or
the
first
input
event
after
bf
cache
navigation
will
be
reported
as
an
event
timing.
A
It's
just
that.
We'll
re
reduce
the
threshold
that
we
typically
use
for
event,
timing
in
order
to
consistently
report
that,
and
that
will
enable
developers
to
know
that
the
first
event
timing,
entry
after
a
bf
cache
nav,
would
be
the
equivalent
to
a
first
input.
A
Potentially,
we
also
want
to
somehow
mark
that
event.
Timing.
Entry
with
you
know
with
that
information
that
enables
you
know
other
types
of
filtering
that
are
not
solely
time
based.
Another
option
would
be
to
fire
multiple
first
input
delay
entries
that
may
be
confusing.
It
needs
some
web
compat
research,
but
that's
not
like
the
web.
Compat
part
is
not
really
scary
to
me.
Also.
A
I
I
didn't
mention
that,
but
for
also
for
pain
timing
and
for
firing
more
pain,
timing
entries,
that's
also
something
I
did
compat
research
on
and
it
seemed
to
be
web
compatible.
Very
few
analytics
providers
collect
unknown
entries
that
may
or
may
not
cause
them
to
misinterpret
the
results.
So
it's
perfectly
safe
to
fire
more
pain,
timing
entries
from
new
with
a
new
name-
I'm
not
like.
I
I.
A
If
we
choose
to
go
that
route
and
choose
to
fire
more
than
one
first
input,
entry
I'll
need
to
do
similar
research
there,
but
I
suspect
that
it
will
be
fine.
A
The
main
concern
there
from
my
perspective
is
that
it
may
be
confusing
to
developers,
but
I'm
curious
to
hear
y'all's
thoughts
on
that
and
then
the
third
option
is
fire
like
come
up
with
a
new
entry
type
for
a
bf
cache
first
input,
which
would
mean
that
if
folks
want
to
observe
that
they
need
to
observe
yet
another
entry-
and
that
may
not
be
great.
A
So
I'm
interested
to
hear
your
thoughts
on
that
and,
finally
for
lcp,
because
the
lcp
in
the
bf
cache
navigation
case
is
highly
likely
to
just
be
identical
to
the
first
pain
there.
It
makes
sense
to
not
re-fire
it.
I
looked
into
what
it
would
take,
it's
possible.
It
adds
some
complexity
and
it
seems
like
something
we
can
ignore
for
now,
but
we
will
probably
need
to
tackle.
A
What
happens
with
lcp
in
the
future
if
we
come
up
with
new
navigation
types,
such
as
soft
navigations
for
sbas,
and
with
that
I
am
out
of
slides
but
yeah
like
I
said,
I'm
curious
to
hear
your
thoughts
on
fidd
and
other
than
that.
Various
bike
shedding
related
arguments.
A
D
So
you
up
so
for
paint
timing.
Have
you
thought
about
expanding
existing
first
paint
a
little
bit
like
to
having
an
attribute
saying
this
is
for
bf
cache.
Instead
of
creating
a
new
paint
timing,
entry.
A
So
I
thought
about
so:
it's
not
so.
Instead
of
we're
not
creating
a
new
type
of
entry,
we're
just
adding
a
new
name
to
the
list
of
names.
So
it's
the
same
paint
entry
observers
have
to
observe
a
single
paint
type
and
then
they
get
first
paint
first
contentful
paint
as
well
as
this
new
bf
cache
paint.
A
I
thought
about
just
re-firing
first
paint,
but
there
are
some
like
compatibility
concerns
with
the
fact
that
people
will
collect
that
as
their
first
paint
potentially
and
that
may
or
may
not
confuse
current
analytic
providers.
A
D
Cool
thanks,
I
think
I
misunderst
I
understood
yeah.
That
makes
sense
another
question
I
have
for
reducing
the
threshold
for
fid.
Have
you
thought
about
like
what
the
threshold
would
be
for
that,
because
I
also
recall
it
during
we
said
something
like
the
current
bar
is
already
too
low
like
for
the
fresh
food.
D
So
it's
it
wasn't
that
useful.
So
I
wonder
if
we
keep
reducing
it
even
further,
like
even
just
for
bf
cash
with
that,
like
still
having.
D
A
Yeah,
so
I
think
it's
I'm
talking
about
maybe
a
different
threshold,
so
I'm
not
talking
about
the
threshold
of
what
is
a
good
fid
versus
bad
fid.
I'm
just
stop.
I
talked
about
the
threshold
for
event,
timing
that
right
now
we
don't
fire
event,
timing
entries
for
every
input
event,
but
just
for
ones
that
we
consider
slow
for
the
threshold
of
slow
events,
which
I
believe
is
a
50,
milliseconds
or
52.
A
I
don't
remember
like
there
was
some
weird
thing
about
running
rounding
to
eight
milliseconds
there
and
we
discussed
making
that
threshold
customizable
up
to
a
certain
point,
and
what
I'm
suggesting
here
is
that,
after
a
bf,
cache
will
always
fire
an
event.
Timing
entry,
regardless
of
how
long
it
took
for
that
event
to
be
processed.
A
B
A
Events
which
is
a
bit
of
a
higher
bar
but
yeah
but
feasible
and
yeah,
I'm
not
aware
of
anyone
doing
that
today.
B
B
It
it
almost
seems
to
me
like
from
a
compatibility
perspective,
if
somebody,
if
there's
some
analytics
provider
or
package
or
somebody
that
has
very
little
or
no
insight
about
bf
cache
today,
if
they're
going
to
be
updating
their
code
anyway
to
care
about
it,
it
seems
reasonable
that
they
would
intentionally
then
listen
to
more
entry
types
to
get
more
data
about
this
new
new
new
event
that
they're
listening
to.
A
B
A
Yeah
that
that
was
my
thinking
and
yeah
and
if
I
understand
what
you're
saying
correctly
is
that
if
we
don't
do
that,
people
will
potentially
be
confused
if
they
don't
take
bf
cash
into
account,
potentially
yeah,
and
maybe
we
can
diffuse
some
of
that
confusion
by
marking
those
event.
Timing
entries
as
a
bf,
cache
event,
timing,
thing
and
yeah,
so
we
can
add
a
new.
I
don't
know.
If
name
is
the
like.
What's
the
best
place
to
hang
that
but
yeah
we
could
do
that.
B
Nicholas,
can
you
say
that
again,
what's
the
type
in
this
case,
what
are
the
different
types.
E
I'm
sorry,
I
don't
know
if
you
can
hear
me
properly,
I'm
using
another
microphone,
it's
event,
type
like
a
mouse
down.
Click,
okay,.
A
A
A
Yeah,
so
anyone
with
strong
opinions
regarding
those
two
options,
thoughts
or
three
options.
I.
A
F
Hey
yo,
I
have
a
question
not
about
that,
but
about
that
last
bullet
point
on
the
lcp
slide
where
you're
talking
about
like.
Do
we
re-fire
lcp,
fcp
fp,
on
the
nab
case
and
for
future
navigation
types,
I.e,
spas
navigation?
What
are
we
going
to
do
so?
I
just
want
to.
F
I
want
to
kind
of
think
through
this,
assuming
we
have
other
navigation
types
besides
back
forward
cache,
and
that
includes
some
of
the
things
we
know
we
need
and
I'm
wondering
if
you
can
kind
of
generalize
this
to
that
like
for
me,
it
seems
safer
to
say
that
we
are
going
to
re-fire
all
this
stuff
instead
of
special
casing,
just
bf
cache,
because
I
think
in
the
spa
navigation
case
you
would
have
to
re
re-fire
those.
A
I
agree
that
in
the
spawn
navigation
case
we'll
have
to
re-fire
those,
I
don't
think
we
have
enough
insight
into
what
that
would
look
like
the
the
spa
navigation
case
and
I'm
concerned
about
solving
a
problem.
We
don't
yet
fully
understand
here
with
lcp
because
for
bf
cache,
if
we
were
to
re-fire
lcp
like
I
have
a
sketch
design
of
what
the
spec
changes
would
look
like,
but
then
developers
will
have
like
the
the
part
that
I'm
mostly
struggling
with
is
how
will
developers
be
able
to
distinguish.
A
You
know
lcp
for
navigation,
one
from
lcp
to
navigation
two,
and
I
think
that
would
potentially
differ
depending
on
the
shape
of
the
api
that
we'll
land
on
for
sbas
and
deciding
on
that
before.
We
are
actually
like
before
we're
confident
solving
the
sba
problem,
because
I'm
I'm
I'm
currently,
I
don't
know
what
the
apa,
what
the
api
shape
would
look
like
that
that
it
seems
premature.
So
I
don't
think
there
are
advantages
to
solving
this
problem
like
it's
a
problem
we'll
need
to
solve.
F
F
So
for
me
it
seems
harmless
to
just
treat
them
consistently
if
only
to
simplify
the
mental
model
here,
but
you
know,
opinions
may
differ.
I
agree
we
don't
want
to
like
make
crazy,
abstract
interfaces,
but
I'm
just
saying
like
to
me:
it
seems
like
the
cause.
The
the
path
of
least
resistance
is
to
re-fire
and
then
maybe
re-fire
for
spas
2,
and
then
we
have
an
advantage
of
consistency,
but
you
know
not
everybody's
super
keen
on
consistency,
so
they
love
you.
E
B
G
A
The
problem
is
that,
right
now,
the
current
libraries
that
collect
lcp
and
the
advice
we
give
the
developers
that
want
to
collect
lcp
is
just
iterate
over
iterate
over
the
array
until
you
know,
find
the
last
entry,
and
that
is
your
lcp
and
once
we
introduce
new
navigations
like
other
navigations.
On
top
of
that,
that
will
change
so
maybe.
A
What
we
should
be
doing,
like
is
to
think
about
ways
like
that
we
can
change
that,
like
the
current
libraries
and
developer
advice
to
make
it
so
that
a
future
future
lcp
entries
that
we
may
want
to
add
will
be
compatible
and
start
working
on
that
now,
without
necessarily
like,
potentially
without
tying,
that
to
bf
cache,
but
just
making
sure
that
adding
more
lcp
entries
is
a
future
compat.
A
Actually,
it
would
be
challenging
to
actually
get
people
to
change
their
website
to
the
new
guidance
and
then
because
yeah
I'll
web
compatibility
changes
are
hard.
So.
A
Yeah,
it
may
make
sense
to
yeah.
If
we
were
to
introduce
a
new
type
on
the
lcp
entries,
we
can
tell
people
to
yeah
check
for
the
type
or
check
for
boolean,
or
I
know
that
nicholas
had
thoughts
about
final
lcp,
which
would
be
potentially
easier
from
a
compat
perspective
in
those
cases.
So
maybe.
E
H
B
I
want
data
after
you
know,
sometime
and
and
kind
of
related
to
that.
I'm
actually
I'm
curious.
How
many
analytics
providers
actually
do
anything
after
they've
detected
either
a
page
hide
or
I
guess
that
would
be
the
main
one
here.
Paycheck
event,
you
know,
for
example,
for
boomerang.
We
generally
shut
down
a
lot
of
our
monitoring
and
stuff,
so
we
wouldn't
necessarily
get
tripped
up
if
the
user
comes
back,
because
we've
stopped
monitoring
anyways
for
many
cases.
A
I'm
not
sure
yeah,
so
it
may
make
sense
to
start
collecting
data
on
that
and
see
if
anyone
like
yes,
this
is
true
like
if
no
one
is
calling
like
the
observers.
If
everyone
are
shutting
down
their
observers
after
the
f
cache
navigations,
then
yes,
we
can
add
whatever
we
want
in
those
cases.
A
I
I
wouldn't
want
to
block
the
initial
bf
cache
case
for,
like,
like
the
initial
bf
cache
changes
that
we
know
what
we
want
them
to
look
like
for
this,
but
maybe
we
can
start
thinking
about
measuring
that
part
measuring
people
who
observe
and
touch
performance
entries
after
you
have
cash
navigations
or
for
the
sba
case.
Maybe
this
is
also
something
we
can
measure
after
something
happened
on
the
page.
H
I
kind
of
echo
a
point
made
by
moses,
which
is
that
I,
I
think
we
we
would
also
be
uncomfortable,
adding
this
be
specific
solution
for
bf.
Caching
later
you
know,
maybe
next
year
or
a
couple
years
from
now,
we
come
up
with
a
yet
another
solution
for
sba.
I
think
we
need
to
figure
out
a
generic
solution
that
supports
both,
like
we
shouldn't,
be
just
keep
adding
random
new
solutions
to
each
problem
we
encountered
in
the
new
year
right
like
we
need
to
have
a
platform,
consistency
and
every
new
type
and
every
new
solution.
H
A
E
Okay,
maybe
maybe
it
could
be
good
to
highlight
how
it
would
be
extended
for
other
types
of
navigations
like
stuff,
navigations
portals
or
whatever,
like
show
that
it
is
extensible
to
other
use
cases
besides
bf
cache,
maybe.
H
Yeah
I
mean
like
like
let's
say:
we
decided
that
okay,
the
best
way
to
solve
the
bf
cache
is
that
the
new
types
right
then
we
don't
want
to
like
get
to
the
situation
where
a
couple
years
later,
oh,
like
we
have
that
yet
another
new
types
for
other
types
of
navigation,
like
it.
A
Yeah
sure,
but
maybe
we're
running
a
bit
out
of
time
here,
but
just
to,
I
think
that,
yes,
we
already
have
four
navigation
types,
now
we're
adding
a
fifth,
and
it
seems
reasonable
that
we'll
add
a
sixth
once
one
is
needed
same
for
paint,
timing,
entry
where
it's
yeah.
We
already
have
first
paint
and
first
contentful
paint,
and
now
we'll
add
a
third
to
that.
A
So
I
don't
think
that
those
additions
for
navigation
timing
and
for
paint
timing
are
somehow
inconsistent
with
what
we
have
today.
I
agree
that
regard
like
when
we
look
at
fidd.
We
need
to
make
sure
that
whatever
we
do,
there
is
consistent
with
with
what
currently
happens,
with
either
event
timing
or
or
which
is
why
I'm
more
favorable
of
either
like
firing
more
like
firing
more
of
what
we
already
have
either
event
timing
or
first
input
rather
than
adding
another.
H
B
B
I
B
If
we
do
have,
you
know
we
have
another
13
minutes
or
so
till
the
end
of
the
hour.
Do
we
want
to
think
through
a
little
bit
more
about
the
bf
cache
stuff.
I
I
know
that
we
have
a
lot
of
interest
from
bob
and
other
people
on
my
team
about
just
how
all
the
different
types
of
navigations
do
fit
together.
Are
there
other
people
that
are
interested
in
this
topic
that
might
want
to
spin
up
some
some
time
to
work
together
on
it?
Does
that
sound
like
a
good
next
stop.
J
F
Yeah,
I
know
the
biases
on
the
bf
cache
right
now,
but
we're
looking
ahead
to
spots
so
yeah
we
would
love
to
see
kind
of,
like
you
know,
a
grid
of
working
with
you
to
establish
a
grid
of
navigation
types
and
what
the
constraints
are
on
these
metrics.
I
think,
if
just
to
explain
it
to
ourselves
and
to
our
colleagues,
I
think
it
would
be
very
helpful.
A
Yeah,
so
maybe
if
we
yeah
yeah,
I
think
it
generally
makes
sense.
A
I
think
that
generally
we
have
like
the
various
performance
entries
have
some
like
consistency
problem,
for
example,
like
name,
is
used
for
different
things
in
different
entries,
and
it
may
like
for
web
compatibility,
we'll
have
a
hard
time
dropping
what
is
currently
shipped,
but
maybe
we
can
figure
out
a
way
for
people
to
move
away
from
that,
although
that
always
runs
a
risk
of
you
know
the
n
plus
one
problem
where
we
just
add
a
new
thing.
A
We
can't
drop
the
old
thing
and
then
we
have
inconsistency
between
those
two.
I
don't
know
if
this
is
but
but
yeah
generally
working
on
the
consistency
problem
makes
sense.
I
yeah,
like
I
said
I
tried
to
work
with
the
current
mechanisms
for
each
one
of
those
entries
when
adding
a
new
one.
It
would
have
been
good
if
we
had
a
single
mechanism
for
all
entries
in
which
we
can
use
so
instead
of
using
name
in
one
and
type
in
the
other.
E
Better,
but
that's
not
that
there
was
ryozuki's
idea
to
just
have
a
method,
and
that
is
a
single
mechanism
right,
so
there
are
ways
to
do
it.
A
Oh
add
a
method
of
move
me
to
the
new
type
of
entries,
and
then
we
drop
name
and
do
something
else
with
it.
A
No,
it's
just
that
the
the
entry
name
is
for
me,
one
of
the
biggest
like
sources
of
inconsistency,
because
it's
used
for
different
things.
So
in
resource
timing,
it's
the
url
in
navigation
timing,
its
document
and
other
like
it's
used
for
different
things.
So,
but
but
I'm
not
sure
like
yeah.
Maybe
you
can.
A
No,
I
I,
I
think
that
adding
new
entries
is
fine.
I
think
that
the
fact
that
you
know
we
can't
consistently
use
a
single
a
single
attribute
for
all
of
them
to
signify.
This
is
a
new
entry.
This
is
a
is,
I
mean
it
can
always
add
a
new
attribute
to
performance
entry.
B
A
H
A
Okay,
so
that
the
bf
cache
navigation
time
will
be
somewhere
after
the
start
time
of
a
different
navigation.
But
before
the
end
time
of
that
navigation.
H
E
B
And
russia
you're
talking
about
both-
I
mean
that
could
happen
just
during
a
normal
navigation.
Before
the
you
know,
load
event,
fires
or
whatever
you
could.
I
guess
bf
cache
navigate,
but
it
could
also
happen
with
like
a
for
a
type
that
we
don't
have
yet,
which
is
more
of
like
a
soft
navigation
within
a
site.
Certainly.
H
B
And
if
we're,
if
we're
really
just
concerned
about
not
confusing
existing
analytics,
I
think
the
easiest
way
is
just
to
make
these
all
new
things
that
you
have
to
listen
for,
and
then
you
just
don't
have
to
worry
about
it,
yeah
that
it's
your
whole
end
placement
thing
where
there's
always
like
additional
things
to
do
and
stuff,
but
maybe
that
will
help
break
the
log
jam
of
us
being
concerned
about
well.
H
I
mean
so,
I
think,
I'm
not
saying
that
I
I
don't
have
a
bad
ways
to
do
this,
but,
like
I
think
one
interesting
thing
is.
Is
that
there's
some
sort
of
study
of
how
the
different
forms
of
navigation
happens
within
that
given
website
like
soft
navigation,
as
well
as
the
bf
cache,
navigations
and
other?
You
know
other
forms
of
things
that's
happening,
and
you
know
there
are
cases
where
things
are
overlapping.
There
is
that's
no
overlapping,
but
I
think
it.
H
I
think
we
need
to
come
up
with
some
sort
of
like
a
mental
model,
of
how
all
these
navigations
happens
in
order
for
us
to
come
up
with
a
sensible
api
for
observing
each
type
right,
because
because,
at
the
end
of
the
day
like
we
need
to,
we
need
to
make
sure,
like
whatever
the
page
observes
actually
makes
sense.
You
know
like
we
need
to
make
sure
the
api
is
such
that
when
you
get
the
data,
you
can
discern
different
kinds
of
navigations.
H
If
navigations
are
happening
within
another
navigations,
we
want
to
make
sure
like
scripts.
Don't
get
confused
about,
for
example,
like
which
navigation
that
you
know
for
explain,
corresponds
to
and
so
forth
or
like
every
so
you
know
resource
timing.
A
H
Observe
I
so
let
me
give
you
example
right
in
the
case
of
soft
navigation,
like
let's
say
you're
on
some
page
a
and
you
go
to
b,
right
and
user
immediately
goes
back
to
a
in
that
case,
it's
possible
that
the
navi
so
like
in
in
sort
of
abstract
the
page
loading
with
a
continued
while
b
was
being
loaded
right,
because
once
you
start
fetching
things
from
over
network
you're
not
going
to
stop
it
per
se.
In
a
soft
navigation
case,
often
up.
H
B
H
In
that
sense,
it
might
be
that
when
user
navigates
from
a
to
b,
that
you
know
navigation
for
it
just
never
ends,
I'm
not
sure
if
that's
necessarily
the
right
model
for
all
the
apps.
I'm
not
saying
that,
but
I
mean
like
certainly
for
some
apps,
that
kind
of
model
makes
sense.
H
So
I
I
think
I
think
we
need
to
have
a
better
understanding
of
like
what
all
these
you
know,
new
types
of
navigation
that
may
happen
in
the
web,
apps
the
websites
that
and
then
how
each
website
wants
to
treat
them,
what
their
models
are.
A
Trying
to
reconcile
that
I
don't
want
to
like
I
explicitly
don't
want
to
have
to
solve
everything
that
anyone
will
want
to
do
in
the
future.
In
order
to
you
know,
solve
a
problem.
We
already
have
a
fairly
good
understanding
of,
but
yeah
getting
some
sense
of
that
through
yeah,
potentially
talking
to
developers
who
currently
shipped
those
kind
of
experiences
makes
general
sense.
H
Yeah
yeah,
I'm
obviously
not
saying
that
we
need
to
solve
all
those
problems
before
we
can
add
api
for
bf
cache
right.
I'm
just
saying
that
we
need
to
have
some
sort
of
mental
model
of
like
how
all
that
stuff
kind
of
fits
together.
So
when
we
try
to
add
those,
we
don't
sometimes
oh
wait
a
minute.
We
made
a
mistake,
we'll
be
of
cash
and
we
have
to
you
know,
create.
B
B
And
with
that,
we
are
out
of
time
for
the
day.
So
thanks
everybody
for
the
discussion
today
reminder
again
two
weeks
from
now
we'll
be
doing
a
slightly
different
meeting,
not
at
this
time,
but
I
think
two
hours
later
yeah
so
starting
an
hour
from
now
yep
on
that
thursday
and
then
we'll
re
resume
this
meeting
two
weeks
after
that,
thanks
everyone
for
joining.