►
From YouTube: WebPerfWG call 2021 11 18 - Interaction Count
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
Yeah,
all
right,
so
I'm
going
to
chat
about
exposing
the
number
of
interactions
to
web
developers.
So
let's
go
over
the
goal.
First,
what
we'd
like
to
do
is
to
enable
computing
input
c,
sorry,
input,
latency,
metrics
and
pages,
and
this
is
useful
for
analytics
providers
where
they
don't
have
full
knowledge
of
what
the
site
is
doing,
so
they
need
to
rely
on
heuristics
that
work
for
most
pages.
A
This
is
also
useful
to
create
metrics
that
can
compare
the
performance
across
multiple
sites
and,
as
I've
talked
several
times
in
the
working
group
before
we
established
that
the
way
to
do
this
requires
grouping
certain
events
together
as
a
single
user
interaction,
since
they
are
caused
by
one
single
user
interaction.
So
we
exposed
interaction
id
for
in-event
timing
to
group
events
that
correspond
to
the
same
interaction.
So
what
is
an
interaction?
It
can
be
a
key
press
and
what
are
events
associated
with
key
press?
They
can
be
key
down
key
up
or
input
event.
A
A
A
A
Now
we
want
to
enable
knowing
those
interactions,
but
we
also
expose
other
kinds
of
events,
so
the
interaction
id
is
zero
when
the
entry
does
not
correspond
to
a
user
interaction
from
the
ones
that
I
just
defined.
A
It's
also
just
much
easier
to
know
how
many
of
them
there
are.
So
the
the
reason
we
don't
know
as
of
today.
How
many
there
are
is
because
the
observer
exposes
entries
after
a
certain
duration,
so
not
all
entries,
and
so
it
it's
possible
that
an
interaction
is
super
fast,
meaning
all
of
the
events
that
compose
it
do
not
make
the
cut,
and
so
the
developer
will
never
receive
any
entry
for
such
interaction.
So
it
would
be
hard
for
them
to
know
that
it
took
place
in
the
first
place.
A
So
having
that
problem
in
mind,
I'm
going
to
talk
about
several
basically
brainstorming
solutions
about
what
are
ways.
We
could
actually
expose
this
information
and
then
my
hope
is
for
people
in
the
call
to
look
at
all
the
solutions
and
be
like
I
like
this
one,
and
this
is
why
so
that's
kind
of
the
idea
of
the
presentation.
So
just
keep
that
in
mind,
while
I
present
them
so
first
solution
is
extending
event
counts,
so
the
idea
would
be.
A
A
Notice
that
event
counts
is
a
map
like
interface.
So
it's
like
a
map
that
you
can
already
call
in
javascript
it's
in
the
spec
and
it's
shipped
in
chrome
already.
So
the
difference
here
is
that
event
counts
is
usually
for
event
types.
So
things
like
give
me
the
number
of
clicks.
So
this
is
click
events,
it's
a
little
bit
different,
semantically
from
what
we
mean
by
user
interaction.
A
So
that's
kind
of
the
downside
of
this
proposal
is
that
it's
cramming
different
semantically
different
things
into
the
same
map,
if
that
makes
sense
so
to
try
to
counter
that
problem.
The
second
solution
is
basically
do
the
same,
but
in
a
different
map
like
interface,
which
will
have
a
separate
name
like
interaction
counts.
A
So
it's
just
like
creating
a
new
map
where
you
can
have
the
interaction
counts,
so
you
can
have,
for
example,
give
me
how
many
keyboard
interactions
there
have
been
on
my
page
and
this
kind
of
goes
around
the
problem
of
having
those
event,
types
and
interaction
types
grouped
together
in
the
same
map
which
is
potentially
confusing.
So
that's
the
second
solution.
A
Another
solution
is:
if
we
think
that
developers
would
not
really
care
about
the
different
types
of
interactions,
meaning
keyboard
or
tap
or
drag,
then
we
could
just
have
a
single
integer
in
the
performance
interface,
which
is
just
give
me.
The
number
of
interaction
counts
in
the
page
that
we
have
seen
so
far.
So
the
benefit
of
this
one
is,
we
don't
have
a
the
horrible
map
structure
that
event
counts
requires,
I
suppose,
that's
more
of
a
downside
for
us
developers,
because
it's
horrible
to
implement,
but
for
web
developers.
It's
almost
the
same
right.
A
So
here
it's
just
a
little
bit
simpler.
It's
just
a
single
number.
How
many
interactions
have
occurred
in
the
page?
The
next
one
is
allow
duration
threshold
to
be
zeroed.
I
have
talked
about
this
one
a
few
times
where
I've
run
into
problems
because
of
the
fact
we
have
a
duration
thresholds
that
is
minimum
16
milliseconds.
What
that
means
in
practice
is
that
entries
that
have
a
duration
below
that
minimum
duration
threshold
can
never
be
surfaced
to
the
performance
observer
right,
and
this
is
kind
of
what
got
us
into
this
problem.
A
A
So
by
doing
this
getting
rid
of
the
threshold,
it
could
potentially
become
a
little
bit
expensive
because
remember
remember
that
every
time
an
entry
is
created,
you
can
potentially
post
a
task
that
the
user
agent
has
to
run
to
let
the
developer
run
the
callback.
So
there
could
potentially
be
many
cases
where
the
developer
is
running
a
callback
where
they
don't
care
about
any
of
the
entries
that
are
in
that
callback
simply
because
they're
not
of
the
type
they
wanted.
A
A
So
that
is
the
fourth
brainstorm
solution
and,
lastly,
another
option
is
to
expose
entries
with
interaction
id.
So,
as
I
mentioned
before,
these
are
only
some
kinds
of
entries
for
the
specific
events
that
we've
defined
as
interactions
those
have
their
interaction
id
set
to
something
that's
non-zero,
so
we
could
just
say
well,
those
entries
are
exempt
from
the
duration
threshold
limits
and
they
are
just
surfaced
by
default.
A
Now
this
has
a
little
bit
of
a
problem
that
it
kind
of
breaks
the
assumption
that
the
duration
threshold
is
a
duration
threshold,
because
then
the
developer
will
be
like.
Oh,
this
is
like
a
super
fast
event.
Why?
Why
am
I
getting
the
entry
for
this
event?
That's
so
that
could
introduce
that
kind
of
confusion.