►
From YouTube: WebPerfWG call - August 27 2020
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
as
always,
this
call
is
recorded
and
will
be
posted
online
and,
let's
starting
with
the
administrative
stuff,
so
the
next
call
is
scheduled
for
september
10th
like
same
same
day
same
time,
two
weeks
from
now.
If
there's
a
problem
there,
please
let
me
know
and
yeah
we'll
figure
something
out.
Otherwise,
regarding
the
hackathon
coming
up
before
tpack,
we
basically
talked
about
running
one
or
two
days
of
hackathon
working
through
issues,
but
time
zone
wise.
A
It
will
be
better
to
have
a
few
half
days.
So
what
I
was
thinking
is
basically
for
the
like
from
mid-september
till
mid-october.
We
could,
for
example,
schedule
more
or
less
this
time
around
for
tuesdays
and
then
have
people
join.
If
they
can.
I
know
that
not
everyone
said
that
they
can
join
for
the
hackathon,
but
for
the
ones
that
can
maybe
we
can
run
this
sort
of
like
three
or
four
half
days
as
a
as
a
format.
Does
this
make
sense
for
folks
any
major
objections.
A
Maybe
a
show
of
hands
of
who
can
join
such
a
format.
At
least
I
don't
know
for
two
sessions
out
of
the
four.
A
Okay,
cool
awesome,
so
I
will
set
that
up
and
send
yeah
send
an
invite
to
the
folks
that
signed
up
and
generally
alert
like
send
it
to
the
group
so
that
maybe
even
more
people
can
attend.
A
A
A
Talk
through
that-
and
maybe
let
I
know
benjamin
you
had
like
you-
responded
on
the
thread,
so
I'm
I'd
love
to
better
understand
your
position.
I
saw
that
for
at
least
for
some
of
those
incubations
you
weren't
super
comfortable
in
adopting
and
I'd
like
to
better
understand
why.
A
Somewhat
related,
but
I
think
that
all
of
them
are
more
or
less
covered
by
the
current
charter,
but
it
would
be
good
to
like,
for
the
ones
that
we
adopt
would
be
good
to
add
them
as
deliverables,
but
we
can
amend
the
charter
afterwards
if
like,
if,
if
the
current
timing
doesn't
work
for
some
reason,
we
can
always
like
keeping
them
in
incubation
and
adding
them
like
adopting
them
later
on
is
not
an
awful
outcome.
As
far
as
I'm
concerned,
it's
it's
just
that
I
would
like.
A
If
we'll
reach
that
outcome,
I
would
like
us
to
reach
that
for
the
right
reasons.
What
are
the
right
reasons?
I
I'm
not
sure
I
guess.
From
my
perspective,
I
think
that
we
all
agree
that
the
use
cases
those
incubations
tackle,
or
at
least
most
of
them,
I
think
we
agree
on
the
use
cases
being
valuable
and
worthwhile
to
collaborate
on
so.
A
The
main
reason
they
have
to
be
is
like
again:
they
don't
have
to
be
the
main
reason
I
think
it
would
be
good
to
work
on
them
in
the
group
is
to
ensure
that
we're
all
comfortable,
collaborating
on
them
and
contributing
to
them
and
ensure
that
we
can
basically
discuss
those
issues
like
specific
issues
as
part
of
the
working
group
calls,
rather
than
have
them
be
as
a
separate
incubation,
which,
in
my
view,
will
increase
visibility
into
those
issues,
and
you
know,
visibility
and
collaboration
between
us
all.
B
Okay-
I
I
am
a
little
uncomfortable
about
this,
because
I
don't
really
feel
like
there's
multi-vendor
consensus
here,
although
I
do
think
a
lot
of
these
things
are
very
useful
and
worth
pursuing.
I
have
been
advised
that.
B
I
don't
know
at
this
time
I
think
mozilla
feels
more
comfortable
keeping
them
in
incubation
until
we
feel
like
there's
a
stronger
consensus
on
putting
them
into
wg,
and
I
don't
think
like
this
actually
will
hurt
the
development
of
these
proposals.
Like
I
don't
really
see
any
significant,
I
don't
see
any
significant
harm
in
keeping
them
out
of
wg
right
now.
A
Does
that
apply
to
all
of
the
incubations
listed,
because
we
have
largest
contentful
paint
layered
in
stability
element,
timing,
event,
timing
and
is
impending,
where
at
least
for
is
input
pending.
We
already
discussed
this
once
in
the
group,
but
didn't
really
issue
a
separate
cfc
for.
A
Do
you
feel
the
same
way
regarding
all
of
those
incubations.
A
At
the
time,
yes,
there
was
consensus
on
the
call
and
I
did
not
send
the
cfc
specifically
for
his
pending
at
the
time
I,
if
yeah.
C
A
So
to
me,
that's
not
like
we've
had
cases
in
the
past
for
the
working
group
to
adopt
specifications
that
lagged
in
implementation
in
webkit
and
elsewhere.
So
to
me
the
question
is
more:
do
you
object
to
those
like
specifications
being
worked
on
in
the
working
group
or
or
like.
C
I
mean
specifically,
if
it
is
to
going
to
affect
the
future
chartering.
I
rather
not
have
any
more
specifications
than
we
absolutely
have
to
right
like
because
it
would
affect
it
may
affect
our
ability
to
continue
to
be
in
a
working
group
so
that
we
are
not
interested
in
pursuing
any
any
of
these
specifications.
C
I
rather
not
have
them,
but
I
mean
if
the
working
group
feels
that
that
you
know
the
specification
needs
to
be
discussed
in
the
working
group.
I
mean
it.
I
I
don't.
I
don't
know
if
I
would
strongly
object
to
having
these
specifications
but,
like
my
preference,
is
not
to
have
them.
A
A
Noted
and
benjamin
from
your
perspective
from
mozilla's
perspective,.
B
We
don't
have
clear
consensus
here:
okay,
and
that
is
not
a
formal
objection
which
I
believe
is
what
you're
looking
for
that's
more
of
an
abstain,
and
I
would
repeat
my
request
to
delay
this
yeah
okay
until
we
get
to
a
better
place.
It's
worrisome
when
one
of
the
main
vendors
says
that
they're
not
going
to
do
this.
E
B
E
F
Philip,
this
is
stephen
from
salesforce.
Absolutely
we
would
like
to
be
to
have
those
api
available
in
all
the
browsers.
Having
them
in
only
one
is
is
troublesome
for
us,
because
we
don't
need
to
monitor
them
or
just
ignore
them.
So
we
we
would
love
to
have
those
those
api
natively.
Absolutely.
A
Yeah,
but
the
question
is
not
the
question
is:
do
you
feel
that
these
incubations
should
be
adopted
to
the
working
group
and
being
worked
in
the
working
group?
So
we
we
can
decide
here
on
what
various
engines
will
and
will
not
implement
and
ship
we
can
decide
on
or
what
we're
asking
here
is.
Do
you
feel
like
those
should
be
worked
on
in
the
working
group
or
stays
an
incubation
for
now.
F
F
Stephen
yeah,
I
mean
it's
hard
for
me
to
say
as
a
user.
What
exactly
the
difference
is,
I
understand
from
you
know
benjamin
and
ryosuke's
point
of
view,
but
as
a
user,
you
know
I'm
part
of
the
working
group
I
would
rather
than
to
be
incubated,
but.
A
The
practical
difference
from
your
perspective
is
that
the
various
issues
will
be
discussed
as
part
of
the
working
group
issue.
Triage
and
decision
making
versus
just
be
worked
on
at
github.
That's
the
most
obvious,
practical
difference
it
and
yeah.
My
hope
is
that,
having
that
discussion,
having
that
visibility
will
bring
us
closer
to
multi-vendor
consensus
and
implementations,
but
those
are
not
tightly.
A
C
H
C
A
A
Do
you
feel
that
it
would
be
productive
to
discuss
alternative,
absolute
or.
A
Do
you
feel
that
adopting
the
incubations
as
is,
would
cement
the
solutions
as
they
are
today
or
like,
or
do
you
think
that
we
could
discuss
those
alternative
solutions?
You
have
in
mind
as
part
of
the
working
group.
C
I
mean
we
don't
necessarily
have
alternative
solute
like
solution
for
all
the
use
cases.
I
think
it.
I
think
it'll
be
definitely
useful
to
talk
about
use
cases
behind
these
specifications
by
I
mean
so.
I
think
for
me
right
the
most
particular
difference
between
these
specifications.
Being
a
logging
group
versus
no
being
a
working
group
is,
if
you
effectively
chartering.
If
these
specifications
are
listed
as
deliverable
for
this
working
group,
then
it
would
have
a
specific
ip
implications
right
and
those
like,
you
know,
need
to
be
reviewed
for
us.
A
A
A
Useful
any
other
users
with
opinions.
I
I
mean
as
akamai
we
certainly
have
a
stake
in
using
all
of
these
right
now
and
for
our
customers
and
the
products
that
we
make
and
stuff
like
that,
I
I
would
personally
prefer
that
we
have
the
ability
to
discuss
them
within
this
working
groups.
I
think
there's
a
lot
of
broad
implementers
and
users
that
uniquely
get
together
for
this
working
group
to
call
and
discuss
them,
but
you
know
I'm
certainly
opinionated
as
being
one
of
the
chairs
of
it
as
well.
I
So
anyway,
from
our
perspective,
like
all
of
these
specs
themselves,
we
have
a
use
or
interest
in
using
and
would
like
to
try
to
get
consensus
across
the
vendors
to
see
what
concerns
they
would
have
or
how
we
would
implement
them,
or
you
know,
get
to
get
to
a
happy
endpoint.
F
Is
the
following
true,
this
is
steven
again,
so
it
sounds
like
for
for
me
and
maybe
for
jill.
It
sounds
like
we
will
and
it
sounds
like
we
love
this
place
to
talk
about
those
api
to
get
everybody's
point
of
view.
But
if
I
understand
well,
rio
suke's
point
is
that
if
we
incubate
them
and
put
them
as
deliverable,
then
that's
a
problem
with
apple's
participation
to
this
working
group,
because
it
would
be
a
deliverable
and
they
don't
have
the
agreement
to
start
with.
Is
that
correct?
F
A
I
don't
believe
that
was
what
ryosuke
was
saying,
the
like
having
something
as
deliverable
doesn't
mean
that
every
implementer
member
has
to
implement
it,
but
there
are
intellectual
property
implications
on
something
being
a
deliverable,
and
this
is
what
I
believe
rios
is.
We
ask
you
mentioned
that
you
will
need
to
check.
Is
that
a
correct.
C
Yeah,
I'm
not
I'm
not
saying
that
like
it
would
immediately
cause
an
issue
for
us
right.
I'm
just
saying
that
having
more
deliverable
would
mean
that,
like
you
know,
I
I
I
would
have
to
do
things
so
I
you
know
if,
since
at
this
point,
we're
not
interested
in
these
specifications,
I'd
rather
I'd
rather
not
having
to
do
that
process
right
I
mean
you
could
call
that
as
more
selfish
position,
but.
J
E
We
would
still
have
to
adapt
them
if
the
technical
proposal,
but
you
know
if
we
can't
please
them
those
deliverables
yet
in
this
in
the
deliverable
section
of
the
charter,
because
we
don't
agree
on
the
technical
solution
yet
less
than
b,
but
we
would
not
be
preventing
from
talking
about
it.
It's
it's
those
proposals.
All
those
proposals
are
within
the
scope
of
the
existing
working
group.
I
believe
so
rios.
You
would
not
have
to
ask
your
lawyer
again.
C
So
I
I
I
so
yeah
thanks
for
qualifying
that
I
so
alright,
like
that
at
a
somewhat
tangential
point,
I
I'm
I
my
intention
here
is
not
to
signal
any
vendors
here
like
I.
I
think
we
are
also
guilty
of
doing
this,
but
I
think
in
specifically
in
today's
browser
industry
climate,
I
think
it's
a
bit
problematic
when
brazilian
propose
the
feature
and
then
implements
a
feature
and
then
start
shipping
them
such
that
some
website
starts
using
them
right
away
before
there's
a
multi-vendor
consensus.
C
I
think
it
seems
that
we
want
to
be
more
conscientious
about
that
impact,
be
specifically
because
of
the
today's
more
I
don't.
I
don't
know
how
to
say.
Like
today's
browser
vendor
environment,
I
think
it
we,
like,
I
think,
locking
in
the
solutions
before
there
was
sufficient
discussions
and
consensus
on
a
specific
solution
to
the
use
case.
Us
is,
I
think,
is
a
pretty
big
problem
going
forward.
A
C
Well,
I
mean,
I
think,
the
reason
we're
discussing
adapting
these
specifications
is
because
we
believe
these
in
a
good
state.
I
don't
feel
that
way,
because,
frankly,
we
don't
believe
any
of
these
specifications
are
good
solutions
to
the
underlying
use
cases
right.
I
think
the
and
I
have
heard
voices
that
the
people
who
are
maintaining
websites
would
have
liked
these
expectations
and
the
I
believe,
the
reason
they're
saying
that
is
because
the
there
are
some
implementations
out
there
right
and
you
know
people
believe
that
these
would
become
reality.
A
I
think
that,
like
it's
a
bit
weird
to
talk
about
this
in
a
in
the
abstract,
so
if
we
just,
for
example,
focus
on
element,
timing
and
lcp,
for
example,
we've
been
talking
in
this
working
group
about
providing
more
accurate,
visual
metrics
for
websites
to
be
able
to
measure
what
they
do
for
years.
I
think
at
least
five
years
probably
before,
but
that
was
before
I
joined.
So
this
is
not
like.
The
use
case
is
something
that
people
are
interested
in.
A
Measuring
the
use
cases
seem
at
least
to
me,
like
things
that
we
have
been
discussing
here
for
a
long
while.
C
I
I
agree
use
case
we
have
been
discussing
a
while
right.
I
think
I
think
concern
here
is
that
there
have
been
multiple
proposals,
multiple
discussions
on
how
to
solve
that
each
problem-
and
these
are
like
one
type
of
solutions
and
I'm
not
sure
if
you,
if
I
recall
quickly
or
if
you
recall,
but
I'm
pretty
sure
I
have
raised
multiple
concerns
about
this
particular
element.
Timing,
and
I
just
continue
to
faint,
like
I
have
raised
multiple
concerns
and
issues
with
them.
So
I.
C
Yeah
so
so
I
I'm
a
bit
confused
as
to
why
we
think
they're
in
they
have
been
incubated
and
then
a
good
state
to
move
forward
in
the
logging
group.
A
A
We
are
trying
to
get
them
adopted
as
working
drafts,
which
I
don't
know
traditionally.
Working
drafts
have
been
just
that
an
initial
draft
of
a
specification,
so
I
don't
think
there's
a
necessarily
a
quality
bar
here.
At
the
same
time,
I
understand
that
we
don't
have
consensus.
I.
C
Mean
I
I
understand
that
there
there's
no
quality
buffalo
the
draft
per
se,
but
I
mean
the
whole
point
of
incubation
is
that
we
incubate,
so
that
we
have
a
good
sense
that
okay,
this
solution
is
a
good
fit
for
this
use
case
right
I
mean
that
that
isn't
the
whole
point.
If
that
were
not
the
case,
why
do
we
incubate
at
all?
Why
don't
we
just
start
all
the
ideas
in
the
working
group
directly?
C
H
C
B
C
A
I
feel
like
so
my
recollection
is
that
for
lcp,
specifically
so
lcp
was
arguably
the
most
contentious
one
of
the
incubations
discussed.
A
If
I
recall
correctly,
it
was
presented
multiple
times
to
the
working
group
you
raised
concerns
and
you
and
others
raised
concerns
and
I
believe,
annie
presented
data
to
address
those
concerns
and
from
my
recollection
from
that
meeting,
we
left
the
meeting
feeling
that
the
initial
skepticism
was
addressed.
A
C
Mean
I
I
I
mean
we
can
go
into
discussing
largest
content
content
for
pain
if
you
like,
but
I
think
I
do
recall
that
discussion
and
I
do
recall
that
the
data
was
presented,
but
data
was
presented
based
on
the
data
that
was
gathered
on
chrome
right.
I
mean
I
understand
that
it
would
work
specifically
the
way,
chrome,
paints
and
a
low.
You
know
paints
doing
the
page
builder.
I
have
no
doubt
about
that
right
and
I
people
believe
that
that's
a
useful
metric.
C
A
useful
metric
I
mean
also
like
you
know
they
what's
important
during
page-
is
a
bit
subjective
right
like
depends
on
the
what
your
user
experience
ought
to
be
and
what
you
value
in
terms
of
user
experience
for
longest
time,
safari
refused
to
paint
any
part
of
page
until
the
entire
page
was
ready
to
be
painted,
because
we
didn't
want
the
page
to
be
kept
moving
around
and
repainting
as
the
page
loaded
right,
so
I
mean
some
people
may
think.
C
That's
a
bad
user
experience,
because
user
would
like
to
see
any
content
asap
and
then
you
know
want
the
painting
to
be
updated,
but
that's
just
not
the
way
we
thought
users
would
see,
and
then
we
thought
that
was
the
worst
was
experience.
So
I
I
think
I
mean
to
to
that
extent.
I
think
the
what
is
important
for
the
user
experience
is
pretty
subjective
right.
So
I'm
not
even
sure
it's
something
that,
like
you
know,
watching
group
could
even
come
to
consensus
about.
C
But
I
I
I
think
as
an
implementer,
we
have
a
pretty
serious
doubt
that
in
fact
we
have
pretty
large
objection
to
having
the
largest
content
for
paint
as
a
metric
and
a
page,
because
that
might
encourage
your
website
to
optimize
the
wrong
thing
for
safari.
So
I
I
think.
C
Yeah,
I
don't
know
I
mean
to
your
point.
I
think
I
think
it
is
valid
argument
to
say
that
yes,
like
these
are
the
things
that
we
should
be
discussing
working
with
because
they're
you
know
we
are
in
just
the
underlying
use
case.
That
is
true,
but
I
mean
that
is
true
of
anything
that
get
incubated
right
before
coming
to
this
working
group,
and
I
think
I
I
guess
the
question
really
is:
what
is
the?
C
What
is
the
distinction
we
make
between
the
things
we
should
be
intuitive
versus
things
that
should
not
be
incubated,
and
you
know
ready
to
be
discussed
in
the
working
group.
I
think
I
I
guess
that
that
fundamentally
is
the
question
right
like
what?
What
is
the
distinction?
What
is
the
purpose
of
integration.
A
So
yeah
a
few
points
that
you
raised
there,
so
I
wanna
maybe
address
them
before
that
question.
So,
regarding
the
painting
differences
between
different
engines,
I
was
under
the
impression
that
that
is
something
we
more
or
less
defined
as
part
of
fcp
and
maybe
element.
Timing
and
lcp
can
benefit
from
the
similar
definitions
that
would
work
for
all
engines.
But
let's
put
that
aside,
that
is
potentially
a
discussion
to
be
had
after
like
to
be
had
in
the
working
group
after
adoption.
Otherwise
the.
A
The
question
regarding
when
incubations
should
be
adopted
is
not
necessarily.
A
Not
necessarily
well-defined
line,
it
has
been
so
with
my
ycg
hat
on.
This
has
been
something
that
was
mostly
working
group
driven,
so
incubations
were
adopted
when
working
groups
decided
that
this
is
something
they
want
to
work
on
inside
the
working
group
rather
than
as
an
external
incubation.
A
So
it
was
a
working
group
by
working
group
decision.
There
is
no
strict
criteria
and
yeah.
I
guess
it's
a
question
of
like
it's
potentially
a
question
to
the
working
group.
When
do
we
feel
that
a
use
case
has
been
clear
enough
and
a
solution
has
a
well
well
enough
defined
shape
that
we
want
to
work
on
it
inside
the
working
group
rather
than
as
an.
A
And
but
yeah,
but
potentially
going
back
to
yeah.
Maybe
we
can
move
on
to
discuss
some
more
specific
issues,
but
generally
I
feel
like
this
was.
This
was
a
call
for
consensus.
A
It
is
obvious
to
me
that
we
don't
currently
have
consensus,
so
it
might
be
interesting
if
there
are
some
incubations
in
that
list
that
you
feel
are
more
ready
than
others,
for
example,
is
input
pending,
which
we
already
verbally
decided
to
adopt,
but
never
sent
an
official
cfc.
That
could
be
one
outcome
or
otherwise
we
can
close
the
cfc
and
reopen
it
in
a
few
months
or
because,
essentially,
I
believe,
benjamin
you
asked
for
an
extension
till
t-pac.
B
B
Yeah-
and
I
I
think
like
something
they
think
about-
is
maybe
automating
that
process
so
that,
like
every
six
months,
we
have
like
show
hands
or
status
on
like
what
do
we
think
of?
What's
the
current
thinking
on
incubations,
you
know
like
regularizing.
That
process
might
be
helpful
in
getting
us
towards
consensus,
which
is
what
I'm
really
going
for
here.
A
Just
yeah
that
that
makes
sense
other
than
yeah
the
fact
that
the
automation
will
probably
be
a
notification
in
my
calendar,
but
sure
we
can.
We
can
make
it
a
regular
cadence
to
ping
the
group
and
yeah
and
get
like
check
the
temperature
on
the
various
incubations.
A
Sure,
okay,
so
with
that,
maybe
so
one
quick
topic
of
discussion,
we've
had
requests
from
people
to
integrate
more
and
more
parts
of
the
preload
processing
model
into
html,
as
well
as
people
saying
that
current,
like
having
preload
be
defined
in
html
but
still
have
its
own
separate
spec
is
somewhat
confusing
and
one
potential
solution
for
that
would
be
to
just
merge
all
the
processing
model
from
preload
into
html
publish
it
as
a
note,
move
over
a
relevant
issues
and
pass
that
deliverable
from
the
working
group
to
the
what
wg
and
I'm
wondering
if
folks
have
strong
opinions
on
that
one
way
or
the
other.
I
A
So
it
might
be
yeah
147
is
also
related
because
it's
yeah,
that's
the
issue
that
I
referred
to,
trying
to
like
basically
move
more
of
the
processing
model
into
html.
A
Or
although
yeah
147
is
probably
just
about
the
legion,
so
it's
mostly
mostly
about
154
and
confusion
of
having
those
two
separate
specifications.
A
E
A
A
A
E
So
I
once
people
gave
their
opinions.
I
can
give
you
practically
what
it
means
doing
that
by
the
way,
it's
not
as
simple
as
it
sounds.
Okay,.
E
E
We
have
a
few
working
groups
like
device
and
sensors,
the
media
working
group
and
the
css
working
groups
that
are
ahead
of
us
and
we
due
to
the
summers
meetings
between
the
world
which
gmwc
have
been
spotty
at
best,
so
it
may
take
us
a
month
or
two
to
get
back
to
you
guys
and
says
yeah.
We
can
do
it
just
because
of
the
backlogs
that
we
have
of
agenda
items
between
the
two
organizations
at
the
top
right
now
of
that
list.
If
you're
curious
he's
web
ideal.
K
A
E
A
A
H
Sure
so
there
was,
I
think,
webkit
dev
thread
about
event
timing.
So
I
just
wanted
to
open
for
discussion
again
to
clarify
the
use
cases
and
like
differences
between
long
tasks
and
event.
Timing.
H
H
In
particular,
I
guess
there
was
some
concern
that,
since
long
tasks
is
already
I
guess
adopted,
there
was
concern
that
maybe
even
timing
solve
similar
use
cases
is
that
accurate.
L
D
H
Okay,
sure
so
I
can
go
over
the
use
cases
of
both
and
anyone
feel
free
to
chime
in
when
I
s
what
to
compliment
so
for
for
long
tasks
there
are.
H
It
is
true
that
one
of
the
use
cases
is
to
ensure
that
the
website
is
able
to
respond
to
user
input
relatively
quickly
right,
because
if
you
have
a
long
task
and
the
user
inputs
say
near
the
beginning,
then
that
means
that
the
input
delay
for
that
input
will
be
high.
So
that
is
certainly
one
of
the
use
cases.
There
are,
however,
other
use
cases.
For
example,
another
use
case
is
to
ensure
that
animations
that
run
in
the
the
main
process
or
the
main
thread
run
smoothly.
H
Another
use
case
is
for
websites
to
try
to
manage
the
amount
of
battery
drain
that
they
cause
to
a
phone,
because
cpu
usage
is
tightly
linked
with
well
battery
consumption
right
so
by
measuring
long
tasks,
you
basically
ensure
that
you
keep
it
keep
the
battery
usage
as
slow
as
possible,
and
another
use
case
of
long
tasks
is
that,
since
it
provides
you
basically
like
an
overview
of
the
chunks
of
tasks
that
are
sufficiently
long,
that
they're
like
meaningful
to
the
page,
you
can
compute
various
metrics
based
on
the
long
tasks.
H
H
That
the
the
initial
part
will
not
be
considered
blocking,
or
I
guess
the
final
part
of
the
task
so
like
if
you
click
on
the
towards
the
end
of
the
long
task.
It's
not
really
blocking
the
input
meaningfully.
H
And
there
are
some
other
use
cases
for
examples.
For
example,
sorry,
some
ads
teams
use
long
tasks
to
compute
metrics
on
the
impact
of
ads
on
websites.
H
K
The
way
you
described
it
as
a
total
blocking
time
for
user
session,
and
we
use
that
to
kind
of
grade
sessions,
user
experience
and
then
we
use
those
session
other
telemetry
of
what
activity
happened
on
during
those
sessions
and
use
that
to
analyze
where
the
bottlenecks
are
where
we
need
to
improve
our
code.
Basically,
so
it's
a
very
useful
tool
for
us
for
that
use
case.
F
H
Slowness
thanks
for
providing
handicaps,
and
now
we
can
compare
that
with
event.
Timing
so
note
that
many
of
the
long
tasks
use
cases
are
not
quite.
H
How
to
say
it
related
to
events,
not
not.
All
of
them
are
event.
Timing
tries
to
capture
specifically
the
like
responsiveness
of
events
that
actually
happen.
It's,
I
think
it's
kind
of
well
known
that
it's
really
hard
to
predict
when
user
input
is
going
to
happen.
H
So
if
you
try
to
use
long
tasks
to
measure
things
like
input
delay,
it's
not
going
to
work
that
well,
because,
basically,
the
the
time
when
the
user
actually
clicks
is
very
unpredictable
or
like
very
hard
to
predict
so
event,
timing
solves
use
cases
related
to
actually
directly
measuring
delays
in
responding
to
user
inputs.
So
one
of
the
metrics
that
event
timing
allows
measuring
is
first
input,
delay,
which
I
think
we've
defined
previously
in
this
in
the
course,
but
I
can
briefly
explain
what
it
is.
H
It
attempts
to
measure
how
long
does
it
take
for
the
user
agent,
so
the
browser
to
start
handling
the
event
so,
for
example,
if
it's
a
click
or
like
a
tap,
then
how
long
does
it
take
for
the
user
to
start
dispatching
the
pointer
down
corresponding
to
that
user
interaction
so
that
that
is
the
first
input
it
does
not
measure?
H
H
The
amount
of
time
the
event
handlers
take
to
run,
and
I
mean
I
guess
I
should
point
out
the
the
caveat
here
is
that
any
asynchronous
tasks
posted
during
the
event
handler
are
not
measured
yet
by
the
api
right.
So,
for
example,
if
your
event
handler
is
something
that
is
starts
with
set
timeout
and
performs
all
all
the
work
inside
of
the
set
timeout,
then
event,
timing
will
only
measure
the
amount
of
time
it
takes
for
you
to
post
the
set
timeout.
H
If
that
makes
sense,
and
the
final
component
that
event
timing
measures
is
how
long
does
it
take
for
the
user
agent
to
update
the
screen
based
on
the
user
interaction?
So
here
the
assumption
is
that
there's
some
assumptions
here
like
there's
an
assumption
that,
during
the
event
handler,
the
screen
is
updated
due
to
the
user
interaction.
H
So,
of
course,
the
next
paint
after
user
interaction
is
not
really
meaningful.
If
that
does
not
happen
right,
but
in
cases
when
it
does,
it
will
expose
the
the
time
it
takes
for
that
next
paint
or
the
next
update
to
the
screen
based
on
the
user
interaction.
H
J
I'm
not
sure
how
useful
this
is,
but
long
task
seems
to
be
good
at
predicting
issues
I
mean
in
terms
of
battery
usage.
It
reports
real
a
real
issue,
but
in
terms
of
smoothness
of
animations
or
or
user,
like
real
responsiveness
to
input,
it's
a
it's
a
predictor.
It
doesn't
actually
measure
the
underlying
thing.
So
event,
timing,
actually
measures
the
underlying
thing
and
then
for
animation.
Smoothness
there
there
have
been
some
early
attempts
to
try
and
work
out
that
problem
directly.
C
Hold
on
but
like
the
janks,
rendering
so
forth
that
there's
also
frame
timing
right
I
mean
I,
I
think
our
main
issue
here
is
not
so
much
all
these
use
cases
and
what
apis
of
each
use
case
it's
that
they
there's
so
many
of
these
apis
and
it's
unclear
how
all
these
two
things
these
things
will
fit
together.
For
example,
in
like
in
event
timing,
there
was
a
mentioning
of
how
we
want
to
know
how
long
the
event
the
website
takes
to
respond
to
the
input
boy,
I
mean
event.
C
Hunter
is
one
thing,
but
in
today's
websites
oftentimes
there
are
multiple
promises
being
involved
in
a
process
and
given
input
right.
So
then
you
have
to
like
just
using
this
is
about
the
getting
of
initial
delay
until
event
listeners
called,
and
then
you
have
the
instrumentation
code
to
track
all
the
promises
that
you
may
have
and
then
once
all
the
promises,
then
you
have
to
wait
for
that
final
result
to
be
painted
well
like
a
painting.
C
C
H
So
so
I
think
the
proposal
is
to
address
that
use
case
with
event
timing,
but
I
do
agree
that
we're
not
there
and
the
reason
we're
not
there
yet
is
because
we
it's
basically
impossible
to
track
causality.
So,
like
you're
mentioning
you
have
promises
and
then
you
need
to
track
those
promises
and
when
they
get
resolved
and
then
you
need
to
drag
the
paints
that
occurs
after
the
dhamma
updates.
That
happened
because
of
the
resolution
of
those
promises.
So
that's
a
problem
we're
like
really
hoping
to
address
at
some
point
and
we
agree
that
event.
H
Timing
doesn't
yet
address
it,
but
the
reason
is
we.
We
don't
know
how
and
we
believe
this
is
a
good
first
step
towards
that
direction.
Regarding
frame
timing,
I
believe
the
the
proposal
is
more
geared.
I
think
michael
can
correct
me
if
I'm
wrong
towards
measuring
smoothness
of
animations
and
smoothness
of
scrolling,
so
it
will
be
kind
of
a
little
different
use
case
than
say
tapping
measuring
how
long
it
takes
for
the
tapping
to
actually
produce
a
response
versus
measuring
how
smoothly
you
scroll
or
how
smoothly
you
can
see
an
animation.
If
that
makes
sense,.
A
Regarding
so
regarding
the
scenario
you
point
out,
I
think
that,
yes,
it
is
hard
to
have
a
high
level
api
that
measures
exactly
that
because
of
the
indirection
because
of
the
asynchronous
nature
of
adding
things
to
dom,
but
I
think
developers
like
we
can
provide
developers
with
the
building
blocks
to
do
that.
So
event,
timing
is
one
building
block
element.
Timing
is
another
and
then
user
timing
can
enable
them
to
you
know,
bridge
the
gap
of
the
asynchronous
calls
if
that
is
of
value
as
well.
A
So
I
I
agree
that
this
is
yeah.
Ideally,
we
would
have
a
high
level
api,
but
a
set
of
low-level
apis
that
are
basically
building
blocks
that
enable
developers
to
measure
anything
they
want
to
instrument
doesn't
sound
like
a
bad
outcome.
C
I
mean
I,
I
think,
I'm
not
even
sure
these
are
the
right
primitives
right,
that's
the
main
concern
I
have,
which
is
that
the
I
mean
all
these
apis
are
addressing.
Like
you
know,
people
saying
oh
yeah,
this
one
addresses
this
use
case,
but
it
doesn't
understand
slightly
different
use
cases,
so
we
need
to
have
a
completely
different
api
that
made
you
this
completely
other
thing
and
then,
when
you
combine
these
two
things
you
can
achieve,
you
know
addressing
the
underlying
use
case.
That,
to
me
is
just
bad
api.
C
C
A
So
yeah
I'm
having
trouble
yeah
we're
a
bit
out
of
time,
but
also
maybe
we
can
continue
this
discussion
next
time
around
my
main
problem
with
the
categorization
of
so
of
this
as
a
bed
api
is
that
I
would
like
I
would
love
to
see
an
alternative
that
you
would
consider
a
good
api
or
some
like
an
alternative
that
would
address
all
those
all
those
use
cases
from
related
to
to
causation.
A
A
Yeah
I
feel
like
I,
I
would
love
to
understand
what
you
would
consider
a
good
api.
A
And
with
that,
we
are
three
minutes
over
time.
So
thanks
all
and
right,
thanks
I'll
see
you
all
thank.