This is a
playground to test code. It runs a full
Node.js environment and already has all of
npm’s 400,000 packages pre-installed, including
usertiming with all
npm packages installed. Try it out:
This service is provided by RunKit and is not affiliated with npm, Inc or the package authors.
Copyright 2014 Nic Jansma
Licensed under the MIT license
UserTiming.js is a polyfill that adds UserTiming support to browsers that do not natively support it.
UserTiming is accessed via the PerformanceTimeline, and requires
window.performance.now() support, so UserTiming.js
adds a limited version of these interfaces if the browser does not support them (which is likely the case if the browser
does not natively support UserTiming).
As of 2013-04-15, UserTiming is natively supported by the following browsers:
UserTiming.js has been verified to add UserTiming support to the following browsers:
UserTiming.js will detect native implementations of UserTiming,
the PerformanceTimeline and will not make any changes if those interfaces already exist. When a prefixed version
is found, it is copied over to the unprefixed name.
Releases are available for download from GitHub.
Development: usertiming.js - 18.1kb
Production: usertiming.min.js - 1,187b (minified / gzipped)
usertiming.js is also available as the npm usertiming module. You can install using Node Package Manager (npm):
npm install usertiming
usertiming.js is also available via bower. You can install using:
bower install usertiming
usertiming.js is available from the following CDNs:
Please see the W3C UserTiming API Reference for details on how to use the UserTiming API.
To include the UserTiming.js polyfill, simply include it via a script tag:
If the browser does not natively support
window.performance.now(), UserTiming.js adds a
small shim (via the
Date object) to mock this interface. However, DOMHighResolutionTimestamp provides higher
precision (0.1 milliseconds or better) than the native
Date object can (1.0 millisecond -- or worse in older
browsers). So if
window.performance.now() has to be mocked, it will not be as precise as native implementations.
UserTiming marks and measures are queried via the PerformanceTimeline,
for example by using
getEntriesByName(). UserTiming.js adds these
interfaces so you can query for marks and measures, but they obviously will not support any other PerformanceEntrys
such as ResourceTiming.
measure() at a high-rate, you might incur a performance cost from the UserTiming.js
UserTiming.js tests are provided in the
test/ directory, and can be run via
The tests can also be run in a web browser:
The latest W3C UserTiming tests (as of 2013-04-15) were copied into the
test-w3c/ directory and can be run in any browser to validate UserTiming.js. In browsers that natively support
UserTiming, UserTiming.js does not change anything so the tests will be running against the native browser interface.
The following changes were made to the W3C test suite to work with UserTiming.js:
The relative test harness JS/CSS urls were changed to point to the local
All tests were updated to add a reference to
../src/usertiming.js so usertiming.js is actually used
test_user_timing_mark.htm: The threshold was increased from 20ms to 50ms
(due to inefficiencies in the test suite)
usertiming.js does not pass the IDL tests (
idlharness.html), nor will it ever.
The W3C test harness itself does not appear to work in several older browsers (IE <= 8, Firefox 3.6, etc). The UserTiming.js test cases should cover most of what the W3C tests are doing, and the nodeunit test harness works in these older browsers.