►
From YouTube: WebPerfWG call 2022 03 31 - Unload beacon
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
All
right,
okay,
so
I'm
fergal,
I
work
in
tokyo
with
user
as
well,
and
I
work
on
bf
cache,
and
this
is
not
exactly
bf
cache
related,
but
actually
unload
is,
is
a
big
enemy
of
bf
cache,
and
so,
if
we
can
provide
apis
that
allow
people
to
stop
using
unload,
we
can
increase
our
bf
cache
rate.
So
we
have
this
proposal,
okay.
So
what
problem
are
we
trying
to
solve?
And
actually
ian
has
presented
this
here
before?
A
But
now
we
have
a
much
more
concrete
api
and
a
much
more
concrete
proposal
that
we're
close
to
starting
to
implement
as
well.
So
the
problem
is
the
problem
of
beacons
that
people
want
to
send
reliably
when
the
page
at
the
end
of
the
page.
A
Basically
so
a
beacon
is
something
that
sends,
but
doesn't
care
about
response
pages
want
to
send
something
at
the
end,
so,
for
example,
cls
or
other
full
page
performance,
metrics,
ad
impressions
or
anything
else,
any
other
data
that
maybe
it's
better
to
accumulate
over
the
lifetime
of
the
page
and
send
it
at
the
end
rather
than
trying
to
send
it
continuously.
All
the
way
through
problem
is
that
there
is
no
right
time,
unload
and
isn't
always
fired.
Page
hide
is
fired,
but
you
might
come
back
again
out
of
bf
cache
visibility.
A
Change
is
again
another
point
where
you
might
try
it,
but
again
it
has
the
same
problems
as
page
hide
and
also
then
existing
transports
have
reliability
issues
as
well,
so
the
existing
navigator
send
beacon
and
some
other
things
are
not
not
always
working
so
well,
not
always
not
guaranteeing
to
to
deliver
something.
A
If
you
really
care-
and
you
you,
if
you
really
care
about
your
data
and
you
don't
really
care
about
the
user
or
their
battery
life
or
data
consumption
or
whatever,
and
you
can
beacon
continuously
right
so
and
just
sort
it
all
out
on
the
back
end
right,
but
that's
bad
for
everyone,
but
I
mean
you
can
think
of
that
as
a
as
a
mental
model
for
what's
what's
the
what
someone
could
do
already
right
if
they,
if
they
wanted
to,
if
you're
trying
to
figure
out
if
we're
adding
new
features
or
new
risks
to
the
platform
and
bear
in
mind
that
this
is
like
this
is
what
someone
could
do
right
now
is
just
continuously
send
data
back.
A
So
the
proposal
is
that
you
know
we
let
pages
set
data
for
a
beacon
and
that
the
browser
ensures
that
it
gets
sent.
A
That's
it
sounds
really
simple
so
like,
but
that's
that's
kind
of
about
the
size
of
it
and
that
the
b
and
and
the
timing
is
pretty
much
after
the
page
is
gone
and
there's
an
explainer
here
and
there's
a
discourse
for
for
leaving
comments.
So
I'll
talk
a
little
bit
about
here's
an
example
using
the
api
that
we've
described.
So
you
create
a
beacon,
you
attach
data
to
it,
and
that's
it
right
you
in
this
example.
It's
the
simplest
possible
example
and
the
script
loses.
A
A
If
the
page
goes
into
bf
cache
and
then
just
times
out,
it
will
still
send
it
right
and
probably
I
guess
it's
kind
of
implementation
dependent
or
not.
But
if
the
page
we
plan
to
make
it
still
send
the
data
even
after
a
crash.
A
So
here's
another
example
where
you
create
a
beacon.
You
set
some
data
on
it,
you
keep
it
around.
You
set
some
data
again
later
on.
Maybe
your
data
has
changed,
you're
accumulating
cls
stuff
or
something
like
that,
and
so
you're
always
keeping
your
beacon
up
to
date,
and
if
you
did
nothing
else
now,
when
your
page
goes
away,
you
would
send
your
latest
data
or
you
can
stop
it
and
you
can
decide.
Oh,
I
don't
want
to
send
that
at
all,
but
you
can
you
can
deactivate
the
beacon.
A
So
this
is
the
full
api.
Some
attributes
here,
url
method
like
get
get
or
post
state,
tells
you
whether
the
beacon
has
been
sent
or
is
sending
or
has
failed.
The
reason
why
we
have
a
state
is
because
we've
also
added
this
page
hide
timeout,
page
height
timeout
says.
Actually
I
want
you
to
send
this
beacon
at
the
end
of
the
page
when
the
page
is
gone,
or
this
many
seconds
after
page
hide
right.
A
A
Your
data
send
now
says:
yep
send
this
now,
just
don't
don't
wait
till
later,
beacon
is
only
ever
sent
once
so
you
send
now
that
it
means
it
won't,
be
it
won't
be
sent
again
later
on,
and
that
would
that
would
change
the
state
and
also,
if
you
use
the
page,
hide
timeout
and
you
go
into
bf
cache
and
you
send
it
while
you're
in
bf
cache
and
you
come
back
out
again,
the
state
will
be
sent
will
be
set
to
sent
or
failed
or
whatever
happened,
and
then
there's
deactivate
to
stop
a
beacon.
A
So
some
implementation
details
as
well
like
extensions,
should
be
able
to
block
these
just
as
they
come
with
any
other
network
requests.
When
exactly
that
will
happen
like
how
we're
going
to
do.
That
is
a
bit
tricky,
because
if
the
page
is
in
bf
cache
or
unloaded
completely,
then
the
extensions
right
now
might
have
a
kind
of
a
be
surprised
to
see
that
they
have
a
network
request
that
they
have
to
think
about
related
to
that
page.
So
we
may
have
to
do
something
else
there.
A
It's
not
clear
exactly
what
we'll
do
and
yeah
when,
when
an
extension
blocks
the
beacon,
how
does
the
page
should
the
page
know
and,
and
how
does
it
know
as
another
question
and
then
surviving
crashes
and
restarts?
There's
an
interesting,
so
surviving
crashes?
A
A
Well,
it
could,
I
guess,
but
it
seems
unlikely
we
would
just
send
a
load
of
beacons
there,
so
we
would
send
them
when
you
restart-
and
this
is
actually
one-
I
think,
the
one
new
capability
that
this
adds
our
new
kind
of
risk,
that
this
adds,
which
is
that
if
we
decide
to
survive
across
restarts,
then
you
might
end
up
sending
the
beacon
from
a
different
network
than
the
network
you
were
on
when
when
the
beacon
was
set
and
when
the
page
was
loaded
and
all
of
the
stuff,
this
is
actually
a
problem
or
a
an
issue
with
the
reporting
api
currently
as
well
in
chrome
or
any
browser
that
has
implemented
reporting
api
survival
over
restarts,
I'm
not
sure
which
other
browsers
they
finally
have.
A
So
that's
the
only
yeah.
That's
the
only
new
cable,
not
new
capability,
but
the
only
thing
that
is
is
different
or
from
from
a
page.
That
was
just
somehow
just
like
beaconing
all
the
time,
for
example,
and
so
I
think
oh
yeah,
I
had
a
couple
of
questions
as
well,
so
I'm
not
I'm
not
the
person
working
on
this
project.