►
From YouTube: WebPerfWG call 2021 04 15
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
Raised
his
arms
yeah
yeah,
so
this
is
being
recorded
and
posted
online
and
yeah.
Welcome
to
the
web
performance
working
group,
we
had
a
discussion
about
medium
recordings,
which
wasn't
recorded,
and
now
we
move
on
to
the
main
event.
B
And
the
notes
of
that
will
be
within
the
minutes
later
for
anybody
that
wants
to
review
it,
and
if
anybody
has
any
questions,
they
can
contact
joe,
and
I
directly
about
that
discussion
next
meeting
two
weeks
from
now
on
the
29th
of
april
any
problems.
Okay,
I
did
want
to
share
one
thing
that
came
out
of
a
community
group.
B
There
is
a
new
spec
editors
community
group
that
was
started
up,
basically
a
discussion
and
friendly
group
for
people
that
are
spec
editors,
so
for
anybody
here
that
is
working
on
specs,
you
may
or
may
not
want
to
join
and
see
how
everybody
can
help
each
other
out,
but
just
wanted
to
share
that
link.
B
And
after
that,
gnome
did
you
want
to
take
some
time
for
fetch
and
html
integration
with
the
specs.
C
Yeah
sure
so
I
wanted
to
present
to
you
the
work
we
were
doing
in
the
last
five
or
six
weeks.
C
Together
with
you
have
and
with
the
what
work
folks,
so
the
idea
was
to
solve
a
long
age,
technical
debt
of
a
resource,
timing
and
navigation
timing,
defining
defining
the
processing
model
internally,
while
the
processing
model
actually
is
defined
in
fetching
in
html,
while
the
processing
model
in
research,
timing
and
navigation
timing
was
a
like
a
reflection
of
that
like
a
saying,
the
same
thing
in
different
words
and
putting
in
when
things
when
things
should
be
measured,
yeah
as
sort
of
an
add-on
to
the
other
specs
and
the
idea
of
this
effort,
which
is
a
nearly
at
the
end
of
my
current
tenure
unit.
C
Specs
would
define
is
how
they're
exposed
so
actually
a
lot
of
this
is
already
in
the
the
editor's
draft
and.
C
D
C
B
C
This
has
changed,
and
now
you
can
see
that
all
the
different
metrics
they
are
just
a
timestamp
conversion
form
a
something
that's
called
timing
info
and
timing
info
is
something
that
derives
from
fetch.
C
C
And
we
can
see
how
how
they're
actually
measured
like
a
redirect
end
time.
You
can
go
to
the
reference
and
at
a
particular
point
in
the
fetch
algorithm.
It
says
oh
now,
this
is
the
redirect
end
time,
so
I'm
going
to
going
to
mark
it,
which
is
more
like
also
how
the
code
works,
how
the
implementation
work
usually
there's
some
struct
somewhere
in
the
document
loader
or
in
resource
loader,
depending
on
your
browser
engine
of
choice
and
later
on,
it's
a
it's
exposed.
C
This
also
interesting
because
it's
uncovering
a
lot
of
issues.
One
issue
that
is
in
progress
is
the
what
we
talked
about
few
weeks
ago.
I
think,
which
was
the
worker
timing
and
so
worker
timing,
a
an
explicit
implement,
spec
of
that
which
corresponds
to
what's
happening
in
chromium
and
then
gecko
is
the
is,
is
in
review
and
it's
going
to
go
in.
So
all
of
that
is
going
to
be
explicit.
C
Should
they
get
an
a
research
timing
entity
or
shouldn't
they
it's
very
difficult
to
to
put
it
in
the
fetch
spec.
Many
things
return
a
network
error
in
all
kinds
of
places.
So
it's
difficult
to
say
when
is
timing
recorded
for
them?
D
D
B
D
So
I
think
we
agree
that
we
want
to
report
http
errors,
those
happen
after
the
course
checks,
and
so
the
question
is:
do
we
have
a
use
case
for
reporting
core
servers
right
and
other
network
errors
right,
because
the
easy
solution,
right
from
my
perspective
or
well,
I
don't
know
if
easy
but
like
just
not
reporting
to
them
at
all
right,
there's
no
use
cases
for
them.
D
B
C
C
C
Anyway,
I
I
would
this
is
a
discussion
that
spurred
up
from
this,
and
it
would
be
good
to
to
continue
that
on
the
github
issue.
In
the
meantime,.
C
I
wanted
to
have
a
master
issue
for
this.
However,
this
so
far
it
spans
seven
different
repositories,
and
so
it's
difficult
to
tell
which
repository
should
hold
the
metabolic
for
all
of
the
stuff
that
is
about
this.
In
the
meantime,
I
created
a
google
doc
in
where
you
can
see
all
of
this
right
now.
There
are
quite
a
few
things
that
are
done
and
a
few
things
that
are
in
review
yeah.
How
do
we
handle
network
errors?
Is
here
I
can
share
the
the
document.
C
Big
word
is
still
required.
Is
that
fetch
itself
does
not
report
it
resource
timing.
It
just
marks
the
timings,
the
different
metrics
and
it
it's
up
to
the
caller
to
say:
okay,
this
is
my
initiator
type,
and
I'm
going
to
mark
it.
So
there
are
about
15
colors.
This
is
also
sort
of
how
it
works
in
the
implementation
and
because
the
the
caller
needs
to
decide
whether
the
reporting
needs
to
be
happened
before
or
after
the
load
event,
which
is
very
color
specific,
for
example,
and.
C
And
the
initiator
type
is
something
that
comes
from
the
color
and
fetch
doesn't
know
anything
about
it.
So
there
needs
to
be
work
on
the
html
spec
in
css,
spec
to
in
other
specs,
like
beacon,
to
say.
Okay
at
this
point
actually
reports
the
resource
timing
for.
C
C
I
think
also
several
issues
that
were
fleshed
out
already
fixed,
which
is
which
is
nice.
They
actually
came
from
working
on
this,
for
example,
the
fact
that
the
tao
was
exp
that
they
saw
protocol
was
still
reported,
for
they
were
protected
and
a
few
little
privacy
security
issues
and
were
just
popped
out
from
doing
this
work.
C
A
Nothing
to
add
other
than
the
fact
that
I'm
super
excited
about
this
finally
landing
after
many
years
of
this
dragging
on.
So
thank
you
for
that
work.
Amazing
work.
C
Now
I
want
to
say
like:
let's:
let's
try
to
keep
it
clean,
like
you
know,
additions
additional
metrics,
let's
start
by
putting
them
in
the
right
place
in
a
in
fetch
and
html,
rather
than
put
a
non-normative
stuff
in
there
research
timing
and
then
adding
technical
deaths
like
it's,
not
the
what
people
are
very
responsive
and
they
help
flesh
out
issues
like,
for
example,
how
now
we
have
to
transfer
size
becomes
sort
of
a
fake
like
it
could
be
issues
that
we
can
flesh
out
earlier.
C
A
And
one
one
question:
so
there
are
some
differences
here
that
will
require
implementations
to
slightly
adjust
what
they're
currently
doing.
A
So
I'm
wondering
more
like
a
question
for
benjamin.
Were
you
aware
of
this
work?
Is
this
something
you're
tracking
is
it
like?
Are
you
yeah.
E
We're
super
excited
to
see
this
work
yeah.
I
have
definitely
been
tracking
it
and
you
know
honey
and
gnome.
Thank
you
so
much
for
this.
This
is
definitely
worth
your
time
and
effort
yeah
we're
we
like
this
and
want
it
to
succeed
and
clearly
the
right
part.
The
right
standard
for
this
is
html
and
fetch.
So
this
is
perfect.
We
like
having
all
this
encapsulated
in
one
place
instead
of
in
resource
timing
and
nav
timing.
So
this
is
all
great
from
us.
You
have
nothing
but
my
full
support.
E
I
know
last
week
that
you
had
asked
about
app
cache
yov,
so
I
replied
in
that
bugzilla
about
it.
I
mean
I
as
part
of
the
fetch
integration.
I
would
like
some
of
the
like
dangling
bits
like
app
cache
to
be
removed
or
clarified,
but
I
don't
that's
not
really
no
on
his
work
like
that
is
for
us.
I
think
I
think
that's
cool.
E
E
Okay:
okay
yeah:
we
have
been
going
through
resource
timing,
wpt
fails,
but
we're
kind
of
hoping
for
this
to
solidify
a
little
bit
before
we
made
another
round
at
that.
So
we're
expected
to
review
nap
time
and
resource
timing
after
these
kind
of
are
stable
enough,
and
it
seems
likely
that
that's
either
here
now
or
we'll
be
here
within
two
weeks.
So.
C
Yeah
right
now,
I'm
just
waiting
for
like
ipr
for
service
workers
back
what
kind
of
things
but
but
the
general
stuff
has
been
reviewed
already.
E
D
C
C
C
I
think
one
thing
that
is
maybe
a
change
and
would
would
be
a
bigger
change
once
the
html
specific
color
bits
are
more
in
place,
is
a
the
the
previous
spec
did
not
specify
at
all
when
it
is
reporting
done,
it
did
for
navigation
timing,
but
not
for
resource
timing.
It
said
sometime
after
some
time
after
a
response,
and
it
should
be
reported
so
currently
with
the
only
one.
C
The
only
color
that
is
fully
in
right
now
is
fetch
the
fetch
api
itself,
and
it's
it's
documented
there
exactly
when
it's
reported,
I
don't
exactly
remember,
but
whether
it's
before
or
after
the
load
event
or
whatever,
but
it's
like,
and
it's
going
to
be
like
that
for
the
rest
of
the
html
callers.
So
that
would
be,
I
think,
a
change.
I
think
in
the
program
implementations
there's
all
kinds
of
timers
of
when
things
are
actually
reported.
C
Of
of
a
resource
timing,
entry-
and
I
think
one,
oh
one
other
thing
that
popped
up
from
this
is
that
this
question
mark
about
the
media
and
resource
timing.
Maybe
it
would
be
good
to
have
an
issue
about
it.
I
don't
know
if
there
is
one
like
there
are
resources
that
never
end
like
long
videos
and
like
should
they
be
reported?
Are
they
resources
maybe
do
they?
C
Can
you
see
them
and
then
see
the
end
of
them
just
when
they
end
like,
like
the
html,
like
the
navigation
timing?
C
It's
another
thing
that
came
up
from
doing
this,
especially
since
response
ends
seem
to
be
like
the
most
intricate
part
of
the
measuring.
C
C
It's
not
defined
how
it's
saved
in
cache.
It's
not
defined.
How
it's
saved
in
the
caches
of
a
service
worker
response
is
kind
of
this
opaque
thing
that
has
all
kind
of
associated
things
with
it,
and
so
so
some
things
are
defined
in
fetch
now,
but
they're
still
hand
wavy
like
like
how
a
encoded
body
size
is
saved
in
cash.
D
D
We
might
not
even
remember
what
was
supposed
to
be
tested.
Well,
not
a
month
from
now,
maybe
six
months
from
now.
So
will
people
be
interested
in
helping
writing
up
some
tests
or
do
do
you
think
it's
not
that
much
work
and
someone
can
just
do.
A
D
Such
a
spec
with
so
many
so
many
things
being
reported,
and
it's
just
we
could.
We
could
definitely
use
having
better
test
coverage,
in
particular
for
the
things
that
just
now
changed.
I
think
it's
super
important
to
have
them
so
that
implementers
can
double
check.
What's
the
right
thing
to
do,
in
which
cases
and
so
on.
C
B
Thank
you
for
going
over
all
that
with
us.
We
do
have
a
couple
see
we
have
about
15
minutes.
We
have
a
couple
issues
that
we
could
dive
into
if
we
wanted.
In
fact,
the
first
one
that
I
wanted
to
bring
up,
although
I
think
it's
already
mostly
resolved,
is
one
related
to
this
resource
timing
issue
number
260..
B
This
is
changing.
The
current
definition
of
start
time
exposes
the
total
redirect
time
when
tao
fails
and
gnome
you
open
that
up.
It
looks
like
it's.
You
guys
have
already
resolved
it.
I
guess
I
just
want
to.
If
you
don't
mind
just
talking
about
for
a
moment,
I
just
have
like
one
clarifying
question.
C
Yeah
the
way
start
time
worked
before
was
that
it
was
the
time
after
redirect
it
was.
It
was
mapped
to
a
fetch
start,
even
when
tao
fails,
which
means
that
if
one
was
to
mark
user
timing
before
it
started,
the
fetch
towel
fails
and
they
will
get
the
start
time
for
the
for
the
entry
and
see
that
it's
a
little
bit
after-
and
it's
like-
oh
this-
probably
redirects
here.
So
maybe
that
means
the
user
was
logged
in
or
something
they
can
extrapolate
from
this.
C
B
And
there
there
was
initially
some
talk
about.
Maybe
gating
fetch
start
on
tao,
but
it
sounds
like
the
end
result.
Is
that
start
time
will
be
equal
to
fetch
start,
which
will
be
the
start
time.
They'll
both
be
still
set.
D
C
B
And
they
still
won't
know
if
there's
any
redirects,
because
we're
only
providing
two
real-time
stamps,
which
is
start
and
end
and
fetch
start,
is
also
basically
just
same
as
start
time.
So,
okay,
okay,
make
sense.
I
I
I
guess
I
just
want
to
make
sure
that
we
weren't
zeroing
out
fetch
start
because
that
could
have
some
compatibility
issues
with
scripts
that
we're
reading.
B
Specifically,
if
I
start
if
it
exists
in
some
cases:
okay,
okay,
thank
you
so
that
one
it
looks
like
it
even
could
be
closed
out
once
it
lands
into
the
it's
landed.
C
D
D
I
think,
in
in
pull
requests
so
having
that
for
our
specs
could
be
nice
just
so
that
we
don't
forget
right,
because
sometimes
people
just
I
need
to
fix
this
quickly
and
then
they,
the
problem
of
forgetting
tests,
is
that
then
later
other
implementers
are
like
they
they
they're
unable
to
follow
along,
because
there's
no
record
for
them
to
realize
that.
Oh,
this
change
happened
so.
C
D
B
Okay,
thank
you.
The
next
resource
timing
issue
is
one
that
was
opened
up
by
iov.
This
is
render
blocking
status
of
resources
number
262..
A
So
this
is
basically
feature
requests
that
I
thought
I
added
years
ago,
but
didn't
so.
I
just
added
that.
A
Essentially
I
very
recently
added
the
exposure
of
render
blocking
status
for
scripts
and
styles
to
chromium
traces,
mainly
for
them
to
be
used
in
devtools
and
lighthouse,
and
now
webpage,
that's
also
playing
around
with
them,
and
that
seems
like
a
generally
useful
concept
in
order
for
people
to
know
when
they
are
loading,
a
render
blocking
resource
like
or
loading
non-blocking
resources
before
fcp,
for
example,
and
they
can
delay
those
resources
to
be
loaded
later
or
otherwise
see
what
their
render
blocking
resources
are,
and
it
turned
out
that
devtools
and
lighthouse
were
already
trying
to
guess
that,
but
mostly
based
on
the
type
of
resource
and
when
it's
loaded
and
its
priority,
which
is
a
good
estimate,
but
not
always
super
accurate.
A
So,
yes,
I
added
it
to
traces.
It
is
like
it
seems
useful
initially,
and
I
thought
that
this
could
be
like,
given
the
fact
that
yeah
resource
timing
is
now
cleaned
up
and
we
can
start.
Finally,
we
can
start
to
add
new
things
to
it.
It
might
be
interesting.
To
also
add
that
that
would,
of
course,
involve
some
specification
around
what
render
blocking
resource
is
and
isn't
but
yeah.
It
seems
like
a
useful
feature
and
I
would
love
to
hear
y'all's
thoughts
on.
A
A
I
was
more
thinking
of
not
necessarily
not
a
buffer
of
like
a
separate
api,
just
as
part
of
resource
timing,
so
I
have
a
resource
timing
entry
for
a
script.
It
has
a
render
blocking
status.
Enum.
A
That
says
this
is
non-blocking
or
blocking
or
partially
blocking,
because
there
are
various
subtleties
to
that
and
ones
that
I'm
like,
hoping
that
the
implementation
experience
with
like
exposing
it
to
traces
and
having
it
be
used
in
lighthouse
and
devtools
and
webpagetest
will
give
us
all
the
different
status
of
blocking
resources
for
like
we
have
fonts
that
are
non-blocking
or
we
have
fonts
that
are
partially
blocking
and
yeah.
So
generally,
I
thought
of
exposing
this
as
part
of
the
resource
timing.
A
Entry,
I'm
not
100
sure
what
the
api
shape
would
be,
and
this
is
something
that
I
think
will
need
some
more.
You
know
experience
with
the
traces
and
with
the
different
like
with
the
different
resource
types
like
I
said,
I
edited
for
scripts
and
styles.
I
haven't
yet
edited
for
for
fonts.
A
Also,
my
implementation
naively
relied
on
the
h,
like
there's
a
non-blocking
flag
in
html
for
script,
loading
that
I
just
reflected
here
and
apparently
it
does
some
weird
things
with
the
when
dynamic
async
scripts
are
injected,
so
they
are
considered
blocking,
even
though
they're
not
really
blocking.
But
it's
used
like
there's,
there's
a
boolean
in
html
there
that
needs
to
be
disambiguated,
and
this
this
surfaced.
So
I
think
we
will
need
some
more
implementation
experience
before,
knowing
exactly
what
the
shape
would
be.
E
Okay
and
then
I
guess,
as
you
experiment,
I
would
be
curious
to
see
if
there's
a
value
of
just
reporting
the
blocked
elements
and
not
recording,
not
blocked
blocks
set
us.
A
Yeah,
I
think
like
right
now,
I'm
only
reporting
it
for
l
for
resources
that
are
potentially
blocking
so
for
images.
There
is
no
like
it
doesn't
make
sense
to
always-
or
maybe
it
does,
but
yeah
images.
There
is
no
blocking
status,
so
yeah
yeah,
we'll
we'll
definitely
discuss
the
api
shape
before
I
just
like
wanted
to
get
y'all's
opinions
on
the
usefulness
of
the
concept
and.
C
I'm
thinking
that
the
whole
render
blocking
thing
is
not
is
more
like
a
browser
choice
rather
than
a
standard
thing.
In
most
cases,
isn't
it
or
in
some
cases.
A
I
think
that
at
least
for
some
cases
it
is
defined
so
at
least
in
some
cases
the
render
like.
A
You
know
rendering
doesn't
take
place
as
long
as
there
are
pending
like
head
styles.
I
think
this
is
specified
benjamin
correct
me
if
I'm
wrong,
but
or
I'm
I
I
haven't,
looked
at
the
specification
specification
status
of
this.
I
assume
that,
like
at
least
for
like
blocking
scripts
or
blocking
you
know,
they
are
defined
to
be
blocking
for
styles
and
render
blocking
can
be
slightly
more
ambiguous.
I'm
not
sure.
E
I
expect
there
will
be
some
vendor
specific
parts
of
how
resources
are
downloaded,
but
I
mean,
if
you're,
just
looking
for
show
of
hands,
is
this
potentially
useful?
Yes,
of
course,
this
is
potentially
useful.
We
would
encourage
experiments
in
this
hey,
just
a
real,
quick
point
of
order.
We've
got
three
minutes
and
there's
a
whole
bunch
of
calls
for
consensus.
Like
can
somebody
say
something
about
this
because
it
looks
like
the
action
is
to
do
nothing
to
approve
it,
which
is
kind
of
weird,
like.
A
The
action,
so
this
is
basically
a
result
of
the
discussion
from
last
two
weeks,
so
one
is
a
decision
we
made
there
and
yes,
the
action
there
is
to
do
nothing.
I
think
that
for
the
for
the
rest,
it's
also.
Similarly,
if
we
are
like,
I
think
it's
mostly
were
looking
for
objections
and
folks
on
the
call
were
all
supportive.
A
So
it's
my
understanding
and
yeah
kareem
is
on
vacation,
but
my
understanding
is
yes
that
if
no
one
objects
then
we're
good
and
we
can
publish
and
move
the
specs
forward
based
on
the
discussion
on
the
call,
if
our
objections-
please
let
us
know
if,
if
there
are
like,
you
know,
just
questions
about
this
also.
Similarly,.
E
Feel
free
to
do
you
mind
if
I
just
reply
just
to
make
it
clear
saying
I
don't
have
any
objections.
That
would
be
awesome.
Okay,
great
thanks.
Thanks,
okay,
cool.
B
Thank
you
everybody
today
for
all
of
your
discussions
and
obviously,
if
there's
follow-ups
to
any
of
these
or
other
meeting
recording
stuff.
Let
us
know
later
and
we'll
see
you
in
two
weeks.
Thank
you.