►
From YouTube: WebPerfWG call - January 16th 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
E
F
G
E
A
A
Two
days
at
the
beginning
of
April,
let
me
just
make
sure
that
I
remember
the
dates
right.
So
it's
the
second
and
third
of
April
and
in
the
Bay
Area
in
Sunnyvale,
and
we
are
planning
to
have
one
day
that
more
or
less
mirrors
what
we
had
last
year
with
a
more
industry
participation.
And
we
want
to
invite
various
folks
from
from
the
frameworks
world
from
the
single-page
app
world
and
figure
out
hash
out
whatever
it
is
that
we
need
to
do
there
in
that
space
and
then
a
second
day
for
a
regular
face-to-face.
H
A
D
So
just
yeah,
it's
a
couple.
Neat
things
are
additional
things.
Rather
we
do
have.
Our
current
charter
expires,
I
believe
in
a
little
wrong.
So
one
of
the
hopes
is
that
we
correctly
your
unmute
or
we
can
hear
you
unfortunately,
sorry
end
of
June
end
of
June
okay,
so
we
have
a
bit
more
time
than
I
thought,
so
we
do
have
two
recharter
sometime,
not
sometime
in
2020
I.
D
Guess,
yes,
and
one
of
the
hopes
is
that
the
discussions
and
the
priorities
that
we
identify
that
the
face-to-face
would
inform
what
we
focus
on
one
of
the
area.
That's
been
burning
conversation
for
us
for
many
years
and
we've
spent
a
lot
of
time
on
the
last
face
to
face
is
single
page
apps.
So
there's
some
discussions
that
we've
previously
held
about
this.
How
do
we
enable
better
measurement,
single
page
apps
and,
for
example,
in
context,
though
navigation
timing
in
the
rest,
but
I
think
there's
also
just
in
broader
discussion
around?
D
What
is
it
that
we
ought
to
be
thinking
about
for
measuring
JavaScript
applications?
Are
there
api's
that
we
have
not
discussed
or
thought
about,
so
the
thought
was
to
put
together
a
day
where
we
can
bring
in
folks
that
are
working
on
frameworks
to
just
kind
of
soak
and
hear
what
their
problems
are
similar
to.
What
we
did
a
lot
of
face
to
face
and
then
have
a
discussion,
and
we
used
that
as
input
for
our
charter
process
and
also
areas
of
focus
and
all
for
us.
D
D
K
D
A
So
with
that,
out
of
the
way
we
can
talk
about
what
performance
stuff
any
you
wanted
to
share
your
research
on
largest
disk
and
pencil
paint
and
element
removal.
L
Yeah,
so
there's
been
a
couple
of
questions
generally
largest
content.
Will
pain?
Is
the
largest
image
or
text
content?
The
paint
on
the
page
as
its
loading
and
one
of
the
exceptions
to
that
is
that
if
the
element
is
removed
from
the
Dom
and
the
reason
we
did,
that
was
because
of
splash
screens.
Is
somebody
splashes
some
content
on
the
screen
and
then
removes
it?
Then
you
have
the
largest
content.
Will
maybe
something
after
that.
But
I
was
asked
for
examples,
which
is
perfectly
reasonable.
L
The
example
that
we
have
been
using
was
Twitter,
but
when
I
went
back
to
Twitter,
I
couldn't
reproduce
what
we'd
seen
before,
where,
if
I
take
out
that
behavior
I
actually
get
a
perfectly
reasonable,
largest
content.
Okay,
when
the
page
is
loaded,
so
I
went
back,
I
used
a
testing
tool
which
can
kind
of
pull
like
ten
thousand
sites
and
do
a
film
strip
of
them
and
I
looked
for
pages
that
had
a
difference
with
and
without
this
behavior,
and
what
if
phone
was
80%
of
them
were
carousels.
L
So
if
you
have
this
site
like
it
loads
this
image,
then
the
next
image
and
the
next
image
and
the
largest
content
will
paint
will
just
be
like
the
last
thing
that
just
loaded
in
the
carousel
is
so
it
essentially
in
this
case
tracks
the
time
on
page,
and
that
was
actually
eighty
percent
of
the
cases
in
which
there
was
a
good
difference
with
getting
rid
of
this
removal
behavior.
If
we
get
get
rid
of
it
and
we
just
count
the
images
that
have
been
removed
we
come
up
with.
L
This
is
a
largest
concept
for
paint,
which
is
probably
what
most
people
would
expect.
I
did
find.
This
is
80%
of
the
cases
in
about
10%.
I
found
this.
This
header
placeholder,
where
the
largest
kind
of
bull
paint
would
be
this
placeholder
image
if
we
ignored
things
that
are
removed
and
if
we
didn't
ignore
things
that
are
removed
and
if
we
did,
it
will
get
the
headlines
so
that
that's
more
correct,
I
found
a
few
pages
with
flash
of
unstyled
content
like
I.
L
Think
three
or
four
pages
and
I
only
found
three
pages
in
the
the
dataset
about
200
pages.
Were
affected
by
the
change
in
metric
out
of
10,000,
and
then
only
three
of
those
actually
had
splash
screens.
So
what
we're
gonna
do
on
our
end
is
implement
both
both
metrics
in
Chrome,
like
with
them,
without
this
ignoring
of
removed
images
and
we're
going
to
look
at
the
the
data
that
version
of
chrome
rolls
out
to
stable
to
see.
If
this
is
a
representative
sample
or
if
there's
other
cases
that
we
didn't
catch.
B
L
D
L
G
H
And
I
thought
we
had
done
this
better
with
cara
sauce
if
they're
the
same
size,
then
if
you
just
broke
ties
by
just
basically
expecting
only
a
larger
size
and
imagine
right
now,
the
problem
is
we
break
ties
by
sending
the
latest
one?
Do
you
may
taste
that
way,
then
that
caused
us
all
to
kill
the
castle
case?
Presumably
cuz
I.
Imagine
the
images
are
the
same
size
if
every
time
so
just
by
sending
the
first
one
that
could
also
mitigate
the
problem.
There.
H
So
so,
basically
the
idea
is
you
only
update
the
LCP
value
if
it's
a
strictly
larger
size.
So
in
the
case
of
the
carousel
right
now,
I
assume
it's
getting
updated
because
it's
the
same
size
so
it'll
be
updated
every
time,
because
every
whatever
it
took
care
so
length
is
every
two
seconds
or
something
you
get
in
your
image.
H
L
So
some
other
cases
just
so
so
this
is
also
the
same
size,
this
header
placeholder
image
and
then
in
this
flash
of
unstyled
content.
Generally,
it's
a
very
large
flash
like
this
and
then
it's
going
to
be
a
smaller
image
here.
D
Yeah
I'm
thinking
of
like
a
couple
of
examples
where
I
myself
built
or
used
some
carousel
playand
on
certain
websites,
where
basically
just
big
three
images
from
my
media
gallery,
all
of
which
have
different
aspect
ratios
and
then
the
carousel
just
does
like
you
know
a
little
bit
clipping
magic
to
just
like
fit
into
that
thing.
Right.
H
But
even
in
that
case
you
wouldn't
just
loop
eternally
right,
because
you
will
pick
LCD
as
the
largest
image
in
the
carousel
the
first
time.
It
shows
up
not
the.
D
H
L
I
mean
the
the
reason
we
didn't
really
consider.
This
is
just
because
this
behavior
already
is
complex
and
I
found
a
bug
in
it,
while
I
was
doing
this
analysis
and
slowly
put
any
more
logic
on
top
of
it
at
its
complexity,
if
we
could
get
something
that
captured
both
of
these
cases
and
if
they
really
are
like
two
percent
of
the
cases,
would
it
be
worth
it.
F
For
I
guess,
I'm
more
interested
in
terms
of
special
case
being
the
splash
screen
case,
which
is
starting
to
really
impact
results,
also
in
frameworks
like
browser
time.
So
can
you
talk
a
little
bit
about
with
like
how
you're
identifying
these
flash
grains
and
I
can't
actually
tube
this
presentation
congested
a
vigil
I'm.
L
D
B
Mean
in
general
the
simpler
it
is
that
it's
easier
just
to
explain
to
customers
and
to
other
people
that
care
about
the
symmetric
right,
the
more
you
more
edge
cases.
You
add
the
more
like
caveats.
You
have
to
talk
about,
or
things
like
that
and
you
know
advanced
people
that
want
to
do
this.
They
can
use
element
timing,
probably
to
kind
of
work
around
those
edge
cases.
So.
C
G
H
H
L
H
H
G
H
G
G
G
H
Well,
I
mean
it's
currently
shipped
in,
but
it's
true
that
we
did
have
to
work
a
bit
on
reducing
the
initial
performance
regressions
that
were
caused
by
this
additional
tracking,
so
that
yeah
you're
right
that
it's
a
little
expensive.
But
it's
certainly
something
that
can
be
done
and
I
think
if
we
get
rid
of
the
removal
logic.
Yes
we're
kind
of,
then
it
might
make
the
algorithm
less
expensive
because
we
have
to
keep
track
of
less
things.
D
L
K
Okay,
all
right
cool,
so
yeah
I
thought
I'd.
Just
do
like
a
very
quick
like
presentation
about
like
some
of
the
feedback
we've
addressed
post
t
back.
We
had
a
lot
of
useful
feedback
back
in
what
was
it
like
october,
and
we've
made
a
few
spec
changes,
let's
dive
into
it,
so
I
think
most
people
would
call
here
have
contacts
on
it.
K
But
for
quick
recap,
isn't
appending
is
basically
a
low-level
like
api
intended
for
like
javascript
schedulers,
in
order
to
predict
when
future
or
to
get
hints
when
feature
input,
events
are
going
to
arrive
and
yield.
There
were
news
to
it.
So
imagine
like
you're
doing
a
bunch
of
expensive
work
and
it
was
I,
don't
know
who
would
do
that
and
he
comes
in
or
the
browser
receives
like
a
mouse
down,
we're
going
to
want
to
stop
doing
that
and
address
the
input
like
as
soon
as
possible.
K
So
isn't
appending
lets
us
do
that
we
read
an
origin
trial
in
Chrome,
I,
believe
q2
q3
last
year,
and
we
confirmed
our
hypothesis.
We
reduced
our
input
queuing
delay
by
quite
a
large
margin
and
got
positive
signal
from
other
partners,
and
we
presented
on
this
last
feedback
and
yeah.
So,
let's
dive
into
some
of
the
feedback
we
received.
K
So
one
of
the
big
issues
that
was
brought
up
was
that
using
Dom
event,
types
for
input
is
impending.
It
was
sort
of
unspeakable
in
a
way
the
spec
itself
had
no
notion
of
like
what
might
be
able
to
dispatch
like
that,
or
even
something
as
simple
as
like
a
mouse
down
front
in
other
normative
documentation.
These
events
are
sort
of
considered
like
an
act
of
God
and
there's
no
real,
like
concise,
algorithm
or
strategy
to
like
allow
implementers
to
act
based
on
these.
K
K
Every
time
is
offending
is
called,
which
is
sort
of
okay
for
other
web
platform
api's
that
may
be
called
infrequently,
but
in
our
case
and
in
many
other
sites
cases
they
were
calling
ism
eventing
very,
very
often,
and
so
we're
doing
a
bunch
of
extraneous
like
swim
matches.
For
no
reason.
In
addition,
the
way
isn't
before
is
news.
Very
stateless.
You
just
called
navigator
does
scheduling
that
is
impending
and
expected
a
boolean.
K
It's
a
it's
a
miracle,
but,
as
it
turns
out,
the
user
agent
might
actually
want
Ince
prior
without
at
least
in
chrome,
to
whether
or
not
we
should
start
running
any
kind
of
prediction
logic
to
determine
whether
it
is
like
input
spending
so
that
sites,
but
don't
use,
isn't
the
pending
won't
necessarily
get
Sloane
down
by
more
complex
implementation.
So
the
way
we
saw
this
in
the
spec
is
by
adding
an
option.
K
Thunk
object,
so
I
like
the
idea
is
that
when
you
allocate
like
the
offered
parameter
hint
to
the
user
agent,
hey
like
they
might,
actually
this,
like
slate
might
actually
start
using,
isn't
a
pending.
Please
warm
up
any
kind
of
prediction:
logic
in
your
like
fit
test
to
etc.
And
lastly,
when
the
issue
brought
up
masti
back
was
the
idea
of
how
are
we
going
to
be
able
to
kill
early
regarding
multiple
urgent
frames?
It
might
be
tricky
to
perform
attribution
ahead
of
time.
K
So
right
now,
we've
got
a
prototype
in
chromium
like
in
the
chromium
case.
It's
compositor
based
hit
testing
based
on
the
state
in
which
the
input
event
arrives,
which
is
the
same
state
which
is
presented
to
the
user
ie
the
last
frame.
So
this
is
pretty
much
we
expected
not
to
introduce
any
kind
of
new
clickjacking
attack
vectors
and
pretty
much
like
is
the
same
as
the
existing
like
render
based
allegation,
but
that's
most
implication,
detail
yeah
cool.
So
any
questions
on
this
or
should
I
just
jump
into
the
event
type
stuff.
K
Obviously,
so
what
we
proposed
originally
was
suggesting
that
user
agents
like
perform
this
based
on
the
last
frame
perform
hit
testing
based
on
the
last
frame
displayed
to
the
user,
and
so
that's
the
implementation
of
the
export
here.
And
so
that
would
let
us
say
that,
like
we
perform
like
origin
level,
attribution
for
frames
and
so
that,
like
a
frame
in
a
different
organ,
doesn't
mistakenly
receive
the
wrong
event.
H
H
K
But
ultimately,
this
falls
play
to
like
very
similar
issues
with
event
targeting
in
general,
like
imagine
like
a
site
that
blocks
the
main
thread
like
after
it
displays
a
frame
which
moves
frame
around
like.
In
that
case,
the
user
will
click
on
something
and
that
event
might
not
actually
bring
that
they
thought.
H
K
So
one
of
the
big
pieces
of
implantation
work
for
the
chrome
one
was.
We
did
hit
testing
based
on
browsing
contacts
and
those
browsing
conflicts,
at
least
for
isn't
appending
group
events
by
same
origins
so
like.
If
you
have
two
frames
now
the
same
origin
is
the
map
ending
will
return.
True
when
it
event
occurs
in
one
of
the
frames
so
that
we
can
actually
get
the
scheduling
properties
that
we
want,
which
is
like
yield
to
anything
that
shows
the
event
loop,
that
safety
and.
K
Which
right
so
in
Chrome's
case
for
our
initial
origin
trial?
We
ran
this
in
the
browser
process,
which
only
had
knowledge
of
like
unit
of
similar
origin
browsing
fabulous,
fit
test.
So
with
the
second
phase
of
the
implementation,
we
move
this
to
the
renderer
as
well,
so
that
would
work
for
Android
and
other
situations
where
it's
same
site,
the
different
origin,
okay,.
K
What
do
you
mean
like,
as
I
mentioned,
like
a
like
mainframe,
could
block
the
main
thread
like
after
displaying
Ram,
so
he's
in
the
moon.
Browsing
context
could
block
the
main
thread
of
displaying
a
frame
like
shuffles
and
frames
around
and
caused
like
the
dispatch
of
the
event
to
go
to
the
wrong
frame
like
it's
already
like
a
pretty
well-known
and
clicked
jacking
attack,
vector
I'm,
one
of
the
mitigations,
for
this
in
chromium
at
least,
is
to
actually
like
block
certain
event.
Dispatch
after
frames
have
been
moved
for
a
brief
period
of
time.
Yeah.
H
K
In
order
for
that
to
happen,
this
would
only
happen
in
an
iframe
or
in
a
case
where
you
have
multiple,
like
nesting
browser
contexts
per
page.
The
attack
that
I
can
imagine
is
where
you
click
like
on
a
cross
origin.
Iframe
you'd,
like
you,
move
the
iframe
away
like
programmatically,
so
from
the
time
that
the
event
is
dispatched
to
the
like
to
a
post
layout
time
where
the
task
runs,
it's
no
longer
going
to
receive
the
event,
so
you
might
think
that
you're
getting
events
that
you
don't.
K
G
K
G
Just
because
the
demo
some
browser
may
have
a
bug
about
this
doesn't
necessarily
mean
that
we
can
make
it
worse
right
like
clearly.
This
is
proposed
like
introducing
new
security,
sensitive
surfers,
so
I
think
that
needs
to
be
very
carefully
studied
and
I
already
peed
myself.
That
I
don't
think
that
what
you're
currently
proposing
is
something
that
will
be
very
comfortable,
important
thing
that
get
what
you
described
does
not
change
that
feedback.
K
Correct,
but
it
remains
to
be
seen:
I
think
that,
like
mitigations
aren't
possible
that
prevent
this
for
the
scrolling
case
that
you're
describing
it
requires,
like
the
main
thread
to
actually
like
process.
This,
like
the
case
you're
describing,
is
we're
all
scrolling
a
synchronous
say
you
dispatch
like
a
girl
event.
What
causes
a
frame
to
move?
K
It
won't
actually
cause
misattribution
from
what
I
understand,
because
the
frame
won't
actually
move
if
the
main
thread
is
blocked
in
this
case,
and
if
it
does
yeah
I'm,
not
sure
the
attack
vector
that
you're
referring
to
in
particular
sorry
could
you
like
provide
walk
me
through
an
example.
Well,
I
mean.
G
K
Yeah
so
you're,
imagining
like
user
Scrolls
clicks
like
the
frame,
doesn't
update
with
the
scroll
processes
and
it
clicks
on
a
different
origin,
iframe
and
then,
as
a
result
like
the
parent
of
the
iframe
will
receive
in,
is
about
ending
true
call
from
that.
That
will
be
incorrect
and
will
leak
like
it.
Click
intended
for
the
cross
original
iframe
well.
K
G
G
For
how
I,
like
all
of
this
hit,
the
stained
stuff
works
at
least
not
necessary,
hit
this
thing
model,
but
like
how,
when
things
are
done,
you
should
probably
need
to
define
in
a
spec,
or
at
least
there
needs
to
be
a
section
in
spec
where
it
says
what
kind
of
security
mitigation
needs
to
be
done
like
it's,
not.
Okay,.
E
G
K
K
But
I
think
it
would
be
yeah
I'm,
just
trying
to
think
of
I.
Think
the
the
big
concern
that
we
have
here
beyond,
like
a
philosophical
like
sort
of
like
same-origin
policy
like
nice,
for
your
second,
all
cases
like
like
what
actual
attacks
are
possible
with
this
and
how
we
can
like
guarantee.
We
mitigate
those
like
I,
can
imagine.
Most
of
those
are
involving
key
events
where
you
listen
to
say,
like
the
length
of
users
password
which
doesn't
seem
very
likely
with,
since
those
will
be
dispatched
based
on
focus,
not
here.
Testing
I.
G
Like
any
security
program
we
may
have,
we
can
just
simply
at
API
in
a
hope
for
the
best
that
it
won't
pose
a
new
problem
there.
Every
security
possible
every
possible
new
security
cell
first
needs
to
be
very
carefully
studied,
and
unless
we
can
be
sure
that
there's
no
new
security
problem,
we
can
have
such
an
API.
H
H
G
H
A
Maybe
it
like
I
think
a
good
first
good
step
would
be
to
render
the
discussion,
but
was
already
had
public.
If
we
can
do
that
and
then
it
would
be
great
if
Apple,
folks
and
Mozilla
folks
would
be
able
to
review
that,
and
given
your
browser,
architecture
and
security
concerns
see
if
you
know
what
what's
your
opinion
regarding
the
API
security
does
that
we
asking
and
also
Benjamin
I
mean.
G
A
K
K
I
think
that
the
security
guarantee
seems
reasonable.
Obviously
we
should
dive
into
this
more,
especially
with
some
of
the
data
from
the
Chrome
security
bug,
but
we're
doing
hit
testing
based
on
what
the
user
sees,
which
I
believe
is
like,
in
my
opinion,
at
least
closest
to
what
the
user
intended
in
the
first
place.
K
H
K
A
I
guess,
in
my
view,
I
agree
with
your
statement
that
the
head
testing
done
at
is
in
the
pending
time
is
probably
more
accurate
than
the
head
testing
done
later
on.
If
frames
have
moved,
mm-hmm
I
would
expect
the
browser
to
not
dispatch
anything
in
case
that
those
two
are
different,
because
it
means
that
the
user
yeah,
the
the
first
one,
is
closer
to
the
user's
intent
and
the
second
one
is
probably
not
what
these
are
intended
to
do
so
I
mean.
G
Time
when
hit
this
thing
happens,
browser
to
then
like
it'll,
be
insane
to
like
once
he
went
to
the
end
road
process
to
realize.
Oh
wait,
I'm
gonna
hit
this
thing.
Nice
tap
on
the
render
one
is
this:
we
will
send
it
to
render
one
right.
That's
just
an
probably,
never
gonna
happen.
So
why
isn't
that
always
the
case
like?
Why
can't
we,
at
the
time
when
the
browser
process
is
whatever
the
the
thing
that
decides?
Which
frame
is
get
the
event?
A
H
K
G
H
See
or
the
option
that
you
have
suggested
as
well,
it
could
be
feasible
that
you
hit.
It
keeps
a
hip
the
hit
testing
afterwards,
but
if
it
provides
a
different
result
from
the
one
doing
is
impending
then
you're
like
well
I,
don't
know
which
is
target.
So
you
end
up
just
changing
and
not
doing
anything
about
the
event.
Both
could
be
solutions
to
the
problem
that
you,
the
frame,
is
getting
information
that
shouldn't
be
getting
ready.
Yeah.
K
G
G
After
yep.
K
K
G
The
one
one
thing
I
would
say,
though,
is
that
like
here?
What
we
really
need
is
like
a
multi
implementation
like
feedback
and
then
like,
because
the
browser
engine
tests
are
very
different.
Like
input
dispatching
mechanism,
we
really
need
to
have
the
feedback
from
us
as
well
and
I.
Think.
Maybe
we
need
to
have
more
people
work
in
HTML
and
web
apps
working
group
involved
here.
I
think
who
may
not
have
all
the
experts
needed
just
in
path
working
there,
for
example?
G
Maybe
we
need
to
get
involved.
Somebody
from
CSS
working
group
right,
a
kadai
baron
from
was
there,
for
example,
met
perhaps
well
like
iMovie
Pavan
eating
something
like
I
need
that
talk
to
Simon
Fraser
who's,
also,
a
system
working
group.
They
take
a
look
like
so
maybe
move.
What
we
might
need
to
do
is
just
reach
out.
This
is
walking
group
and
you
know
see
what
they
think
about
this
issue.
A
A
K
No,
this
is
good
feedback.
We
yeah,
especially
with
speck
level,
constructs
like
this,
where,
like
the
UA,
doesn't
really
give
yet
that
much
freedom.
It's
important
to
make
sure
this
works
for
other
implementers
well
beyond,
like
Chrome
security
review,
so
yeah
that
sounds
good.
J
A
Mean
the
the
time
of
use
I
think
maybe
it
was,
can
you
take
an
action
to
figure
out
the
like?
If
we
can
render
the
Security
Review
public
yeah,
then
we
can
probably
file
an
issue
on
his
but
isn't
but
pending
saying
this
is
the
Security
Review
and
then
tab
there
Apple
and
the
folks
to
see
what
they
think
about
the
above?
K
We're
time
now,
I
guess
I
can
follow
up
on
some
of
the
later
changes
next
meeting
or
in
whatever
cross-functional
group
we
get
going.
Okay,.