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
(
subscribe
,
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()">
<!- Main page body goes from here. -->
</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.
Though
workerStart
is
exposed
in
PerformanceResourceTiming
,
it
has
a
different
meaning
in
Navigation
Timing,
as
unlike
subresources,
a
navigation
may
trigger
the
activation
or
running
of
a
service
worker.
In
the
context
of
Navigation
Timing,
workerStart
returns
the
timestamp
measured
just
before
the
worker
has
been
activated
or
started.
See
[
service-workers
]
for
a
precise
definition.
The
fetchStart
getter
steps
are
to
perform
the
following
steps:
When
a
service
worker
is
used
as
part
of
the
navigation,
The
fetchStart
overload
holds
a
different
meaning
than
the
meaning
in
PerformanceResourceTiming
.
It
returns
the
timestamp
measured
right
before
the
FetchEvent
is
dispatched
for
the
service
worker
.
The
time
difference
between
workerStart
and
fetchStart
in
the
document's
navigation
timing
entry
can
be
used
to
determine
roughly
how
long
it
took
for
the
worker
to
be
initialized
or
activated.
See
[
service-workers
]
for
a
precise
definition.
If
the
previous
document
and
the
current
document
have
the
same
origin
,
this
timestamp
is
measured
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
will
return
zero.
If
the
previous
document
and
the
current
document
have
the
same
origin
,
this
timestamp
is
measured
immediately
after
the
user
agent
handles
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
will
return
zero.
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.
The
redirectCount
getter
steps
are
to
return
this
's
redirect
count
.
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
from
different
origins
.
5.
Creating
a
navigation
timing
entry
Each
document
has
an
associated
navigation
timing
entry
,
initially
unset.
To
queue
the
navigation
timing
entry
for
Document
document
,
queue
document
's
navigation
timing
entry
.
5.1
Privacy
This
section
is
non-normative.
5.1.1
Information
disclosure
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
unloading
a
document,
as
detailed
in
the
HTML
spec
.
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.1.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.
5.4
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
MUST
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.
5.5
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.
