►
From YouTube: WebPerfWG call 2021 04 01
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,
hi
and
welcome
to
the
war
performance
working
group.
As
always,
this
call
will
be
recorded
and
posted
online
on
the
agenda.
A
Today
we
have
a
few
exciting
things
around
publishing
and
then
some
issue
triage,
but
first
one
thing
I
wanted
to
mention:
I
sent
out
a
survey
on
meeting
recordings
and
whether
y'all
find
them
useful
or
painful
or
both,
and
if
you
haven't
filled
that
out
I'd
highly
appreciate,
if
you
would
because
yeah
there
may
be
some
future
changes
around
that,
and
I
would
like
them
to
be
informed
by
more
than
my
just
my
own
opinions.
So
please
fill
out
the
survey.
A
A
We
easily
made
the
changes
to
hr
time,
but
then
publishing
those
changes
was
a
somewhat
manual
process.
It
turns
out
that
we
have
set
up
auto
publishing
for
hr
time
many
years
ago,
based
on
a
resolution
the
group
took
in
2015,
but
that
auto
publishing
pipeline
broke
for
some
reason.
The
github
tokens
were
no
longer
in
effect
or
something
along
those
lines
so,
and
it
seems
like
we
need
in
order
to
establish
an
auto
publishing
pipeline.
A
We
need
to
link
to
a
url
where
the
working
group
is
making
a
decision
to
auto
publish
drafts,
and
it
seems
that
we
can
refresh
that
decision
since
2015
was
a
long
time
ago.
A
A
Okay,
so
essentially,
there
is
a
working
draft
that
is
published
on
the
w3c
site
under
slash
dr
slash
hr
time,
dash
three
or
resource
timing
dash,
three
or
whatever.
It
is
the
spec
that
we're
talking
about,
and
that
is
a
published
working
draft.
Whereas
when
we
work
on
the
editor
draft
of
the
various
specs
and
commit
new
changes
to
them,
they
are
not
automatically
published
unless
we
decide
that
they
should
be.
A
That
means
that
other
specs
can't
reference
those
changes
until
we
publish
those
commits-
and
that
is
something
that
at
least
when
it
comes
to
working
graphs,
doesn't
make
a
ton
of
sense
because
there
is
no
like
there
are
no
implications
like
no
ipr
or
other
implications
of
just
publishing
them
other
than
the
fact
that
it
makes
it
hard
to
reference
them.
A
So
yeah,
that's,
basically
what
I'm
suggesting
to
auto
publish
commits
so
that
when
we
land
the
pr
in
hr
time
in
resource
timing
or
any
other
of
the
specs
that
are
currently
in
a
working
graph
status
that
will
auto
publish
that
to
to
w3c,
slash
tr,
slash,
spec
name.
A
Yeah
cool
karine:
do
you
like?
Does
the
auto
publishing
I'm
assuming
that
it
doesn't
extend
to
specs
that
are
no
longer
in
working
draft
status?
Is
that
a
correct
assumption,
or
do
we
also
want
to
pub
how
to
publish
those.
A
C
Just
for
those
that
require
a
transition
request,
we
can't
do
that
of
course,
but
we
we
need
a
group
decision
for
transitions,
but
all
the
other
levels
so
working
drafts,
ocr
updates,
are
okay
to
publish
upon
commit.
C
I
don't
see
any
downside
personally
yeah,
except
if
you
want
to
extend
the
editor's
rights
to
other
people
and
then
you
want
better
control,
but
I
I
don't
think
that's
that's
a
big
issue.
A
Okay,
cool
so
decision
made
okay
other
than
that.
I
was
looking
through
the
list
of
specs
that
we
have
in
the
spec
status
spreadsheet
and
let
me
try
to
open
it
in
a.
A
Okay,
so
essentially
looking
at
that
list.
A
A
Hr
time
two
is
in
rec
hr
time.
Three
is
a
working
graph,
that's
fine
to
leave
it
at
that.
For
now
for
performance
timeline,
we
have
two
parallel
working
graphs,
so
we
have
l2.
That
was
in
pr,
if
I
remember
correctly,
and
then
we
made
some
changes
to
it
and
then
brought
it
back
to
a
working
graph
as
a
result,
and
now
we
have
two
working
graphs
in
parallel.
A
In
my
view,
it
makes
sense
to
to
take
l2
again
through
the
2cr
and
pr
and
then
eventually
to
wreck.
Unless
there
are
any
objections
or
any
open
issues.
I
think
that
we
have
like,
as
far
as
the
issues
that
are
marked
as
level
two.
All
of
them
are
currently
closed,
other
than
a
test
saying
ensure
that
other
than
an
issue
saying
that
we
need
to
ensure
the
tests
are
clean.
A
Does
it
make
sense
for
us
to
move
performance
timeline
v2
to
cr,
and
if
so,
what's
the
like?
Do
we
need
a
call
for
consensus
on
that
or
does
the
working
group
decision
like
is
a
working
decision
enough.
A
I
think,
because
we
added
features
around
the
basically
change
the
like
the
performance
observer
types
and
like
edit,
the
type
and
buffered
flag.
I
believe
that
was
the
reason
for
that.
B
A
B
That
I
mean
it
probably.
B
Makes
sense
to
ask
if
people
have
any
objections
to
the
additions
to
l2,
but
I
don't
think
there's
any
and
then
based
on
that
do
as
little
process
as
possible
to
move
it
to
wreck.
Does
that
make
sense.
A
Yeah,
let
me
just
if
we,
if
we
go
to
github
on.
A
Does
that
make
sense
for
folks?
Do
we
need
so
first
of
all
question
for
karine?
Do
we
need
anything
beyond
the
working
room
decision
in
order
to
move
l2
like
performance
timeline,
l2
now
to
cr
or
in?
If
that
is
sufficient,
can
we
make
that
working
room
decision
now,
because
or
is
there
like?
Are
there
any
objections.
C
So
we
can
do
it
now
on
the
call
and
get
this
recorded
on
the
minutes.
We
really
need
to
sense
if
they
are
likely
objections,
because
if
we
get
them
later
it
it
doesn't,
it
doesn't
bring
anything
if
if
we
don't
go
for
an
email
call
for
consensus,
if
and
and
we
discover
later-
that
we
have
objections
and
and
we
get
them
at
cr
after
the
transition,
so
it's
better
if
we
have
at
least
we
are
100
sure
that
the
group
is
okay
with
that,
with
the
current
content.
A
So
I'm
I'm
not
sure
I
got
all
that
like
so
do
we
need
a
separate
email
asking
the
group
if
anyone
objects
or
will
make
a
decision
on
the
call,
be
sufficient,
because
objections
later
will
just.
C
C
But
I
I
I
feel
that
that,
given
the
question
we
had
just
now
that
people
need
take
some
time
back
and
look
at
it
and
then
agree.
A
A
I'm
not
sure
if
we
so
right
now,
level
three
has
a
few
more
things
that
l2
doesn't
have
so
the
buffered
flag.
Do
you
remember
nicholas,
do
you
remember
if
we
added
anything
beyond
the
buffered
flag
too,.
A
A
I
think
that
it
makes,
from
my
perspective,
it
makes
sense
to
publish
l2
to
rec
and
then
for
l3.
We
just
move
it
to
a
living
standard
model,
which
last
time
we
discussed
this
with
elite.
If
I
remember
correctly,
we
talked
about
moving
the
drafts
to
cr
and
then
continuously.
A
Maintaining
cr,
as
the
you
know,
published,
published
living
standard,
yeah.
B
A
H
Okay,
just
a
quick
addition
to
the
difference
between
l2
and
l3,
I
think
l3.
The
disconnect
method
also
clears
the
options
list
which
l2
doesn't
have.
I
think.
A
Okay,
so
moving
on
to
resource
timing
and
navigation
timing
so
norm,
rosenthal
is
doing
a
bunch
of
work
on
integrating
both
of
them
with
fetch
and
html,
which
was
the
big
hold
up
for
us
from
moving
from
l2
to
l3,
and
then
there's
a
big
question
there.
A
If
we
want
to
publish
l2
for
both
of
them
to
wreck
or
not
because
it
seems
like
for
resource
timing,
l2
is
a
working
graft
and
for
navigation
timing,
it's
a
cr
and
personally,
I
think
it
would
make
sense
to
just
move
both
of
them
to
the
living
standard
model.
Now
that
we
have
the
like
fetch
integration
behind
us,
you
can
move
both
of
them
and
then
just
add
new
features.
A
On
top
of
that,
without
worrying
too
much
about
levels,
I
think
that
bringing
them
to
rec
will
just
take
a
long
time
in
which
we'll
have
two
versions
in
parallel
to
maintain-
and
this
is
work
I
would
prefer
to
avoid.
Does
that
make
general
sense.
A
Yes,
please,
let's
not
do
the
dual
tracking
again,
it
can
be
avoided,
awesome
cool.
So,
on
that
front
colleen,
what
would
be
the
procedural
bit
here?
Do
we
also
need
a
call
from
consensus
to
move
them
to
the
living
standard
model.
A
E
A
And
on
navigation
timing,
maybe
because
it
will
undergo
significant
changes
as
part
of
the
fetch
and
html
integration
and
which
may
like,
I
don't
know
if
that
would
result
in
downgrading
it
to
a
working
graph
and
then
what's
the
like,
once
we
have
both
of
them
in
cr.
Do
we
need
anything
else
in
order
to
move
them
to
the
living
standard
status,
or
we.
C
C
A
C
I
guess
the
super.
I
suppose
that
the
reason
why
it's
still
level
level
one
is
still
in
crs
for
implementation
problems.
G
A
A
Not
yeah.
C
Well,
it's
look
entirely
possible
to
push
into
recommendation
very
easily
okay,
so
it
depends
on
what
the
group
wants
to
do.
If,
if
the
group
want
to
say
it's
a
living
standard
and
stop
with
that
level,
one
recommendation
put
it
in
level
two
well
consider
level.
Two
is
the
right.
One
drop
level
ones
well
drop
levels
all
together
in
some
way.
A
I
don't
have
strong
opinions.
I
would
like.
I
have
a
slight
preference
to
pushing
forward
the
l1
to
wreck.
If
you
say
it
would
be
easy
and
then
you
know
just
to
to
make
sure
that
bit
is
yeah
documented.
A
H
Brackets,
I
I
personally
find
having
all
kinds
of
words
makes
me
feel
confusing,
because
I
think
I
think
when
we
like
actually
like
implementing
stuff,
we
always
refer
to
the
latest
one
like
the
l3
y.
That's
the
standard
one
so
having
both
l3
and
l,
having
both
l2
and
l3
already
makes
me
like
like.
Why
do
I
have
both.
A
A
I'm
not
going
to
wreck
okay,
I'm
fine
with
that
as
well.
It
might
be.
A
Yeah,
maybe
I
can
formulate
like
an
email
to
the
group
about
moving.
A
Also
see
if
anyone
has
strong
opinions
regarding
keeping
l1,
you
know
basically
a
cfc
to
move
l2
to
cr
and
abandon
l1
and
see
if
anyone
objects
does
that
make
sense
as
a
path
path
forward
and
then
what
is
l3
is
now
going
to
be
a
living
standard.
We
will
yeah,
there
will
be
no
l3.
We
will
merge
whatever
work
we
did
in
l3,
which
I
don't
think
we
really
did
back
to
l2
and
then
keep
l2
as
a
living
standard.
A
B
A
B
We
can
do
that
if
no
one
really
cares
about
the
published
l2
version.
What's
the
point
of
doing
all
the
work
for
it
right.
C
A
Yeah,
so
that
would
mean
a
bet:
yeah
change,
the
resolution
we
made
10
minutes
ago
to
abandon
l2
and-
or
I
guess-
maybe
I
don't
know
if
that
changes.
The
resolution.
E
C
A
B
But
this
is
why
I'm
saying
I
would
just
think
l3
is
just
basically
the
new
l2
there's
no
need
to
merge,
because
it's
all
the
changes
have
been
on
top
of
l2.
There's
no
contradictory
changes
so
right
now
we
have
two
branches,
which
is
one
is
level
two
and
the
other
is
gh
pages,
which
is
level
three.
So
you
just
it's
just
renaming
gh
pages
to
be
the
actual
level.
Two.
F
A
A
C
C
F
C
You
can
find
it
if
you
say
slash
all
at
the
end,
then
you
get
the
list.
The
recommendation.
A
I
A
Cool
and
now
so
shall
we
move
down
the
list
to
user
timing,
so
basically
for
user
timing
we
have
published
actually
published
l1
and
l2,
and
now
l3
is
a
working
draft
which
similarly,
it
seems
like
it
would
be
worthwhile
to
push
to
cr
and
then
make
that
l3
the
living
standard
for
all
the
future
user
timing.
A
A
A
A
The
easier
version
is
that
we
push
a
spec
to
cr,
say
that
it's
now
a
living
standard
and
future
changes
are
republished
as
cr,
and
if
I
understand
correctly
and
correct
me
karine
if
I'm
wrong
without
requiring
any
further,
you
know
process
so
in
a
very
similar
way
to
how
the
html,
spec
and
fetch
are
maintaining
the
wg,
where
you
know
for
things
that
are
prs
that
are
landing,
require
group,
consensus
or
some
form
of
consensus,
and
then
they
are
automatically
published
as
part
of
the
standard.
H
So
if
we
do
that
for
user
timing-
and
we
move
the
l3
to
cr,
do
we
still
need
to
have
those
too?
You
know
rex
status.
A
They
will
remain
published,
but
yeah.
We
can
generally
ignore
them
as
historical
artifacts.
C
The
old
way
to
do
that
was
to
supersede
your
recommendations,
typically
groups,
that
keep
old
recommendations
do
that
for
reasons
when
you
have
kind
of
profiling,
the
spec
like
having
a
one-node
that
would
be
quite
easy
and
implementing
in
some
situations,
and
you
have
a
tool
that
have
additional
features
that
will
be
used
in
other
situations
and
and
people
would
want
to
keep
the
100,
because
it's
easier
it's
simpler
and
the
use
case
for
having
the
simpler
version
still
exists,
which
is
not
the
case
for
any
of
the
spec
of
this
working
group.
C
The
way
we
could
also
do
it
is
yeah.
I
think
that,
because
level
2
was
published
under
the
previous
process,
we
can't
really
use
it,
as
I
believe
we
can't
use
it
as
a
living
standard.
C
That
way,
we
can't
really
supersede
the
previous
recommendations,
because
only
new
recommendation
would
do
that.
We
could
obsolete
the
old
ones.
That's
another
possibility
stay
forever
in
cr
and
regularly
at
least
once
a
year,
probably
cr
snapshots,
which
are
the
crs
that
are
that
require
group
approval,
but
ensure
that
the
patent
policy
protection
is
on
the
content
of
the
spec.
C
A
Yeah,
I'm.
I
think
that
the
group
previously
decided
that
the
forever
cr
model
is
more
like
favorable,
but
yeah
agree
that
we
can
start
by
pushing
the
working
draft
to
cr
and
yeah
and
then
seeing
that
and
like
revisiting
that
in
the
future,
if
needed,.
A
A
And
then
what
we
have
left
is
on
the
list.
Page
visibility
which
is
currently
in
pr.
A
And
there
is
okay,
there
is
still
one
html
integration
related
issue
to
resolve
and
then
we'd
be
able
to
potentially
take
it
to
wreck.
But
maybe
we
need
to
do
that
first
before
making
a
decision
on
this.
A
A
I
see
michael's
face
in
the
icy
assignee
column
on
this
one.
So,
michael
you
looked
into
this
one.
I
Right
sorry,
I
was
partially
distracted.
A
Page
visibility
issue
51
that
I'm
currently
presenting
yeah
yeah.
How
much
work
would
it
take
to
take
that
over
the
finishing
finish.
F
I
Yeah,
I
think
it's
pretty
well
outlined
what
it
would
take
here.
There
would
be
changes
to
both
this
spec
html
and
some
dependencies,
but
generally
speaking,
it's
not
too
it's
not
too.
It's
not
too
bad.
I
A
Yeah,
so
it's
yeah.
Basically,
I
I
believe
that,
in
order
to
move
to
wreck,
we
need
to
close
all
the
open
issues,
and
this
seems
to
be
the
last
one.
Okay,
I'll
take
it
I'll.
A
Yeah
and
I
think
that,
in
terms
of
testing
status,
we
are
in
perfect
shape.
I
mean.
A
Yeah
or
but
yeah
I.
A
Yeah
so
it
seems
like
we
just
have
this
last
issue
left
and
then
we
can
take
it
to
wreck
and
the
other
and
last
one
that
I
have
on
my
list
is
the
beacon
api,
which
is
zero,
open
issues
it's
currently
in
cr,
and
we
can
take
it
to
pr
zero
open
issues
and
as
far
as
the
tests
go,
we
are
almost
green.
I
mean
we
have
like
two
implementations
for
each
one.
A
A
Sorry
yeah,
so
we
have
two
implementations
passing.
Oh,
oh,
not
even
no
there's
a
econ
basic
yeah.
I
do.
We
need
perfect,
perfect
score
on
tests
to
move
to
pr
karine.
Or
can
we
take
it
to
pr
and
fix
the
tests
on
our
way
to
rap.
C
A
Yeah,
I
think
it
would
be
simpler
to
just
fix,
like
there
are
those
like
chromium
failures
that
I
suspect,
or.
A
Okay,
so,
similarly,
in
order
to
move
that
to
pr
is
that
I'm
guessing
it's
like
a
cfc
but
potentially
a
separate
one,
because
the
other
ones
are
moved
to
cr,
yes
or
can.
C
A
Writing
emails
is
cheap,
presumably
yeah,
okay
cool.
So
I
think
we
have
a
bunch
of
action
items
for
the
chairs
here
nick
we
can
probably
negotiate
offline
yeah
yeah
splitting
it
up
cool,
and
with
that
we
have
full
eight
minutes
to
talk
about
the
different
issues.
D
D
126.
yeah,
I
think
I
think
we've
actually
already
talked
about
this
in
the
previous
one,
so
this
is
about
possibility
of
getting
the
hp
status
code
from
the
response.
A
Header
yeah,
we
we
talked
about
it
a
while
back
and
said
that
this
is
a
like
an
l3
that
now
we
know
will
never
happen,
but
yeah
yeah,
but
basically
something
that
was
postponed
after
the
html
and
fetch
integration,
which
are
happening
very
soonish.
And
then
we
can.
You
know,
rediscuss
this
in
terms
of
yeah
exposing
the
status
code.
It
feels
like
something
that
we
would
want
to
move
to
resource
timing.
E
F
D
I
can
do
some
research
on
that
and
see
if
I
can
find
something.
B
D
Yep
yeah
there's
a
related
resource
timing
case
number
90,
that's
been
open
since
2017.
A
D
D
Okay,
that
makes
sense-
let's
see
five
minutes
left.
So
another
issue
that
was
opened
up
is
navigation.
Timing
issue
number
140.
D
The
title
is
app
cache
meeting
and
the
question
is
around
the
block
of
time
that
we
have
in
the
diagram
that
is
just
listed
as
app
cache,
and
I
think
it's
more
of
a
kind
of
a
clarification
question
around
like
what
what
exactly
what
times
can
go
in
there
or
what
what
components
can
contribute
to
non-zero
time
in
the
app
cache.
D
D
A
My
natural
tendency
would
be
to
say
app:
cache
is
dead,
that's
not
like,
let's
not
bother
with
defining
it
all
too
much.
I
don't
know
if
this
is
like
benjamin.
Do
you
know
if
firefox,
similarly
removed
or
planning
to
remove
appcache.
D
D
A
B
D
B
E
B
D
B
D
I
can
I
can
do
a
little
bit
of
research
here
to
see
if,
like
we,
this
in
this
day
and
age,
see
any
significant
difference
between
fetch
dart
and
domain
lookup
start
for
resources
that
have
that,
and
the
original
question
was
basically
like
what
is
that
time
like
if
there
is
nonzero
time
there,
what?
D
A
Bit
yeah,
it
would
be
interesting
to
do
some
research
there
and
yeah
I'll
follow
up
on
that.