►
From YouTube: TPAC WebPerfWG 2021 10 25 - Measuring preconnects
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
Okay,
so
yeah
measuring
preconnects
resource
timing
gives
us
a
connection
time,
so
we
can
essentially
yeah.
We
can
essentially
know
when
a
connection
was
reused
because
pet
start
equals
two
connection,
start
connection,
connect,
connect,
start
connect
and
and
the
main
lookups,
and
essentially
we
can
know
whether
we're
the
resource
we're
on
was
pre-connected
if
the
connect
end
equals
to
that
start.
A
But
we
can't
really
distinguish
between
implicit
preconnects,
which
are
pre-connected.
The
browser
has
initiated,
because
it
knows
things
about
the
user,
explicit
pre-connects,
which
are
pre-connects.
A
We
explicitly
said,
link
parallel
pre-connect
as
a
developer,
told
the
browser
to
pre-connect
to
a
specific
resource,
or
there
was
an
existing
persistent
connection
that
was
reused
for
that
resource.
Specifically,
we
also
don't
know
when
preconnects
actually
happened
and
whether
they
were
actually
useful,
because
even
if
we
sent
the
preconnect-
and
we
see
an
implicit
and
we
see
that
the
resource
was
pre-connected,
we
don't
know
if
this
wasn't
because
of
one
of
the
other
reasons
for
implicit
pre-connects.
A
Yes,
like
I
said
the
browser,
knows
things
about
the
user
and
can
connect
to
various
hosts
in
various
origins
ahead
of
time
for
persistent
connections.
Yes,
since
http
one,
we
have
persistent
connections
that
enable
the
browser
to
reuse
them
and,
yes,
explicit
pre-connectives
link
krell
pre-connect.
So
I
opened
an
issue
many
many
years
ago
about
resource
timing
and
pre-connect
and
trying
to
figure
out
whether
whether
a
pre-connect
was
actually
useful
and
trying
to
estimate
its
benefits.
A
This
has
become
recently
more
relevant
with
an
early
hints
experiment
from
the
folks
at
cloudflare,
in
collaboration
with
the
pro
networking
team
they
are
so
early
hints
is
a
way
to
send
headers
ahead
of
time.
So
ahead
of
time,
the
the
browser
sends
a
request
to
the
server.
The
server
then
needs
to
figure
out
what
the
req,
the
response
to
that
request
is,
and
in
case
of
a
cdn
edge
server.
A
It
needs
to
go
to
the
origin
server
and
get
the
actual
response,
but
it
can
send
headers
ahead
of
time
using
a
103
early
hint
status.
That
is
a
new
thing
that
is
being
experimented
with
in
chrome
and
in
this
architecture
that
klaus
grew
up
on
their
blog
post.
They
are,
they
send
those
early
hints
from
the
cache
and
those
early
hands
can
be
used
with
preload
headers.
A
They
can
be
used
with
pre-connect
headers
in
order
to
trigger
the
browser
to
either
preload
resources
or
pre-connect
them
ahead
of
time
and,
and
that
is
so
the
sorry
so
that's
great
and
for
preloads.
We
can
also
estimate
whether
those
preloads
were
useful
using
the
resource
timing
api,
but
for
preconnects
we
don't
really
have
a
way
to
say:
okay,
this
is
a
connection
that
happened
because
of
the
early
hint
and
wasn't
available
before.
So.
A
So
a
few
options
on
how
we
could
try
to
distinguish
the
different
pre-connect
types.
We
could
have
an
enum
on
the
resource
timing
entry
indicating
that
a
preconnect
happened
and
indicating
whether
it
was
an
implicit
one,
an
explicit
one
or
a
connection
reuse.
A
We
could
have
completely
separate
entries
for
connections
that
would
potentially
be
tricky
in
cases
where
the
connection
happened
before
the
time
origin,
because
we
don't
currently
report
any
negative
times,
and
this
may
result
in
some
negative
times
some
part
of
the
time
or
we
could
do
something
else
altogether.
A
A
That
seems
like
good
enough
for
me,
but
I
may
be
wrong
here,
so
I
would
like
the
group's
opinions
on
that
and
yes,
having
separate
connection
entries,
would
address
this
use
case
but,
like
I
said,
I'm
not
100
sure
that
it's
a
strong
one
and
then
finally,
a
strong
use
case
is
finding
useless
pre-connect.
A
So
if
we,
if
we
pre-connected
to
a
certain
origin,
but
then
that
origin
was
never
used,
that
is
a
useless
pre-connect
and
it
would
be
good
to
tell
developers
that
right
now
we
have
no
mechanism
for
doing
that.
Preload
has
console
warnings
which
are
not
necessarily
significantly
better
than
useless
anecdotally.
I
see
a
lot
of
them
all
the
time
on
very
large
sites.
That
should
know
better.
So
maybe
we
need
a
better
reporting
mechanism,
so
we
could
add
console
warnings
for
pre-connect.
A
That
seems
like
a
baseline
thing
to
do,
but
it
seems
like
a
good
idea
to
augment
both
with
the
reporting
api
that
tells
people
hey.
You
have
useless
preconnects
or
preloads,
please
don't,
and
with
that,
let's
chat.