►
From YouTube: WebPerfWG call 2021 12 02 - Beacon improvements
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
Everybody
there:
oh
there,
we
go
okay,
cool,
so
yeah,
so
this
is.
This
is
just
a
very
sort
of
early
proposal
for
a
new
kind
of
page
unload
beacon,
all
right.
We
we
have
beaconing
already
in
the
platform
with
things
like
navigator.centbeacon
people,
using
unload
handlers
to
trigger
either
that
or
putting
image
pixels
on
the
screen
or
using
you
know,
xhr
synchronous
or
not,
and
all
these
methods
are
rather
unreliable.
A
A
We
have
network
requests
being
de-prioritized
if
they
are
emitted
during
an
unload
handler
and
also
we
want
to
get
rid
of
unload
anyway,
because
it
makes
pages
ineligible
for
the
backboard
cache
and
generally
slows
the
web
down.
A
So
I'd
like
to
propose
a
new
way
of
doing
this
we'd
like
to
build
something
on
the
reporting
api,
so
that
it
will
be
automatically
sent
out
of
banned
by
the
browser.
So
the
right,
the
page,
can
basically
register
data
as
an
end
of
session
beacon
and
have
that
stored
by
the
browser
up
until
the
point
where
it
should
go
out.
A
Oh
end
of
session
itself
is
also
sort
of
a
an
unclear
term,
because
a
number
of
people
will
do
things
on
page
hide
or
they
will
do
things
on
unload
or
they
will
just
find
some
other
sort
of
arbitrary
marker
for
when
the
page
is
done
and
try
to
send
things
out,
then
so
we
would
like
to
say:
okay
at
the
point
where
the
page
is
going
to
be
unloaded
from
the
browser.
A
This
is
now
the
time
to
send
these
beacons
and
have
that
just
be
consistent,
and
obviously
because
this
is
a
register
once
and
then
possibly
forget
about
it
sort
of
method.
A
A
So
using
the
reporting
api
as
a
foundation
for
this
would
generally
mean
that
you
would
set
a
header
defining
an
endpoint
collector.
A
This
is
already
used
for
things
like
csp
for
deprecation
reports
for
various
policy
violations.
Things
like
that,
so
this
would
be
an
additional
use
of
that
endpoint
collection
and
then
we've
got
a
couple
of
different
ways
of
oops
there.
We
go
of
registering
these
beacons,
so
the
first
one
that's
been
tossed
around
is
entirely
market-based,
so
we
basically
meant
a
new
link
tag
in
this
case.
We've
just
called
it
rel
equals
beacon.
A
A
I've
added
a
sort
of
integration
to
this
with
performance
timeline
to
say
also,
please
send
me
any
any
entries
of
these
types
that
are
queued
up,
and
then
we've
heard
that
it
would
be
very
useful
to
be
able
to
compress
this
sort
of
thing,
because
this
could
be
a
lot
of
data
so
providing
the
compression
algorithm
there
and
then
having
this
having
this
link
in
the
head
would
basically
be
enough
to
register
that
beacon.
A
A
A
So
so
that
that's
that's
sort
of
one
of
the
proposals.
The
second
one
is
very
similar
to
what
you
have
presented
to
tpack
this
working
group
last
year,
and
it's
let's
do
all
of
this
in
javascript.
Let's
extend
the
performance
api
and
and
give
it
away
to
cue
beacon
to
register
a
report,
that's
going
to
have
performance
data
and
possibly
any
other
payload
that
we
want.
A
I
cue
that
in
the
browser
and
the
there's
several
advantages
to
doing
this
in
script,
not
everybody
has
access
to
markup
or
wants
to
mess
with
the
markup.
It's
also
more
familiar
to
a
lot
of
people.
A
It
would
also
allow
you,
by
using
the
reporting
api,
to
register
a
reporting
observer.
This
example
here
has
a
has
a
timeout,
so
it
would
say
if
these
are
still
on
this
page
in
five
minutes.
Please
just
send
this
report
anyway
and
then
the
reporting
observer
would
be
able
to
actually
see
that
if
that
goes
out,
obviously
it
happens
at
the
end
of
the
session.
Then
there's
no
reporting
observer
left
to
see
it,
but
and
then
being
a
script-based
api.
A
A
But
we
do
think
that
having
something
that
is
going
to
be
much
more
reliable
than
existing
methods
is
worth
doing
so.
Yeah
we'd,
like
feedback
on
that,
okay,
yeah,
stopping
the
recording
and
then.