►
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
Of
predicting
where
the
likely
user
is
likely
to
go
next
and
what
the
browser
should
do
in
response
to
it,
there's
of
course
existing
work
on
prefetching
and
pre-rendering,
and
we
know
that
other
browsers,
I'm
from
the
chrome
team
by
the
way,
are
working
on
prefetching
pre-rendering
at
the
very
least
from
their
own
ui
surfaces
like
the
address
bar,
and
we
know
that
authors
also
want
to
make
content
initiated
navigation
fast
too.
A
There's
a
lot
of
new
challenges
to
make
this
useful
for
developers.
My
focus
today
is
on
making
it
possible
to
tell
when
a
document
was
pre-fetched,
so
we're
going
to
tell
the
the
server
that
this
is
a
request
whose
purpose
is
to
pre-fetch
it,
but
also
so
that
when
the
document
is
subsequently
loaded
that
the
author
can
reason
about.
Okay,
this
document
prefetched-
and
that
might
be
why
my
lcp
is
faster
this
time
or
that
might
be
why
something
didn't
behave.
A
The
the
way
that
I
expected
there's
a
lot
of
other
stuff
going
on
here
about
thinking
about
how
does
prediction
work
from
content
house
prediction
work
from
browser
chrome?
How
does
how
do
we
make
prefetching
work
in
a
way?
A
That's
consistent
with
cookie,
blocking
and
partitioning
that
a
lot
of
browsers
are:
are
shipping
and
planning
to
ship
how
to
deal
with
providing
ip
anonymity
for
cases
where
the
site
would
would
doesn't
want
to
do
the
prefetch
unless
the
user
can
be
anonymized,
because
the
ip
address
can
be
used
as
a
as
a
vector
for
identifying
the
user?
A
There's
also
work
being
done
in
pre-rendering
to
distinguish
the
document
being
rendered
and
to
try
and
write
down
what
the
behavior
of
a
document
is
during
pre-rendering,
so
that
developers
can
understand
what's
going
on
in
their
document
when
it's
being
rendered,
and
ideally
that
could
become
interoperable
over
time
with
the
very
variety
of
browsers
implementations
of
pre-ending.
But
at
the
moment
today,
I'm
sort
of
going
to
focus
on
distinguishing
was
a
document
prefetched.
A
A
That
might
be
why
the
navigation
is
fast,
and
you
know
we
want
authors
to
be
able
to
know
that
the
navigation
it
might
be
fast
because
it
was
prefetched
to
encourage
them
to
to
roll
it
out
more.
It
also
might
be
related
to
their
business
metrics.
The
fact
that
the
navigation
was
faster
because
of
prefetch
might
mean
that
users
are
more
engaged
and
being
able
to
tell
that
programmatically
is
quite
useful.
A
This
feels
like
a
description
of
the
navigation
like
how
authors
can
learn
about
other
activity
that
happened
during
the
fetch,
the
page
using
navigation
timing,
so
the
simplest
take
on
this
that
I
could
come
up
with
is
to
add
a
boolean
to
the
performance,
navigation
timing.
Interface
just
says:
prefetched,
it's
fairly
simple
and
easy
to
understand.
It
doesn't
provide
a
natural
place
to
provide
additional
information
about
this
in
the
future,
but
it
doesn't
necessarily
preclude
that.
A
So
this
is
just
you
know,
a
snippet
of
javascript
about
what
that
sort
of
option
would
look
like
and
just
a
short
partial
interface
on
the
prefetch
navigation
timing.
Interface.
A
Sort
of
a
second
idea
in
that
space
was
to
add
a
dedicated
information
for
information
related
to
the
prefetch.
So,
instead
of
just
having
a
boolean
having
an
interface
there,
that
would
be
now
if
there's
no
prefetch,
where
we
could
say
was
the
prefetch
used
and
therefore
the
authors
can
tell
well
maybe
a
prefetch
was
attempted
but
couldn't
be
used,
because
there
was
some
some
some
sort
of
failure,
mismatch
or
some
condition
failed.
A
That
prevented
the
prefetch
from
being
used,
also
information,
potentially
about
how
long
the
prefetch
took
or
how
much
bandwidth
it
took,
or
you
know
various
other
information.
A
We
can
always
obviously
expose
this
in
the
browser
developer
tools,
but
there
might
be
value
in
developers
being
able
to
deal
with
programmatically
and
feed
it
into
analytics,
and
then
just
sort
of
another
take
is
instead
of
saying.
Well,
maybe
this
isn't
really
a
description
of
the
navigation?
A
Maybe
it's
really
more
like
a
separate
resource
fetch,
and
so
we
should
have
a
different
resource
timing,
entry
for
the
navigation
prefetch,
and
that
can
tell
you
if
it's
used,
why
it
wasn't
used
that
would
sort
of
struck
by
the
structure
of
it
imply
also
sending
unless
we
need
to
redact
or
censor
it
all
the
information
that
we
get
for
other
resource
timings,
like
you
know
how
long
the
tls
connection
setup
was
and
what
the
exact
timing
of
those
those
parts
of
that
fetch
were
relative
to
one
another.
A
You
can
imagine
that,
potentially
being
useful
the
way
it's
useful
for
other
resources,
but
it's
it
becomes
a
little
bit
more
complicated
to
figure
out
what
we
can
expose
than
what
we
can't
and
it's
not
obvious
how
much
value
this
has
over
the
other
alternatives.
But
that's
sort
of
the
the
third
option
that
that
occurred
to
me.
I'm
curious
what
people's
you
know
inside
about.
What's
what
the
right
level
granularity?
What
the
right
format
to
expose
this
information
is.