►
From YouTube: WebPerfWG call 2021 03 04
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
Okay,
so
welcome
to
the
web
performance
working
group.
This
call
will
be
recorded
and
posted
online
as
always
on
the
agenda
just
first
of
all
for
administrative,
like
on
the
administrative
side
of
things.
Our
next
call
is
two
weeks
from
now
march
18th
same
time.
If
this
is
a
problem,
please
reach
out
to
one
of
the
chairs
and
we'll
try
to
figure
out
a
solution.
Otherwise
I
think
we
can
get
started
today.
A
What
I
had
in
mind,
what
we
had
in
mind
is
to
essentially
go
through
a
bunch
of
issues
for
the
first
half
of
the
call
and
then
talk
a
bit
about
event,
timing
and
scroll
timing
over
the
second
half
of
the
call-
and
I
think
we
can
get
started
with
an
update
on
resource
timing
and
fetch
integration
that
is
long
overdue
so
norm.
Do
you
wanna.
B
Yes,
sure,
and
so
up
until
now,
resource
timing
itself
in
the
spec
itself
specifies
at
which
point,
during
during
network
request
response
and
the
different
measurements
should
take
place,
and
so
this
kind
of
creates
a
parallel
algorithm
to
what
already
exists
in
fetch.
B
So
research
timing
describes
in
pros
something
that
is
formally
defined
elsewhere.
B
What
we're
trying
to
do
now
we're
not
trying.
What
we
are
doing
now
is
define
inside
fetch
the
different
points
where,
when
the
metric
should
should
be
taken
and
which
raises
a
few
interesting
places
where
the
definition
might
be
vague
or
might
be
very
open
to
implementation,
and
so
we're
trying
to
make
all
that
a
lot
more
precise
part
of
it
will
still
be
a
little
vague
because
they're
not
even.
B
Rather
in
http,
tls,
dns
and
all
those
and
but
for
now,
what
we
can
we
are
defining
inside
fetch.
Instead
of
a
resource
timing,
where
fetch
will
gather
all
the
different
metrics
and
pass
them
to
resource
timing
for
a
to
normalize
and
to
a
course
and
to
do
all
the
stuff
before
it's
exposed
to
the
web
developers
and.
A
Yeah
yeah,
so
I
think
the
interesting
bit
is
that
a
lot
of
the
processing
model
and
the
somewhat
conflicting,
conflicting
getting
like
on
getting
algorithms
will
essentially
move
to
fetch
because,
like
we
will
create
a
structure
in
fetch
that
contains
all
that
information
and
then
report
that,
in
the
resource,
timing
spec,
but
essentially
fetch-
will
call
into
the
resource
timing
spec
to
queue
up
those
entries
or
report
that
information
that
will
then
queue
up
entries
and
it's
a
design.
That's
much
more
so
like
it
really
resembles.
A
How
implementations
currently
do
that,
at
least
for
chromium
and
webkit.
I
I'm
less
familiar
with
how
firefox
is
implementing,
but
I'm
somewhat
assuming
that
it's
similar.
So
I
I
think
it's
a
good.
A
It's
a
good
way
to
make
the
spec
closer
to
what
implementations
do
and
yeah
make
it
more
precise
and
in
the
process
there
is
a
bunch
of
scrutiny
related
to
the
like.
What
are
the
entries
exposing
and
that
is
not
always
super
well
defined
and
hopefully,
we'll
find
ourselves
at
the
end
of
this
refactoring
with
you
know
all
the
entries
being
well
defined
as
to
what
they
expose
and
what
are
their
semantics.
C
I
have
two
questions.
One
is
so
navigation
timing
is
built
on
top
of
a
lot
of
resource
timing.
Things
is,
are
we
gonna
be
tackling
any
of
the
navigation
timing
stuff
as
part
of
this,
or
is
that,
like
phase
two.
B
We'll
have
the
infrastructure,
because
I
probably
do
copying
and
pasting
of
how
I
did
how
we
register
we
both
keep
inside
fetch
and
then
report
it
to
another
api,
so
it
would
probably
be
similar
like,
instead
of
counting
how
long
it
took
to
redirect.
I
would
count
how
many.
B
C
Good
and
then
the
second
question
is,
is
the
goal
to
try
to
maintain
compatibility
with
how
we
report
timings
today
or
are
there
any
obvious
things
that
we're
going
to
need
to
change
as
a
result
of
being
more
integrated
with
spec
like?
Is
there
going
to
be
a
you
know,
browsers
that
are
closer
to
the
new
version
with
based
on
fetch?
Are
they
gonna
be
reporting
slightly
different
numbers
than
other
browsers?
B
B
A
Yeah,
I
I
think
the
goal
is
to
reach
like
definitely,
we
cannot
break
content
but
all
like
in
terms
of
timings.
There
are
a
lot
of
things
that
were
a
may,
or
you
know,
implementation
like
open
to
interpretation
that
we
would
love
to
climb
down
if
possible,
so
yeah.
C
Yeah
and
today
there
are
many
cases
where
different
uis
diverge,
based
on
exactly
what
they're
reporting
in
subtle
ways
right
and
I'm
sure
that
will
always
be
the
case
I'm
just
like.
If
we
do,
if
there's
anything
that
like
we
need
to
redefine
what
tcp
start
means
for
whatever
reason
it's.
I
just
want
us
to
be
very
transparent
about
that,
especially
for
anybody.
That's
looking
at
the
spec
for
what
an
older
browser
might
be
implementing
versus
a
new
browser
just
for
future
analytics
providers
to
understand
if
those
are
the
cases.
C
I
just
want
us
to
be
like
open
about
that.
Yeah.
B
Specifically
like,
if
we
get
to
the
you,
know,
practicality,
the
issues
that
were
raised,
a
lot
of
them
have
to
do
with
what's
exposed
with
a
timing,
allow
origin
versus
not
exposed,
and
the
other
things
were
really
about
things
that
had
issues
about
them
before,
like
workers
start
that
the
definition
wasn't
clear
and.
C
B
A
Oh
okay,
so
basically
all
the
things
that
are
somewhat
like,
contentious
or
vlogging
like
are
on
the
yeah
on
the
agenda
to
to
discuss
here.
One
is
worker
start
and
then
the
like
next
hop
protocol.
It
seems
like
it
would
be
better
to
tell
protect
it
generally,
and
we
probably
need
to
do
that
so.
But
we'll
talk
about
that
in
a
bit
other
resource
timing,
questions
or
can
we
move
on
to
worker
start.
A
Cool:
okay,
thanks
thanks,
noam
yeah
and
yeah
nick.
Do
you
wanna
talk
about
work
or
start?
I
will
take
over
subscribing.
C
Thanks
yeah
so
kind
of
a
follow-up
to
what
noma's
talking
about,
and
I
think
fetch
integration
will
probably
actually
help
with
some
of
the
things
that
I'm
going
to
talk
about
as
well.
Let
me
try
to
share,
and
let
me
know
once
you
see
when
somebody
sees
my
slide
deck,
we
can
see
it.
Okay,
cool,
thank
you,
okay,
so
I'm
gonna
talk
about
worker
start
in
both
the
navigation
timing
and
resource
timing
specs.
Although
what
I'm
trying
to
first
change
is
the
navigation
timing,
spec
and
maybe
that's
backwards.
C
Maybe
I
should
be
tackling
this
from
the
resource
timing,
point
of
view
so
gnome
and
I
can
coordinate
a
little
bit
better.
The
so
worker
start
is
some
nebulous
term
meant
to
capture
when
a
service
worker
started
up
for
the
current
navigation
for
a
navigation
timings
point
of
view.
At
least
it
one
of
the
original
goals
of
worker
start
was
to
help
measure
worker
start-up
cost,
in
other
words,
like
the
serial
cost,
the
synchronous
cost
of
how
long
a
service
worker
took
to
start
up
because
it's
kind
of
in
the
critical
path.
C
I
believe
the
attributes
exist
in
both
safari
and
firefox,
though
I've
never
seen
them
be
anything
but
zero.
So
I'm
not
sure
if,
if
that's,
if
I'm
just
testing
wrong
or
if
those
time
stamps
don't
seem
to
be
populated
at
the
moment,
I
don't
know
if
either
of
those
representatives
have
any
knowledge
about
that.
But
today
the
only
place
that
I
could
find
a
filled
in
timestamp
for
worker
start
was
in
chrome,
notably
in
chrome.
Worker
start
is
always
as
far
as
I
can
tell
less
than
or
equal
to
fetch
start.
C
So,
if
you
look
at
our
current,
I
guess
this
is
the
resource
timing
diagram,
but
I
meant
to
share
the
navigation
timing
diagram.
The
worker
start
kind
of
happens
ahead
of
redirects
in
it.
According
to
some,
definitions
of
worker
starts
in
some
of
our
specs.
C
So
part
of
the
reason
why
and
being
so
nebulous
about
what
I'm
talking
about
is
that
it's
actually
kind
of
confusing
what
worker
start
means
or
what
we're
intending
to
do
with
it,
and
I
think,
there's
actually
quite
a
few
different
things
that
we
can
improve
with
the
definition
of
workers
start
in
both
navigation
timing
and
resource
timing
specs.
C
The
very
first
thing
is
just
that
worker
start,
as
I
showed
you
on
the
last
slide
in
the
visual
diagram
that
we
have
it's
missing
missing
from
the
diagram,
so
that
should
be.
You
know
there
is
an
open
issue
to
request
to
ask
worker
start
to
the
diagram.
C
Once
I
was
started
looking
at,
because
I
was
trying
to
figure
out
exactly
where
it
should
fit
right
in
the
diagram
that
was
actually
what
triggered
all
of
this
diving
into
these
issues.
Is
there
was
a
single
open
issue
to
add
it
to
the
diagram
was
like
okay,
so
where
should
it
fit
started?
C
Reading
through
the
processing
model
and
there's,
I
found
a
bunch
of
edge
cases
where
the
actual,
if
you
implemented
it
exactly
like
the
processing
model
in
navigation
timing,
it
would
either
be
not
what
we
want
or
incorrect
or
just
kind
of
funky
to
work
with.
C
C
C
If
there's
any
cross
origin
redirects,
then
the
currently
the
worker
start
time
is
that
of
the
cross
origin
and
not
your
final
origin
according
to
the
processing
model,
and
that's
definitely
information
leakage
that
we
want
to
avoid
and,
for
example,
the
same
origin
track
to
determine
what
same
origin
means
does
not
work.
If
there
are
no
redirects
like
there's
just
it
behaves
in
the
opposite
way
that
you
want,
so
those
things
can
be
fixed
right.
We
can.
C
We
can
work
through
the
document
to
fix
those
in
discussion
discussing
this
a
little
bit
further,
both
in
the
nav
timing
and
research
timing,
repo,
there's
some
questions
about
when
workers
start
should
be
in
the
diagram
should
it
be
before
fetch
start,
or
should
it
be
after
I'm,
going
to
jump
ahead
just
a
moment
to
the
current
diagram
that
I'm
proposing
fetch
start
again.
You
know,
after
all,
your
redirects,
it's
the
fetch
of
the
last
document,
and
it's
right
before
the
app
cache
the
worker
start.
C
We
are
suggesting
happens
before
then
right,
it's
the
it's
before
any
redirects.
It's
the
when
the
worker
had
the
startup
like
the
amount
of
time
or
the
timestamp,
when
a
worker
literally
had
a
startup,
but
according
to
our
definitions
of
the
attribute
in
resource
timing
and
the
the
definition
in
nav
timing,
but
not
the
processing
model,
it's
actually
the
opposite.
So
in
some
cases
we
are
defining
worker
start
kind
of
in
terms
of
it
having
to
be
after
fetch
start
there's
a
big
discussion
in
the
resource
timing.
C
And
then
it
kind
of
goes
back
to
the
point
of
it
actually
just
makes
the
original
goal,
which
is
how
do
I
measure
how
long
it
took
for
the
synchronous
service
worker
startup
time
to
happen?
You
know.
Originally,
we
had
to
find
it.
I
guess
in
her
original
pull,
requests
and
emails,
describing
it
as
fetch
start.
Minus
worker
start
would
be
your
startup
time,
assuming
that
fetch
start
happens
after
work
or
start.
I
know
that
this
is
how
we
implement
an
impulse.
C
I
don't
know
if
any
other
analytics
providers
are
actually
exposing
service
worker
time
today.
So
if
there
are
examples
out
there,
I'd
love
to
know
if
other
people
are
defining
it
in
any
different
way
at
all,
but
it
you
can't
actually
use
it
that
way
if
there
are
any
redirects
at
all,
because
the
redirects
happen
after
the
start
of
worker
start
and
before
fetch
start.
C
So
if
you
did
this
calculation
and
you
had
to
redirect-
you
would
also
be
including
redirect
time
we
don't
ever
talk
about
service
worker
scopes,
because
you
could
actually
have
a
service
worker,
two
multiple
service
workers
in
your
synchronous,
critical
line
of
measurement
for
different
scopes,
assuming
you're
redirecting
back
and
forth
between
different.
C
You
know
sub
paths
on
your
domain,
so
there
was
there's
been
a
proposal
to
actually
change
this
a
little
bit
to
make
it
easier
to
have
some
sort
of
worker
ready
time
stamp
or
some
besides,
just
having
the
start
time
stamp,
have
the
end
time
stamp
as
well,
so
that
you
could
definitively
say
the
service
worker
started
up
now
and
ended
now,
and
maybe
that's
a
thing
that
we
can
work
on
later.
C
It
also
gets
a
little
confusing
if
you
have
multiple
scopes,
because
maybe
you
actually
have
multiple
service
workers
starting
up.
So
maybe
we
want
to
do
something
even
different
more
different
than
that,
I'm
not
sure
again
in
the
anti-spec
we
like
we
are
we're
not
using
the
same
words
or
processing
model
or
links
as
a
resource
timing
spec,
especially
as
as
it
relates
to
integration
with
fetch.
C
So
I'm
really
glad
that
noam's
working
on
this
and
again
maybe
we
should
work
on
this
from
the
point
of
view
of
rt
first
and
then
backboard
it
to
nav
timing
and
then
it'll
all
be
magical
and
then
finally,
we
don't
have
any.
We
have
very
little
web
platform
test
coverage
about
this,
so
there's
only
a
few
tests
in
nav
timing
checking
for
its
existence,
never
not
on
any
of
its
functionality
or
value,
and
there's
only
a
single
test
in
resource
timing
that
looks
at
it.
C
So
I
think
we
definitely
want
to
lock
in
whatever.
However,
we
work
on
this
after
we
make
some
changes,
that's
kind
of
like
the
scope
of
the
world
today,
if
you
tried
to
implement
worker
start
if
mozilla
or
safari
wanted
to,
I
think
they
would
be
upset
with
where
the
state
of
the
processing
model
and
such
are
so
we
do.
C
I
do
have
a
pull
request
in
the
navigation
timing
revo
to
address
some
of
these
issues
like
here's,
the
new
diagram
I
hacked
out
of
svg
to
kind
of
place,
worker
start
in
the
diagram
and
then
some
of
the
cases
of
the
of
what
I
was
just
talking
about
are
addressed
as
well
so
edge
cases
in
the
processing
model.
I
think
we
have
all
these
figured
out
we're
more
consistent
with
that
work.
That
worker
starts
to
happen
before
fetch
start
and
it
works
in
cases
of
redirects
and
stuff.
C
But
there's
still
a
lot
of
things
here,
like
everything
on
the
most
of
the
stuff
on
the
right-hand
side
is
not
yet
addressed,
and
I
didn't
want
to
tackle
more
in
the
sport
request,
but
I
think
it
actually
makes
sense
to
either
pause
this
pull
request
or
get
it
in
and
then
work
through
the
changes
that
no
one's
working
on
to
to
fix
the
rest.
C
So
that's
kind
of
where
we
are.
You
know
like.
In
addition
to
that
pull
request,
I
think
we
need
to
do
all
these
things.
We
need
to
sync
better
with
the
resource
timing,
spec
and
its
integration
with
fetch
improve
the
web
platform
tests.
C
We
need
to
figure
out
if
multiple
same
origin,
service
workers
in
different
scopes
should
matter
here
and
if
we
want
to
expose
all
of
them
or
the
some
of
their
time
or
do
something
else
crazy
and
that's
kind
of
related
to
worker
ready
time.
So
anyway,
I
just
kind
of
wanted
to
bring
everyone
up
to
speed
where
what
it's
at
and
maybe
decide
if
we
do
want
to
continue
with
this
pull
request,
as
is
and
get
it
in
with
the
minor
fixes
that
it
has
and
then
wait
for
all
the
other
outstanding
challenges
for
fetch.
B
The
redirects
seems
like
the
problem
here
is
that
you
know
everything
in
resource
timing
is
has
as
a
one-to-one
relationship
with
the
request,
like
there's
only
one
point
in
time,
where
redirects
start
only
one
point
in
time
where
the
response
ends,
but
there
could
be
more
multiple
times
where
a
worker
would
start
like
it
feels
it
feels
a
little
bit
like
like
it
needs
to
be.
Several
workers
starts
the
same
way.
C
C
We
could
just
expose
that
as
a
duration
right
we,
you
know,
we
could
say
that
you
know
multiple
service
workers
exist,
maybe
here's
their
total
time.
You
know
we
kind
of
work
around
that
in
resource
timing.
If
there
are
multiple
redirects
by
by
redirect
start
being
the
start
of
the
first
redirect
and
redirect
n
being
the
end
of
the
last
redirect,
so
they
all
kind
of
collapse
into
that
nebulous
area.
C
But
I
think
I
think
service
worker,
like
you,
could
have
a
service
worker
start
and
end
at
multiple
different
points
in
time.
You
know
and
many
many
redirects
in
between
as
well
right,
so
yeah,
so
maybe
maybe
it
makes
more
sense
not
to
have
a
work
to
start
work
and
work
already,
but
have
like
a
workers.
Startup
total
time
thing.
B
D
Hey
nick,
this
is
so
great
that
there's
some
effort
being
put
into
this.
I
really
appreciate
it.
I
just
wanna
for
the
record
that
mozilla
looks
at
this
we're
just
looking
at
the
service
workers
for
fetch,
so
we.
C
D
After
fetch
start-
and
we
have
this
thing
called
fetch
event-
synthesized
response
end
at
the
beginning
of
app
cache.
So
I'm
just
I'm
just
wondering
if
you
like
the
bracketing
approach,
that
that
is
kind
of
what
we're
interested
in
and
the
thing
is
it's
like
they're
going
to
be
different
things,
so
I'm
really
I'm
taking
what
gnome
has
to
say
about
pastor's,
multiple,
start
and
end
points
to
heart
and
like
wondering
if
we
need
a
more
fine-grained
approach
here,.
C
Yeah,
yeah
and-
and
you
know
the
the
confusion
today
around,
where
does
work
start
fall
and
it
kind
of
depends
on
your
definition
of
fetch
start.
I
think
in
some
cases
it's
like
the
entry
point
into
the
fetch
spec,
in
which
case
worker
start
would
be
after
fetch
start
in
other
in
the
like
another
in
the
resource
timing.
Dis
issue
around
this
fetch
start
is
more
of
you
know
the
time
when
not
not
the
entry
into
the
fetch
spec,
but
the
time
when
the
browser
intends
to
go.
C
I
don't
know
like
I'm
not
going
to
define
it.
It
works.
I
don't
know
if
that's
back
well
enough,
but
like
at
a
later
point.
So
if
we
actually
remove
our
dependency
on
work
or
start
being
a
time
stamp,
we
can
actually
just
report
total
time
or
something.
Then
it
actually
kind
of
gets
around
some
of
those
issues
as
well.
C
B
B
No,
I
it
makes
sense
to
me
that
that
when
there
are
things
that
are
not
one-to-one
in
the
in
the
performance
apis
that
there
are
new
entries
for
them,
like
you,
you
had
three
workers
have
a
start
and
end
time
for
each
one
of
them.
B
Call
it
a
type
worker
instead
of
type
resource,
don't
even
need
a
new.
Can
it
can
be
inside
the
resource
timing,
but
like
it's
it's
point
in
time,
just
report
them
like,
as
you
report
other
points
in
time
like
trying
to
aggregate
them
into
into
an
existing
one,
feels
a
little
bit
like
we're
trying
to
avoid
that.
But
should
we
like?
Is
that
correct.
C
B
Yeah-
and
you
can
even
you
can
even
imagine
doing
this-
not
just
for
service
workers
like
in
the
future.
It's
like
have
a
starting
startup
time
for
a
for
the
dedicated
workers,
like
you
know,
no
need
to
decide
on
that
right
now,
but
like
like,
it
makes
sense
to
me
that
if
fortress
startup's
time
is
something
that's
worth
measuring,
let's
measure
it
and
self
aggregating
it.
C
A
Yeah
and
we've
had
open
issue
about
that
for
years
now
about
like
exposing
same
origin,
redirects
and
yeah,
it
could
be
interesting
to
think
of
both
of
them
as
a
similar
problem.
What
I
thought
of
doing,
because
this
seems
like
an
area
where
the
service
workers
working
group
would
have
a
lot
of
both
knowledge
of
service
worker
processing,
as
well
as
experience
from
working
with
years
with
the
service
worker
consumers
that
are
the
people
that
are
trying
to
collect
that
data.
A
I
thought
it
might
be
interesting
to
have
a
joint
meeting
with
the
service
workers
working
group.
I
haven't
coordinated
that
at
all,
but
it
seems
like
something
that
would
tend
to
be
in
the
like
on
the
earlier
side
of
the
day
for
pst
folks,
because
there
are
a
lot
of
folks
based
out
of
japan
that
are
involved.
A
A
If
you
know
pst
folks
are
interested
in
joining
yeah,
so
please
ping
me
and
I
will
try
to
coordinate
that
call
and
we
can
then
deep
dive
into
whether
aggregation
would
work
or
separate
entries
or
something
else
entirely.
Does
that
make
sense
to
folks.
A
Cool
and
with
that,
I
think,
maybe
we'll
switch
things
around
to
make
sure
we
have
enough
time
for
the
event
timing,
or
maybe
I
can
just
spend
one
minute
talking
about
each
one
of
the
issues
like
there
are
two
issues
on
the
agenda
that
are
like
one
is
that
currently
performance.time
origin
is
not
clamped
and
it's
exposing
the
raw
time.
There
is
no
particular
vulnerability
that
we
found
with
this.
A
At
the
same
time,
there
is
no
particular
use
case
either,
so
it
seemed
healthier
to
just
clamp
it
if
you
find
and
there's
an
open
pr
to
do
that
if
you
have
any
strong
objections
to
that
feel
free
to
chime
in
on
the
issue.
Similarly,
for
the
next
hop
protocol
it
seems
like
it
would
be
better
to
make
it
tell
protected.
There
are
some
potential
issues
with
not
doing
that
and
it
seems
safer
to
do
that
and
there's
no
straight
like
I
don't.
A
I
can't
think
of
a
strong
use
case
that
would
prevent
us
from
doing
that
again.
If
you
have
strong
objections
to
us,
taking
that
course,
please
chime
in
on
the
issue
and
with
that
I
think
we
can
move
over
to
nicholas
and
event
timing
and
squirrel
timing.
E
So
I
I
went
to
talk
about
how
we're
thinking
on
improving
the
current
responsiveness
metric
that,
on
the
chrome
side,
we've
been
really
pushing
on
which
right
now
is
fit.
E
So
first,
let
me
talk
about
a
brief
recap
of
what
fit
is
I
think
most
of
you
are
familiar
with
it
already,
but
basically
there
is
the
delta
between
two
different
timestamps.
One
is
the
event
timestamp
of
basically
when
the
user
input
occurred
and
the
other
timestamp
is
the
time
right
before
event.
E
Handlers
for
that
event
are
about
to
begin
running,
so
it
doesn't
include
the
runtime
of
those
event
handlers
and
we
compute
that
delta
for
the
first
of
one
of
four
options:
key
down
mouse
down,
pointer
down,
which
is
followed
by
printer
up
or
click.
So,
basically,
the
idea
is
to
capture
key
or
taps
or
click
interactions.
E
So
some
places
where
we've
been
successful
with
fit
are,
firstly,
encouraging
people
to
basically
break
up
their
long
tasks,
because
the
idea
of
it
is
to
penalize
websites
where
the
user
interacts.
While
it
is
performing
a
really
long
long
task,
because
that
should
cause
the
site
to
have
a
long
fit,
because
basically
the
task
cannot
stop,
and
so
it
will
have.
The
browser
will
have
to
wait
a
while
before
it
can
begin
to
process
the
input.
E
The
other
success
that
we've
had
is
that
it
has
helped
us
in
both
the
browser
side
as
well
as
some
developers
has
helped
us
surface
more
tab,
delay
issues
right
now
on
mobile
in
some
websites
that
don't
have
mobile
optimized
viewports,
you
can
basically
double
tap
to
zoom,
but
the
problem
is
that
for
those
cases,
if
the
user
taps,
we
have
to
wait
in
case
the
user
double
taps,
and
if
they
don't,
then
that
means
that
the
tab,
the
first
tab,
was
a
click,
and
so
we
have
to
treat
it
as
a
click.
E
If
they
do
tap
again,
that
means
they
just
wanted
to
zoom
in
and
so
with
fit.
We
realized
that
there's
a
lot
of
sites
that
actually
have
this
issue
where
the
user
taps
are
being
delayed
because
of
that
behavior,
and
so
some
of
those
sites
have
fixed
their
viewports
to
not
surface
such
behavior
and
chrome
is
also
planning
to
try
to
make
this
pattern
be
harder
to
occur
accidentally
because,
right
now,
it's
a
little
bit
complicated.
E
How
like,
basically
when,
when
this
happens
versus
when
it
doesn't
so
that's
another
success
that
we've
seen
with
fiddle.
E
That
said,
we
do
want
to
improve
fit
because
we're
well
aware
of
lots
of
its
limitations.
So
today
I
wanted
to
talk
about
three
ways
that
we'd
like
to
improve
feed
three
different
avenues.
Basically,
so
one
is
to
consider
more
than
just
the
first
input,
it's
just
an
obvious
way
of
improving
fit
right
since
right
now,
if
it
just
looks
at
the
first
one,
why
not
look
at
more
than
just
the
first
one?
The
other
thing
is
to
potentially
include
scroll
begins.
E
This
is
why
the
pointer
down
only
counts
if
it
is
followed
by
pointer
up,
and
finally,
we
want
to
evaluate
a
larger
chunk
of
the
end-to-end
latency,
because
right
now
fit
only
captures
a
very
small
portion
of
it
and
so
we're
seeing
that
a
lot
of
sites
that
have
poor
responsiveness
actually
have
high
fit
numbers,
because
it
simply
does
not
capture
the
problems.
So
we
want
to
improve
on
that.
E
So
for
the
first
point,
evaluating
more
than
just
the
first
we're
thinking
of
considering
user
interactions
instead
of
individual
events
by
themselves.
E
So
the
idea
is
that
when
the
user
does
a
keyboard
interaction,
you
can
have,
for
example,
key
down
and
key
up
dumb
events,
and
so
we
would
like
to
look
at
them
as
a
whole.
Basically,
generally,
the
key
down
will
be
the
one
that
captures
the
update
to
the
screen,
but
in
certain
sites
it's
possible
that
the
key
app
will
have
some
effect
on
the
website
as
well,
and
so
we
want
to
look
at
the
total
latency
by
all
of
those
dumb
events
that
are
created
when
the
user
does
a
keyboard
interaction.
E
Similarly,
we
want
to
look
at
tap
or
drag
interactions,
so
in
this
case
we're
going
to
be
looking
at
the
all
the
pointer
events
and
synthetic
events
that
are
dispatched
as
a
result
of
the
user
tapping,
so
pointer
down.
Printer
up
touch
start
touch,
end
mouse
and
mouse
up
click,
so
obviously
not
all
taps
trigger.
All
of
this,
for
instance,
touch
events.
They
did
not
they're
not
triggered
on
desktop
or
on
mouse
clicks.
E
So
these
this
tap
will
basically
contain
a
subset
of
these,
but
we
want
to
look
at
the
basically
for
the
type
interaction.
What
is
the
event
latency
of
this
interaction?
Similarly
for
drag,
we
want
to
look
at
the
basically
drag
start
and
drag
end
parts
of
the
interaction.
E
So
it's
harder
to
reason
about
what
happens
when
the
user
is
moving
the
finger
during
the
drag,
because
well
they
could
take
a
long
time
and
so
on.
So
we
basically
want
to
focus
on
the
initial
and
final
part
of
the
drag
and,
finally,
the
third
interaction,
which
is.
E
My
opinion,
the
more
the
newer
one
to
fit
is
the
scroll,
because
fate,
as
I
mentioned,
does
not
capture
scrolls
at
all.
Right
now
and
scrolls
are
actually
really
common
on
websites,
and
so
we
want
to
make
sure
that
we're
capturing
scrolls
that
said
scrolls
are
not
necessarily
blocked
on
any
event,
so
they're
a
little
more
complicated.
I
don't
know
if
this
is
the
case
on
all
platform
on
all
browsers,
but
on
chrome
you
basically
have
to
have
non-passive
listeners,
so
two
blocks
scrolling
on
events.
E
So
that's
why
I
didn't
set
a
specific
set
of
events
associated
with
it,
because
we
want
to
measure
the
initial
scroll
latency.
So
this
may
not
capture
the
event
listeners
that
are
triggered
by
the
user
gestures
that
caused
the
scroll.
If
that
makes
sense.
E
So,
in
order
to
associate
events
to
interactions
in
the
way
that
I
described
where,
for
example,
the
key
down
and
the
key
up
together
form
a
single
interaction,
we
would
like
to
enable
developers
to
do
this
in
a
way
that
is
relatively
simple
right
now.
It
is
somewhat
possible
with
event
timing,
but
not
quite
like
you
could
maybe
play
with
the
timestamps
and
try
to
figure
it
out
like
in
a
heuristic
way.
But
it's
not
it's
not
really
easy
to
do
so.
E
So
this
is
why
I've
proposed
in
the
past
to
have
something
like
an
interaction
id
where
a
key
down
and
the
key
up
entry
that
share
a
common
interaction
will
have
a
shared
interaction
id
and
similarly,
this
can
be
done
for
the
other
types
of
events
like
pointer
down
with
pointer
up
and
so
on,
and
then,
of
course,
event.
Timing
may
surface
entries
that
do
not
belong
to
any
interaction
in
the
way
we
are
currently
defining
them,
and
I
think
that's
also.
E
Okay,
there
can
be
a
basically
undefined
interaction
id
where
this
event
just
doesn't
sorry.
This
entry
just
doesn't
correspond
to
any
of
the
interactions
we've
defined.
So
that
that
is
my
proposal
for
how
to
solve
this
problem,
but
happy
to
hear
thoughts
or
ideas
about
how
else
we
can
associate
events
to
interactions
in
a
relatively
simple
way.
E
The
other
problem
with
what
I've
mentioned
is
that
right
now,
there's
no
way
to
measure
scroll
performance.
Obviously
you
could
basically
try
to
measure
it
with
event
handlers,
but
that's
going
to
introduce
latency
and,
as
I
mentioned,
the
idea
is
that
scrolling
is
not
locked
on
event
handlers.
So
it's
actually,
if
you,
if
your
site,
does
have
performance
scrolling,
it's
actually
impossible
to
measure
this
accurately
right
now,
so
I
think
we
probably
want
to
enable
developers
to
measure
scroll
performance.
E
E
So,
basically,
in
the
slow
path,
and
when
that
happens,
I
think
they
should
be
made
aware
that
this
is
happening,
and
so,
when
this
happens,
it's
likely
that
their
scroll
delays
are
going
to
increase
by
quite
a
bit,
because
usually
the
compositor
is
much
faster,
and
so
this
means
that
we
need
a
way
to
measure
the
initial
scroll
reaction,
which
we
call
scroll
begin,
which
is
basically
the
latency
between
the
touch
move
that
triggers
the
scroll
or,
in
general,
any
the
event
timestamp
that
triggers
the
scroll
to
the
time
when
the
browser
first
reacts
to
that
scroll.
E
Basically,
the
screen
has
changed
as
a
result
of
that
scroll
gesture
from
the
user,
and
there
may
also
be
some
use
cases
for
subsequent
scroll
reactions.
So,
for
example,
imagine
you
do
a
long
scroll.
There
are
many.
E
Many
frames
that
the
browser
needs
to
produce
as
a
result
of
that
user
gesture,
so
the
subsequent
ones
are
called
scroll
updates,
and
my
initial
reaction
is
that
they
would
probably
be
better
addressed
by
the
frame
timing
api,
because
what
we
care
about
there
is
in
some
way
the
frame
latency
of
how
quickly
is
the
browser
producing
those
scroll
update
frames.
E
So,
with
that
in
mind,
there's
two
ideas
that
came
up
when
I
was
thinking.
How
could
we
expose
this
to
developers?
One
would
be
to
basically
extend
event
timing
with
a
new
entry.
E
That
is
a
little
bit
artificial
in
the
sense
that
it
doesn't
have
an
associated
event,
as
the
other
entries
do
so
for
the
name,
which
is
where
we
generally
put
the
event
type.
We
could
do
something
like
scroll
begin,
which
is
not
the
name
of
any
event.
Currently,
something
like
scroll
could
also
be
used,
but
that
would
be
confusing
because
there
is
a
scroll
event
which
happens
after
scroll
takes
place.
E
That
way,
and
in
addition,
some
of
the
event,
timing,
values
just
don't
make
sense
for
the
scroll
begin,
for
example,
processing,
start
and
processing
end
because
there's
no
event
handlers
well,
unless
your
scroll
is
blocked
on
the
event
handlers,
and
so
it's
debatable
whether
it's
meaningful
or
not.
But
I
I
worry
that
the
this.
If
we
do
it
in
even
timing,
the
the
values
of
the
attributes
will
be
potentially
very
different,
and
so
I'm
not
sure
if
it's
probably
more
confusing
than
just
having
a
different
interface
for
the
scroll
values.
E
E
E
The
green
part
is
where
the
the
js
thread
starts,
reacting
to
the
input
by
basically
running
the
event,
handlers
and
whatnot,
and
then
the
first
yellow
star
is
the
frame
that
is
presented
as
a
result
of
the
event
handlers
running,
but
that's
not
necessarily
the
full
end-to-end
latency,
because
the
event
handlers
may
post
tasks
or
fetches
or
any
other
asynchronous
function
that
you
can
think
of
right.
There's
so
many
right
now.
E
So
those
tasks
are
in
red,
basically
but
they're
in
some
sense
ill
defined.
Because
it's
hard
to
know
exactly
what
should
count
as
part
of
that
end-to-end
latency
like
the
set
timeouts
count,
probably
not,
but
you
could
think
if,
if
a
developer
wanted,
they
could
basically
process
the
event
in
asset
time
out
of
zero
and
then
makes
it
hard
to
reason
about
what
exactly
are
those
red
tasks.
E
E
However,
for
the
present
due
to
the
heuristic
nature
and
how
complex
it
would
be
to
track
the
red
tasks,
we're
thinking
of
just
looking
at
the
yellow
first
star,
so
next
frame
presented
on
screen,
which
is
already
exposed
in
event,
timing
via
the
duration
value,
the
duration
attribute
value,
and
so
I
think
I've
mentioned
what
this
slide
is
about.
E
Basically,
asynchronous
work
is
really
hard
to
track
and
we
don't
want
to
accidentally
say
the
event
takes
longer
than
what
it
actually
takes,
and
so
for
that
reason
right
now
we're
focusing
on
the
next
frame
presented
on
screen.
E
In
the
future,
we
would
like
to
explore
looking
at
what
those
red
tasks
should
be
and
how
they
look
like,
so
that
that
those
are
our
current
thoughts
on
how
we're
working
on
it,
creating
a
new
responsiveness
metric
that
is
better
than
fit
so
I'll
open
it
up
now
for
lots
of
questions,
especially
on
interaction
id
on
scroll
timing.
But
any
any
comment
is
also.
G
Welcome,
I
can
comment,
maybe
on
the
scroll,
so
the
name
idea,
I
think,
is-
makes
sense
because
it
would
fit
nicely
with
existing.
G
G
C
G
Be
happy
to
actually
have
many
more
events,
even
if
they're
not
specific,
dumb
events
on
the
on
the
other
side,
I
think
it
would
be
very
interesting
to
have
more
elaborate
scroll
timing
information.
I
guess
so
it's
hard
for
me
to
judge
I'm
just
highlighting
the
the
advantage
of
the
first
proposal.
A
So,
for
me
the
main
question
there
is:
how
different
do
we
expect
scroll
timing
to
be
from
event
timing,
if
it's
the
exact
same
entry,
just
with
a
different
observer,
then
yes,
we
might
as
well
coalesce
it
give
it
a
separate
name
so
that
people
can
look
for
that
specifically,
but
otherwise
it
makes
sense
for
that
to
be
the
same
entry
where
it
like.
A
Do
you
predict
them
to
diverge
at
some
point,
and
then
we
will
have
like
properties
on
that
entry
that
are
only
specific
to
scroll
or
only
specific
to
events,
and,
if
that's
the
case,
then
it
might
be
worthwhile
to
start
with
separate
entries-
and
I
don't
know
like
I'd,
be
interested
in
your
opinions
on
the
likelihood
for
that.
G
Even
if
they
diverge
would
it
matter,
could
we
keep
the
original
scroll
begin
for
legacy
purposes
or
for
those
who
are
not
interested
in
more
granular
scroll
timing,
information.
A
We
could,
but
we
shouldn't
plan
for,
like
it's,
not
a
very
like
we
should
like
for
nicer
apis.
I
think-
and
this
won't
like,
if
we'll
end
up
having
this
as
a
duplicate
that
wouldn't
be
ideal,
so.
E
Yeah
and
if
we
already
predict
we're,
gonna
have
to
have
a
separate
entry
for
scrolling
later,
it
might
make
sense
to
just
basically
do
it
in
a
separate
entry.
In
the
first
place,
I
think
right
yeah,
and
so
I
guess
the
question
is
what
scroll
update
would
require,
and
my
intuition
is
that
that
one
is
harder
to
reason
about
as
a
single
performance
event
timing
entry,
because,
first
of
all,
we
don't
want
to
expose
all
scroll
updates.
E
So
we
need
some
way
to
aggregate
them,
and
so
it's
not
clear
to
me
how
how
we
want
to
aggregate
them,
but
it's
potentially
the
case
that
they
would
require
different
values
than
what
you
see
already
in
event.
Timing,
like
duration
for
scroll,
update.
It's
not!
I
don't
know
if.
G
You're
useful,
that
is,
I
yeah,
because
the
updates
are
more
about
smoothness
right,
less
about
direct
interaction
or
response
to
the
user
action.
E
G
I
don't
remember
the
frame
timing,
does
it
include
the
some
contribution
to
events
or
I
forgot
the
definition.
F
F
Hey
because
it's
my
understanding
correctly,
that
scroll
begins
basically
just
the
purple
area
in
the
diagram
that
you
have
shown.
E
E
I
would
say,
the
diagram
doesn't
make
as
much
sense
in
the
sense
that
if
it
happens
not
in
the
js
thread,
then
there's
no
blocking
tasks
on
this
thread
and
there's
no
handlers
that
need
to
run
before
that
frame
happens.
So
some
of
that
may
not
even
exist.
If
it
does
happen
in
the
gs
thread,
then
the
diagram
still
makes
sense,
and
then
we
should
still
expose
the
basically
the
next
frame
that
is
produced
as
a
result
of
the
touch
move.
E
Well,
let's
assume
it's
scrolling
on
mobile
right
because
touch
move
means
basically,
scroll
does
not
require
touch
move,
but
if
it's
on
mobile,
the
next
frame
after
the
touch
move
that
triggered
the
scroll
right,
so
the
the
initial
frame
that
started
the
scroll
reaction
does
that
make
sense
or.
F
I
guess
so.
There
are
basically
two
possible
scenarios
for
it
like
once
the
jazz
handler
like
would
be
involved.
Otherwise,
if
there
was
one
I'll
be
involved
right.
E
F
E
Yeah,
and
so
one
way
I
was
thinking
that
could
be
handled-
is
by
basically
exposing
the
processing
start
and
processing
and
for
some
event
that
blocks
the
scrolling.
So
so,
for
example,
the
the
entry
is
scrub
again
right.
So
if
it's
not
blocked
on
handlers,
then
processing
start
and
processing
end
will
be
zero.
E
If
it
is
blocked
on
handlers,
then
you
set
the
processing
start
and
processing
end
accordingly,
and
so
that
way
developers
will
know.
Oh,
my
scrolling
is
being
blocked
in
handlers.
I
should
probably
fix
that
because
well,
unless
you're
intentionally
doing
it,
then
that's
okay,
but
in
general,
that's
a
problem
right.
A
Thanks,
you
have
your
muted
yeah,
I'm
sorry,
we
are
three
minutes
over.
I
don't
know.
I
see
that
so
like
peter.
You
raise
your
hand
and.
H
Breathe
yeah
first
of
all,
nicholas
thanks
for
the
first
presentation
yeah.
I
know
what
three
minutes
over
just
like
a
quick
question.
From
my
side,
I've
been
working
with
real
world
cases.
Now
that,
let's
say
in
may,
we
will
see
all
this.
This
web
vitals
update,
going
live
in
the
in
the
algorithm
and
just
like
a
question
of
mine,
which
probably
I
would
really
like
to
to
present
at
the
next
time
like
in
the
in
the
next
meeting.
That
has
certainly
things
to
do
with
this.
H
With
this
specific,
let's
say,
evaluation
of
the
end-to-end
interaction.
I
had
a
question
nicola.
If
you
can
answer
the
the
specific
point
where
we
say
work
kicked
off
by
event,
handlers.
H
What
I
see
in
some
websites,
people
trying
to
just
let's
say,
skip
some
of
the
let's
say
the
web
vital
texts,
at
least
from
the
the
seo
perspective.
What
they
do
is
that
they
define
the
loading
of
some
third-party
snippets
after
the
user
has
just
scrolled
okay.
So
that
means
that
the
event
handler
the
on-scroll
handler
will
run
some
async
ajax
requests
to
pull.
Let's
say
some
snippets.
E
Right,
if
it's,
if
it's
on
the
scroll
event,
it
would
probably
be-
I
mean
either
red
or
not
not
even
part
of
the
diagram,
depending
on
how
you
look
at
it
so
yeah
that
would
be
async
work.
That's
basically
out
of
scope
right
now,
but
depending
on
how
it's
implemented,
you
could
argue
that
it's
part
of
the
red
part
or
just
not
not
really
or
shouldn't,
be
captured
like
there's.
There's
things
like
a
click
triggers
an
animation,
and
so
those
things
some
amazing
quirk
is
not
really
meant
to
be
captured
by
red.
I
One
other
thing
to
keep
in
mind
is
that,
if
you're
tracking,
all
the
inputs
and
scrolls
like
if
future
inputs
are
scrolled
down
by
the
fact
that
they
kicked
off
some
some
work
on
the
first
scroll,
then
then
that
that'll
be
captured
on
the
next
input.
A
Okay
and
yeah,
and
with
that
I
think
we're
really
over
sorry
for
that.
Yeah
thanks
all
and
I
hope
to
see
y'all
in.
C
A
Couple
weeks,
I
will
send
details
regarding
the
service
worker
meeting
once
I'll
have
any
and
yeah
let
the
folks
interested
know
as
well.
Okay,
thanks
all
and
cheers
bye,
bye.