►
From YouTube: WebPerfWG call - 2022 07 21 BFCache restoration entry
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
Let's
see
here,
we
go
yeah
anyways,
just
a
quick
update
on
the
work
we've
been
doing
there.
We
go
on
a
back
forward,
cache
restoration
entry,
addition
to
the
performance
timeline.
How
here
has
been
actually
implementing
it,
and
it's
on
the
call
today
as
well.
A
This
is
this
has
been
response
to
issue
182
on
performance
timeline
where
we're
talking
about
new
navigation
types
and
basically
how
we
want
to
represent
those.
I
believe
the
I
mean
the
resolution
after
after
many
rounds
was
that
we
really
do
want
different
entry
types.
These
aren't
navigation
entries,
they're,
fundamentally
different,
so
we
should
treat
them
differently,
we're
going
to
tie
them
all
together
with
the
concept
of
the
navigation
id.
A
But
basically,
what
we've
got
is
a
new
performance
entry
object
currently
named
back
forward
cache
restoration
entry,
it's
a
bit
long,
but
we
can
bite
hit
on
names,
extends
performance
entry,
entry
directly
we're
not
trying
to
extend
navigation
entry
most
of
the
fields
on
that
simply
aren't
relevant
to
a
bm
cache
restorer,
the
the
fields
we've
got
on
it
from
performance
entry
I
mean
it
doesn't
have
a
name
hasn't
it
has
an
entry
type.
A
And
the
reason
for
that
is
that
we
want
to
basically
encapsulate
the
timing
of
the
page
show
event
so
event
start
event.
End
very
similar
to
the
page
load
start
page
load
end
on
a
navigation
entry
and
similar
things
to
that,
that's
the
end
of
the
slides,
but
what
I'm?
What
I'm
looking
at
is
we're
looking
for
is
feedback
on.
Does
the
api
shape
make
sense?
A
Are
there
additional
fields
that
people
think
that
we
should
capture?
You
know
we
went
through
a
bunch
of
different
things
on
on
navigation
entering
important
entry
and
figured
that
this
is
sort
of
the
minimal
set
that
actually
makes
sense.
Yeah
go
ahead.
Nick.
B
A
And
I
I
believe
so
I
believe
iteration
is
defined
on
performance
entry
directly.
I'd
have
to
go,
look
so
so
start
and
duration
would
both
be,
which
will
be
there
and
yeah
you'd
end
up,
basically
being
a
page.
Two
event
end.
C
B
Good
because
that'll
reflect
kind
of
the
user
experience
right
what
the
user
thinks
the
page
is
ready.
Okay
right,
another
question:
if
you
don't
mind
navigation
id,
you
mentioned
that
this
will
be
the
first
yeah.
So,
okay,
with
that
two
questions
related,
are
I'm
trying
to
remember
our
previous
discussions
on
this?
Is
navigation
id
just
kind
of
like
an
auto
incrementing
number,
or
is
it
some
sort
of
unique
id
that
is.
A
An
excellent
question:
the
current
implementation
that
we
have
behind
the
flag
in
chrome
is
an
auto
incrementing
number.
I
think
it
starts
at
one
with
the
initial
network,
http
navigation
and
would
be
incremented
with
any
bf
cache
or
or
even
spa,
nav
sort
of
with
one
of
these
being
the
first
in
a
new
sequence
of
of
events.
With
that
same
navigation
id,
there
is
definitely
a
point
to
be
made
that
an
unguessable
token
might
be.
A
If
anything,
it
might
stop
people
from
relying
on
the
semantics
of
an
incrementing
id,
and
it
might
allow
us
to
you
know
at
the
point
where
we
want
to
introduce
navigation
id
for
spa
apps.
For
instance,
we
don't
want
to
break
anybody's
assumption
that
only
vf
cache
increments
this
and
it
always
goes
in
strict
descending
sequence.
A
But
yeah
I'd
be
interested
in
knowing
other
people's
take
on
pros
and
cons
of
those.
B
We
one
one
thing
that
we
have
seen
in
our
field
data
for
our
rum
stuff.
Is
that
not
all
beacons?
Not
all
telemetry
makes
it
to
our
back
end
right.
So,
for
whatever
reason,
not
every
single
thing
arrives
at
our
servers
and
we
we
do
increment
the
like
beacon
number.
If
you
will
every
time
we
send
a
beacon,
so
we
can
actually
spot
the
cases
where
we're
missing
some
telemetry,
because,
like
the
numbers
jump
or
something
like
that,
I'm
not
sure
if
that
would
be
applicable
here.
B
B
C
A
B
And,
based
on
that,
are
you
thinking
that
the
other
entries
would
also
by
default,
have
this
navigation
id
at
the
same
time
that
this
this
is
released
now
that
now
that
we
have
a
thing
saying
it's
a
navigation
id,
would
all
the
other
things
link
to
that
navigation.
Id.
A
Yes,
that
that's
the
idea
we
want
to,
we
want
to
append
that
to
basically
every
performance
timeline,
entry
and
then
each
event
basically
gets
the
id
of
the
most
recent
previous
navigation.
B
Okay,
one
more
question:
if
nobody
else
says
the
so
the
thinking
through
the
duration
here
that
we
were
talking
about
of
you-
know
the
user
action
till
the
page
show
event,
and
it's
nice,
that
we
have
this
breakdown
for
how
long
the
page
show
event
took,
because
obviously
that
can
be
affected
by
the
page.
B
The
work
that
they're
doing
there
is
there
any
other
interesting
breakdowns
of
the
difference
that
you
might
encounter
like
the
unexplained
other
duration
until
the
before
the
page
show.
Event
starts,
for
example,
that
we
could
expose
here
something
that
the
site
may
be
able
to
affect
by
doing
less
things
or
something,
or
is
that
more
or
is
that
more
like
browser
internal.