►
From YouTube: TPAC WebPerfWG 2021 10 25 - Preload cache specification
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
A
I
got
it
from
the
preload
spec
fetch
something
early
that
you're
only
gonna
use
later,
meaning
fetch
a
script
now,
but
don't
execute
it
yet
execute
it
only
when
it's
actually
needed
or
fetch
an
image
now,
but
don't
display
it.
Yet
to
avoid
this
situation,
where
too
many
things
that
you
know,
you're
going
to
load
are
delayed,
which
delays
a
bunch
of
stuff.
You
could
do
in
parallel
a
really
good
thing
in
general,
a
good
problem
to
solve
er.
The
problem
with
this
premise
is
that
it
doesn't
go
into
the
detail.
A
One
of
them
is
availability
of
the
resource.
Like
you,
you
pre-loaded,
it
is
available
forever.
Is
it
available
for
the
next
request
is
available,
while
the
preload
tag
is
there?
Is
it
available
or
not
available
in
workers?
A
Second
one
is
caching
should
should
could
would
preload
inter
interact
with
the
cache
headers,
like
very
does
it
actually
mean
to
expire?
Let's
say
you
have
something
that
is
to
expire
within
a
few
seconds
and
you
pre-loaded
it
and
then
a
few
seconds
pass
until
it's
used
is
it
has
it
expired?
A
So
cash
like
the
is
is
pretty
low
the
cash
should
it
like.
What
does
it
mean?
Is
it
considered
store
in
third?
One,
which
is
a
painful
one,
is
is
error,
handling,
let's
say
pre
you
preloaded
the
resource
and
it's
error.
A
Should
you
try
to
reload
it
again
once
it's
once
you
try
to
use
it
what's
if
it's
not
an
error,
but
rather
it's
not
like
a
network
error,
but
rather
some
resource
resources
or
like
an
image
that
you
can't
decode.
A
Should
you
try
to
reload
it
once
it's
visible?
Doesn't
it
just
if
it's,
even
if
it's
just
a
404,
a
unused
resource
like
aren't
you
just
creating
more
network
requests
by
preloading
it?
If
that's
the
case,
so
those
problems
I
found
are
not
just
a
theorem
hypothetical
but
actually
implemented
very
differently
between
the
different
browsers.
A
If
you
go
to
the
issue
which
I
will
share,
also
on
the
chat
you
will
see
like
the
web
platform
test,
I
created
to
check
how
different
pillows
act
on
the
different
browser
and
they
just
act
totally
different.
A
Also
on
chrome,
there
is
optimization
for
next
request
means,
usually
when
you
pre-load
something
chrome
with
a
or
blink
would
keep
it
for
you
for
the
next
request,
but
not
after
after
that,
it
will
just
you'll
have
to
rely
on
it
being
in
the
http
cache,
but
the
preload
might
help
you
or
might
not.
A
The
conclusion
I
got
from
it
the
main
problem
is
that
it
doesn't
necessarily
create
a
problem
for
users,
because
the
worst
that
can
happen
is
that
is
a
new
request
like
in
http
cache,
but
a
cross
browser
fine
tuning
of
preload
is
difficult.
You
don't
know
what
to
expect
most
likely.
If
you
do
some,
if
you
put
some
preload
somewhere,
that's
not
a
trivial
use
case
of
something
that's
not
cacheable,
and
you
know
it's
coming.
It's
going
to
be
loaded
soon.
A
There
is
a
very
high
likelihood
that
you
are
going
to
maybe
improve
performance
in
one
browser
and
in
their
performance
on
another
one,
and
in
any
case,
in
either
case,
fine
tuning
of
free
loads
is
difficult,
dunking,
a
test
of
like
a
like
when
we
were
working
on
this
together
at
twix
how
difficult
this
was.
A
Anyway,
you
can
go
to
this
issue.
Comment
to
see
the
test
results
from
a
web
platform
test.
A
Yes,
now
possible
solutions
and,
as
a
like
before,
there
might
be
more
and
in
general
in
general,
all
the
solutions
try
to
be
explicit
about
what
fetch
preload
does
and
try
to
be
simple
about
it,
so
that
users
can
fine-tune
their
control
and
know
that
the
different
browsers
have
like
have
a
similar
meaning
to
preload,
and
there
were
platform
tests
that
capture
that
meaning
and
they
can
kind
of
counter
quite
what
it
means
and
have
a
good
strategy
around
it.
A
But
that's
very
naive
and
one
problem
with
this
is
that
there
might
be
a
case
which
is
not
an
uncommon
case
where
you
preload
something
and
it
just
gets,
kicked
off,
kicked
away
from
the
http
cache
by
the
time.
It's
actually
by
the
time
the
document
actually
wants
to
use
it,
which
I
think
I
wasn't
there,
but
I
think
was
part
of
why
the
next
level
optimization
of
optimization
was
done.
This
is
a
little
bit
too
much
from
the
naive
side
to
be
useful.
A
The
other
way,
which
is
sort
of
what's
happening
in
safari
and
sort
of
kind
of
what's
happening
in
firefox,
is
that
there
is
a
type
specific
resource
cache
which,
in
the
html
spec,
is
only
defined
for
images,
but
in
the
browser
implementations
is
there
also
for
fonts
and
styles
and
the
svg's,
and
I'm
probably
forgetting
something,
but
something
like
this-
that
when
you
preload
an
image
for
example-
and
you
have
an
as
equal
image-
it's
actually
a
loaded
image
of
the
page
and
goes
into
the
list
of
loaded
images
and,
if
some
other,
if
the
document
wants
that
image
it
can,
they
refer
to
the
same
cache.
A
The
problem
with
this
that
we
see
on
firefox,
we
see
many
on
safari
right
now,
is
the
that
again
in
the
in
the
situation
of
errors,
coming
response
errors
or
invalid
images.
This
will
actually
create
double
responses
and
we
make
performance
force
in
the
case
of
like
missing
images.
A
It
might
be
still
solvable
on
a
on
a
particular
level
to
say
that
every
research
resource
has
its
own
little
cache
that
the
preload
taps
into
this
would
also
mean
maybe
specifying
that
resource
cache,
which
is
currently
like
a
browser
or
a
browser-specific
implementation,
specific
data,
except
for
the
case
of
images,
and
we
will
need
to
decide
to
specify
what
it
means
in
terms
of
a
cache
headers,
which
is
currently
well
specified
for
him.
Images.
A
The
other
option
is
to
do
something:
that's
equivalent
to
the
caches
object
of
service
workers,
meaning
that,
if
you
preload
something
it
ignores
the
http
caching
headers,
or
that
it
only
works.
If
you
have
http
caching
editors,
but
it's
generally
a
I
think
of
it
as
equivalent
of
having
the
link
header
hold
the
response
that
it
that
it
requests
that
is
fetches
and
later.
If
some
element
in
the
document
wants
to
use
that
url
with
the
same
course,
origin
characteristic,
etc.
A
With
this,
we
need
to
be
careful
with
workers,
because
they
can't
have
access
to
to
the
preload
list
of
the
document,
and
we
don't
want
race
conditions
where
this
would
cause
workers
to
load
things
twice,
because
they
had
a
race
condition
with
preload
or
have
the
kind
of
problems
with
that
we
had
with
import
scripts,
and
so
this
will
be
similar
to
having
a
cash
object
in
a
service
worker,
and
if
our
cash
matches
the
response,
we
give
the
response
from
cash.
Even
if
it
was
an
error
or
a
we
don't
care.