►
From YouTube: TPAC WebPerfWG 2021 10 26 - BFCache
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
A
Okay,
so
yeah.
So
what
I'm
here
for
today,
though,
is
to
talk
to
the
you
know:
the
performance,
people
and
the
rum.
People
really-
and
I
have
some
some
requests
from
kind
of
the
chrome
teams,
fbf
cash
team
on
ways
that
you
can
help
improve
the
hit
rate
and
improve
the
performance
of
the
web
in
general
and.
A
Improve
the
developer
experience
as
well
for
this,
so
we
kind
of
want
you
know,
so
I'm
not
sure.
Actually
I
don't.
I
don't
know
the
people
in
the
room
here,
but
so
there
are
rum
companies
here,
people
who
are
like
building
dashboards
that
give
people
metrics
on
their
performance
right,
so
it'd
be
great.
If,
if
those
metrics
included
the
bf
cache
hit
rate
for
the
sites
in
question,
it'll
be
great.
A
If,
if
those
dashboards
could
tell
the
the
sites,
what
on
their
page
is
causing
them
to
miss
bf
cache,
and
then
if
there
are
libraries
and
things
like
that
that
you,
you
know
third
party
libraries
that
sites
run
in
order
to
get
your
metrics
if
any
of
them
are
using
unload.
You
know
I'd
like
to
try
and
figure
out
how
we
can
move
you
off
on
load
and
on
to
something
else.
So
what
yeah?
A
So
on
the
on
the
hit
rate
thing
you
know
this
would
really,
I
think,
raise
the
profile
of
bf
cache.
You
know
some
developers
know
about
it.
Some
don't
and
often
people
are
getting
blocked
from
bf
cache
for
simple
reasons
that
they
can
fix.
Wikipedia
fixed
themselves
very
quickly,
once
we
once
we
worked
with
them
to
you,
know,
told
them
what
was
blocking
them.
A
They
were
able
to
fix
it
very
very
quickly
so,
and
people
also
you
know
if
you
give
people
numbers,
they
can
improve
their
numbers,
and
so
I
have
a
little
bit
of
sample
code
and
the
the
the
url.
I
hope
someone
can
put
the
url
for
these
slides.
You
know
if
you
have
this
url
into
the
into
the
notes
or
something
like
that.
A
A
That's
your
numerator
and
your
denominator
is
every
history
navigation
and
you
can
tell
if
you're
a
history
navigation
by
looking
at
the
performance,
get
entries
by
type
navigation
and
looking
at
the
type
to
see
it
back
forward
so
yeah
this.
This,
I
think,
yeah,
should
give
you
the
correct
numbers
for
for
telling
whether
are
for
giving
aside
their
their
bf
cash
out
rate.
Of
course,
how
you
do
it?
There
are
some
other
ways
you
could
do
it,
but
yeah
it'd
be
fantastic.
If
if
people
could
actually
see
this
with
their
metrics.
A
A
Chrome's
approach
to
implementing
bf
cache
was
to
basically
block
everything
that
we
thought
might
be
even
slightly
problematic
and
and
enable
bf
cache,
knowing
that
we
had
blocked
everything
that
that
might
cause
a
problem,
and
now
we
are
looking
at
our
own
dashboard
and
kind
of
going
through.
Well,
okay,
this
is
the
biggest
blocker.
Let's
try
fix
this.
This
is
the
next
biggest.
This
is
the
next
biggest
right,
but
so
things
example
blockers
are
currently.
A
If
you,
if
your
page,
has
cache
control
no
store
set
on
it,
we
will
not
put
you
into
bf
cache
that
might
change,
but
it's
we
need
to
iron
out
some
things
there.
If
you
hold
a
web
lock,
then
we
we
can't
well,
we
if
we
hold
the
web,
lock
it's
difficult
to
put
you
into
pf
cache.
Currently
we
just
don't.
We
can
improve
that
slightly,
but
basically
a
page.
A
That's
in
bf
cache
should
have
no
influence
on
anything
else
around
it,
and
so,
if
you
have,
if
you
held
a
web
lock
and
someone
else
tried
to
take
that
web
block,
we
would
definitely
have
to
let
them
take
it
and
kick
you
out
of
bf
cache
a
bunch
of
other
apis.
Like
that
speech,
synthesis
api
notifications,
api
they're
not
required
to
be
blocked
by
spec,
but
they're.
A
Just
it's
just
the
fact
is
that
that
chrome
blocks
them
and
I
think
and
where
we
will
get
around
them
eventually,
but
currently
they're
blockers
and
pages
can
see
that
and
they
can
actually
like
release
what
they've
acquired
in
their
page
hide
handler
and
they
can
fix
it
so
yeah.
We
we
want
people
to
be
able
to
see,
what's
stopping
them
from
going
into
bf
cache
and
there's
a
github
issue
and
an
explainer
and
again
I
really
should
have
well.
I
guess
I
can.
A
So
you
know
there
was
an
a.com
frame
with
two
more
a.com
frames
and
the
the
second
subframe
was
using
a
broadcast
channel
and
that's
the
reason.
The
whole
thing
got
blocked
for
for
bf
cache
right.
So
what
we'd
look
we'd
like
feedback
on
the
shape
of
this
api
and
in
particular,
how
to
expose
the
data?
A
So
there's
a
couple
of
ideas:
we
could
attach
it
to
the
page
show
event
we
could
put
it
into
the
performance
navigation
timing,
api,
which
maybe
makes
sense,
because
that's
where
you
can
find
out
whether
things
were
a
history,
navigation
and
then
there's
this
other
option
here
of
putting
in
the
reporting
api.
Now
the
reporting
api,
I
think,
hasn't
been
standardized
and
I'm
not
sure
who
who
implements
it.
But
it
has
this
nice
property
that
it's
you
just
set
it
up
declaratively
and
you
get
the
information
in
a
side
channel.
A
You
don't
have
to
embed
script
in
your
your
page,
so
yeah
we
would
love
feedback.
Please
come
along
and
give
feedback
on
the
github
issue.
There's
already
some
discussion
going
on
there.
You
know
which
of
those
apis
you
would
or
would
not
use
or
could
not
use
for
some
reason
or
if
there
are
other
other
options
that
you
think
are
better
yeah.
So
that
is
the
reporting
api
for
exposing
the
reasons
and
yeah.
A
A
A
Basically,
you
know
we
have
a
far
greater
number
of
users
and-
and
we
know
we
will
get
a
lot
of
pushback
if
we
were
to
just
you
know
unilaterally,
stop
doing
this,
but
it
is
our
largest
blocking
reason
for
pages
not
going
into
bf
cache,
and
so
it's
a
big
concern
for
us
and
in
many
or
most
cases
I
would
say
you
can
change
your
unload
usage
to
page
hide
usage.
Page
hide
has
the
same
timing.
A
So
if
unload
was
actually
going
to
fire,
then
page
hide
would
have
fired
right
before
it.
Every
time
on,
load
fires,
page
hide,
fires,
it's
more
reliable
because
unload
will
not
fire
as
you're
entering
bf
cache,
but
page
hide
will,
and
you
can
tell
the
difference
between
a
page
hide
when
you're
entering
bf
cache
and
a
page
hide
when
you're,
when
you're
being
discarded
completely.
A
There
are
some
other
things
like
sometimes
visibility,
change
event
is
actually
the
suitable
replacement
for
what
you
are
doing
on
unload
and
whatever
you
know,
there's
there
there
can
be
other
things
that
that
might
be
better
than
unload,
but
most
of
the
time
I
think
it's
page
height,
we'd
love
to
know.
If
you
have
unload
usages
that
you
cannot
stop
using.
A
Please
contact
us,
like
I
said:
chrome,
bf,
cache,
dev
at
chromium.org
and
then
a
final
thing
is
that
it's
somewhat
orthogonal,
but
it's
it's,
maybe
makes
it
easier
for
people
to
move
away
from
unload.
Is
this
proposal
for
a
kind
of
beacon
api
that
that
you
can
set
up
and
when
the
page
is
discarded,
no
matter
how
it
gets
discarded,
whether
it
goes
through
bf
cache
and
then
gets
discarded
or
whether
it
gets
discarded
directly
would
deliver
some
bit
of
information
back
to
some
server
right?
A
This
I
say
it's
orthogonal,
because
I
think
almost
every
usage
of
unload
can
be
replaced
by
a
page
height,
but
page
heights
is
and
is
more
reliable
than
unload,
but
it's
still
not
100
reliable.
It's
still
it's!
You
can't
tell
there's
no
such
thing
as
the
last
page
page
hide
if,
like
if
you've
gone
into
bf
cache,
you
might
never
come
out
again.
A
You
might
be
discarded
while
you're
in
there,
so
it's
very
hard
to
kind
of
send
a
final,
a
final
message
from
the
page
and
so
there's
a
there's
a
proposal.
It's
not,
I
don't
think,
there's
any
public
documentation
on
this
to
have
an
api
where
you
could
just
set
up
a
piece
of
data
that
would
be
delivered
when
your
page
is
discarded.
I
think
maybe
ian
mcclellan
is
going
to
talk
about
that
or
can
talk
about
that
a
bit
more
if
people
are
interested.