►
From YouTube: WebPerfWG call - May 7th, 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).
B
A
Yeah,
basically
it's
it's
a
public
holiday
here,
so
I
can
make
the
same
time
or
a
different
time
any
other
day
of
that
week,
but
not
Thursday
you
nor
Friday
and
I'm
guessing
other.
B
E
A
Yeah
so
Tuesday
to
19th
yeah
works
for
me.
A
B
C
So
I
linked
spec
there
in
case
people
don't
have
a
link
handy,
and
I
want
to
update
that.
We've
landed
the
change
to
have
a
method
that
queries,
whether
you
should
add
an
entry
to
the
performance
observer.
It
basically
looks
at
the
dictionary
of
the
observed
call
basically
and
that
dictionary
can
have
a
duration
threshold.
So
if
it
has
a
duration
threshold,
then
it
compares
it
with
the
duration
value
of
the
entry
and,
if
it's
less
than
the
threshold,
then
it
does
not
sense.
C
C
Even
though
win
support
entries
of
duration
greater
than
well
in
duration,
1616
or
more,
which
means
we
still
need
a
way
to
determine
which
ones
are
buffered,
so
I
was
thinking.
Maybe
we
can
hack,
the
ad
should
add
entry
and
if
or
have
a
yeah,
somehow
saying
sure
that
entry.
This
is
about
the
performance
timeline.
If
that
makes
sense.
C
A
C
B
I
agree
with
both
those
intentions,
I
would
say
we
should
definitely
make
it
explicit,
like
call-outs,
within
the
spec,
in
a
couple
different
places.
Just
so,
people
wouldn't
be
confused
about
that.
If
they're
looking
at
it
or
wondering
why
one
of
them's
not
getting
the
same
results
as
another
one
yeah.
C
I
do
worry,
it
can
be
a
little
confusing
and
that
when
you
call
the
buffered
flag,
so
you
get
only
very
slow
entries
from
the
past,
but
then
reduced
duration
threshold
to
know
which
entries
are
being
received,
but
only
in
the
future.
That's
a
little
confusing
but
I'm
not
sure.
If
there's
a
good
alternative,
because.
C
B
That
makes
sense,
then,
okay,
okay,
so
if
you
just
to
restate
what
you
said,
we
will
only
buffer
things
over
at
100
milliseconds
and
if
you
don't
specify
a
threshold.
Otherwise,
if
you
observe
it,
you
would
only
get
things
over
at
2
milliseconds.
If
you
wanted
to
get
something
with
more
smaller
durations,
you
would
have
to
observe
it
and
that
would
not
go
into
the
buffer
right,
observe
it.
What
the
duration
specified!
Okay,
yeah.
C
Yeah
any
any
feedback
that
we
will
have
regarding
what
to
have
to
specify
this
weird
behavior
about
performance,
timeline,
buffering
and
would
be
useful
and
more
generally
feedback.
Regarding
event,
timing
is
welcome,
because
in
chrome
we
we
would
like
to
ask
it
and
implementation
of
the
full
event.
Timing,
sometimes
do
so.
It
would
be
great
to
have
some
feedback
if.
B
There's
any
just
from
an
Akamai
perspective,
we
are
shipping
an
update
to
our
boomerang
library
with
full
capture
of
all
the
that
timing
data
as
well
as
person,
but
delay
kind
of
part
of
that.
So
we
don't
have
immediate
feedback
right
now
other
than
that
we're
starting
to
collect
it
and
hope
to
look
at
the
data
more
soon.
C
Right,
it
would
be
interesting
to
see
if
so,
you're
using
a
polyfill
rain,
aerate
yeah
yeah.
It
would
be
interesting
to
see
how
it
compares
to
event
timing,
I
guess
once
it
ships
but
Jim,
serve
I,
guess
the
performance
cost
of
the
polyfill
versus
event.
Timing,
as
well
as
the
accuracy
of
like
do
they
report
similar
numbers
or
is
it
just
yeah.
B
C
C
A
Yeah
also
for
like
API
customers
in
the
crowd,
if
you
have
opinions
regarding
the
buffering
the
duration
threshold,
whether
you
will
use
a
been
timing
at
all,
if
you
will
look
if
that
model
fits
the
way
that
you
would
like
to
use
it.
If
the
answer
to
the
previous
question
is
yes,
that
would
be
great.
Okay,.
C
C
C
B
Over
that
for
the
moment,
so,
let's
jump
into
resource
timing.
I
guess
so
we
have
a
bunch
of
issues
listed,
I,
think
the
first
group
of
them
so
starting
with
resource
timing,
issue
number
71,
which
just
talks
about
our
transition
plans
to
getting
resource
having
to
see
our
this
issue
is
about
a
long
time
ago,
and
it's
kind
of
a
tracking
issue
for
things
that
we
need
to
get
done
in
order
to
get
there.
B
So
the
first
issue
in
currently
tagged
level,
two
that
we
have
not
closed
out
yet
is
just
issued.
One
number
one
generally
noted
on
the
list.
198
and
I
was
just
mentioning
this
really
quick.
This
is
from
Felipe's
just
saying
that
we
should
make
sure
to
register
the
tangelo
origin
as
a
header
once
we
move
it
to
CR,
so
obviously
I
don't
think
we
can
make
any
progress
on
that
yet
so
that
one
will
wait
until
we
are
ready
for
it.
B
The
second
one
was
a
rep
issued
number
200.
This
is
be
a
bit
more
explicit
about
what
sub
resources
are
to
be
ignored
from
stylesheets
I
can
summarize
it
really
quick
Nicolas
pointed
out
that
if
we
have
like
a
dependency
tree
of
resources
and
one
of
those
style
sheets
is
cross-origin
fetched
with
no
cores,
what
do
we
do
about
like
grandchildren
resources?
Are
they
explicitly
ignored
or
not
and
I
think
at
the
end
of
it?
B
A
And
yes,
so
I
had
a
hard
time
figuring
out
the
language,
but
I
think
I
just
need
to
get
back
to
that
and
find
something
that
is.
You
know
at
worst
hand
wavy
but
describes
what
we
like
the
behavior
that
we
want
from
this,
and
we
can.
You
know,
then
put
an
action
item
that
if
and
when
CSS
will
integrate
with
fetch,
we
will
better
describe
it
and
somehow
you
know,
define
the
ancestry
relationship
in
fetch
and
then
rely
on
that
somehow.
A
So
I
think
that
would
be
the
best
we
can
do
and
then
tests
that
make
sure
that
this
is
actually
what's
what's.
Implementation
are
currently
doing
that
I
and
I.
Don't
think
we
actually
know
that
this
is
true
for
any
of
the
implementations.
So
then
you
can
see
like
once
we
have
desks,
we
can
see
yeah,
you
know
which
one
pasts
and
what
other
action
items
implementations
need
to
go
like
me
too.
What
else
they
need
to
like
people
need
to
do
in
order
to
get
it
to
pass
yep.
C
B
A
B
Okay,
the
rest
of
the
issues,
I
believe,
are
new
issues
that
have
been
filed
that
we
do
not
yet
have.
We
haven't
decided
whether
the
level
2
or
level
3
soloist
recurring.
Why
don't
we
just
go
through
them?
A
figure
out
what
we
need
to
do
to
move
them
forward
a
bit,
if
anything
that
we
can
right
now.
B
First,
one
is
issued
number
220,
since
this
is
from
Nikolas
past
the
realm
when
creating
performance
resource
timing.
It
sounds
to
me,
based
on
the
discussions
that
are
read
from
this.
It's
similar
to
another
change
that
you're
making
Nikolas,
but
we
need
to
wait
for
this
fetch
back
to
define,
let's
better.
C
A
Yeah
so
I
like
unless
we
have
a
clearance,
basically
I,
don't
think
that
change
here
is
something
that
is
highly
observable
or
likely
to
impact
the
API
shape
so
or
it's
not
necessarily
even
a
change.
It's
just.
We
need
to
properly
define
it
right
now,
it's
not,
but
it
would
be
hard
to
do
that
before
fetch
integration.
So
it
can
wait
unless
you
know
if.
C
B
Okay,
thank
you.
The
next
one
is
issue.
Number
220
open
by
yo
a
couple
months
ago,
provide
a
TA,
oh
that
bypass
for
navigation
timing,
and
my
understanding
is
because
navigation
timings
built
on
top
of
the
resource
timing
thing
and
a
lot
of
the
resource
timing
attributes
are
kind
of
gated
by
ta.
Oh
we're
have
timing,
isn't
because
there's
this
the
navigation
that
doesn't
really
make
sense,
so
this
might
just
need
some
spec
language
yo've
to
make
it
clear
that
they
have
timing.
A
A
B
A
Navigation,
I
guess
there
are
multiple
types
of
navigation
timing
entries
here.
One
is
things
like
you
know
things
that
concern
the
document
that
is
being
fetched,
which
is
always
same
origin
and
therefore
like
to
itself
and
therefore
it's
always
like
they're
always
passing
the
time
you
allow
origin
check,
but
there
may
be
some
confusing
there
confusion
there
in
terms
of
the
language
and
then
there
are
the
entries
that
are
related
to
the
previous
document.
A
So
the
unloaded
meant
duration
and
redirects
that
led
to
the
current
document
and
those
they
were
timing
allow
origin
bound,
but
we
removed
it
because
it
just
doesn't
make
sense,
so
we
made
them
same
origin
bound,
and
we
need
to
clarify
that.
But
I
think
these
are
all
decisions
that
we've
made
last
year
during
the
like.
During
and
after
the
face-to-face
and.
A
B
The
next
batch
there's
three
separate
issues:
221
222
and
223,
which
seemed
to
have
come
from
part
of
the
ping
review
process.
One
of
them
is
a
brown
considering
moving
next
up
protocol.
Another
one
is
around
consider
removing
the
wild
card
option
for
ta,
oh
and
the
third
one
is
actually
related
to
ta
o
as
well,
but
I
guess
for
different
reasons
that
the
sessions
themselves
are
somewhat
lengthy
and
obviously
people
here
can
go
through
and
read
them.
I
guess.
My
question
is
what
our
next
steps
for
trying
to
resolve
some
of
these.
A
B
A
A
A
A
A
B
B
A
A
A
How
it's
already
exposed
so,
if
I'm,
looking
at
multiple
connections
like
multiple
requests
sent
to
a
single
host,
if
I
have
connect
time
connection
time
only
on
the
first
one
and
beyond
that,
all
of
them
are
seemingly
using
the
same
connection
versus
connection
time.
That
is,
you
know,
repeats
itself
over
multiple,
like
over
multiple
connections.
This
is
basically
h1
is
using
six
TCP
connections.
Each
one
of
them
is
connecting
separately,
where
h2
is
not
I'm
guessing
we
can
so.
This
is
a
very
obvious.
A
Detection
mechanism
I'm
guessing
between
h2
and
h3.
There
are
subtle,
like
the
differences,
are
more
subtle
and
and
like
the
end,
server
can
potentially
cause
explicit
packet
losses
in
order
to
you
know,
weed
out
the
differences
between
H,
3
and
H
2,
but
that's
a
bit
harder,
but
for
h1
versus
h2.
It's
just
very
like
very
easy
to
write
a
script
that
does
that
distinction.
C
A
E
A
Interested
first
of
all,
h2
to
h1
rollout
is
not
done.
There
are
still
properties
that
are
making
that
transition
and
need
like
want
to
prove
to
themselves
that
it's
a
worthy
one,
and
this
enables
them
to
measure
that
and
then
yes,
similarly
H
3
versus
h2
will
enable
to
measure.
You
know,
switch
some
part
of
the
traffic
to
the
new
protocol
measure.
The
differences
see
that
it's
good
and
then
continue
at
the
same
time,
and
this
like
it
may
be
hard
to
deploy.
But
when
we
shift
next-hop
protocol
we
didn't
really
have
server
timing.
B
We
can
see
kind
of
in
real
time
what
the
performance
is
so
from
both
from
our
customers
point
of
view
and
our
our
Akamai
infrastructures
point
of
view
getting
having
next
up
protocols
pretty
valuable
for
us
as
far
as
whether
it
could
be
inserted.
Timing,
I
think
we'd
have
to
think
things
through
that
a
little
bit
one
of
the
challenges
with
server
timing
is,
you
know
it
can
come
from
multiple
different,
perhaps
along
the
origin,
and
especially,
if
you
have
like
a
multi-tier
set
up,
they
could
all
be
adding
their
server
timing.
A
Whether
server
timing
can
be
a
viable
alternative,
I
can
also
see
if,
because
the
problem
here,
just
to
make
it
more
explicit
server
timing
is
something
that
is
set
but
by
the
application
layer
and
is
done
before
the
last
hop.
You
know
basically
before
the
network
stack
makes,
makes
a
decision
on
like
where
this
in,
like
what
protocol
not
before
it
makes
a
decision,
but
it's
it's
done
independently
to
the
layer
that
is
making
that
decision.
A
A
C
B
Yep,
that
sounds
fair
okay,
so
thanks
for
the
discussion
on
that,
there
are
two
other
related
ones
around
timing,
a
lot
origin,
but
I
did
see
that
Philip
had
joined
and
I
was
wondering
if
we
could
switch
back
to
page
visibility
and
kind
of
go
over.
Those
two
issues
does
that
sound
okay
to
everyone?
Yeah?
B
Okay,
so
we're
gonna
be
talking
about
page
visibility,
issues,
number
29
and
kind
of
a
related
paint
timing
issue
number
40,
which
are
related
to
logging.
If
a
page
ever
was
visible
and
I,
think
the
discussions
kind
of
rounded
out
to
being
something
around
a
page
visibility,
observer,
I,
don't
know.
B
C
The
recap
is,
we
had
two
options
here
to
surface
visibility,
changes
that
occur
early
on
during
the
page,
because,
right
now
we
have
an
event
handler
for
visibility
changes.
But
of
course
you
don't
get
any
updates
about
changes
that
occurred
before
you
register
the
handler.
So
that's
the
problem
we're
trying
to
solve
and
there's
one
option
was
setting
or
something
else
explicitly
and
the
performance
entry
so
that
you
know
this
entry
occurred
basically,
so
that
the
the
page
was
background,
a
that's
at
some
point
before
this
entry
occurred.
C
C
The
visibility
changes
of
the
page,
so
I
sent
an
email
thread
to
public
web
proof.
There
seemed
to
be
agreement
about
the
observer
way.
However,
there
is
some
pushback
on
the
paint
timing
issue,
in
particular
from
Mike
sheriff
we're
saying
that
it
should
still
be
something
explicit
in
the
entry
so
that
developers
don't
get.
C
Like
basically
confused
about
this
and
don't
forget
to
like
exclude
these
entries,
if
they're
trying
to
like
aggregate,
for
example,
for
being
timing,
obviously
that
can
make
a
huge
difference,
because
if
you
just
open
in
the
background
and
then
come
back
to
it,
then
the
pain.
The
first
paint
value
with
the
extremely
high.
G
Yeah
he
put
them
another
way.
I
think
it
was
a
discoverability
issue
that
he
was
concerned
about
I,
didn't
or
would
have
to
know
that
page
visibility
affects
paint
I
mean
in
order
to
exclude
it,
whereas
if
there
is
a
tree
explicitly,
if
there's
a
full
light
on
the
entry
explicitly,
they
might
discover
it
there
I
mean
in
all
cases.
G
You
know
the
guidance
on
the
web
will
have
to
be
pretty
clear,
but
it
did
seem
to
me
like,
like
it
would
be
easier
for
developers
to
discover
this
if
it
was
on
the
entry
and
for
my
own
experience
with
you
know,
promoting
FCP
and
LCP
externally
and
looking
at
writing
sample
code,
where
I
did
not
include
this
check.
Thinking
that
oh,
this
is
a
simple
case.
I
want
to
write
it.
My
simple
code
to
be
as
simple
as
possible.
G
My
point
was
that
I
think
we
should
do
both
I
think
having
the
page
visibility.
Information
available
is
really
helpful
in
general,
but
I
still
think
we
should
have
some
kind
of
flag
on
the
entry
that
says,
like
the
user
agent
thinks
that
maybe
you
shouldn't
trust
this
entry
because
of
whatever
reason,
maybe
the
page
was
in
the
background.
Maybe
dead
too
was
open.
Maybe
it's
running
on
webdriver
tests
or
there's
some
of
the
things
that's
happening.
A
Yes,
so
I
think
that
last
point
is
the
most
meaningful
one,
because,
yes,
page
visibility.
Observer
will
give
us
a
full
picture
as
to
whether
you
know
how
impacted
was
the
resource
and
will
enable
folks
to
you
know,
create
a
better
image
and
maybe
decide
that
pages
that
were
back
rounded.
But
you
know,
for
a
small
fraction
of
time
are
still
counted
or
still
counted
as
something
else.
A
You
know,
and
you
know,
enable
people
to
observe
how
visibility
impacts
performance,
but
visibility
is
not
necessarily
the
only
thing
that
will
involve
painting
and
maybe
like
having
both
I
guess.
It's
just
a
question
of
resources
and
how
hard
it
would
be
to
add
support
for
both,
but
it
seems
to
be
valuable.
C
A
B
A
C
C
G
Was
a
layout,
chef's
kind
of
have
this?
Alright,
we
have
a
flag
that
says,
includes
recent
input
or
had
had
recent
input
or
something
like
that.
It's
concepts
it's
conceptually
similar
and
we
added
that
specifically
because
we
didn't
want
people
to
have
to
deal
with
timestamps
with
events
and
then
like
manually
exclude,
but
we
kept,
we
kept
the
entry
being
dispatched
in
case
they
wanted
to,
for
some
reason.