►
From YouTube: Presentation from WebPerfWG call 2021 05 27
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
So
today,
I'm
going
to
talk
about
the
usual
topic,
these
days,
which
is
web
of
apis
for
responsiveness,
and
I
have
my
teammate
humble
who
has
been
working
with
me
on
the
basically
explorations
we're
doing
so
far.
So
first,
let's
reiterate
the
goal
for
everyone
to
be
on
the
same
page,
about
what
we're
doing
here.
A
A
So
if
a
user
interacts
a
lot
with
the
page,
we
don't
really
look
at
those
further
interactions
and
then
secondly,
it
only
looks
at
the
input
delay,
which
does
not
really
capture
any
work
that
the
website
does
as
a
response
to
the
input,
because
the
delay
only
captures
from
the
input
timestamp
to
when
the
input
is
about
to
start
being
processed
by
the
browser.
A
And
thirdly,
first
import
delay
does
not
measure
scrolling,
which
is
one
of
the,
if
not
the
most
common
user.
Interaction
on
the
web
right
now,
so,
first,
let's
talk
about
what
an
events
duration
is,
and
here
we
just
use
the
term
duration,
because
it's
what
is
used
in
the
performance
event,
timing
interface,
even
though
the
name
is
kinda
generic.
A
A
So
if
you
look
at
that
diagram,
it
would
be
from
the
leftmost
portion
up
to
basically
the
first
yellow
star
on
the
diagram
notice
that
there
is
still
work
ahead
of
that
star,
because
there
could
be
asynchronous
work
that
is
posted
from
event
handlers.
A
There
are
many
ways
to
post
asynchronous
work
right,
for
example,
you
can
just
do
something
like
a
set
timeout
right
and
so
that
work
will
not
be
captured
by
that
initial
yellow
star
and
that's
what
the
diagram
has
in
in
red,
but
capturing
that
asynchronous
work
is
very
difficult
and
so
right
now
we're
focusing
on
just
using
the
events,
duration,
which
is
the
bare
minimum
of
the
amount
of
time
it
takes
for
the
user
to
basically
see
any
response
to
their
interaction
on
the
site.
A
So
now
that
we've
described
more
or
less
what
the
improvement
will
be
over
input
delay.
Let's
talk
about
how
we
can
consider
multiple
events
across
the
page
load,
so
we
so
the
problem
of
just
looking
at
events
is
that
you
can
have
different
number
of
events
for
each
user
interaction
in
the
way
that
you,
like,
normally
think
of
an
interaction
like
tapping
on
something
or
pressing
something
on
the
keyboard.
Things
like
that.
A
So,
for
example,
for
pressing
on
the
keyboard,
you
just
have
key
down
key
press
key
up
most
of
the
cases
you
can
have
some
other
events
depending
on
the
language
you're
using,
but
whereas
clicks
and
tabs
have
a
bunch
of
other
like
have
more
events
associated
with
them
right
like
pointer
down
printer
up
all
the
touch
events,
the
mouse
events,
and
if
it's,
if
it's
a
tap,
then
the
click
event
as
well,
and
so
we
want
to
basically
consider
a
tab
and
a
keyboard
to
be
basically
in
some
sense,
equally
weighted
or
yeah.
A
And
so.
In
addition,
we
want
to
like
try
to
measure
something
that
is
user
perceptible,
which
in
this
case
is
not
the
individual.
Dom
events,
but
instead
is
like
the
actual
interaction
that
they
did
so
for.
For
those
two
reasons,
we
want
to
look
at
the
user
interactions
themselves
which,
as
the
examples
I've
mentioned,
can
be
keyboard
and
it
can
be
a
tab
or
a
mouse
click
or
well
any
click
with
a
device,
and
also
it
can
be
a
drag
right.
A
So
like
moving
from
one
place
to
another.
Now
for
this
interactions,
we
would
like
to
define
something
similar
to
their
duration,
but
they're
not
really
events
right,
so
they
technically
don't
have
a
duration.
So
we
need
to
define
something
about
how
much
they
take.
So
this
is
what
I'm
calling
in
the
slides,
the
latency
so
think
of
it
as
just
the
duration,
but
for
the
user
interaction.
A
So
here
we're
considering
two
options:
one
is
using
the
maximum
duration
of
any
associated
event
and
another
is
to
basically
consider
the
amount
of
time
taken
by
all
the
durations
of
all
of
the
associated
events,
so
basically
kind
of
a
non-overlapping
sum
that
the
events
can
have
overlapping
durations
right.
A
So
those
are
the
two
main
options:
we're
considering
also
open
to
ideas.
So
here
is
an
example,
a
simple
example:
pressing
a
a
key
and
releasing
it.
So
you
have
the
keydown
and
keypress
handlers
which
are
basically
fired
after
the
user
presses
the
key,
and
in
this
example,
the
frame
is
presented
before
the
user
releases,
the
key
and
then
there's
another
task
where
the
key
up
handlers
run
and
the
frame
is
presented
later
for
that
user
key
release.
A
So
basically,
in
this
case
we
have
a
keydown
duration,
which
is
disjoint
from
the
key
up
duration,
even
though
that's
not
necessarily
always
the
case.
It'll
basically
depend
on
timing.
So
in
this
example,
the
the
key
down
duration
is
slightly
longer,
as
you
can
see
in
the
diagram.
So
if,
for
example,
the
duration
is
25
in
in
one
and
15
for
the
other,
then
the
latency
could
be
considered
25
if
we're
using
the
maximum.
A
Of
course,
if
we're
using
the
sun,
then
it'll
just
be
40
right.
So
those
are
the
two
latency
ideas
we
were
considering
now
in
order
to
compute
this
latency
like
as
a
web
developer.
It's
not
really
super
easy
to
do
right
now.
You
can
obviously
use
event
timing
to
gather
durations
of
each
event,
but
there
are
some
problems.
First,
we
have
a
minimum
duration
threshold
which
right
now,
I
think,
is
16
or
something
so
any
event
whose
duration
is
less
than
that
is
not
surfaced
to
the
api.
A
So
you
would
basically
need
to
rely
on
event
counts,
somehow
to
make
sure
that
you
count
those
durations
properly
and
basically
it
becomes
really
hard
to
basically
match
events
that
correspond
to
the
same
user.
Interaction
right
because
you
only
are
receiving
the
dumb
events
you
got.
You
basically
have
to
figure
out
how
to
match
them
and
group
them
into
the
user
interactions
they
correspond
to.
So
you
can
kind
of
try
to
estimate
that
by
using
the
event
timestamps,
but
as
you
can
imagine,
it's
not
really
an
easy
process.
A
So
that's
why
I
have
been
proposing
interaction
id
which
I've
talked
about
before,
which
is
basically
a
new
attribute
to
performance,
even
timing
interface,
where
you
could
have
an
id
that
is
exposed
to
the
entry
itself,
so
that
the
browser
does
the
work
for
the
developer.
In
terms
of
saying
it's
in
terms
of
grouping
entries
that
correspond
to
the
same
user,
interaction
in
the
sense
that
we
defined
previously,
so
those
are
the
two
proposed
changes.
I
guess
one
would
be
no
minimum
duration
threshold
and
the
other
is
the
interaction
id
now.
A
So
in
order
to
enable
developers
to
measure
scrolling,
we
want
to
basically
expose
the
scroll
agency
for
because,
because
right
now,
it's
not
really
something
that
is
easy
to
measure
or
that
the
the
order
that
is
exposed,
the
event
timing,
and
so
first
we
need
to
define
what
about
scrolling
do
we
want
to
expose
so
for
the
purpose
of
this
metric?
A
In
particular,
we
want
to
define
the
latency
as
just
the
initial
scroll
update
latency,
which
means,
from
the
event
timestamp
of
the
first
event
that
made
this
actually
become
a
scroll
right
to
the
first
rendering
update
after
after
that
and
notice.
That
e
scrolling
is
a
bit
different
right
because
there's
not
really
any
dumb
events
associated
with
the
this
latency
in
chrome
and
assume,
probably
most
modern,
browsers.
The
scrolling
can
be
performed
without
having
to
go
to
the
javascript
thread,
and
so
for
that
reason
it's
not
blocked
on
any
dom
event
handlers.
A
A
A
We
expose
the
latency
we
want
and
it's
the
benefit
is
that
it.
It
is
perhaps
nicer
to
augment
in
the
future
right
since
it's
not
tied
to
the
interface
shape
of
every
other
event
type.
The
downside
is
that
it's
yet
another
new
api
right
so
would
welcome
thoughts
on
which
of
those
two
options
are
preferable,
and
that
is
the
end
of
my
slides.
So
I
guess:
should
we
stop
the
recording
here
or
yeah
that
people
can
chime
in
you.