►
From YouTube: WebPerfWG call - July 30th 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
being
recorded
and
will
be
posted
online,
starting
off
with
a
few
administrative
things.
So
nick
can
you
scribe
or
yep.
I
have
started
okay,
awesome,
thank
you
and
with
regarding
the
next
call,
it
will
be
on
august
13th
so
same
time.
As
always.
A
If
this
is
a
particular
issue,
please
let
me
know
and
yeah
we'll
figure
something
out
otherwise,
there's
the
subject
of
tpack.
Last
on
the
last
call,
we
had
a
survey
basically
asking
folks
which
week
works
best
for
them
and
the
result
for
that
is
that
week
of
october
19th,
if
I
will,
if
I
remember
correctly
so
the
week
that
just
precedes.
A
A
So
it
was
a
hundred
percent
yesterday,
but
now
I
see
that
one
of
the
people
can
make
it
this
week,
but
it's
still
significantly
better
than
other
weeks,
so
we'll
go
with
that
and
otherwise
we
also
talked
about
scheduling
a
couple
of
online
half
day
hackathons
before
tpack.
A
The
current
plan
is
to
do
that
during
september,
under
the
assumption
that
august
is
complicated
for
many
folks,
so
I
will
send
out
details
on
exactly
when
that
would
happen
to
the
mailing
list
and
folks
could
then
let
me
know
whether
or
not
they
can
join.
A
A
Oh
good
question,
so
we
were
thinking
of
a
three
hour
like
three
hour
slots
for
four
days
during
that
week,
so
in
terms
of
time
zones
it
seems
that
this
time
of
day
is
the
most
compatible
wood
folks,
because
we
have
people
in
time
zones
ranging
from
israel
to
pacific,
so
basically
an
hour
before
and
an
hour
after
this
slot,
so
9
a.m.
Till
noon.
A
A
A
D
And
yo
would
you
want
to
set
out
some
meeting
invites
soon-ish
now
that
we've
picked
the
date
just
to
make
sure
you
lock
them
down
on
people's
calendars?
Yes,
I
will
do.
C
And
I'm
updating
the
wiki
page
to
indicate
that
as
well.
Our
intent
still
flag
has
tentative,
but
at
least
our
intent
is
documented.
Yeah
cool.
A
Thank
you
cool
and
with
that
out
of
the
way
we
can
dive
into
issue
triage
so
seems
like
we
accumulated
a
bunch
of
issues.
I
put
them
today
on
the
agenda
and
we
can
start
working
through
them
one
by
one.
I
don't
think
they
have
like.
We
have
any
particular
priority.
F
A
Well,
okay,
so
can
you
see
my
screen.
E
I
think,
if
I
recall
the
context
for
this
one,
it's
less
about
resetting
observers
and
more
about
resetting
the
metrics
themselves.
If
that
makes
sense,
I
think
the
specific
context
was
single
page,
app,
navigations
or
other
type
apps
where
they
want.
You
know,
events
that
hire
the
fire
only
ones
per
page
load
or
things.
So
this
is
part
of
the
longer
like
spa
navigation
story,
about
having
like
next
contentful
paint
and
and
next
first
input
type
stuff.
A
A
Cool
so
yeah.
In
that
case
we
can
move
on
to
the
next
one,
which
is
228.
A
Oh
no,
that
is
no
performance,
timeline,
169.,
sorry,
and
that
is
nick.
D
Yes,
so
this
one
came
out
of
the
discussion
we
had
last
time
about
a
month
ago,
where
we
had
talked
briefly
about
determining
a
way
to
determine
if
the
resource
timing
buffer
was
full
when
you're
querying
it
or
if
it
had
been
filled
up
for
some
reason,
nicholas
pointed
out
some
good
questions
around
it.
One
of
the
and
sorry
I
haven't
gotten
back
to
you
yet
nicholas
one
of
the
questions
was
around.
Is
this
something
that
we've
seen
in
the
wild?
D
In
particular,
we
saw
this
for
resource
timing.
Mostly
you
know
when
it
was
when
we
originally
had
the
150
default
resource
timing
limit.
D
We
were
seeing
this
more
frequently
we're
seeing
it
slightly
less
frequently
now
that
it's
the
default
limit
has
been
raised
to
250.,
but
just
in
general,
especially
as
we
keep
on
adding
more
and
more
types
of
things
that
we're
buffering
and
able
to
get
at
the
timeline.
It
seems
like
a
decent
idea
to
be
able
to
try
to
know
if
the
buffer
is
full
for
any
reason
and
there's
a
question
around
what
the
best
signal
would
be
to
know
whether
it
was
full
and
I
don't
have
a
strong
preference
there.
B
Yeah
anyone
have
thoughts
on
whether
well
first,
if
it's,
if
there's
any
objections
to
exposing
this
and
second
like
any
opinions
on
the
api,
shape
the
right
api
shape
to
expose
it,
it
seems
something
that
would
be
simple
to
expose.
Assuming
you
support
the
buffered
flag
mechanism,
it's
just
a
matter
of
finding
the
right
way
to
do
it.
D
A
Resource
timing,
fires
an
event
when
it's
full,
which
somewhat
misses
the
point
here,
because
if
you
can
register
an
event
you
would
have
registered
like
would
have
read
the
buffer
earlier.
So
I
don't
think
that
that
pattern
would
work
here.
D
Yeah
having
the
whole
observer
and
being
able
to
pass
a
buffered
true
flag,
is
you
know
where
we
want
to
operate?
We
want
to
that's
the
point
on
the
page
that
we're
gonna
that
we're
gonna
be
in
we're,
gonna,
be
calling
it
so
whether
it's
part
of
that
callback
or
just
another
api
that
we
could
use
at
the
same
time
would
be
both
of
them
would
be
reasonable.
A
I
have
a
slight
preference
to
the
third
parameter
option,
so
adding
an
extra
parameter
to
the
callback
not
being
the
list
itself,
but
something
that
indicates
whether
the
buffer
was
full
or
not,
and
I'm.
Similarly,
assuming
that
it
would
be
backwards
compatible
because
people
don't
read
that
third
parameter
and
expect
it
to
be
null.
Hopefully,.
A
Does
that
make
sense
for
folks
or
anyone
with
strong
opinions
to
the.
B
B
Yeah
yeah,
but
yeah
having
a
complex
object
inside
an
interface
is
probably
preferable
than
inside
the
parameter
of
the
callback.
A
But
potentially
I
wonder
if
we
could
like,
if
compressing,
that
information
to
a
single
boolean
would
be
enough.
So
if
any
of
the
types
that
were
observed
exceeded
their
buffers,
this
is
true
kind
of
like
it
gives
us
less
information,
but
maybe
maybe
it's
sufficient
information
and
what?
What
do
you
think
nick.
D
In
general,
the
way
that
we're
consuming
the
performance
timeline
is
generally
we're
asking
for
one
specific
type
at
a
time,
so
we
create
different
observers
for
different
types
and
because
different
components
to
it.
So
that
would
work
for
us
because
we're
only
ever
asking
for
a
single
one
at
once.
Usually,
I
guess
there's
an
edge
case
there
of
or
a
counter
case
there
of.
I
think
the
paint
timing,
events
and
the
I
forget,
which
ones
but
like
paint,
timing
and
largest
intentional
paint
are
two
different
types,
but
those
are
only
single.
D
B
B
I
don't
know
yeah,
it
doesn't
quite
work
for
paint,
timing
and
lcp
in
the
same
observer,
because
at
least
for
chrome,
you
would
get
first
paint
and
first
content
for
paint,
and
that
means
the
paint
timing
buffer
is
full,
so
you
will
get
the
bullion
being
true,
whereas
the
lcp
buffer,
which
is
the
one
you
really
care
about,
is
not
full.
I
mean
we
could
make
exclusion
for
yeah.
A
A
So
remaining
size
is
like
I
would
go
with
just
the
like.
If
we
were
to
go
that
route,
then
yes,
a
completely
separate
api
that
just
gives
you
the
buffer
sizes
which
are
completely
static,
and
then
you
can
check
for
yourself
if
any
of
the
entries
you
care
about,
has
run
up
against
those
sizes.
But
you
still
can't
know
if
you
can't
know
if
it
was
like.
I
guess
what
you're
interested
is
not
if
the
buffer
is
full,
but
if
something
was
dropped
from
the
buffer
right.
D
A
A
Yeah
so
giving
you,
the
buffer
sizes,
won't
help
but
yeah,
but
you
can
basically
observe
any
like
you
can
get
a
signal
on
any
dropped.
Entry
and
presumably
like
maybe
one
bullion
is
sufficient
so
that
you
could
basically
try
to
register
your
observers
earlier
or
complain
to
browsers
to
have
larger
buffers
or
both.
A
Any
thoughts
from
other
folks
who
collect
performance
entries
or
mozilla
folks.
Alternatively,
I
you
don't
yet
like.
Would
that
impact
your
implementation
for
the
buffered
flag
or
what?
What
are
your
thoughts
in
general
on
that.
B
B
A
A
So
yeah,
in
that
case
we
can
move
on
to
resource
timing,
228.
A
Which
is
opened
by
noam
who's
not
around
this
evening,
but.
A
Essentially,
if
I
try
to
summarize
it,
it's
like
right
now,
timing
allow
origin
either
requires
you
to
say
this
resource
is
fine
to
expose
timing
for
for
anyone
or
to
write
down
a
list
of
urls
that
you're
comfortable
with,
but
because
it
doesn't
require
cores
in
any
way.
You
don't
have
guarantees
that
you'll
have
the
origin
header
and
as
a
result,
and
as
a
result
of
that
and
as
a
result
of
refer
policies
that
may
omit
the
host
altogether.
A
A
And
noam's
argument
is
that
this
scenario
would
result
in
people
writing
down
a
list
of
all
possible
embedders
for
this
resource,
which
can
potentially
leak
data,
not
necessarily
in
a
web
context,
because
that
data
is
not
web
exp
or
it
could
be.
If
it's
fetched,
for
example,
so
a
fetch
call
would
have
access
to
those
headers.
No,
that's
not
true,
because
it
won't
be.
It
would
be
an
impact
response,
so
yeah.
A
From
my
perspective,
like
noam's
argument
is
that
it
can
like.
Maybe
we
should
move
timing,
allow
origin
to
a
model,
that's
closer
to
corp
rather
than
chords,
so
that
we
don't
necessarily
specify
an
origin.
Just
say
this
is
okay
or
not.
Okay,
to
embed
I'm.
A
I
think
that
this
is
like
I.
A
This
is
a
complex
question
that
would
require
some,
probably
cross-working
group
thinking
with
the
web
upset
folks
but
yeah.
I
thought
we
should
just
mention
this
issue
to
see.
If
folks
have.
B
Opinions,
one
mitigation:
we
could
do
right
now
not
really
a
mitigation
but
like
pointing
out
this
potential
problem
in
the
spec.
As
a
non-normative
note
that
you
should
be
careful
about
the
timing,
origin,
header,
exposing
this
information
and
saying
it
may
be
reasonable
for
your
server
to
expose
a
different
header
depending
on
the
origin
header
value.
If
such
header
value
is
provided
or
also,
if
it's
not
then
as
well
like,
I
don't
know
how
feasible
that
is
or
how
much
it
would
actually
help
people.
But.
A
B
A
A
We
definitely
need
to
figure
out
a
way
in
which
all
these
different
opt-ins
work
together
and
try
to
make
sure
that
they
play
nicely
together
but
yeah.
This
is.
A
It
requires
yeah,
it's
probably
a
good
subject
for
a
focused
tpack
discussion
with
those
folks
in
the
room
as
well.
A
So
I
can
and
nick,
if
you
can
put
me
down
for
an
action
item
on
actually
summing
that
up
on
the
issue.
A
Thanks
next
up,
we
have
page
visibility,
59.
A
The
specs
definition
of
hidden
is
unclear
and
should
be
updated
to
better
account
for
removal
use
cases.
This
is
something
we
already
discussed,
but.
A
Bring
it
up
here,
okay,
so,
yes,
we
discussed
this
issue
yeah
on
january
30th,.
B
One
issue
is
lack
of
ability
to
test
visibility,
changes
in
our
platform
tests
because
it's
not
really
possible,
but
we
should
probably
agree
on
the
desired
behavior.
Did
we
do
that
already.
A
I
A
I
yeah
so
the
question
is
for
those
tab,
switchers.
What's
the
top-level
browsing
context,
that's
the.
A
I
I
guess
for
me
it's
like,
I
feel,
like
the
one
of
the
questions
in
this.
This
issue
is
if
we
have
a
page
that
is
visible
and
create
a
snapshot
of
it
and
put
it
on
one
of
these
tab
trays.
Is
that
page
considered
visible?
I
and
I
I
I
just
don't
understand
how
this
fits
into
a
top-level
russian
context
and
an
active
page
so.
B
A
I
I
think
I
agree
that
a
snapshot
is
not
active.
I
think
that
it's
also
what
we're
like
what
phil
is
suggesting.
A
I
G
B
B
So
it's
it's.
Basically,
you
have
a
one
browsing
tab
open
in
your
mobile
browser
and
then
you
click
on
the
tab
number
at
least
that's
our
working
group
and
then
it
shows
like
it
zooms
out
to
let
you
switch
tabs,
and
so
the
question
is
as
soon
as
you
soon,
like
click
that
to
switch
your
tabs,
should
the
page
be
considered
backgrounded
for
the
purpose
of
page
visibility,
and
I
think
what
we're
saying
is:
yes,
of
course,
yeah
and
I
think
there's
no
disagreement
there.
I
A
Oh
yeah,
I
think
that,
because
of
the
questions
you're
asking
so
like
once,
you
switch
to
this
tab
like
tab,
switching
context,
you
no
longer
have
a
top-level
document,
like
all
documents
are
inactive
in
a
way.
Okay,.
I
So
so
that
is
the
case,
there
is
no
top-level
document.
I
believe
so
yeah
I'd
be
clear,
that
that
would
be
helpful
for
me.
I
do
agree.
I
agree
with
that.
I'm
just
saying
like
I
don't
see
any
wording
anywhere
that
that
defines
that
to
be
the
case.
B
B
Yeah
the
tab,
searcher
is
not
a
it's,
not
a
web
page
at
all.
It's
so
there's.
No,
there's
no
context
there.
It's
just
okay
browse
user
agent,
specific
implementation.
So
maybe
that's
why
we
understand
your
question.
There.
A
Okay,
yeah,
but
if
you're
looking
for
specific
language,
that
would
be,
you
know
specific
language
that
defines
that
that
would
be
a
great
place
to
add
that,
because
this
is
what
the
yeah
this
issue
is
about,
adding
that
language.
So
if
you
have
any
specific
preferences,
there
would
be
great
if
you
can
comment
on
the
bug.
A
A
Okay,
so
maybe
the
action
item
here
is
that
benjamin
would
comment
and
then
we
can
continue
the
discussion
on
the
blog
sure,
okay,
cool.
Thank
you.
A
A
Marcos,
caceres
has
issues
with
us
calling
document.hidden
historical,
basically,
because
there
is
no
reasonable
path
for
us
to
actually
deprecate
and
remove
it.
Remove
it.
A
I
personally,
I
don't
have
context
on
when
this
historical
reference
was
added.
I
think
it
was
a
while
ago,
but
is
there
a
general
policy?
Maybe
philippe?
You
have
opinions
here
on
general
policies
regarding
calling
things
historical
and
discouraging
developers
from
using
them,
even
though
we
have
no
reasonable
path
for
deprecation,
because
I
think
we
also
have
a
similar
situation
with
the
navigation
timing
level.
One.
C
I
C
B
Well,
the
other
thing
is,
I
think
we
wanted
our
past
performance.
People
wanted
to
deprecate
hidden
because
there
was
there
were
three
visibility
states,
but
now
there's
only
two
at
the
moment.
So
it's
it's
not
even
clear.
The
benefit
right
now
of
deprecating,
the
bullion
hidden,
in
my
opinion,
right.
A
Potentially
beneficial
to
have
just
one
way
to
query
for
that
data
rather
than
two
that's
fair,
but.
B
A
Yeah,
I
I
will
yeah.
I
was
just
wondering
if
there
was
a
general
w3c
policy
of
this
being
okay
or
not.
Okay,
that
I
could
point
marcos
ii,.
A
Cool
okay,
so
I
can
take
an
action
item
to
respond
on
that
bug
and
yeah
start
a
discussion
regarding
the
helpfulness
of
this
being
historical
or
not.
A
Cool
otherwise
we're
at
one
is
page
visibility,
65
republish
spec.
So
that's.
B
A
I
don't
like
my
understanding
is
that
they're
not
blocking
republishing
as
pr
they're
blocking
progress
but
beyond
pr,
but
not
necessarily
republishing,
is
that.
C
I
think
we
should
go
back
to
cr
because
the
pr
was
published
a
long
time
ago
and
we
never
managed
to
make
it
to
accommodation.
So
my
advice
is
we
go
back
to
cr
and
and
when
we're
ready
to
actually
move
to
the
new
rank,
we
would
basically
move
back
to
proposal
communication,
assuming
we
still
want
to
move
it
to
proportion
recommendation
at
some
point.
C
Other
solution
is
to
to
move
to
cr
and
then
make
it
a
living
standards
and
and
yeah
and
be
done
with.
B
C
B
C
Maintain
two
branches:
at
the
same
time,
correct.
If
we
go
back
to
cr,
we
can
still,
we
would
be
allowed
to
add
new
features
as
needed
and
stuff
like
that
anyway.
So
and-
and
as
I
don't
think,
we
need
to
block
on
you
doing
your
edits,
because
as
soon
as
you
did
your
medics,
we
can
also
republish
as
well.
A
Yeah,
but
if
nicholas
were
to
add
because
right
now,
test
wise,
this
is,
I
believe,
good
to
go
or
almost
good
to
go
and
if
we'll
now
add
new
features
that
will
add
a
significant
delay
as
implementations
catch
up.
So
from
my
perspective,
it
would
have
been
better
to
do
that
as
part
of
l3.
At
the
same
time,
if
this
would
be
a
significant
delay,
then.
A
Ideally,
I
would
love
to
publish
a
wreck
for
l2
and
then
turn
l3
into
a
living
standard.
Probably
okay
requires
people
to
be
on
board,
but
that
is
where
I
would
love
to
see
things
go.
E
C
To
see
if
we
want
to
backport
anything
but
yeah,
I
would
strongly
advise
not,
to
put
you
know,
not
to
put
the
update
on
l3
in
in
on
hold.
Just
because
of
we
are
planning
to
l2.
We
can
put
l2
in
a
branch
and
keep
the
editor
off
to
be
the
main
l3
l3
branch
that
would
basically
match
living
what
would
become
the
living
standard.
C
A
It
will
create
some
extra
work
for
publishing
l2,
but
I
think
it
won't
be
awful
nicholas.
What
do
you
think.
B
E
These
two
issues
or
other
issues
as
well
these
so
so
one
of
these
is
trivial
and
has
just
been
landed
and
fixed.
So
48.
E
A
Yeah,
it's
basically
a
spec
health
change
right,
it's
not
imp,
not
it
doesn't
have
any
implications
on
implementations
or
on
tests.
So
I
guess
we
could
just
yeah.
We
can
spin
off
an
l2
branch
and
then
once
this
will
be
fixed,
we
can
decide
whether
we
want
to
backport
it
or
not
to
l2.
But
we
can
do
all
that
work
on
elf,
on
the
like
top
of
three,
which
will
be
the
l3
branch.
C
G
C
Yeah,
I
I
I
think
I
have
been
assigned
this
issue
for
quite
a
while.
I
just
need
to
be
poked.
I
A
Cool
and
now
a
series
of
issues
on
preload
that
we
can
discuss
we'll,
probably
not
get
through
all
of
them,
but.
A
Yeah
this
one
is
interesting,
so
the
title
is
not
great
in
a
way,
but
it's
basically
what
this
person
is
asking
for
is
to
have
a
way
to
have
a
group
of
pre-loaded
resources
so
that
they
can
define
multiple
ones
for
for
this
example
for
fonts,
so
that
they
could
say
if
you're
supporting
waff2
preload
this
resource,
if
you're
not
supporting
waft2,
but
you
do
support
download
this
one
otherwise
download
this
ttf
in
a
way
very
similar
to
the
pre
to
the
picture
element.
A
C
C
Font
name
or
anything
like
that,
so
you
know
when
you
have
a
font
in
css,
is
set
to
the
cs,
essentially
to
decide
whether
they
want
to
use
the
system
fonts
or
go
and
fetch
the
fonts
or
if
they
already
have
the
fonts
available.
For
whatever
reason
with,
I
don't
think
there
is
enough
information
in
the
current
proposal
to
allow
the
front
matching
algorithm
to
do
its
job.
A
A
The
browser
discovers
required
fonts
as
early
as
possible.
B
Right,
sorry,
without
loading,
all
three
of
the
different
types
is
that
the
problem
that
currently
they
would
just
load
all
three.
Yes,
it's
like
a
performance,
optimization
to
know
just
the
first
match
right
yeah,
I
mean
that's
very
reasonable.
We
just
have
to
find
a
way
to
be
able
to
do
that.
I
think.
A
Yeah
this,
this
is
not
something
that's
specific
to
css
or
fonts.
This
is
what
they're
suggesting
here
is
a
mechanism
to
basically
have
a
multiple
choice:
option
for
preload,
where
preload
can
pick
either
one
of
those
three
things.
I
think
that
this
is
not
like.
We
talked
about
this
problem
in
the
past
and
we
concluded
that
it's
not
like
it
doesn't
have
a
strong
enough
use
case
to
justify
the
complexity.
A
At
least
that
was
the
conclusion
for
picture.
I
think
that
for
fonts
it's
even
a
stronger
conclusion,
because
there
are
no
browsers
today,
that's
like
all
modern,
browsers
support,
waff2.
There
are
no
browsers
that
support
preload
and
don't
support
waff2.
A
So
this
is
rather
theoretical
at
the
moment,
at
least,
but
it's
an
interesting
angle
to
solve
this
problem,
but
not
a
feasible
one,
because
I
believe
that
all
tags
that
enable
like
all
the
tags
that
are
safe
to
include
in
the
head
are
also
self-closing
or
almost
all
of
them
style
and
script
aren't.
But
but
that
would
be
very
weird,
like
link
is
self-clothing,
so
we
won't
be
able
to
do
that,
but.
B
If
it
would
have
it's
feasible
and
just
to
clarify,
is
this
already
solved
for
images,
because
the
the
first
sentence
seems
to
be
about
images
and
I'm
confused?
Why
they
then
choose
to
focus
on.
A
Fonts,
I
don't
know
why
they
chose
to
focus
on
fonts
for
images.
It
is
partially
solved
it's
solved
for
source
set
where
there's
the
image
images
set
and
image
sizes
attributes
for
preload
that
enable.
A
Enable
you
to
specify
multiple
resources
and
have
the
browser
pick
them
in
a
way
similar
to
how
it's
picked
with
source
at
it's
not
sold
for
picture.
So
if
you
have
a
hero
element
that
varies
between
different
like
an
image,
you
want
to
preload
that
has
a
different
art
direction
and
different
crops
in
different
viewports.
A
This
is
not
something
you
can
preload
today,
and
I
was
thinking
that
maybe
we
could
like
initially
thinking
that.
Maybe
we
could
reuse
that
solution
for
that
problem,
but
it
doesn't
seem
like
it's
a
workable
one.
A
A
A
The
main
question
is:
should
link
header
processing
for
preload
be
defined
in
the
preload
spec
or
somewhere
else,
with
a
more
like
with
a
broader,
broader
perspective,
because
yeah
from
my
perspective,
I
it
feels
more
like
an
html
like
something
that
should
be
defined
in
html
with
regard
to
which
relations
support
or
don't
support,
link
headers
and
which,
like
whether
link
headers,
should
work
on
sub
resources
or
navigations
and
all
those
questions
that
keep
popping
up
and
are
not
really
specified,
and
none
of
that
seems
preload
specific.
A
Oh
and
we're
at
time
so
does
that
make
sense
for
folks,
let's
just
wrap
this
one
up
quickly.
Does
that
make
sense
to
just
comment
that
this
is
probably
better
defined
in
html
and
not
something
that's
preload
specific.
B
A
Yeah
cool,
then
I
will
do
that
awesome.
So
thanks
all
well,
we
made
quite
a
good,
quite
good
progress
on
going
over
various
issues,
and
I
will
see
you
all
in
a
couple
weeks.
Cool
thank.