►
From YouTube: WebPerfWG call 2021 03 18
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
Hello
and
welcome
to
the
web
performance
working
groups
festivities
today
is
the
service
workers
edition.
As
always,
this
is
being
recorded
and
will
be
posted
online,
and
today
we
want
to
continue
the
discussion
from
two
weeks
ago,
but
essentially
with
more
people
in
the
room
that
know
things
about
service
workers.
A
So
we
want
to
discuss
worker
start
and
how
we
can
properly
define
what
it
does,
because
currently
it
is
not
well
defined
and
there
are
various
edge
cases
where
we
don't
know
what
it
should
be
doing
and
then,
beyond
that,
it
would
be
good
to
trace
out
a
path
towards
defining
a
potentially
more
complete
solution,
because
at
least
our
conclusions
from
last
time
were
that
worker
start
is
not
sufficient
to
actually
measure
the
worker
like
service
workers
startup
time
in
many
cases.
A
So
it
would
be
nice
to
come
up
with
a
plan
to
do
that.
So
as
part
of
that
nick,
do
you
want
to
briefly
summarize
the
discussion
from
last
time.
B
Yeah
and
really
quickly
before
we
jump
into
that,
are
we
planning
on
meeting
then
two
weeks
from
now
on.
A
A
No
joke
yeah.
If
anyone
has
any
issues
with
that
particular
date
or
time,
please
let
us
know
and
we'll
try
to
find
an
alternative
time
slot
yep.
B
Okay,
thank
you.
So
let
me
just
use
one
of
the
tabs
ahead,
so
this
is
a
continuation
of
what
we
were
talking
about
last
time
and
now
we
have
ben
and
jake
and
others
who
may
want
to
give
us
a
little
better
opinion.
B
To
briefly
summarize,
if
that's
okay
with
you
ben
and
jake
kind
of
what
we
were
talking
about
last
time,
so
we
have
a
worker
start
attribute
today
in
navigation
timing
and
resource
timing.
B
We
have
it
defined
in
the
two
specs
research
timing
and
nav
timing.
It's
partially
implemented
amongst
the
uas
today,
but
in
practice,
when
we're
looking
at
the
consistency
between
the
two
specs
of
like
what
we
define
it
as
and
the
processing
model
for
how
we
set
it
or
unset
it
or
what
it
actually
means.
B
It
leads
to
a
lot
of
edge
cases
where
it's
not
very
useful
and
we
have
an
open
pull
request
for
kind
of
addressing
some
of
the
higher
level
just
processing
model
shenanigans,
to
make
it
a
little
more
readable
and
consistent
and
easier
to
implement.
But
I
think
that,
as
yova
is
leading
to
there's
kind
of
two
major
things,
one
is
what,
in
in
the
with
the
focus
of
trying
to
measure
how
long
it
takes
for
service
workers
to
start
up
in
that
critical
path.
B
What
should
we
be
measuring,
and
in
some
cases
we
realize
there
could
probably
possibly
be
more
than
one
service
worker
starting
up
in
the
critical
path
with
redirects
and
such
like
that,
and
so
maybe
a
broader
discussion
around
how
we
could
possibly
be
how
we
should
be
measuring
multiple
things
in
that
case
as
well,
so
the
slide
deck,
which
I
don't
know
if
you've
had
a
time
to
review
it
all,
goes
into
a
lot
of
the
different
like
kind
of
edge
cases
and
weirdness
what
we
have
today.
B
The
current
proposal
basically
updates
the
diagram
that
we
had
that
we
have.
You
know
in
the
nav
timing,
spec
at
least
to
start
out
with
to
place
worker
start
theoretically
before
all
of
the
final
same
origin.
Redirects,
so
fetch
start
is
the
last
resource,
the
final
resource
in
any
redirect
chain,
redirects
happening
before
that
same
origin.
B
Redirects
happened
before
that
and
we're
trying
to
capture
theoretically
like
that
worker
that
started
up
before
then,
if,
if
at
all-
and
we
realized
you
know
there
again-
there
could
be
multiple
workers
in
this
path
as
well,
and
there
could
be
workers
for
other
origins
that
we're
explicitly
not
trying
to
measure
here
right
because
we
don't
want
to
leak
any
information
about
other
origins.
B
So
this
kind
of
yellowish
blob,
which
may
not
be
appropriate
to
describe
like
that,
is
kind
of
what
we
want
to
measure.
So,
given
that
we,
we
have
a
pull
request
that
addresses
some
of
the
like
inconsistencies
and
processing
model
and
stuff,
and
basically
the
current
wording
says.
B
Worker
starter
is
the
first
worker
that
starts
up
in
the
last
same
origin
redirect
chain
so
in
other
words
trying
to
capture
when,
if
assuming
there's
just
one
worker,
that's
handling
all
of
a
single
origin,
ignoring
other
cases
and
scopes
and
stuff.
When
did
that
guy
start
up,
and
how
long
did
it
take.
B
And
kind
of
like,
where
does
that
belong
in
in
the
definition
of
worker?
Sorry
in
comparison
to
fetch
start,
which
is
another
thing
that
we've
defined
not
very
consistently
but
we're
trying
to
improve
because
we're
trying
to
link
it
more
directly
to
the
fetch
back
these
days.
B
So
I
guess
those
are.
The
two
of
the
kind
of
broad
areas
is
like:
what
do
we
define
as
worker
start
and
how
should
we
should
we
be
thinking
about
this
differently
in
terms
of
more
than
one
worker?
B
I
know
that
there's
been
one
proposal
or
a
proposal
to
have
it
like
a
second
time
stamp,
not
just
worker
startup,
but
worker,
ready
time,
which
will
give
us
the
start
and
end
time
stamps,
which
makes
sense,
and
maybe
do
we
need
multiple,
an
array
of
those
instead
out
of
everything
I
said,
does
anything
sound
strange
or
incorrect
from
there.
D
So
when
I,
when
I
looked
at
the
diagram,
the
the
first
thing,
I
I
felt
was
it
it
seemed.
It
seemed
confusing
that
workers
start
came
before
fetch
start
like
because,
as
you
mentioned
in
terms
of
syncing
this
to
the
spec,
it's
well
fetch
calls
the
service
worker
so
to
having
workers
start
before
the
effect
happens.
Seem
seems
weird
the,
but
then
I
I
started
to
realize
that
the
wording
of
of
these
values
generally
meant
the
final
of
those
things
you
know
like
after
redirects,
which
makes
me
wonder
if
we
want
to
change.
D
The
name
of
worker
starts
in
a
way
that
highlights
that
exception
that
they
that
we,
you
could
have
a
first
worker
start
and
a
worker
start
where
first
worker
start
is.
Is
this
exception
case
where
it's
like
you
know
this
is
the
workers,
the
the
the
first
worker
that
was
encountered
in
a
chain
of
redirects,
whereas
worker
start
is.
D
You
know
when
we
wanted
to
go
for
the
to
the
service
worker
for
that
final
request,
so
they
so
worker
start
would
come
after
fetch
start,
whereas
first
worker
start
maybe
earlier
as
an
indication
that
it
was
it
was
involved
in
the
redirect
chain.
D
I
agree
what
you're
saying
like
having
the
extra
values
to
know
why
your
service
worker
was
slow
would
would
be
useful,
so
I
had
I
was
having
a
look
at
the
the
spec
to
sort
of
think
of
where
there
are
particular
points
in
time
that
are
interesting.
D
But
if
you've
got
a
big
gap
between
like
your
worker,
is
ready
and
the
the
start
of
the
fetch
event,
that
indicates
that
we've
got
a
lot
of
main
thread
contention
in
the
service
worker,
which
could
just
be
a
there's.
A
lot
of
events
going
on
or
it
could
be
one
event
is
taking
a
lot
of
time
and
yeah.
We've
got
points
in
the
spec,
where
those
could
hook
into
if
that's
useful.
B
Yeah
that
makes
sense
to
me,
especially
if
you
know
that
javascript
main
thread
processing
time
is
going
to
be
part
of
the
critical
path
we
if
we're
going
to
be
making
changes
here,
we
might
as
well
try
to
capture
all
of
that.
So
there's
not
some
kind
of
a
nebulous
black
area
that
we
don't
know
about.
D
So
what
what
would
we
do
in
the
case
where
our
very
first
service
worker
and
our
eventual
service
worker
are
the
same
service
worker
that
I
wasn't
sure
what
to
do
with
that?
Like
would
those
numbers
be
the
same
or
well
yeah?
I
guess
those
numbers
would
be
the
same
at
that
point,
which
might
mean
first,
worker
start
comes
after
some
of
the
redirect
stuff.
E
Is
that
sorry,
sorry,
if
I
can
jump
in
like
I
think
today,
workers
start
we've
take
a
time
stamp
there,
whether
you
have
to
actually
start
the
worker
or
not.
That's
the
decision
point
saying
we
want
to
start
the
worker,
so
even
if
it's
already
running,
we
would
still
have
that
with
a
redirect
case,
we
would
still
say:
try
to
start
this
worker,
but
it's
already
running
so
that
the
time
to
start
the
worker
is
just
really
short
in
that
period.
Right
yeah.
That.
B
And
I
would
say
it's
not
very
reliable,
though,
because
because
it
is
there
today
and
we
use
it
like
impulse
uses
it
today.
But
if
you
have
any
redirects,
it's
not
reliable
because
you
actually
capture
the
redirects
in
that.
E
I
don't
know
it
would
create
a
lot
of
churn
unnecessarily
and
it
seems
like
we
need
some
something
and
like
if
it's
not
fetch
start.
What
would
it
be?
I
don't
know
like.
I
I'm
not
convinced
that
we
should.
We
should
drop
fetch
like
move
worker
start
after
fetch
start.
I
do
agree
that
we
should
separate
the
last.
E
Let
the
the
final
navigations
workers
start
from
any
redirect
worker
start,
whether
we
call
that
first
reader,
first
worker
start
or
redirect
worker
start.
I
think
I
kind
of
prefer
redirect
worker
start,
because
it's
a
little
bit
more
clearer
to
me
and
that
could
correspond
with
the
same
heuristics
as
redirect
start
in
terms
of
what
start
you
know
like.
Is
it
the
first
redirect
or
the
last
redirect.
C
C
We
are
just
talking
about
working
start,
but
actually
most
of
these
metrics
could
happen
several
times
and
we're
all
only
measuring
the
last
one
is.
I
think
that
there's
there's
a
separate
issues,
one
of
them
being
measuring
redirects
for
resource
and
maybe
adding.
C
I'm
not
sure
if
those
in
this,
you
can
maybe
shoot
some
more
light.
I'm
not
sure
if
the
life
cycle
of
of
the
worker
is
a
a
one-to-one
match
with
the
lifetime
of
a
resource
fetch
like
a
maybe
a
is
a
service
worker,
maybe
working
on
several
resources,
like
maybe
maybe
inside
the
service
worker.
You
should
do
performance,
get
entries
and
get
all
kinds
of
information
about
service
workers
performance
and
for
the
resource
it
only.
What
matters
is
when
did
we
send
the
message
to
the
service
worker?
E
Altogether,
I
I
I
mean,
I
think
that
conceptually
is
in
the
current
processing
model.
What
we
have
when
did
we
decide?
We
have
to
go
to
the
the
worker
and
we
call
it
worker
start.
I
mean
we
could
change
it,
the
name
to
more
reflect
what
it
means.
We
don't
always
start
the
worker
when
worker
start
is
set.
E
E
C
E
D
A
No,
so
just
yeah
a
short
comment.
I
I
just
think
that
we
cannot
just
change
the
semantics,
because
people
are
using
that
today,
so
we
need
to
provide
an
alter
like.
Ideally,
we
want
to
define
what
is
currently
implemented
in
worker
start
and
then
define
something
better.
Maybe
it
is
multiple
phase,
so
one
would
be
on
the
current
resource
timing,
entry
and
then
another
solution
for
redirects
in
general,
but
we
we
cannot
just
modify
the
current
semantics.
E
Of
bike
shedding,
I
will
throw
up.
I
know
people
have
gotten
confused
by
worker
start
because
it
doesn't
say
service
workers,
start
and
so
they're
confused
by
other
worker
types.
Like
is
this
only
something
that
matters
for
other
worker
types?
So
maybe
there's
an
opportunity
to
call
it
service
worker,
something
something.
Even
though
it's.
E
D
B
Well,
well,
I
think
I
think
we
want
to
make
sure
it's
useful
for
the
original
intent
which
is
measuring
the
critical
path
cost
of
starting
up
a
service
worker.
So,
if
we're,
if,
for
example,
if
we're
not
going
to
change
the
definition
of
essentially
where
worker
start
fits
in
the
diagram,
it
still
reflected
kind
of
how
it
looks
today.
B
E
G
The
entire
block
of
resource
timing
you've
got
there
needs
to
be
an
array,
then
redirects
need
to
go
away
right.
They
would
be
entries
in
because
a
redirect
has
every
ever
absolutely
every
part
of
that
path
and
they
are
separate
requests,
at
least
as
far
as
fetching
is
concerned,
and
so
an
array
of
resource
timings
that
all
roll
into
a
single
navigation
timing
is
what
ultimately
you
need
and
then
worker
would
fit
cleanly
in
there
right
right
before
the
the
fetch
actually
starts.
G
D
C
And
I
think
current.
Currently
it
means,
and
also
what
I'm
suggesting
is
when
did
fetch
hand
off
fetching
to
the
worker.
E
E
B
It's
the
legacy
definition
of
when
you
started
to
fetch
the
resource
right.
So
again,
remember
fetch
start
here
came
about
before,
like
the
fetch
deck
like
we,
we
called
this
attribute
fetch
start
back
in
20
something
and
it's
been
adapted
over
time
to
try
to
align
better
with
the
fetchback,
but
I
think
you
know
to
what
been
saying
and
stuff
like
the
actual
definition
of
fetch
start
even
in
the
resource
timing.
B
C
E
And
the
idea
is
like
yes:
if
the
worker
was
zero,
overhead
right,
fetch
start
would
be
basically
the
same
as
it
is
with
redirects,
but
we're
trying
to
measure
this
before
you
can
even
like
run
the
you
know
proceed
with
the
the
the
communication.
We
have
to
stop
and
start
the
worker
here.
So
that's
why
it's
interjected
there.
E
E
E
A
Yeah
I'm
supportive
of
that
approach
because
it
enables
us
to
not
break
existing
content
and
then
yeah.
We
can
remove
those
like
current
entries,
but
the
current
attributes,
as
we
can
never
but
yeah.
E
I
or
or
if
we
wanted
to
one
day,
actually
get
rid
of
this
stuff
it
might
I
don't
know
if
it
would
be
easier
or
not.
You
guys
tell
me
to
create
a
different
resource
timing
type.
You
know
we
create
both
types
and
people
who
use
the
new.
I
don't
know,
then
you
can
measure
that
people
aren't
using
the
old
type
anymore,
but.
E
E
Yeah,
I
had
a
dumb
idea
for
the
redirects
and
I
think
it's
dumb,
but
I'll
say
it
anyway,
which
is
actually
creating
separate
timeline
entries
for
every
redirect,
treat
them
completely
as
separate
requests,
particularly
for
navigation.
That's
what
the
browser
does.
However,
the
thing
you
then
need
is
a
way
to
like
chain
them
together.
So
you
could
reason
about
a
particular
navigation.
C
I
think
that
I
think
it's
good
to
have
those
timeline
entries,
but
also
for
resource
timing,
like
we
have
to
remember
that
the
master
is
the
resource
like.
If
we
have
an
image,
we
want
to
know
everything
about
that
particular
image,
rather
than
like
try
to
collect
it
from
all
kinds
of
entries
like
like
maybe
have
have
an
array
of
those
entries
inside
the
image
or
or
some
way,
some
way
to
connect
between
the
resources
and
those
redirects.
G
D
D
Lookup
starts
depending
on
how
your
redirects
are
happening,
and
you
can
assume
that's
the
the
final
fetch
start
or
whatever
becomes
known,
as
is
the
the
one
after
the
redirects.
E
I'll
throughout
another
idea,
just
this
is
complete
brainstorming,
I'm
not
sure
it's
a
good
idea,
so
I
don't
know
was
it
like
two
years
ago
now
or
a
year
and
a
half
ago,
I
proposed
the
fetch
event
worker
timing
api,
where
we,
the
the
service
worker,
could
actually
like
inject
manually
event
like
resource
sorry
timing
entries
that
would
then
get
put
into
an
array
on
the
the
final
outer
resource
like
what,
if,
instead
of
worker
start,
we
just
have
this
array
of
worker
timing
entries
and
we
pre-populate
it
with
like
a
startup
like
all
the
things
that
like
jake
mentioned
earlier,
we
could
pre-populate
those
with
native
ones,
and
then
it
would
also
be
a
place
where
we
would
stick
like
these
manually
generated
ones
from
from
the
developer.
E
H
Hey
would
that
include
registration
time
to
work
or
start.
C
It's
like
we
can
somehow
and
and
that
api
already
exists.
We
can
somehow
treat
treat
the
timings
that
the
service
worker
does
a
server
timings
quote.
Unquote,
it's
more
like
like.
As
far
as
the
main
document
is
connected
is
concerned,
the
service
worker
is
sort
of
a
server
okay,
yeah.
E
G
I
get
a
little
nervous,
it'd
be
nice
if
it
was
a
little
more
structured,
or
at
least
there
was
a
little
more
definition
just
because
for
like
the
simple
case
where
a
service
worker
makes
a
single
fetch
or
two
fetches
to
construct,
what's
coming
back
for
any
analytics
tool
to
be
able
to
rationalize
or
make
any
sense
of
that,
it'd
be
nice.
G
If
different
service
workers
implemented
their
custom
metrics
in
the
same
way
right
like
if
there
was
a
way
to
construct
or
pass
through
fetches,
for
example,
as
an
array
that
automatically
populates
whatever
the
service
server
timing,
because
otherwise
server
timing
as
it
stands.
Right
now
is
just
a
complete
back
black
box
and
it's
implement
implementation.
Specific.
E
You
can
create
essentially
mark
type
entries,
but
it
has
the
flexibility
where
we
could
say
you
could
take
get
the
performance
timeline
in
the
service
worker
be
like
this
is
the
fetch
that
I
just
did
and
actually
stick
it
in
there
and
we
could
like
clone
it
across
it'd,
be
up
to
the
script
to
do
that,
but
I
I
didn't
go
that
far:
it's
not
implemented
anywhere,
so
it's
sort
of
like
this
is
it's
partially
implemented
in
chrome.
We
have
a
partial
implementation
for
sub
resources,
only
not
navigation.
Yet.
D
D
E
We
we
could,
if,
if
the
service
worker
simply
does
a
pass-through
or
it
does
respond
with
fetch,
event.request
right
or
something
like
that,
and
we
return
the
response
without
like
touching
it
cloning
it,
you
know,
maybe
cloning
would
be
fine
but
like
if
it
does
anything
like
you
know,
repackaging
in
the
response
or
like
pulling
from
you
know,
then
we
would
lose
that
data,
but
in
and
this
this
comes
with,
like
noma's
work
in
the
fetch
spec
right
once
that
data
is
in
the
request,
object
we
can
or
the
response
object,
it's
easier
to
say
it
just
pull
it
from
the
response,
object
and
slap
it
into
like
this,
like
service
worker
provided
response
entry,
you
know.
E
E
H
A
So
I
think
I
don't
know
if
we
reached
any
conclusions
on
like
the
definition
of
worker
start,
which
I
think
is
the
like.
A
I
would
imagine
that
if
we
provide
a
more
supported
alternative
people
will
migrate
to
that.
But
do
we
have
a
good
path
of
like?
I
know
that
nick
had
one
definition
of
a
worker
started
which
and
then
noem
had
another
one
which
is
simpler,
but
potentially
less
useful
for
cases
where
there
are
same
origin
redirects,
but
maybe
it's
like
because
it's
less
complex
because
it
would
be
aligning
with
other
attributes.
A
Maybe
it's
worthwhile
to
consider
it.
So
maybe
we
can
start
by
making
a
decision
there
and
then
yeah.
I
think
that
it
would
be
good
to
have
some
like
long-term
collaboration
with
the
service
worker
folks
to
draw
some.
You
know
to
draw
an
api
shape
that
we
would
like,
for
you
know,
to
represent
the
case
where
we
have
multiple
service
workers.
We
have
redirects.
There
is
our
scopes
and
yeah.
We
want
to
be
able
to
represent
all
that,
as
well
as
the
user
timing
proposal.
A
Ideally
so,
like
maybe
on
the
first
point,
do
you
like
nick?
Do
you
have
any
comments
on
noam's
proposal?
From
that
perspective,.
C
C
B
No,
we
wouldn't
want
to
switch
the
worker
start
to
be
after
fetch
start
for
compat
reasons.
But
if
it's,
if
we're
talking
about
the
redirects,
instead
of
defining
it
as
the
first
redirect
on
the
chain,
we
define
it
as
the
last
redirect
the
one
closest
to
the
final
fudge
that
makes
it
simpler
to
define.
I
think
it
makes
it
less
useful
if
there
were
any
redirects,
because
it's
probably
much
smaller,
because
the
cost
was
already
happened
before
then,
and.
C
I'm
not
sure
it's
it's,
oh,
if
it's
same
origin,
it
redirects,
maybe
yeah.
G
B
I
don't
have
a
good
sense
today
of
how
frequently
websites
with
that
are
measuring
service
workers.
Startup
time
have
redirects
in
front
of
them.
It
sounds
like
ben
most
of
those
times
with
customers.
You've
worked
with
have
not
had
that
concern.
E
I
I
don't
know
that
I
would
say
most
of
them.
I
I
would
just
say
like
at
least
the
ones
I
know
who
are
using
this
api.
Don't
have
that
problem.
E
However,
I
can
think
of
other
sites
that
you
know
use
service
workers
that
also
have
redirects
sometimes
like,
for
example,
gmail
right.
If
you
type
gmail.com,
that's
a
redirect.
That's
a
vanity
url
that
goes
to
like
the
real
domain
right,
and
so
if
they
were
ever
to
stick
a
service
worker
on
gmail.com,
they
would
probably
be
they
would
want
to
know
how
long
that's
taking,
but
they
don't
have
that
today.
B
And
they
will
say
that,
as
far
as
I
remember,
the
current
processing
models
of
nav
timing,
at
least
and
maybe
resource
timing,
define
it
as
this
final
service
worker
startup
time
before
the
last
fetch
and
we
started
going
down
this
path.
We
thought
that
was
not
as
useful,
so
we
thought
the
worker
startup
cost
would
be
zero
in
the
case
of
redirects.
B
Maybe
we
just
describe
that
better
in
you
know,
documentation
for
the
attribute
or
just
to
make
it
more
clear
that
if
you
do
have
redirects
you're,
probably
not
capturing
this
time.
C
D
C
E
There
there
are
still
cases
I
think
where,
if
the
service
worker
doesn't
do
it
jake
said
and,
for
example,
returns
without
calling
respond
with,
I
think
redirects
can
then
happen,
but
you've
still
paid
the
cost
of
starting
the
worker.
E
E
There
are
other
cases
where,
like
the
honestly,
I
can't
they're
there.
We
have
a
bunch
of
tests
about
this
and
it's
really
confusing,
but
if,
like
the
service
worker
like
opts
not
to
take
a
hand
at
one
point,
I
can't
remember
if
it
re-enters
the
service
worker
again
or
not,
I
think
it
does
not.
It
does
not
yeah.
So
in
that
case
the
redirect
would
be
handled
outside
of
the
service
worker,
okay,
yeah,
and
then
then
we
have
the
split
with
navigation
being
different,
which
is
edge
case
worker.
E
E
D
C
B
If
we
were
to
do
that,
do
we
still
need
the
worker
ready
proposed
time
stamp
like?
Is
that
a
separate
timestamp
from
redirect.
A
E
I
guess
I
would
propose
we
defer
that
worker
ready
for
now
until
we
have
a
more
like
a
more
like
a
complete
service
worker
proposal,
specifically
written
up
and
because
I
think
it'd
be
good
to
obey
whether
we
want
to
go
like
the
worker
ready,
more
probe
approach
versus
creating
like
let's
have
an
array
of
entries
or
we
can
stick
different
service
worker
type
marks
in
I
I
don't
know,
which
way
would
be
better.
E
B
Yeah-
and
I
think
worker
ready
was
proposed
more
for
the
case
of
if
there
were
redirects
being
able
to
get
that
break
down
so
for
saying
that
redirects
are
not
part
of
our
worker
start
will
be
after
all,
the
redirects.
I
don't
think
it's
as
needed.
I
think
for
our
customers
just
doing
that
simple
math
effect,
start
minus
worker
start
gives
you
a
fairly
reliable,
then
service
worker
startup
time,
and
it
sounds
like
that's
what
other
people
are
using
as
well
so
yeah.
So
maybe
that's
the
simplest
solution.
B
B
It
may
not
be
very
useful
because
it
may
not
actually
capture
the
big
chunk
of
time
before
then,
but
you
already
have
redirects
you
don't
already
don't
have
visibility
into
those
redirects
anyway,
and
we
can
later
try
to
both
get
more
detailed
timings
out
of
service
workers
and
get
more
detailed
timings
out
of
those
redirects.
C
But
something
that
came
up
here
that
I
just
didn't
know
of
about
fetch
start
being
different
in
the
work.
You
start
scenario,
but
maybe
should
take
it
to
a
different
thread
like
it's.
It
was
a
surprise
for
me
and
to
look
at
the
implementation
this,
because
that
research
timing,
spec,
was
not
talking
about
at.
C
E
I
guess
I
just
have
a
random
question
for
folks
here
who
work
with
other
sites
that
are
measuring
performance
like
if
you
have
a
sense
for
their
views
of
service
worker
performance
and
if
it's
a
problem
area,
if
there's
particular
things
they're
concerned
about
or
again
this
could
be
a
separate
thread
if
we
don't
have
time
for
here,
but
you
know,
like
I
hear
from
a
lot
of
people
like
we
gotta
have
navigation
preload,
it's
not
fast
enough
without
navigation
preload,
I
don't
know
if
you
hear
the
same
thing
from
your
customers.
B
E
G
G
A
So
I
think
we
have
a
conclusion
on
the
worker
started
it
and
agreement
that
we
need
more
work
on
getting
a
better
solution
of
some
form
and
shape.
Shall
we
give
the
service
worker
folks
eight
minutes
fact
of
their
time
and
then
move
on
to
talk
about
like
I
think
we
have
one
or
two
issues
in
the
queue
that
we
can
discuss,
or
is
there
anything
else
we
want
to
talk
about
service
workers.
B
B
Yeah
but
other
than
that,
thank
you
so
much
ben
and
jake
and
everybody
else.
That's
discussed
this
gnome.
D
A
Cool
okay,
so
one
issue
that
the
first
issue
on
the
list
of
future
topics
is
a
resource,
direct
lookup
support,
issue,
255.
A
Quick
nicholas,
I
see
you
have
commented
on
that.
So
do
you
want
to
maybe.
F
F
So
the
problem
right
now
is:
there's
not
really
a
way
to
do
it.
You
can
try
to
get
the
one
with
the
given
source
in
this
case
it's
an
image
right,
so
you
can
use
the
image
source,
but
there
could
be
multiple
entries
with
that
same
url,
and
so
so
they
will
begin
to
know
which
of
those
entries
with
the
shared
name
will
correspond
to
the
one
that
they
care
about.
A
Basically,
like
an
issue
that
had
a
reverse
type
of
mapping
where
you
haven't
like
this
is
trying
to
get
the
element
from
the
entry
or
the
entry
from
the
element.
The
entry
from
the
element,
okay-
and
I
think
we
also
had.
A
A
Yeah,
so
so
I
think
just
like
in
terms
of
triaging,
I
think
we
can
clearly
say
that
this
is
a
feature
request
for
l3,
but
since
l3
is
approaching,
like
you
know,
presumably
after
the
fetch
integration
is
done.
This
is
the
point
in
time
where
we
can.
A
You
know,
start
to
look
into
implementing
new
and
exciting
things.
This
could
be
like
yeah.
I
think
it
has
a
lot
of
connecting
point
like
we
talked
about
fetch
id.
That
will
also
be
enable
us
to
distinguish
different
fetches,
so
it
seems
to
line
up
with
a
bunch
of
other
feature
requests,
and
but
it
would
probably
make
sense
for
us
to
like
once
we
reach
a
like
stable
state
with
resource
timing.
It
would
make
sense
for
us
to
discuss
the
different
different
feature
requests
which
ones
of
them
make.
A
A
Reasonable
cool
and
with
that,
I
think,
we're
out
of
time
so
thanks
all
and
yeah,
if
nothing
else,
I
will
see
you
in
two
weeks
for
april
1st,
not
joking,
not
joking,.