►
From YouTube: W3C WebPerformance WG Design call - March 14th 2019
A
A
We
need
to
subscribe
for
days
we're
gonna
go
for
two
days
as
usual,
we're
probably
gonna
go
for
Monday
and
Tuesday,
but
we
were
wondering
which
groups
we
should
ask
for
like
to
avoid
conflicts
with
I
heard
from
Marcus
that
he
would
like
to
avoid
CSS
and
Houdini
meeting
conflicts.
I
can
ask
for
that
any
other
conflicts.
We
should
try
to
avoid
ríos
k,
specifically
as
I
know
that
last
time
around
you
had
many
conflicts.
So,
oh.
A
E
A
A
A
F
F
G
I
guess
I
don't
have
a
proposal.
This
is
more
questions
to
the
group.
This
came
up
in
a
couple
of
discussions
on
some
of
the
internal
mailing
lists,
so
when
I
got
a
pulse
from
this
group,
so
the
observation
is
chrome
is
shipping,
sign
exchanges
and
if,
if
you're
not
familiar
that
the
general
idea
is
you
can
rap,
you
can
rap
on
a
single
document.
It's
a
sign
exchange
that
can
be
served
off
some
CDN
edge.
G
That
is
not
your
origin
and
when
the
browser
fetches
the
sign
exchange,
it
will
verify
the
identity
and
present
the
URL
as
if
it's
coming
from
the
actual
origin.
So
one
particular
problem
it
solves
is
the
amp
cache
or
amp
documents
where
currently
they're
being
served
off.
Google
cache
and
they
have
the
camp
m
cache
CDN,
and
we
would
like
to
show
the
actual
origin
of
that
page.
That's
one
of
these
cases.
So
if
that's,
if
that's
a
platform,
primitive
one
interesting
question
is
what
implications
does
that
have
for
performance
telemetry?
G
Because
now
your
document
can
be
served
off
the
origin
and
it
can
also
be
served
off
some
CDN
edge
and
presumably
the
performance
characteristics
might
be
significantly
different,
because
the
CDN
cache
is
closer
to
the
user
or
has
some
different
characteristics.
What
does
this
actually
mean
for
our
performance
api's,
for
example,
in
the
network
or
logging
api?
We
actually
recently
added
some
changes
that
will
allow
you
to
distinguish
when
a
sign
exchange
failed
to
load.
So
that's
one
example
where
one
of
our
performance
api's
is
already
providing
some
telemetry
about.
G
It's,
not
just
that
the
navigation
to
your
origin
failed.
It's
the
sign
exchange
that
failed
slow.
What
about
something
like
navigation
timing,
for
example,
would
or
should
navigation
timing
actually
expose
some
new
attribute
or
new
information
about
the
fact
that
this
particular
navigation
is
actually
for
sign
exchange.
It
was
meaningfully
different
to
you
who's.
You.
A
B
A
A
G
G
So,
for
example,
when
a
user
on
Twitter
or
on
Google
search
clicks
on
a
link
that
that
links
to
the
sign
exchange,
the
exchange
is
loaded
off
the
CDN,
not
off
your
origin,
and
because
it's
signed,
we
can
verify
the
authenticity
and
present
the
URL
as
if
it
came
from
the
actual
origin.
So
we
will
present
the
origins
URL,
but
the
implication
for
performance
here
is
what
do
we
say
if
anything,
if
you
have
your
performance,
ulema
tree
collecting
data
about.
G
G
So
a
platform
like,
let's
say,
Twitter
or
Google
search
would
know
to
point
to
their
education,
so
a
concrete
example
would
search
we
crawl.
The
page
during
the
crawling
we
identified
that
you
advertise
support
for
sighing
exchange.
Our
cache
then
picks
up
the
signed
exchange
puts
it
into
our
cache
and
in
the
future,
when
they
user
clicks
on
the
link
we
directly
to
the
cache
version.
Oh.
B
G
B
G
How
do
we,
how
do
we
verify
that
it's
signed
by
the
yeah
so
I
think
we're
getting
into
the
weeds
of
the
actual
sign
exchange,
which
would
probably
be
a
good
thing
for
us
to
review,
but
I
don't
want
to
take
too
much
time
on
it
right
content,
so
we
do
verify
like.
Basically,
we
verifying
the
authenticity.
We
verify
that
the
content
hasn't
been
modified.
As
you
have
said,
we
don't
provide
that
doesn't
provide
the
confidentiality
I
guarantee
that
CLS
does,
but
it
decouples
the
identity
from
the
end-to-end
confidentiality
I.
B
A
A
It
does
not,
so
the
browser
doesn't
verify
with
the
original
origin
that
the
content
is
authentic.
At
least
that's
the
there
are
discussions
about
doing
such
verification
on
some
basis,
but
there
are
trade-offs
there
with
it
like
between
user
privacy
and
and
having
a
quick
way
to
verify.
The
content
is
purged,
so
the
browser
knows
that
the
origin
has
signed
this
content
within
the
last
few
days.
That
is
something
that
the
browser
knows.
A
It
doesn't
need
to
Rivera
fie
that
with
the
original
origin,
but
there
can
be
cases
where
the
origin
has
signed
a
typo
and
then
tries
to
revoke
it.
So
there
are
mechanisms
in
the
caches
for
making
that
kind
of
purges
and
making
those
verifications.
There
are
ongoing
discussions.
Whether
or
not
the
browser
should
also
do
that
kind
of
verification.
E
G
Pause
this
I.
What
I'm
hearing
is.
It
sounds
like
what
we
should
do
is
draft
like
do
a
little
bit
of
an
audit
and
draft
a
summary
of
how
this
works
and
think
through
the
implications
for
resource
timing
and
navigation
timing,
I
was
hoping
to
get
like
a
quick
gut
check,
but
I
think
we
need
to
do
some
groundwork
before
we
can
even
do
that.
So
I
can
take
that
as
an
AI,
yeah
I'd
say
the
gut
check
is.
We
definitely
need
telemetry
for
this
situation
to
distinguish
it.
G
I
I
We've
already
presented
briefly
element
timing
for
images.
This
is
more
focus
on
text.
The
idea
is
that
we're
going
to
expose
entries
for
important
text
components
of
a
website.
So
brief
recap
right
now.
The
element
timings
expert
says
that
performance
entry
and
it
has
three
additional
fields.
This
has
changed
since
the
last
presentation.
The
intersection
rect
is
the
intersection
with
the
viewport
response
and
is
the
images
resource
response,
and
so
it
comes
actually
from
resource.
Timing
and
identifier
is
element.
Timing,
attribute
value.
I
We've
decided
to
change
name
to
be
the
resource
timing,
name
just
for
consistency
with
research
timing.
So
for
image
element
timing.
We
want
to
expose
image
elements,
images
that
are
inside
SVG,
poster
images
of
videos
and
background
images.
The
weird
case
there
is
background
images
because
they
are
not
Dom
elements,
so
the
way
you
would
expose
them
is
you
have
to
observe
the
Dom
elements
that
is
affected
by
the
CSS
property.
I
Again,
to
recap,
for
we
have
two
types
of
registration:
we
have
developer
led
registration,
which
is
basically
the
study
element,
timing,
attributes
to
some
value
and
the
second
one
is
automatic,
an
alkaloid
automatic
registration,
which
is
when
the
image
occupies
a
significant
portion
of
the
viewport.
Then
we
dispatch
an
entry
corresponding
to
that
image.
So
now
that
I,
recount
how
element
timing
is
working
currently,
four
images,
let
me
now
propose
how
it
would
look
like
for
text.
So
the
first
problem
is
text
is
that
text
nodes
are
not
elements,
so
we
want
well.
B
I
B
I
All
right
so,
as
you
note
that
the
text
component
has
not
been
added
to
that,
so
the
W
ACG
link
is
just
very
images
so
right
now,
this
is
like
a
fairly
recent
proposal
to
add
text
and
wanted
to
hear
some
thoughts
about
it.
I
everyone
explainer
about
it.
There
are
still
things
that
need
to
be
worked
on.
I
The
problem
being
that
usually
there
is
some
hierarchy
between
the
element
and
text
need
to
be
a
sans
dips
and
whatnot.
So
we
plan
to
do
some
research
on
this
by
looking
at
corpus
of
websites,
probably
Alex
at
10k
websites,
and
see
what
would
make
sense
for
those
and
then
propose
how
to
define
which
text
nodes
we
go
along,
which
Dom
elements
so.
K
A
Think
which,
like
maybe
in
a
pro
a
reasonable
approach,
would
be
to
take
the
similar
coverage
approach
of
images
on
the
whole
viewport
and
to
apply
them
to
elements.
So
if
an
element
has
text
that
is
rendered
and
sometimes
that
isn't
rendered,
it's
fully
rent
like
we
can
say
it's
rendered
when
some
percentage
of
its
text
is
rendered
and
I'd
like
I,
don't
know
what
that
percentage
might
be,
but
that
could
be
from.
K
I
The
idea
being
that
ideally
we'd
like
to
not
allow
things
like
I,
don't
know,
set
an
element.
Timing
attribute
for
your
body
and
basically
you'd
have
to
wait
for
all
of
the
text
to
be
rendered
and
so
on,
because
this
will
involve
computation
of
the
bounding
boxes
of
the
texts.
I'll
explain
that
a
bit
later,
but
I
think
the
question
here
was
more
about
how
blogging
should
work
and
by
belonging,
I
mean
which
text
node
should
be
considered
for
which
Dom
elements?
I
I
Automatic
registration,
we
want
automatic
registration
for
text
as
well,
so
a
lot
of
these
competitions
have
to
be
done
regardless,
and
so
we
want
them
to
be
efficient
and
so
in
particular
saying
that
attacks
in
that
would
be
long
suit.
Of
some
elements
that
are
contained
in
it
would
mean.
Then
you
have
to
do
a
lot
of
computations.
So
that's
that's!
The
problem
could.
D
K
I
think
the
concrete
example
where
the
first
doesn't
make
a
lot
of
sense.
Consider
two
headlines.
That
are
two
words:
each
is
the
first
one.
The
first
word
is
bold
and
the
second
one.
The
second
word
is
bold.
It
seems
kind
of
and
say
the
full
text
load
slowly.
It
seems
kind
of
strange
to
say
that
the
one
is
significantly
different
reports
perspective
from
the
other,
the
other
option,
the
word
and
it
considering
is.
Can
we
found
the
depth
that
we
consider
text
nodes
to
belong
to
elements?
I
I
think
this
needs
to
go
under
some
research
in
terms
of
looking
at
websites.
I
guess
it's
kind
of
hard
to
reason
about
it
before
that.
So
I
was
just
wondering
if
anyone
had
any
clever
ideas
that
we
could
use
the
way
we
could
explore
as
well
when
we
do
this
research,
but
if
not
then
we'll
we'll
go
with
it
and
see
what
happens
so.
F
B
Mm
sighs
doesn't
work
correctly.
We
should
find
the
different
locations
depth
of
Dom
trees,
complete
irrelevant
right,
like
the
tricky
cases
of
overflows
and
clipping,
and
you
know,
text
wrapping
and
so
forth.
I
get
it
computing.
A
bounding
boxes
text
is
notoriously
expensive
because
of
that
I
know,
I,
don't
think
limiting
what
based
on
Dom
tree
tips
of
any
problems.
B
B
Do
we
know
that,
like
we're,
painting
right
so
it's
pretty
inexpensive,
what's
expensive
is
the
fact
that
now,
like
whatever
this
thing
is
set,
we
have
to
remember
for
the
fact
for
the
element
and
we
basically
you
know
I'm
combining
the
rack
to
whatever
be
overflows
so
I,
don't
it's
really
the
overflow
that's
expensive
right
we
can
grow
on
all
over
floors.
Is
the
easy
right.
K
D
I
Does
this
is
relevant
to
your
question,
I
think,
because
an
element
for
an
element
to
be
considered
rendered?
We
just
need
to
wait
for
all
the
text
notes
to
have
renders
the
first
time.
So
in
the
case
where
content
is
injected
asynchronously,
then
that
could
be
a
race
condition
if
I'm
understanding
correctly
your
questions
with.
K
I
It's
a
CSS,
then
yeah
I
think
this
is
affecting
an
element
is
hosts
synchronously,
so
it
will
just
to
the
dam.
I
was
thinking
about
JavaScript
content.
That
would
be
asynchronous
its
software,
the
scripture
and
it's
afraid.
So
that
is
a
problem
which
I
think
I
think
is
not
very
common,
so
I
think
it's
okay,
that
we
a
case.
So
basically
we
just
consider
the
element
rendered
when
all
the
text
notes
have
been
first
rendered
and
design
answer.
The
question.
D
I
I
We
want
to
define
the
size,
and
this
is
relevant
only
for
registration,
automatic
registration,
which
means
that
which
which
elements
are
considered
important.
Those
will
have
an
element.
Timing
entry
dispatched,
regardless
of
if
there
is
an
element,
timing
attribute
or
not
so,
for
that
I
proposed
just
adding
the
sizes
of
the
text.
Nodes
that
belong
to
the
element.
K
I
I
I
So
far,
I
think
for
image
element
and
we
haven't
moved
away
from
that.
The
reason
being
that
considering
like
some
other
proposals,
would
involve
setting
in
how
to
the
point
of
when
we
stopped
looking,
which
I
think
is
not
ideal
but
yeah.
That's
a
good
point.
The
question
of
which
elements
are
considered
important
by
themselves
is
still
open
for
debate,
but
right
now,
yes,
we're
using
percentage.
C
K
I
B
I
I
Base
it
is,
it
didn't,
have
a
great
idea
for
this
one,
because
the
element
can
contain
a
bunch
of
text,
notes
that
are
sprayed
all
over,
so
I
just
went
with
basically
the
smallest
rectangle.
That
should
be
smaller.
Sorry,
that's,
okay,
the
smallest
rectangle
that
contains
all
of
the
text
notes
belonging
to
the
element.
I
I
B
K
B
K
I
A
I
I
E
I
I
The
script
right
away,
because
then
you
can't
do
any
but
basically
performance
observer,
would
allow
the
browser
to
dispatch
the
callback
whenever
it's
idle
or
whenever
it
thinks
that
the
work
can
be
done
without
affecting
the
user.
But
right
now
a
big
flaw
with
performance
observer
is
that
we
don't
expose
entries
from
the
past.
I
K
I
And
the
other
pull
up
the
other
problem
is
that
obviously
the
browser
itself
still
has
to
keep
a
list
of
the
entries.
So
we
still
need
to
decide
in
a
way
to
handle
the
size
of
this
buffer,
preferably
without
so
much
methods
as
we
did
with
reserved
standing,
which
has
the
set
size
and
so
on
so
I
have
we
had
a
complete
proposal
to
just
a.
I
I
That's
a
good
question
in
my
proposal.
I
said
basically
keep
resource
timing
as
it
is
because
it
feels
like
that
would
be
a
breaking
change
and
I.
Don't
I,
don't
feel
like
yeah
I
feel,
like
developers
will
not
like
that
suggest
it
out
of
the
mood
change
the
behavior
so
much
because
resource
timing
already
does
their
own
buffer
handling,
which
is
visible
to
developers.
Russell
is
more
about
new
entry
types
or
the
ones
that
don't
have
this
kind
of
behavior
right
now,
so
think
about
so
long
tasks.
I!
I
H
D
I
I
K
K
I
I
I
G
I
I
K
G
Yeah,
you
may
also
just
be
like
a
documents
or
something
that
we
need
to
drop
those
general
guidance
because
I
think
what
I'm
hearing
is.
We
want
to
drive
people
away
from
get
entries.
So,
if
I'm,
if
I'm
onboarding
somebody
new,
like
writing
a
spec,
the
guidance
would
be.
You
should
be
using
performance
observer.
First
of
all,
like
that's
your
bread
and
butter,
but
performance
observer
does
not
address
the
initial
load
use
case
where
you
have
to
register
it.
So
for
that
we
support
some
buffering
capability.
G
Your
responsibilities
specify
the
number
of
events
that
will
be
buffered
and
if
the
driver
passes
in
the
buffer
flag,
they'll
be
able
to
retrieve
it,
but
they
plus
an
implicit
assumption
is
that
by
the
time
that
buffer
should
be
large
enough
such
that
you
should
be
able
to
register
a
performance
observer
to
have
the
full
picture
right,
even
if
we
say
nothing
about
the
global
get
entries
and
all
the
rest.
Basically,
we're
saying
characterizes
a
legacy
thing
that
we're
trying
to
migrate
away
from.
G
F
If,
if
we
want
to
have
the
new
performance
observer
as
the
new
API,
we
should
it
be
consumed,
so
we've
declared
that
buffering
solve
some
existing
things,
navigation,
timing,
resource
I
mean
etc,
but
it
is
also
might
be
that
you
need
something
like
headers
or
HTML
in
the
head.
You
know
our
meta
tags
that
set
these
buffers.
It
may
not
be
that
the
default
buffers
are
sayest.
That's
another
way
to
think
about
this.
Yeah.
K
C
F
F
D
Gate
on
trees
allow
you
to
access
some
trees
that
we're
notified
before
you
had
a
chance
to
register
an
observer
by
the
way.
So
I.
Don't
think
that
we
ever
I
mean
correct
me
if
I'm
wrong,
I
haven't
followed
that
closely
lately,
but
I.
Don't
think
we
have
a
resolved
the
problem
of
what
about
entries
that
gets
added
before
we,
even
at
the
time
to
attach
an
observer.
So.