This
specification
defines
an
interface
for
web
applications
to
access
the
complete
timing
information
for
navigation
of
a
document.
Status
of
This
Document
This
is
a
preview
Do
not
attempt
to
implement
this
version
of
the
specification.
Do
not
reference
this
version
as
authoritative
in
any
way.
Instead,
see
https://w3c.github.io/navigation-timing/
for
the
Editor's
draft.
This
section
describes
the
status
of
this
document
at
the
time
of
its
publication.
Other
documents
may
supersede
this
document.
A
list
of
current
W3C
publications
and
the
latest
revision
of
this
technical
report
can
be
found
in
the
W3C
technical
reports
index
at
https://www.w3.org/TR/.
Navigation
Timing
2
replaces
the
first
version
of
[
NAVIGATION-TIMING
]
and
includes
the
following
changes:
GitHub
Issues
are
preferred
for
discussion
of
this
specification.
Alternatively,
you
can
send
comments
to
our
mailing
list.
Please
send
them
to
public-web-perf@w3.org
(
archives
)
with
[NavigationTiming]
at
the
start
of
your
email's
subject
.
Publication
as
an
Editor's
Draft
does
not
imply
endorsement
by
the
W3C
Membership.
This
is
a
draft
document
and
may
be
updated,
replaced
or
obsoleted
by
other
documents
at
any
time.
It
is
inappropriate
to
cite
this
document
as
other
than
work
in
progress.
Accurately
measuring
performance
characteristics
of
web
applications
is
an
important
aspect
of
making
web
applications
faster.
While
JavaScript-based
mechanisms,
such
as
the
one
described
in
[
JSMEASURE
],
can
provide
comprehensive
instrumentation
for
user
latency
measurements
within
an
application,
in
many
cases,
they
are
unable
to
provide
a
complete
or
detailed
end-to-end
latency
picture.
For
example,
the
following
JavaScript
shows
a
naive
attempt
to
measure
the
time
it
takes
to
fully
load
a
page:
<html><head><scripttype="text/javascript">var start = newDate().getTime();
functiononLoad() {
var now = newDate().getTime();
var latency = now - start;
alert("page loading time: " + latency);
}
</script></head><bodyonload="onLoad()"><!-Mainpagebodygoesfromhere.--></body>
</
html
>
The
above
script
calculates
the
time
it
takes
to
load
the
page
after
the
first
bit
of
JavaScript
in
the
head
is
executed,
but
it
does
not
give
any
information
about
the
time
it
takes
to
get
the
page
from
the
server,
or
the
initialization
lifecycle
of
the
page.
startTime: 0.000// start time of the navigation request
responseEnd
:
100.000
//
high
resolution
time
of
last
received
byte
The
following
script
shows
how
a
developer
can
use
the
PerformanceNavigationTiming
interface
to
obtain
accurate
timing
data
related
to
the
navigation
of
the
document:
<script>functionshowNavigationDetails() {
// Get the first entryconst [entry] = performance.getEntriesByType("navigation");
// Show it in a nice table in the developer consoleconsole.table(entry.toJSON());
}
</script>
<
body
onload
=
"showNavigationDetails()"
>
2.
Terminology
The
construction
"a
Foo
object",
where
Foo
is
actually
an
interface,
is
sometimes
used
instead
of
the
more
accurate
"an
object
implementing
the
interface
Foo
.
The
term
navigation
refers
to
the
act
of
navigating
.
The
term
JavaScript
is
used
to
refer
to
ECMA262,
rather
than
the
official
term
ECMAScript,
since
the
term
JavaScript
is
more
widely
known.
[
ECMASCRIPT
]
Throughout
this
work,
all
time
values
are
measured
in
milliseconds
since
the
start
of
navigation
of
the
document.
For
example,
the
start
of
navigation
of
the
document
occurs
at
time
0.
The
term
current
time
refers
to
the
number
of
milliseconds
since
the
start
of
navigation
of
the
document
until
the
current
moment
in
time.
This
definition
of
time
is
based
on
[
HR-TIME-2
]
specification.
If
there
were
redirects,
this
attribute
MUST
return
a
DOMHighResTimeStamp
with
a
time
immediately
before
the
request,
or
if
user
agent
ran
the
worker
for
the
first
request
in
final
same-origin
redirect
chain.
Otherwise,
if
there
is
no
active
worker
this
attribute
MUST
return
zero.
a
DOMHighResTimeStamp
with
a
time
immediately
before
the
user
agent
ran
the
worker
required
to
service
the
request.
When
getting
the
value
of
the
unloadEventStart
attribute,
run
the
following
steps:
If
there
is
no
previous
document,
or
if
the
same-origin
check
fails,
return
a
DOMHighResTimeStamp
with
a
time
value
equal
to
zero.
Otherwise,
return
a
DOMHighResTimeStamp
with
a
time
value
equal
to
the
time
immediately
before
the
user
agent
starts
the
unload
event
of
the
previous
document.
When
getting
the
value
of
the
unloadEventEnd
attribute,
run
the
following
steps:
If
there
is
no
previous
document,
or
if
the
same-origin
check
fails,
return
a
DOMHighResTimeStamp
with
a
time
value
equal
to
zero.
Otherwise,
return
a
DOMHighResTimeStamp
with
a
time
value
equal
to
the
time
immediately
before
the
user
agent
starts
the
unload
event
of
the
previous
document.
The
loadEventStart
attribute
MUST
return
a
DOMHighResTimeStamp
with
a
time
value
equal
to
the
time
immediately
before
the
load
event
of
the
current
document
is
fired.
It
MUST
return
a
DOMHighResTimeStamp
with
a
time
value
equal
to
zero
when
the
load
event
is
not
fired
yet.
The
loadEventEnd
attribute
MUST
return
a
DOMHighResTimeStamp
with
a
time
value
equal
to
the
time
when
the
load
event
of
the
current
document
is
completed.
It
MUST
return
a
DOMHighResTimeStamp
with
a
time
value
equal
to
zero
when
the
load
event
is
not
fired
or
is
not
completed.
The
type
attribute
MUST
return
a
DOMString
describing
the
type
of
the
last
non-redirect
navigation
in
the
current
browsing
context.
It
MUST
have
one
of
the
NavigationType
values.
Note
Client-side
redirects,
such
as
those
using
the
Refresh
pragma
directive
,
are
not
considered
HTTP
redirects
by
this
spec.
In
those
cases,
the
type
attribute
SHOULD
return
appropriate
value,
such
as
reload
if
reloading
the
current
page,
or
navigate
if
navigating
to
a
new
URL.
When
getting
the
redirectCount
attribute,
run
the
following
steps:
Figure
1
This
figure
illustrates
the
timing
attributes
defined
by
the
PerformanceNavigationTiming
interface.
Attributes
in
parenthesis
indicate
that
they
may
not
be
available
for
navigations
involving
documents
or
redirects
from
different
origins
.
If
the
navigation
is
aborted
for
any
of
the
following
reasons,
abort
these
steps.
If
no
domain
lookup
is
required,
go
to
connect-start-step
.
Otherwise,
immediately
before
a
user
agent
starts
the
domain
name
lookup,
record
the
time
as
domainLookupStart
.
Record
the
time
as
domainLookupEnd
immediately
after
the
domain
name
lookup
is
successfully
done.
A
user
agent
MAY
need
multiple
retries
before
that.
If
the
domain
lookup
fails,
abort
the
rest
of
the
steps.
[connect-start-step]
If
a
persistent
transport
connection
is
used
to
fetch
the
resource,
let
connectStart
and
connectEnd
be
the
same
value
of
domainLookupEnd
.
Otherwise,
record
the
time
as
connectStart
immediately
before
initiating
the
connection
to
the
server
and
record
the
time
as
connectEnd
immediately
after
the
connection
to
the
server
or
the
proxy
is
established.
A
user
agent
MAY
need
multiple
retries
before
this
time.
Once
connection
is
established
set
the
value
of
nextHopProtocol
to
the
ALPN
ID
used
by
the
connection.
If
a
connection
can
not
be
established,
abort
the
rest
of
the
steps.
[request-start-step]
Immediately
before
a
user
agent
starts
sending
request
for
the
document,
record
the
current
time
as
requestStart
.
Record
the
time
as
responseStart
immediately
after
the
user
agent
receives
the
first
byte
of
the
response.
Record
the
time
as
responseEnd
immediately
after
receiving
the
last
byte
of
the
response.
Return
to
connect-start-step
if
the
user
agent
fails
to
send
the
request
or
receive
the
entire
response,
and
needs
to
reopen
the
connection.
Note
When
persistent
connection
[
RFC7230
]
is
enabled,
a
user
agent
MAY
first
try
to
re-use
an
open
connect
to
send
the
request
while
the
connection
can
be
asynchronously
closed
.
In
such
case,
connectStart,
connectEnd
and
requestStart
SHOULD
represent
timing
information
collected
over
the
re-open
connection.
Some
user
agents
maintain
the
DOM
structure
of
the
document
in
memory
during
navigation
operations
such
as
forward
and
backward.
In
those
cases,
the
PerformanceNavigationTiming
object
MUST
NOT
be
altered
during
the
navigation.
4.2
Same-origin
check
When
asked
to
run
the
same-origin
check
,
the
user
agent
MUST
run
the
following
steps:
There
is
the
potential
for
disclosing
an
end-user's
browsing
and
activity
history
by
using
carefully
crafted
timing
attacks.
For
instance,
the
unloading
time
reveals
how
long
the
previous
page
takes
to
execute
its
unload
handler,
which
could
be
used
to
infer
the
user's
login
status.
These
attacks
have
been
mitigated
by
enforcing
the
same-origin
check
algorithm
when
timing
information
involving
the
previous
navigation
is
accessed.
The
relaxed
same
origin
policy
doesn't
provide
sufficient
protection
against
unauthorized
visits
across
documents.
In
shared
hosting,
an
untrusted
third
party
is
able
to
host
an
HTTP
server
at
the
same
IP
address
but
on
a
different
port.
5.2
Cross-directory
access
Different
pages
sharing
one
host
name,
for
example
contents
from
different
authors
hosted
on
sites
with
user
generated
content
are
considered
from
the
same
origin
because
there
is
no
feature
to
restrict
the
access
by
pathname.
Navigating
between
these
pages
allows
a
latter
page
to
access
timing
information
of
the
previous
one,
such
as
timing
regarding
redirection
and
unload
event.
In
case
a
proxy
is
deployed
between
the
user
agent
and
the
web
server,
the
time
interval
between
the
connectStart
and
the
connectEnd
attributes
indicates
the
delay
between
the
user
agent
and
the
proxy
instead
of
the
web
server.
With
that,
web
server
can
potentially
infer
the
existence
of
the
proxy.
For
SOCKS
proxy,
this
time
interval
includes
the
proxy
authentication
time
and
time
the
proxy
takes
to
connect
to
the
web
server,
which
obfuscate
the
proxy
detection.
In
case
of
an
HTTP
proxy,
the
user
agent
might
not
have
any
knowledge
about
the
proxy
server
at
all
so
it's
not
always
feasible
to
mitigate
this
attack.
All
time
values
defined
in
this
section
are
measured
in
milliseconds
since
midnight
of
.
navigationStart
This
attribute
must
return
the
time
immediately
after
the
user
agent
finishes
prompting
to
unload
the
previous
document.
If
there
is
no
previous
document,
this
attribute
must
return
the
time
the
current
document
is
created.
If
the
previous
document
and
the
current
document
have
the
same
origin
,
this
attribute
must
return
the
time
immediately
before
the
user
agent
starts
the
unload
event
of
the
previous
document.
If
there
is
no
previous
document
or
the
previous
document
has
a
different
origin
than
the
current
document,
this
attribute
must
return
zero.
unloadEventEnd
If
the
previous
document
and
the
current
document
have
the
same
same
origin
,
this
attribute
must
return
the
time
immediately
after
the
user
agent
finishes
the
unload
event
of
the
previous
document.
If
there
is
no
previous
document
or
the
previous
document
has
a
different
origin
than
the
current
document
or
the
unload
is
not
yet
completed,
this
attribute
must
return
zero.
If
there
are
HTTP
redirects
when
navigating
and
if
all
the
redirects
are
from
the
same
origin
,
this
attribute
must
return
the
starting
time
of
the
fetch
that
initiates
the
redirect.
Otherwise,
this
attribute
must
return
zero.
redirectEnd
If
there
are
HTTP
redirects
when
navigating
and
all
redirects
are
from
the
same
origin
,
this
attribute
must
return
the
time
immediately
after
receiving
the
last
byte
of
the
response
of
the
last
redirect.
Otherwise,
this
attribute
must
return
zero.
In
case
where
the
user
agent
already
has
the
domain
information
in
cache,
domainLookupStart
and
domainLookupEnd
represent
the
times
when
the
user
agent
starts
and
ends
the
domain
data
retrieval
from
the
cache.
PerformanceTiming
.
connectEnd
must
include
the
time
interval
to
establish
the
transport
connection
as
well
as
other
time
interval
such
as
SSL
handshake
and
SOCKS
authentication.
secureConnectionStart
This
attribute
is
optional.
User
agents
that
don't
have
this
attribute
available
must
set
it
as
undefined.
When
this
attribute
is
available,
if
the
scheme
[
URL
]
of
the
current
page
is
"https",
this
attribute
must
return
the
time
immediately
before
the
user
agent
starts
the
handshake
process
to
secure
the
current
connection.
If
this
attribute
is
available
but
HTTPS
is
not
used,
this
attribute
must
return
zero.
requestStart
This
attribute
must
return
the
time
immediately
before
the
user
agent
starts
requesting
the
current
document
from
the
server,
or
from
relevant
application
caches
or
from
local
resources.
If
the
transport
connection
fails
after
a
request
is
sent
and
the
user
agent
reopens
a
connection
and
resend
the
request,
PerformanceTiming
.
requestStart
should
return
the
corresponding
values
of
the
new
request.
Note
This
interface
does
not
include
an
attribute
to
represent
the
completion
of
sending
the
request,
e.g.,
requestEnd.
Completion
of
sending
the
request
from
the
user
agent
does
not
always
indicate
the
corresponding
completion
time
in
the
network
transport,
which
brings
most
of
the
benefit
of
having
such
an
attribute.
Some
user
agents
have
high
cost
to
determine
the
actual
completion
time
of
sending
the
request
due
to
the
HTTP
layer
encapsulation.
responseStart
This
attribute
must
return
the
time
immediately
after
the
user
agent
receives
the
first
byte
of
the
response
from
the
server,
or
from
relevant
application
caches
or
from
local
resources.
responseEnd
This
attribute
must
return
the
time
immediately
after
the
user
agent
receives
the
last
byte
of
the
current
document
or
immediately
before
the
transport
connection
is
closed,
whichever
comes
first.
The
document
here
can
be
received
either
from
the
server,
relevant
application
caches
or
from
local
resources.
Due
to
differences
in
when
a
Document
object
is
created
in
existing
user
agents,
the
value
returned
by
the
domLoading
is
implementation
specific
and
should
not
be
used
in
meaningful
metrics.
This
attribute
must
return
the
time
immediately
before
the
load
event
of
the
current
document
is
fired.
It
must
return
zero
when
the
load
event
is
not
fired
yet.
loadEventEnd
This
attribute
must
return
the
time
when
the
load
event
of
the
current
document
is
completed.
It
must
return
zero
when
the
load
event
is
not
fired
or
is
not
completed.
This
attribute
must
return
the
type
of
the
last
non-redirect
navigation
in
the
current
browsing
context.
It
must
have
one
of
the
following
navigation
type
values.
Note
Client-side
redirects,
such
as
those
using
the
Refresh
pragma
directive
,
are
not
considered
HTTP
redirects
by
this
spec.
In
those
cases,
the
type
attribute
should
return
appropriate
value,
such
as
TYPE_RELOAD
if
reloading
the
current
page,
or
TYPE_NAVIGATE
if
navigating
to
a
new
URL.
redirectCount
This
attribute
must
return
the
number
of
redirects
since
the
last
non-redirect
navigation
under
the
current
browsing
context.
If
there
is
no
redirect
or
there
is
any
redirect
that
is
not
from
the
same
origin
as
the
destination
document,
this
attribute
must
return
zero.
The
timing
attribute
represents
the
timing
information
related
to
the
browsing
contexts
since
the
last
non-redirect
navigation.
This
attribute
is
defined
by
the
PerformanceTiming
interface.
navigation
The
navigation
attribute
is
defined
by
the
PerformanceNavigation
interface.
8.
Conformance
As
well
as
sections
marked
as
non-normative,
all
authoring
guidelines,
diagrams,
examples,
and
notes
in
this
specification
are
non-normative.
Everything
else
in
this
specification
is
normative.
The
key
words
MAY
,
MUST
,
MUST
NOT
,
and
SHOULD
in
this
document
are
to
be
interpreted
as
described
in
BCP
14
[
RFC2119
]
[
RFC8174
]
when,
and
only
when,
they
appear
in
all
capitals,
as
shown
here.
A.
Acknowledgments
Thanks
to
Anne
Van
Kesteren,
Arvind
Jain,
Boris
Zbarsky,
Jason
Weber,
Jonas
Sicking,
James
Simonsen,
Karen
Anderson,
Nic
Jansma,
Philippe
Le
Hegaret,
Steve
Souders,
Todd
Reifsteck,
Tony
Gentilcore,
William
Chan
and
Zhiheng
Wang
for
their
contributions
to
this
work.
