►
From YouTube: WebPerfWG call January 7th 2021
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,
the
meeting
is
being
recorded
and
will
be
posted
online.
Welcome
to
the
web
performance
working
group
2021
edition
happy
new
year,
everyone
on
today's
agenda.
We
mostly
have
a
discussion
around
the
measure,
memory,
measure,
memory,
measurement,
api
and
then
a
bunch
of
issues
to
triage
or
check
on
that.
We
have
left
from
most
of
them
left
from
last
year
for
the
next
call
we're
planning
on
january
january
21st
same
time
as
today.
A
If
this
is
a
problem,
please
let
me
know
offline
and
we'll
try
to
figure
out
an
alternative
time.
I
also
need
to
reshuffle
the
meetings
because
we're
now
now
one
week
offset
compared
to
the
original
schedule
due
to
the
holidays.
A
Otherwise,
one
more
administrative
point
that
I
wanted
to
mention
is
that
I
started
to
look
into
the
field
of
client-side,
a
b
testing
and
it's
performance
problems,
and
it's
something
that
I
think
has
a
lot
of.
There
are
a
lot
of
issues,
there's
also
a
lot
of
misunderstanding
between
the
different
sides
in
the
different
stakeholders.
So
this
is
something
that
I'm
planning
to
run
a
working
group
open
meeting
on.
A
I
don't
yet
have
a
clear
date,
ideally
I'd
love
to
run
it
within
like
in
a
month
or
so.
I
still
need
to
talk
to
various
industry
folks
and
see
which
of
them
can
join
us
for
that
meeting.
A
But
just
as
a
heads
up,
I
would
love
to
run
such
a
meeting
early
february
either
as
like
a
replacement
for
our
regular
call
time
or
as
an
extended
call,
maybe
for
two
or
three
two
or
three
hours
call
depending
on
the
agenda
that
will
form
and
with
that,
let's
talk
about
the
memory
measurement.
Do
you
want
to
present.
B
B
They
are
inherently
user
engine
specific
and
cannot
be
compared
between
different
browsers
right
and
but
the
naming
doesn't
reflect
that
and
we've
got
that
this
feedback
from
mozilla
fox-
and
this
is
an
issue
in
our
repository
and
yeah-
and
today's
discussion
is
about
that.
Should
we
stress
in
the
name
that
the
bytes
returned
a
user
agent
specific
or
can
we
do
that,
and
here
are
some
options
like
the
option?
B
A
is
to
keep
the
current
naming
scheme
like
assuming
that
it
is
clear
that
the
bytes
are
user
agent,
specific
and
maybe
interesting.
Detail
here
is
that
the
memory
measurement
api
will
is
enabled
only
in
cross-origin
isolated
contacts.
B
Should
we
set
the
name
user
agent,
specific
string
in
the
name
of
the
function
or
put
it
into
the
fields
so
that
that's
that's
the
main
questions
and
then
the
options
are
ordered
in
order
of
my
preference,
like
I
slightly
prefer
option
a,
but
I
think
option
b
would
be
also
okay.
C
C
Could
I
ask
maybe
the
the
group
I
don't
have
enough
historical
background?
Have
we
had
this
question
come
up
in
other
contexts
where
any
performance
measure,
while
the
api
could
be
the
same
and
the
the
meaning
could
be
the
same,
the
actual
results
could
be
quite
different
across
implementations.
C
A
I
recall
us
having
that
discussion
and
that
kind
of
naming
before
I
don't
remember
specific,
like
the
specific
example
and
where
we
landed
on
that.
A
But
it's
it's
a
good
point
that
we
should
maybe
look
at.
A
Presidents
from
the
past
and
try
to
align
with
that.
A
Do
need
to
outline
that
it's
yeah
that
the
result
is
ua
specific
but
yeah.
I
don't
have
a
strong
opinion.
Whether
b
or
c
is
preferred.
D
So
so
what
we're
trying
to
to
do
for
brc,
something
like
the
css
prefix,
you
know
when
we
used
to
have
dash
webkit
dash.
Is
that
what
we
are
talking
about.
A
Not
as
far
as
I
understand
it
because
dash
webkit
was
vendor-specific,
this
is
not
vendor-specific,
it's
just
that
the
result
can
vary
among
different
uas
and
different
implementations.
So
the
api
is
the
same
for
everyone.
It's
just
that
the
result
may
be
different.
We
want
to
avoid
developers
comparing
one
to
the
other
and
saying
browser
x
is
better
at
memory
than
browser
y
on
that
front,
because
that's
not
necessarily
a
fair
comparison
that
people
should
do.
D
A
B
I
think
so
far
the
performance
apis
were
mostly
about
time
like,
for
example,
performance.
Don't
now
is
also
user
agent
specific.
But
since,
if
every
invocation
of
that
changes
there
are
not
so
many
risks,
whereas
with
memory
like
it's
kind
of
another
dimension,
but
it
the
risk
is
that
memory
could
be
more
stable
than
time.
So
then
users
may
be
misled
to
believe
that.
C
Yeah,
but
my
understanding
as
one
past
example,
is
that
I
I
believe
in
webkit,
first
paint
is
delayed
until
there
is
contentful
content,
and
so
the
the
actual
meaning
behind
the
first
paint
is
a
little
bit
different
than
on
other
platforms.
So
while
the
api
might
be
the
same
and
the
thing
the
numbers
are
not
directly
comparable
and
so
to
me,
it
seems
like
existing
precedence
that
you
know
the
definitions
or
things,
but,
like
things
are
rarely
directly
comparable.
C
I
could
see
why
memory
is
a
little
bit
more
sensitive
just
because
of
just
how
much
gets
measured
and
how
different
the
scope
could
be,
and
so
this
seems
like
a
lightweight
way
to
address
that
concern
by
just
like
making
it
super
obvious
and
hinting
at
there's.
There's
more
that
needs
to
be
looked
into
so
same
option
b
seems
very.
B
There
was
one
concern
raised
with
option
b,
and
the
issue
is
that
if
we
go
with
this
route
of
adding
ui
specific
string
in
the
name,
there
may
be
other
apis
that
appear.
That
also
start
adding
this
string.
E
Or
so
the
question
I
want
to
ask
about
this
is
the
goal
is
to
avoid
web
compatibility
errors
right,
so
it's
to
avoid
javascript
developers
taking
a
dependency
on
one
specific,
uas
implementation,
and
originally
this
came
up
because
we
had
the
user
agent
specific
types
array
in
this
api
right.
E
So
the
idea
is
that
you
know
a
developer.
Might
do
user
agent
specific
dot,
find
you
know
looking
for
like
window
right.
E
Something
and
that
would
cause
you
know,
a
null
error.
So
with
this
one,
it's
a
it's
a
little
less
clear
to
menia.
E
What
like
a
web
can
what
what
a
webcompat
bug
would
actually
look
like
in
this
situation
like
would
it
be
like?
Would
it
be
a
web
developer
like
reading
the
amount
of
bytes
and
then
checking,
if
that's
less
than
or
greater
than
some
number
and
then
just
guessing?
Aha?
Okay,
so
you
know
I'm
going
to
go
into
low
memory
mode,
I'm
going
to
go
into
high
memory
mode.
So
I
guess
the
question
is
like
how
likely
that
is,
or
if
you
know,
developers
already
have
some
kind
of
intuition
that
you
know
hey
this
device.
E
E
B
B
So
the
main
use
case
is
to
collect
telemetry
data
and
then
detect
regression
absolutely
like
this.
That
aggregated
results
are
meaningful
and
individual
results
are
less
meaningful.
G
Yeah,
so
it
doesn't
seem
like
there's
any
special
considerations
of
this
api
compared
with
like,
if
you're
tracking
pain
timing
and,
like
all
browsers
that
support
it
right
like
it
doesn't
seem
to
me
like
there's
like
it's
worth,
buttering
the
name
with
ua,
something
that
I
don't
even
know.
If
developers
understand
what
ua
means
in
general
like
like
it,
it
doesn't
seem
to
me
like
another.
G
Right
right
and
then
the
name
just
becomes
super
duper
ultra
long
right
like
so
I
personally
I'm.
I
would
agree
that
option.
A
is
like
that's
what
I
would
go
with,
but
it
might
be
worth
hearing
from
other
user
agents
in
the
call
what
if
they
think,
that's
reasonable
as
well.
I
C
Yeah,
like
nolan,
said
that
there
was,
I
guess,
an
alternative
or
past
version
where
you
literally
needed
a
large
switch
statement
to
make
sense
of
the
results
based
on
the
ua,
and
then
that
would
make-
and
it
sounds
like
that's
not
the
case.
This
is
literally
just
forcing
documentation
to
be
read
at
each
call
site.
G
A
Yes,
so
the
main
concern
is
that,
like
when
interpreting
the
results,
people
will.
A
Do
things
like
yeah
compare
the
numbers
in
places
where
they
shouldn't
yeah?
I
guess
I
can
see
that
yeah
that
problem
potentially
can
be
addressed
elsewhere
and
not
necessarily
in
the
function
name
just
by
you
know,
having
proper
become
documentation
which
warns
people
against
those
kind
of
patterns
and
yeah,
and
as
nolan
stated,
there
is
no
real
web
compat
risk
associated
with
that
behavior.
It's
just
an
understanding
problem
right.
F
Well,
I
guess
personally,
I
prefer
b
because
because
I
I
think
for
other
performance
timings
like
sometimes
we
do
use
them
to
compare
between
different
browsers
for
their
performance,
like
performance
like
first
contentful
paint,
so
they
also
even
even
though
like
sometimes
it
might
still
be
like
ui
specific,
but
we
still
use
them
like
to
compare
the
numbers
and
see
if
there's
a
huge
difference
between
them.
F
A
I
I
G
So
yeah
this
may
be
a
thing
where
we
just
need
a
better
developer
outreach
from
like
people
that
are
in
charge
of
those
things
right
like
it
seems
like
adding
user
agent
specific,
might
help
some
people
in
like
understand
that
it's
your
surgeon
specific,
but
I
I
still
think
a
lot
of
people
would
not
even
understand
what
that
means,
and
they
would
just
still
use
it,
especially
the
kind
of
people
that
are
likely
to
just
aggregate
all
the
values
across
all
user
agents.
Right.
J
A
Yeah,
is
there
an
issue
open
on
on
that
front?
Oh,
can
you
maybe
link
to
that?
It
will
link
it
here.
Okay,
so
is
she
11.
A
A
F
A
Okay
yeah,
so
maybe
it's
worthwhile
to
like
note
the
like
the
group's
preference
in
the
meeting,
but
then
let
folks
who
have
strong
opinions
give
them
a
few
more
weeks
to
weigh
in
in
case
there
are
strong
arguments
in
favor
of
b
or
c.
H
A
A
Yeah,
so
let's
continue
on
to
talk
about
issues.
First
up
we
have
issue
51
from
page
visibility.
Let
me.
A
A
Okay,
so
this
is
an
issue
we
already
discussed
multiple
times.
I
think
we
had
a
good
path
forward
towards
closing
it.
C
Yeah,
I
think
there
is
a
very
good
plan
listed
there.
I
just
haven't
had
the
time
to
poke
at
it.
I
still
would
like
to
to
get
this
one
done.
So
there's
no
concerns
and
I
think
the
the
outline
is
good
just
a
matter
of
putting
the
time
in.
A
Okay,
cool,
okay,
so
not
a
whole
lot
to
discuss
here.
Yeah,
just
yeah
need
to
try
to
nudge
that
along
and
then
the
next
like.
Do
you
have
any
like?
A
I
don't
know
in
terms
of
timeline
or
we
can.
We
can
discuss
that
later.
Yeah.
The
next
issue
with
page
visibility,
is
the
one
that
david
broken
opened
as
a
result
or
right
before
yeah.
A
We,
we
discussed
this
on
the
on
the
call
last
month
and
essentially
I
believe
that,
where
he
landed
during
the
call
we
decided
to
yeah
to
bring
the
hour
during
the
call,
we
decided
that
he
will
run
an
analysis
on
the
various
states
and
then,
where
he
landed,
is
on
adding
an
orthogonal,
document.uh
pre-rendering
flag,
or,
I
guess,
and
and
then
became
disposable
event.
A
A
Like
should
this
be
wrapped
up
into
page
visibility,
or
is
this
something
that
goes
beyond
that
and
should
go
into
html
directly
and
then
other
than
that?
I'm
wondering
if
any
like
folks
from
apple
or
mozilla
have
had
a
chance
to
look
into
that
and
have
thoughts
about
this
proposal.
G
A
Otherwise,
have
folks
had
a
chance
to
look
at
that
and
form
opinions.
F
Okay,
yeah
I'll,
take
a
excito.
A
A
Yeah
another
issue,
the
next
issue
on
the
list-
resource
timing-
239,
that's
one
that
was
recently
opened.
A
What
that
means,
but
maybe
we
can
just
you
know.
A
A
And
a
start
event:
oh
okay,
I
think
I
get
it.
It's
not
really
related
to
resource
timing,
but
get
an
event
whenever
a
resource
started
fetching.
I
think
this
is
the
future
request.
I
Yes,
yeah
so,
and
we
have
another
open
issue
like
this,
which
is
like
the
the
fetch
observer
kind
of
set
of
issues.
Yeah.
A
Yeah,
so
maybe
we
can
just
fold
this
one
into
the
other
open
issue
and
yeah.
That
sounds
reasonable.
A
A
So
yeah
nick
will
you
be
able
to
just
comment
on
this
one?
Yes
I'll,
take
this
out
and
try
to
figure
out
the
right
place
to
merge
into
awesome.
Thank
you.
A
A
Next
up
is
issue
237
for
resource
timing.
A
I
Vaguely
remember
this:
I'd
have
to
reread
it
over
again.
I
think
part
of
the
issue
was
that
they
in,
like
the
load
event
handler,
they
were
looking
at
the
time
stamp
of
a
resource.
I
Oh
man,
I'm
trying
to
remember
the
exact
specifics,
but
it
was
it
was.
I
think
it
was
due
to
the
fact
that
they
were
looking
at
time
stamps
in
the
load
event
handler
itself
and
if
they
just
waited
a
few
milliseconds
still
after
the
load
event
handler
was
complete.
The
math
that
they
were
trying
to
do
would
work
out,
but
I
don't
recall
if
that's
exactly
it
or
not,.
I
A
when
to
how
to
do
the
math
at
the
right
time,
question:
okay,
I
I
don't
think,
there's
anything
outstanding
here.
I
I
believe
we
had
between
nicholas
and
I
we've
answered
this
question.
We
could
probably
double
check
to
make
sure
that
he's
satisfied
with
our
response
and
then
close
it
up.
A
D
A
Cool
next
up
issue,
238.
A
I
And
yeah
I
would
agree
there
was
there
was
also
during
the
discussion.
Some
talk
about
just
removing
transfer
size
entirely,
and
we
were
going
over
like
what
were
the
use
cases
for
people
needing
that
versus
the
encoded
body
sizes,
decoded
body
sizes.
I
don't
remember
when
I
was
thinking
about
it
later,
if
we
just
discuss
the
fact
that
that's
the
only
way
to
detect
cash
status.
At
this
point.
A
Yeah,
I
I
don't
think
we
discussed
it,
but
I
think
that
is
a
valid
point,
but
it
might
be
worthwhile
to
just
you
know
expose
so
so
right
now.
I
think
there
are
two
different
states
that
this
exposes
beyond
just
the
you
know,
the
header
size
it
also
exposes
like
was
this
cached
and
heuristically.
A
A
Yeah,
if
we
were
to
remove
transfer
size,
it
might
be
worthwhile
to
expose
those
states
directly,
because
I
think
they're
already
like,
on
the
one
hand,
sniffable
and
at
the
same
time,
useful
from
analytics
perspective.
I
Yeah
we
yeah
for
impulse
for
our
really
user
measurement.
We
have
a
lot
of
charts
and
graphs
and
analysis
that
heuristically
look
at
the
cache
state
of
a
lot
of
resources
on
the
page,
so
we
depend
on
transfer.
Size
is
much
pretty
a
lot
for
that
particular
reason.
Yeah.
A
A
H
That's
a
great
question:
I
know
for
sure
that
we're
not
interested
in
exposing
the
pre-decryption
transfer
size
and
eliminating
cookies
from
the
transfer
size
seems
a
little
silly
to
me
because
it's
a
strange
calculation
of
the
transfer
size
of
something
that
we've
tried
to.
A
Yeah
and
with
regard
to
revealing
cash
state
and
cash
revalidation
state,
it
is
there
like
other
problems
with
that
in
a
double
keyed
double
triple
kid
world,
like.
A
So
so
yeah
so
generally,
if
I
hear
you
correctly,
you
would
prefer
removing
the
headers
all
together
and
then
we
can
separately
discuss.
A
The
like
exposing
cash
states
and
whether
this
entails
any
further
woes
that
we
are
missing
right
now.
F
Sorry,
I
don't
know
enough
to
comment
on
this
thing.
A
A
G
G
I
mean,
of
course,
well
yeah.
One
use
case
is
yes,
headers
big
headers
are
bad
for
performance,
but
I
I
think
I
also
agree
that
exposing
this
isis
it
it's
likely
gonna,
have
issues
and
not
just
with
this
problem,
but
some
similar
issues
in
the
future.
So
we
may
just
have
to
give
up
on
that
use
case.
A
A
That
makes
sense
yeah
the
main.
A
A
A
So
everything
was
fed
from
cash,
but
for
the
case
of
yeah,
so
either
like
fetch
from
the
network
or
fetch
from
cash.
But
for
the
case
of
304
revalidations,
they
will
have
like.
If
we
remove
the
headers,
they
have
a
length
of
zero
which
is
indistinguishable
from
local
validate
cash
hits.
A
A
Yeah
potentially
run
the
risk
of
breaking
that
kind
of
analytics
and
providing
an
alternative
and
carefully
nudge
people
towards
that
alternative
path.
A
A
It
is,
but
it's
potentially
solving
the
problem
I
mean
with
heuristics.
A
People
are
deploying
for
you
know
if
they're
doing
something,
that's
smaller
than
zero,
but
yeah,
but
if
we
return
a
fixed
size,
regardless
of
the
header
like
we
could
say,
yeah
that
that
may
be
a
good
solution
to
just
say:
okay
headers
are
300
bytes
and
that
could
enable
us
like
give
us
a
good
compat
path
forward
without
exposing
information,
and
then
we
can
figure
out
like
alternative,
like
you
know,
exposing
the
cash
state
directly
in
some
other
attribute.
A
Okay,
cool
next
issue:
we
have
performance
timeline,
issue,
100.
A
Yes,
I
can
take
an
ai
to
to
comment
on
yeah
on
issue
238
to
yeah.
To
summarize
that.
A
Cool
yeah
next
issue
performance
timeline,
issue
100.,
so
essentially,
this
is
just
a
checkpoint
to
bug
folks
about
a
couple
of
failing
tests.
So
generally
the
overall
tests
look
good.
There
are
a
couple
of
a
couple
of
failing
tests
in
both
firefox
and
safari
for
performance
timeline.
A
A
Alex
and
sean
it
would
be
great
if
you
could
take
action
items
to
have
someone
look
into
those
issues,
and
so
both
the
performance,
observer,
disconnect
removes
observed
types
and
the
supported
entry
types
test.
A
A
The
solution
is
not
as
simplistic
or
as
simple
as
we
would
necessarily
want
it
to
be.
A
Given
that,
maybe
it's
like,
maybe
we
can,
like
I'm
hesitant
whether
this
is
something
we
should
close
or
just
keep
it
around
as
a
feature
request
for
sba
reporting
and
but
not
something
that
is
a
blocker
for
anything
short
term.
I
I
mean
it
ties
in
a
lot
to
the
work
that
michael's
been
doing
and
proposing
and
he
was
presenting
on
from
tpack
and
stuff
right.
Yeah.
C
It
takes
a
while
to,
I
would
say
the
way
you
have
you
mentioned
it.
I
agree.
The
the
specific
request
here
is
likely
not
feasible
in
the
way
that
it
was
asked
and
the
way
that
some
of
the
discussions
were
here.
So
if
we
just
turn
this
into
a
broad
feature
request
to
like
on
the
greater
issue,
then
that's
fine.
Otherwise,
I
think,
like
there's
plenty
of
ongoing
work
in
several
different
places,
and
so
I
don't
know
that
this
specific
bug
is
the
catch-all
umbrella.
C
A
So
maybe
it's
like,
maybe
you
can
take
an
action
item
to
open
a
new
issue
that
covers
the
broader
ask
and
then
close
this
one
while
pointing
to
the
larger
like
broader
issue.
Does
that
make
sense
awesome?
Thank
you.
A
Okay,
cool
and
next
up
we
may
even
go
through
all
of
those.
Today,
that's
surprising
next
up
is
176
performance.line
176.
A
Nicholas
and
the
fact
that
the
observer
parameters
are
hard
to
feature
detect.
A
To
me
that
feels
like
a
broader
issue,
which
is
the
one
that
you
mentioned
this
issue
from
so
where
web
ideal
needs
a
better
pattern
for
detecting
dictionary.
A
Members
other
than
like
there's
a
try
catch,
one
that
you
mentioned
here
and
then
on
that
issue.
There's
a
another
one
involving
getters.
If
I
remember
correctly,
is
that
correct.
G
Allegedly
be
able
to
detect
it,
but
it's
probably
worse
than
just
using
a
tray
catch
anyway,
so
yeah.
I
just
think
it
would
be
good
to
have
that
in
particular
for
type
versus
entry
types
just
because
I'm
I'm
not
sure
if
all
user
agents
now
support
just
the
single
type,
but
in
in
the
period
of
transition
it
can
be
pretty
breaking
if
a
developer
moves
just
because
it
sees
it
working
in
one
browser
and
basically
just
stops
collecting
data
on
other
browsers
that
don't
support
this
new
parameter.
G
So,
ideally,
we
can
have
a
canonical
way
to
feature
detect,
dictionary
members,
but
that
issue
hasn't
really
moved.
So
I
don't
know
if
we
should
continue
pinging
there
or
what's
the
right
thing
to
do.
I
I
guess
the
the
question.
G
B
G
G
G
So
that
one
would
be
urgent,
because
that
one
would
also
break
a
lot
of
potentially
and-
and
it
would
be
hard
to
know
that
one
in
particular,
because
nothing
would
break
without
it.
A
Yeah,
so
maybe
this
is
something
that
we
should
like:
keep
the
issue
open,
blocked
on
that
external
dependency
and
then
keep
that
in
mind
next
time
around
and
when
we
want
to
add
another
dictionary
member
and
then
we
can
consider
you
know
doing
something
hacky
in
case.
The
broader
ideal
issue
is
not
addressed
by
that.
A
Sounds
good
okay,
cool
yeah
so
can.
A
Cool
and.
G
I
I
think
it
was
just
clarification
around
the
spec
and
when
timings
happen
and
stuff
like
that,
so
I
think
they
yeah
they
plus
one
to
my
final
response.
So
I
think
this
could
probably
actually
be
closed
out.
A
A
And
then
oh
and
we're
out
of
time
for
just
with
with
just
one
to
go
the
but
a
big
one.
I
think
the
worker
start
diagram
bit,
so
we
can
keep
that
one
for
next
time.
Probably
oh
awesome,
okay,
cool,
so
awesome!
So
thanks
all-
and
I
will
see
you
in
a
couple
weeks-
good
seeing
everyone
bye.