►
From YouTube: WebPerfWG Call - December 3rd 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
Thank
you.
I
guess.
First,
things
first
is
to
figure
out
when
we're
gonna
talk
next,
so
two
weeks
from
now
would
be
december
17th.
I
know
that's
starting
to
get
closer
to
holidays
and
potential
time,
offs
and
stuff,
although
two
weeks
after
that
is
also
new
year's
eve.
So
I
didn't
know
what
people
wanted
to
do
for
a
meeting
next.
If
we,
I
think
in
some
years
past
we've
kind
of
skipped
some
of
the
middle
december
meetings.
B
C
It's
it's
my
last
work
day.
I
think
a
lot
of
us
at
google,
that's
the
last
workday
before
a
lot
of
folks
are
taking
vacation.
It
seems
perhaps
not
advisable
to
meet
with
a
busy
important
schedule.
On
the
other
hand,
it
might
be
a
good
time
to
do
some
things
that
are
somewhat
optional,
but
on
our
backlog
and
rather
than
meeting
six
weeks
from
now
right.
A
Yeah,
I
don't
know
that
we
have
a
ton
of
things
on
the
like
issue
backlog,
so
it
seems
safe
to
skip
from
my
perspective.
Unless
people
have
things
they
want
to
discuss.
A
B
Okay,
we'll
go
with
that
unless
there's
any
other
reason
to
change
that
later
today,
we
have
a
little
bit
shorter
of
a
total
agenda,
but
we
definitely
have
some
things
to
talk
about.
I
think
david
would
like
to
first
talk
about
page
visibility
in
transient
states,
and
then
we
also,
I
think
we
just
have
one
new
issue
from
recently
to
discuss
about
research,
timing,
transfer,
size,
size
and
http
only
cookies.
D
Present
sorry:
what's
the
meeting
name.
B
D
Okay,
can
everybody
see
that.
D
Okay,
so
hi
everyone,
I'm
david
volkan.
I
work
on
the
chrome
team
working
on
some
of
the
pre-rendering
changes
that
we're
working
on,
and
you
might
remember
me
from
the
discussion
we
had
around
pre-rendering
at
tpac,
so
I
just
thought:
I'd
come
back
and
give
a
small
update
on
some
of
the
changes
that
we're
proposing
for
pre-rendering
state
and
I'm
mostly
doing
this
just
to
share
some
visibility
into
what
we're
working
on
and
to
solicit
feedback
early
in
the
process.
So
this
is
all
still
super
early.
D
We're
willing
to
change
course
if
needed
and
then,
given
that
pre-rendering
is
very
closely
related
to
web
perf,
and
this
group
previously
specified
the
last
iteration
of
like
the
pre-rendering
visibility
state.
So
I'm
hoping
to
reach
some
of
the
right
people
here
and
feel
free
to
reach
out
to
me
either
today
or
any
other
time.
D
So
this
is
basically
the
proposal
as
I
currently
see
it,
and
it's
different
from
the
visibility
state
in
that
it's
completely
decoupled
from
visibility.
D
But
basically
this
repo
defines
this
new
concept
of
a
pre-rendering
browsing
context
and
this
this
kind
of
context
places
restrictions
on
documents
that
are
relevant
for
pre-rendering.
So,
for
example,
like
you
can't
window.open
or
you
can't
show
alert
boxes
and
things
like
that,
and
so
this
new
bit
on
document
would
basically
just
be
visibility
into
whether
or
not
you're
in
that
kind
of
a
browsing
context,
as
well
as
an
associated
event
handler
whenever
that
changes.
D
So
we
had
a
good
discussion
at
tpac
around
some
of
like
the
early
thoughts
here,
and
we
got
some
good
ideas
and
feedback.
I
decided
to
take
a
look
at
how
some
of
the
visibility
state,
both
like
the
existing
ones
and
then
the
how
the
pre-render
value
was
used
on
the
web.
I've
got
a
doc
here.
You
can
look
at
it's
somewhat
long-winded
and
unfocused,
but
it
might
help
explain
how
we
got
to
where
we
are,
and
it
basically
boiled
down
to
looking
through
http
archive
at
some
random
sample
of
pages
that
use
visibility
state.
D
It
still
required
some
manual
inspection
since
it
was
noisy.
So
the
conclusions,
don't
necessarily
give
you
an
exact
percentage
of
like
how
often
pages
do
certain
things,
but
it
was
really
useful
to
find
some
interesting
use
cases
and
kind
of
like
what
the
rough
frequency
is
of
some
of
these
things.
C
D
C
D
The
exact
thing
I
did
was
looking.
I
would
take
the
whole
page
and
just
run
inner
text
over
that
and
then
basically
do
a
string
comparison
with
some
some
of
the
kind
of
common
pitfalls
removed.
So,
for
example,
like
dates,
I
would
just
strip
into
all
zeros
and
numbers
and
things
like
that:
okay,
but
it
was
any
kind
of
textual
differences
really
so
for
things.
C
D
Autoplay
audio,
for
example,
or
so
that
wouldn't
yeah
so
that
wouldn't
show
up
there.
This
did
filter
out
things
like
differences
from
just
like
random,
ads
or
images.
But
then
there
was
some
noise
for
other
reasons,
and
so
I
would
kind
of
go
through
case
by
case
and
then
just
look
at
what
the
page
was
actually
doing
so
from.
E
D
D
So
yeah
the
use
cases
that
I
found
generally
broke
down
into
these
five
buckets,
so
very
common
that,
like
videos
and
animations,
would
want
to
start
or
stop
playing.
So
in
some
cases
I
did
actually
notice
like
animations,
because
there
might
have
been
some
some
text
or
something
that
that
changed
there
or
just
the
layout
of
the
page,
there's
also
fetching
of
large
images
and
resources
so
sometimes
pages
if
they're
hidden.
D
They
don't
want
to
download
like
some
of
the
the
top
images,
I'm
not
necessarily
sure
why
they
do
this.
It
might
just
be
to
save
on
bandwidth
or
it
might
be
that
they
want
to
fetch,
like
the
latest
images,
when
the
page
comes
into
view,
there's
also
avoiding
measuring
of
any
kind
of
like
user
metrics.
So
ads
is
a
major
use
case
here,
but
I
did
also
find
some
ads
and
analytics
libraries
that
use
the
pre-rendering
state
specifically
to
to
avoid
this,
and
then
there
were
some
features
that
have
some
server-side
logic:
a
common
example.
D
Of
other
use
cases
like
this,
so
one
that
comes
to
mind
is
like
you
don't
want
to
start
like
a
if
you're
trying
to
buy
an
airline
ticket.
You
don't
want
to
start
the
countdown
timer
when
it's
pre-rendered,
you
want
to
start
it
when
the
user
navigates
the
page
and
finally,
that's
not
related
to.
I
didn't
actually
find
any
use
cases
this,
but
I
know
that
we
use
visibility
state
as
a
termination
signal.
D
D
D
The
first
one
is
that
some
of
the
assumptions
around
what
pre-rendering
is,
I
think,
are
going
to
change.
So
from
my
perspective,
this
is
mainly
due
to
portals.
So
the
portals
proposal,
if
you
don't
know,
is
basically
allowing
you
to
show
a
live
preview
of
a
pre-rendered
page,
so
pre-render
invisible,
won't
be
mutually
exclusive
states
anymore,
but
even
without
portals.
D
The
second
reason
is:
it's
not
really
mutually
exclusive
with
hidden
either.
So
I
think
this
was
already
a
problem
in
like
the
visibility
state
case,
but
if
you're
pre-rendered
in,
like
the
classic
sense,
you're
also
technically
hidden.
So
this
is
less
problematic
from
like
the
user's
point
of
view
since
like
if
you
do
have
bad
code
like
this.
D
It
would
just
result
in
the
pre-rendered
page
thinking
it's
visible,
but
it
might
mean
that
you're
doing
some
wasteful
work
or,
if
the
page
really
wanted
to
the
user,
to
see
like
an
animation
when
they
visit
the
page
might
load
with
the
animation
already
finished.
D
It's
also
less
ergonomic
for
authors
to
use,
so
you
have
to
if
you
want
to
really
get
this
right.
You'd
have
to
write
these
kind
of
cases
where,
like
if.
E
D
Hidden
or
you're
pre-rendered,
then
you
have
to
do
this
thing.
We're
really.
If
you
look
at
some
of
these
use
cases,
the
ones
related
to
like
animation
and
loading
resources,
they're
really
more
concerned
with
whether
or
not
you're
on
screen
they
don't
actually
care
if
you're,
pre-rendered
or
not
so,
authors
shouldn't
really
have
to
reason
about
these
sub
states,
and
in
this
case
specifically,
you
might
say
like
well.
D
The
natural
thing
here
to
do
would
be
if
visibility
state
is
not
visible,
but
then
that
gets
you
back
to
the
broken
cases
and
portals,
and
it
takes
us
to
the
next
point,
which
is
their
code
like
this
already
exists,
and
I
found
plenty
of
examples
of
pages
that
would
basically
just
assume
that
there's
only
two
visibility
states.
D
D
So
to
summarize,
basically,
every
combination
of
pre-rendering
and
visibility
can
occur,
so
we
have
basically
all
the
states
here,
and
I
think
that
this
is
a
good
reason
to
split
it
out
into
a
totally
orthogonal
state
and
given
that
we're
already
going
to
be
asking
authors
to
do
some
work
to
opt
into
the
new
pre-rendering.
I
think
that
this
is
a
small
and
reasonable
change
and
then
the
other
topic
that
came
up
is
that
visibility
state
is
currently
used
as
a
termination
signal,
so
issue
59
in
the
visibility
page.
Visibility.
D
Github
repo
has
some
details
on
this,
but
the
basic
summary
is
that
on
mobile,
being
backgrounded
means
that
the
os
might
kill
you
without
notice,
so
we
can't
run
unload
handlers.
So
authors
have
been
told
to
just
use
the
hidden
state
as
a
signal
to
do
any
kind
of
work
like
sending
out
beacons
or
saving
state
and
there's
some
interesting
edge
cases
here
that
are
related
to
some
of
the
issues
that
we're
having
in
pre-rendering
so
app
and
tab.
D
So
I
think
the
solution
right
now
is
to
kind
of
lie
to
the
page
and
just
say
that
actually
you're
hidden,
but
in
in
an
app
switcher
like
on
ios
or
on
android,
like
we
expect
that
the
app
should
still
look
and
feel
like
it's
alive.
So
if
you
open
a
youtube
page
and
then
like
in
the
native
app,
if
you
open
a
youtube
page
and
then
go
into
the
app
switcher
in
ios,
you'll
see
that
it
still
plays.
D
D
The
page,
sorry,
I
lost
my
train
of
thought
here
right
when
we
enter
into
a
portal.
D
Right
when
we
enter
into
a
portal,
I
think
that
this
is
one
of
those
places
where
we
would
actually
want
to
save
state
and
and
so
having
having
an
explicit
state.
For
this,
I
think,
would
be
a
much
better
solution
than
relying
on
just
visibility,
and
so
we
could
also
think
of
like
the
app
switcher
or
the
tab
switcher
as
being
a
place
where
maybe
pre-rendering
equals.
True
might
also
make
sense.
In
those
cases.
D
So
that's
basically
everything
that
I
have
and
I'm
interested
if
anybody
has
feedback,
whether
it's
something
critical
or
or
reasons
that
this
might
not
work
or
just
to
say
that
we're
on
the
right
track.
So
there's
some
links
that
I've
left
to
the
github,
repo
and
I'll
make
sure
that
they
get
added
to
the
agenda
but
yeah.
That's
basically
it
thanks
for
your
time
and
I'm
happy
to
answer
any
questions.
If
you
have
them.
F
I
wonder
if
we've
thought
about
exposing
the
previous
pre-rendering
history
for
a
script
or
something
I'm
thinking
about
the
the
current
issue
with
we
have
with
visibility
states
is
that
if
you
load
the
script
too
late
for
some
reason,
basically,
you
may
miss
data,
so
the
the
proposed
interface
has
the
same
problem,
because
it's
just
basically
copy
based
from
the
current
interface
of
visibility
state.
So
what
are
your
thoughts
on
that?
D
Where
you
basically
want
to
know,
have
I
ever
been
pre-rendered
right.
F
Yeah
I
I
presented
a
performance
observer-ish
kind
of
solution
where
basically,
we
would
buffer
the
previous,
in
this
case,
visibility,
history
and
then
you
could
just
register
the
observer
later
and
set
the
buffer
flag
to
true,
which
would
get
you
the
stored
previous
states
and
then
obviously
they
would
have
some
time
stamp
to
say
when
this
happened
and
it
seems
like
we
may
even
need
both
this
and
the
observer
thing,
because
some
of
the
use
cases
seem
to
require
like
pretty
quick
notification
when
the
state
changes
due
to
like.
D
Yeah,
I
think
so
yeah
I'd
have
to
consider
that
you
what's
the
name
of
that.
F
I
can
send
you
the
my
slides
later.
I
just
presented
it
to
the
working
group,
so
it
really
has
no
name
I
mean
or
something
like
visibility,
state
entry,
yeah.
D
B
Yeah
and
for
analytics
being
able
to
know
whether
the
page
the
page
had
been
loaded
under
a
pre-render
like
state,
I
mean
it's
definitely
gonna
affect
the
characteristics
of
the
page
and
kind
of
how
it's
presented
to
the
user
and
everything.
So
I
think
from
from
an
analytics
point
of
view,
it
nice
people
it'd,
be
nice
to
be
able
to
put
that
into
this
page
had
been
pre-rendered
bucket
or
not.
B
Loading
too
late,
you
wouldn't
be
able
to
like
many
analytics
load
at
download
or
later
and
if
there's
only
a
boolean
of
like
what
is
the
current
state,
we
wouldn't
know
whether
it
had
been.
D
That's
a
good
point
yeah.
I
was
going
to
say
that
the
the
reason
I
thought
this
was
less
of
an
issue
for
pre-rendering
was
the
only
way,
at
least
that
in
our
current
state
that
you
could
enter.
Pre-Rendering
is
through
a
portal
which
requires
a
user
gesture,
which
means
that,
like
most
likely,
your
scripts
will
be
loaded.
But
if
you're
loading
analytics
after
page
load,
then
yeah.
That
would
be
a
problem.
F
And
doesn't
safari
do
already
some
sort
of
pre-rendering
in
the
url
bar,
so
I
presumably
you'd
want
that
to
be
surfaced
via
this
api
as
well.
Right-
and
I
mean
it's
not
really-
I
mean
I
don't
know
if
you
count
it
as
a
user
gesture
for
the
navigation
that
hasn't
happened
right.
D
Yeah
yeah,
I
think,
there's
a
number
of
use
cases
you
could
imagine
using
this
so
like
yeah,
the
app
switcher
is
another
case
where
maybe
you
enter
it
and
like
you
might
even
load
into
it.
So
maybe
you
don't
even
need
a
user
gesture.
C
David,
I
have
a
whole
bunch
of
things
to
discuss.
First
of
all,
I
wanted
to
just
start
with
saying
excellent
documentation,
I'm
so
glad
after
tpack
you
went
and
actually
did
a
bunch
of
the
research
and
all
of
the
charts
that
you
created
and
the
thing
it
was
great
reading
through
and
actually
finding
a
lot
of
conclusions
to
the
questions
that
I
had.
C
I
don't
necessarily
know
where
to
start.
So
I
think
that
I,
like
nicholas,
like
the
separation
of
this
new
type
of
state
from
the
existing
visibility
state.
I
think,
for
all
the
reasons
discussed,
we
should
keep
them
distinct.
C
C
D
Two
questions
there
one
was
about
whether
this
was
really
pre-rendering
versus
non-interactive,
and
so
I've
thought
about
this,
a
bunch,
because
that
was
the
first
kind
of
thing
that
I
thought
I
I
went
off
and
thought
about
the
interesting
case
there
is
like.
Do
you
consider
a
background
tab
to
be
interactive
or
not?
I.
C
Would
say
that
I
consider
a
background,
tab,
non-interactive,
and
so
I
know
I
saw
in
your
naming
open
questions
at
the
end
you
assumed
that
it
wouldn't
be,
and
so
maybe
that's
a
discussion
worth
having,
but
I
assumed
that
the
mental
model
right
now
is.
You
are
either
interactive,
invisible
or
non-interactive
and
not
visible,
and
there
are
cases
that
were
brought
up
where
actually
you
are
still
visible
but
no
longer
interactive,
and
so
that
was
the
there
was
a.
C
There
was
a
separate
request
to
add
a
non-interactive
mode
for
those
cases,
and
I
think
you
listed
them
out
and
so
being
not
visible
is
just
further
down
the
path
of
still
being
non-interactive.
That
was
my
mental
model.
D
So
the
the
problematic
case
there
is
for
things
like
analytics
where,
if
it
loads
into
a
background,
tab
like,
for
all
intents
and
purposes,
that's
still
like
a
live
page,
and
so
we
need
some
signal
to
discriminate
that
from
really
like
the
user
hasn't
clicked
on
the
link.
We
don't
want
to
do
anything
that
would
imply
that
the
user
has
intentionally
navigated
to
the
page.
D
C
D
Yeah
so,
for
example,
ads
ad
measurements
will
still
happen
that
but
they'll
they'll
make
a
note
that
the
page
was
hidden
until
you
show
it.
So
I
think
the
the
important
thing
that
they
want
to
measure
is
whether
or
not
the
page
was
intentionally
loaded
rather
than
whether
or
not
it's
visible
or
whether
or
not
it's
interesting.
C
So
there
is
a
distinction
conceptually
between
a
pre-render
which
was
automatic,
that's
really
the
distinction
there,
and
so
this.
The
second
clarifying
question
I
wanted
to
ask
was
I
I
think
in
one
of
your
documents
you
talk
about
portals
being
able
to.
I
forgot
the
word
being
able
to
like
adopt
the
the
current
visible
yeah,
the
predecessor.
C
So
so
you
could
go
from
pre-render
to
visible
back
to
pre-render
back
to
visible
and
some
of
the
hooks
you
discussed,
where
you
might
want
to
start
firing,
timers
or
something
like
that
and
delay
until
the
initial
visibility
state
actually
toggles
from
pre-render
like
it
seems
like
you
would
want
to
just
make
distinct
the
very
first
pre-render
state
from
all
subsequent
non-interactive
states.
Even
in
that
mode
like
does
it
really
make
sense
to
go
back
into
pre-rendering
mode.
C
C
D
C
D
There
there's
a
couple
of
overlapping
like
meanings
that
we
want
here
and
so
interactivity
works
for
some
things,
but
doesn't
work
for
other
things
and
then
yeah.
E
D
Sort
of
like
intentionally
loaded
versus
not
intentionally
loaded
is
another
thing
yeah.
I
I
find
pre-rendering
just
a
lot
easier
to
think
about,
but
yeah,
I'm
not
even
sure
that
pre-rendering
is
the
right
name
for
this
right,
because
if
you
do
get
put
back
into
a
portal,
it's
not
really
pre-rendering
right.
C
D
I've
been
thinking,
preview
might
be
a
better
name
for
it,
but
it
it
might
be
a
little
bit
too
early
to
bike
shed
on
the
name.
Yeah.
C
D
C
Right
because
pre-rendering
could
be
either
visible
or
hidden,
and
so
you
want
right
right.
Yeah,.
A
C
F
D
Yeah,
I
think
so
so,
like
the
main
cases,
I've
been
looking,
are
things
like
analytics
and
also
those
like
server
side
type
features,
because
I
think
that
those
are
really
the
the
the
driving
use
cases
for
needing
to
know
that
you're
in
a
pre-rendered
state.
Whereas
a
lot
of
the
other
use
cases
really
are
captured
by
like
whether
or
not
you're
visible.
F
And
then
so
in
that
case,
I
guess
my
question
is:
do
you
really
need
to
have
like
it
starts
in
tension,
so
it
starts.
Not
intentional
then
moves
to
intentional,
and
then
from
that,
can
it
move
back
to
not
intentional,
like
does
that
have
any
use
case
whatsoever.
D
Yeah,
so
so
that's
the
the
portals
use
case
and
like
the
thing
we're
thinking
there
specifically
is,
you
can
imagine
like
a
carousel
of
articles
or
something
where
you
swipe
to
the
next
article
and
then
that
activates
the
portal.
So
now
that's
the
main
page,
but
you
want
to
be
able
to
swipe
back
to
the
previous
article.
So
you
adopt
that
as
a
as
a
portal,
and
so
then
it
enters
like
this
pre-rendered
state.
F
D
It
would
remain
in
memory
and
yeah,
it's
not
quite
a
navigation,
but
it's
similar.
A
lot
of
these
things
are
still
kind
of
under
discussion
of
exactly
how
they'll
work
but
yeah.
The
idea
is
that
what
the
active
pages
might
change
and
even
though
you
might
be
the
active
page
now
you
might
become
a
portal.
F
A
Sorry
about
that,
can
you
hear
me
yeah.
You
mentioned
the
like
about
to
terminate
case
that
we're
currently
using
visibility
hidden
for,
but
it's
weird
and
doesn't
work
great
in
many
edge
cases,
and
so
your
thoughts
there
are
to
add
yet
another
state
to
so
like
another
signal
of
you're
gonna
be
terminated
soon
or
is
that
out
of
scope
from
what
you're
discussing
here.
D
So
I
I
think
it's
it's
somewhat
related,
so
it's
not
what
I'm
primarily
looking
at,
but
I
think
mainly,
I
just
wanted
to
make
sure
one.
We
don't
make
the
situation
any
worse
than
it
is
and
that
two
there
is
like
a
plausible
path
to
actually
make
it
better.
D
So
I
think
the
problem
right
now
is
that,
because
we're
using
visibility
state
as
that
signal,
it
kind
of
interferes
with
those
cases
like
the
app
switcher
where
we
might
have
to
lie
in
order
to
get
termination
state.
D
But
then
we
lose
like
nice,
ui
affordances,
and
so
I
think
that
the
right
path
there
is
not
even
necessarily
like
an
explicit
state
that
you
can
query,
but
just
an
event
that
you
get
and
then
the
browser
can
be
in
charge
of
when
to
dispatch
that
event,
and
I
think
that
that's
a
lot
cleaner,
because
we
can.
D
We
know
semantically,
that
that's
what
the
app
need
is
gonna
run
some
sort
of
a
cleanup
state
in
that
event,
and
so
we
can
we'd
be
free
to
move
it
around
so
today
like
on
android,
if
you
don't
get
any
functionality
from
the
operating
system
to
run
any
more
code,
when
the
app
is
terminated
from
the
app
switcher,
then
we
would
just
run
it
when
it
becomes
hidden,
but
if,
in
the
next
release
of
android,
they
say
like
okay,
now
your
app
will
get
a
signal
and
it
can
run
some
more
code.
A
D
Yeah,
so
I
I
did
worry
about
like,
especially
because
this
is
the
advice
we've
been
giving
web
authors
for
the
last
couple
years
is
just
use
hidden,
but
I
think
the
nice
thing
is
hidden
still
will
mostly
work.
So
if,
if
all
you
do
is
just
run,
some
cleanup
code
and
hidden
like
that'll
work
in
95
of
cases,
and
then,
if
you
find
it's
really
problematic
that
you
don't
get
called
when
you
get
killed
from
the
app
switcher,
then
you
can
just
add
a
little
bit
more
code
to
make
that
case.
Work
too.
F
F
C
C
I
think
some
of
the
unreliability
of
visibility
was
just
due
to
like
implementation
lack
of
implementation.
Some
of
it
was
due
to
disagreements
on
like
exactly
this
like
preview
mode
during
app
switcher,
where
at
least
on
safari,
they,
they
were
uncomfortable,
claiming
that
the
page
was
not
visible,
and
so
with
this
new
mode.
I
wonder
if
the
very
first
advice
we
could
give
is
check
for
visibility
hidden
or
this
preview
mode
to
save
state,
and
I
don't
recall
your
table
of
like
matrix
of
options
if
that
would
actually
work
like.
C
Are
there
cases
where
you
don't
want
to
save
state?
Yet
if
you
enter
preview
mode.
D
I
so
yeah,
I
think
that's
actually.
I
did
mention
that
right
here
so
yeah.
Basically,
the
idea
was
like
maybe
having
like
this
new
event.
Maybe
that
could
just
be
syntactic
sugar
for
you
entered
hidden
or
you
entered
pre-rendering
cool,
so
yeah.
C
C
I
worry
that
that
that
will
kill
proc
will
never
be
reliable,
like
I
know
that,
already
for
native
apps,
it's
not
fully
reliable
because
there
are
times
where
the
system
can
give
you
some
amount
of
time
to
save
state,
and
there
are
times
where
you
can't,
and
so
I
don't
know
if
the
suggestion
on
like
at
least
native
is
not
is
to
like,
basically
trust
that
signal.
C
If,
if
truly
the
system
is
under
such
pressure,
that
thing
that
you
shouldn't
just
try
to
save
more
often
earlier,
but
anyway,
I
don't
know
if
developers
would
actually
adopt
it
if
they
found
it
still
unreliable.
C
And
so
I
don't
know
if
it's
a
bit
speculative
to
think
that
this
would
be
thing
and
if
you
could
do
just
or
with
visibility
and
pre-rendering,
then
it
seems
like
you
could,
under
the
assumption
that
a
single
pre-rendering,
slash
like
intentional
or
non-intentional
preview
mode
is
all
we
need
is
the
one
signal
that
handles
all
of
the
different
options
here.
C
Yeah
but
interestingly,
I
I
first
thought
that
maybe
the
advice
would
be
switch
from
visibility
to
this
signal.
But
if
background
tabs
are
not
always
in
this
state,
then
you
would
need
an
or,
but
that
actually
makes
the
transition
easier,
because
you
just
now
need
to
handle
another
case
to
make
it
a
little
bit
more
reliable,
as
opposed
to
changing
wholesale.
D
C
And
then
I
had
a
question
about
bf
cache.
I
think
you
addressed
it,
which
is
bf.
Cache
is
entirely
different.
It's
not
some
sort
of
non-interactive.
First
of
all,
this
isn't
a
non-interactive
mode,
but
then
also
things
in
preview
mode
get
limited
privileges,
but
more
escalated
privileges
than
a
cached
page.
D
Yeah,
so
it's
not
entirely
clear
to
me,
but
I
think
this
is
like
the
most
recent
thinking.
Is
it
wouldn't
be
in
this
state?
A
bf
cached
page,
I
think,
is
completely
frozen,
so
it
couldn't
really.
It
couldn't
really
query
the
estate
anyway,
you
could
consider
sending
it
an
event
like
this,
but
I
think
like
the
on
freeze
and
on
resume
events
are
much
better
suited
for
it.
D
Yeah,
I
I
mean
having
these
kinds
of
abilities.
I
think
you
could
then
make
a
case
for
like
well.
Maybe
a
b
of
cash
should
use
a
pre-rendered
browsing
context,
and
in
that
case
I
think
you
would
just
have
to
make
sure
that
it
conforms
to
like
all
of
the
guarantees
that
we
make
about
what
is
a
pre-rendering
browsing
context,
so
it
should
all
just
work.
If
that's
the
direction
we
would
go.
I
think.
F
B
Thank
you,
david
great
discussion.
We
only
have
one
other
thing
on
the
agenda
for
today,
which
is
a
resource
timing
issue
number
238
I'll
post
it
in
the
chat.
B
If
you
want
to
take
a
look,
this
was
one
that
was
opened
last
week
around
transfer
size
and
how
it
might
reveal
the
presence
of
http
only
cookies.
I
think
it
was
open
from
anna.
I
don't
know
you
over.
Somebody
else
want
to
chat
about
it,
a
little
bit
sure.
A
I
can
do
that.
Essentially,
it
came
up
when
talking
about,
I
believe,
transfer
size
in
the
service
workers.
Working
group
and
anna
raised
a
very
good
point
that
the
current
definition
in
revealing
the
headers
so
basically
transfer
size
minus
the
encoded
body
size
gives
you
the
size
of
the
headers,
which
includes
the
cookies,
which
is
bad,
and
it's
bad
regardless
of
timing.
A
Allow
origin,
because
it
can
also
reveal
the
cook,
so
cookies
are
something
and
http
only
cookies
are
something
we
don't
want
to
reveal
to
web
content
even
in
same
origin
contexts.
A
So
there
is
no
essentially
the
fact
that
we're
using
timing
allow
origin
for
that.
Opt-In
in
cross-origin
context
doesn't
help
the
same
origin
context,
so
I
I
think
that
what
we
should
do
is
simply
define
that
transfer
size
does
not
include
cookies
and
drop
that
bit
altogether
and
we
could
essentially
like
we
could
go
beyond
that
and
exclude
headers
entirely.
F
Talk
about
what
would
be
the
use
cases
for
knowing
the
header
sizes
outside
of
cookies
like?
Is
it
maybe
to
detect
cases
where
websites
are
sending
ginormous,
headers
and
probably
causing
performance
issues
to
the
page?
Due
to
that
or.
B
Yeah,
I
think
that's
a
big
one,
and
you
know
one
of
cookies
are
often
one
of
the
biggest
bigger
culprits
of
that
right.
So
that
was.
F
Yeah
but
that's
the
problem
right,
if
you
can't
do
the
cookie
part,
then
it's
kind
of
a
half-baked
solution
and
then
like
it's,
not
clear.
If.
A
One
thing
that
I
can
think
of
is,
for
example,
properties,
sending
debugging
information,
so
various
like
x,
slash
headers,
that
bloat
up
the
responses
and
are
there
by
mistake,
and
that
may
enable
them
to
catch
that.
But
I
don't
know
that
this
is
something
that
kurt,
like.
I
don't
know
like
nick.
Is
this
something
that
you're
currently
flagging?
Is
this
something
your
customers
care
about?.
B
We
independently
report
transfer
size,
and
I
think
I
can't
remember
honestly
if
it's
encoded
body
size
or
decoded
body
size
through
our
dashboards.
So
customers
could
like
look
at
and
compare
the
values
to
see
if
there
is
a
major
difference
between
them.
B
But
we
don't
have
any
like
specific
reports
that
are
like
this
is
your
largest
header.
You
know
resource
or
anything
like
that.
It's
more
of
a
manual
thing
that
our
customers
could
do.
I'm
not
entirely
sure
if
there's
been
any
specific
analysis
from
our
customers,
because
they
do
have
access
to
some
of
the
raw
data.
So
there
might
be
some
customers
that
use
some
of
our
data
science
stuff
to
like
look
at
those
kinds
of
things
outside
of
our
dashboards.
B
But
we
generally
just
you
know,
I
think,
most
of
the
customers
that
report
on
this
data
report
on
the
total
transfer
size
because
they're
looking
for
something
like
a
page
weight
which
has
its
own
issues
separate
of
this
topic.
B
B
Yeah
it
if
we
were
to
if
we
were
to
go
down
the
path
of
removing
cookies
from
total
from
sorry
from
transfer
size.
A
Yeah,
michael.
C
Sorry,
it's
just
off
topic,
I
I
am
woefully
under
prepared
for
this
topic,
so
this
might
be
an
embarrassing
question,
but
I
figured
I'd:
ask
what
about?
Is
it
not
the
case
that
modern,
like
http,
2,
plus
the
headers,
can
be
compressed
and
that
transfer
size
is
like
over
the
wire
size?
Is
it
actually
the
case
that
we
could
remove
the
size
of
cookies
or
even
answer
the
question?
How
large
were
the
cookies
themselves,
at
least
in
all
cases,.
A
So
you
can't
so
on
h2
the
headers
are
compressed,
but
they
are
compressed
in
a
very
specific
like
it's
not
just,
let's
apply
gzip
and
forget
about
that.
They
are
so.
The
header
names
are
compressed
based
on
a
table
of
mostly
predefined
values,
although
there
are
always
new
ones
that
are
not
in
that
table,
and
then
you
have
basically
references
to
past
instances
of
those
names
or
values,
but
they
have
to
be.
I
completely
identical,
so
essentially
we
can
split
it
out.
I
don't
know
like
it's
it's
possible
to
say
this
responses.
A
Headers
took
this
amount
of
bites
and
exclude
the
cookies
from
that.
A
That
is
clearer
and
has
you
know
simpler
semantics
than
you
know,
headers,
but
without
cookies,
and
like
maybe
it's
worthwhile
for
us
to
try
to
gather
use
cases
for
headers
without
cookies
and
see
if
people
chime
in
with
interesting
stories
of
what
they
did
with
that
data.
And
if
that
did
not
happen
in
the
last
few
years,
then
maybe
it
wasn't
meant
to
be.
C
I
think
you
have
asked
at
the
beginning:
should
we
expose
all
headers
without
cookies
or
just
remove
all
headers.
I
think
correct
yeah,
and
if
it's
difficult
to
remove
cookies
because
estimating
their
size
is
complicated,
then
maybe
the
easier
alternative
is
just
to
remove
everything
like
the
whole
header.
So.
A
Yeah,
so
my
motivation
is
less
the
ease
of
implementation,
although
it's
definitely
a
factor,
but
it
question
is:
like:
are
people
looking
in
the
wild
at
transfer,
size,
minus
encoded
body
size
and
doing
something
interesting
with
that
data?
I
agree
with
nicholas
that
it's
not
going
to
give
us
like.
A
Maybe
people
are
using
that
to
detect
bloated
cookie
headers
that
this
information
will
no
longer
be
available
for
them,
but
I'm
not
sure
that
people
are
even
doing
that
and
if
they
are,
it
can
still
potentially
be
interesting,
but
if
no
one
is
looking
at
it
then
yeah.
Maybe
it's
not
worthwhile
to
preserve,
and
that
would
also
solve
the
problem
of
transfer
size.
Changing
semantics,
mid-flight.
B
My
only
concern,
I
think,
is
that
removing
the
headers,
like
the
count
of
bytes
of
the
headers
moves
us
further
away
from,
like
a
total
page
weight
being
able
to
be
calculated,
and
we
already
have
some
issues
with
that
and
so
like.
If
you're
looking
at
your
dev
tools-
and
you
see-
you
know
one
meg
transferred
and
for
whatever
reason,
your
rum
tools
are
only
going
to
report
800k
or
whatever,
because
the
headers
are
so
big,
it
just
starts.
It
gets
us
further
away
from
the.
A
Yeah,
so
maybe
we
can
take
two
action
items
out
of
that.
Oh
sorry,
go
ahead.
G
I
had
a
question
because,
in
this
comment,
ryo's
case
says
that
this
is
one
of
many
reasons:
safari
webkit
doesn't
expose
transfer
size.
So
I'm
wondering
is
what
are
the
other
reasons
that
there's
blocks
on
transfer
size
with
webkit
and
if,
along
with
the
other
point
that
you're
making
love
is
like?
Is
this
really
a
move
towards
encoded
transfer
size
where
we
deprecate
transfer
size
like?
A
Clarifications
from
safari
what
they
would
like,
because
they
haven't
implemented
encoded
body
size
either.
So
what
like,
what
would
make
them
comfortable,
implement,
transfer
size
or
maybe
they
won't
and
maybe
yeah?
You
know
there
are
no
clear
use
cases,
but
there
are
clear
uses
for
encoded
body
size.
So
what
would
get
them
to
implement
that
as
well?
I
agree
that
that's
a
good
question,
unfortunately,
yeah,
ryosuke
and
alex
did
not
make
it
here
today,
so
we
can
maybe
take
that.
F
Awesome.
Thank
you.
The
other
thing
is,
we
already
have
a
open
problem
with
such
sizes.
Right
because,
as
was
mentioned,
we
want
to
move
away
from
relying
on
timing.
Allow
origin
for
those.
A
E
F
A
Yeah,
so
so
going
back
to
the
like
use
cases,
so
one
thing
would
be
to
just
ask
people
whether
they
use
this
information
to
get
interesting
insights.
The
other
would
be
maybe
we
can
start
counting
in
chrome
or
other
browsers.
The
difference
like
what's
the
weight
of
headers
in
total.
B
It
makes
sense
to
me
one
just
really
quick
clarification
and
how
you
might
actually
be
able
to
detect
hp
only
cookies.
Is
it
like
you
would
look
at
document.cookie
and
compare
it
to
the
transfer
size,
but
then
you
have
to
know
the
other
header
sizes
like
I
guess.
How
do
you?
Actually?
How
would
you
actually
use
this.
A
You
can
basically,
you
see
the
headers
like
you
send
out
fetches
and
you
see
the
header
is
coming
in,
but
I
believe
http
only
cookies
are
stripped
before
the
response
makes
it
back.
A
B
B
E
Can
I
ask
a
quick
question:
this
is
not
about
heather
size,
although
I
will
say:
we've
never
actually
looked
at
that,
so
removing
the
cookies
from
that.
Would
it
matter
so
much
for
us,
but
this
is
more
from
our
last
meeting
about
transfer
size
when
the
service
worker
is
involved.
E
You
all
were
saying
that
there
might
be
a
path
forward
with
integrating
the
response
object
into
the
processing
model.
I
was
just
curious.
What
does
that
path
look
like,
and
I
asked
because
this
is
something
that
our
team
has
been
trying
to
do
is
to
get
a
cash
hit
rate
when
the
service
worker
is
involved,
and
it's
we've
had
some
workarounds,
but
it's
been
kind
of
messy.
A
The
path
mostly
involves
fetch
integration
for
either,
like
ideally,
the
full
resource
timing
processing
model,
but
at
the
worst
case,
basically
have
resource
timing
operate
on
the
response
object
and
then
you
know
continuing
to
like
extract
the
values
from
the
response
object,
because
essentially
service
workers
end
up
like
returning
a
response,
and
that,
like
that
response,
object,
contains
the
values
for
the
encoded
and
decoded
body
size.
Already.
It
doesn't
contains
transfer
size
but
yeah,
maybe
removing
it
all
together
would
be
also
simplifying
that
processing
model.
A
A
I
don't
have
like
it
it
it's
just
essentially
I'm
yeah
there's
no
public
timeline
for
that.
Unfortunately,
it's
work.
People
need
to
do
that
work.
I
am
trying
to
get
people
to
do
that
work,
but
you
know.
E
E
B
All
right
a
couple
follow-ups
from
there
thanks
everybody
for
commenting,
that's
the
end
of
our
time.
We
decided
we
would
meet
next
again
in
january,
so
january,
7th,
I
guess
I'll
see
everybody
then.