Presentation at WebPerfDays Amsterdam, May 18 2013. This newish browser API can be used to gain insight in the load time of individual page resources. Does the API behave consistently and as expected? Short answer: no, not really. Long answer: view the presentation ;-)

1. State of the Resource Timing API
Aaron Peters
aaron@turbobytes.com
WebPerfDays Amsterdam, May 18 2013

2. What is the Resource Timing API?
API in the browser that exposes load time data for page
resources. "Navigation Timing API for for page objects"

3. How get timing data via the API?
window.performance.getEntriesByType("resource")[1] {
connectEnd: 298.0000000097789
connectStart: 298.0000000097789
domainLookupEnd: 298.0000000097789
domainLookupStart: 298.0000000097789
duration: 682.9999999608845
entryType: "resource"
fetchStart: 298.0000000097789
initiatorType: "css"
name: "http://st.cdnplanet.com/static/fonts/amaranth-bold-webfont.woff"
redirectEnd: 0
redirectStart: 0
requestStart: 946.9999999962747
responseEnd: 980.9999999706633
responseStart: 962.9999999962747
secureConnectionStart: 0
startTime: 298.0000000097789
}

4. Is the API ready for use?
Spec is not final yet. W3C Candidate Recommendation
API currently implemented in a few browsers:
● IE10
● Chrome, Chrome Mobile, Chrome Frame
Does it behave constistently & according to the spec?

5. 12 things you should know
when using the API

6. When does the API make data
available for a resource?
While it's loading (OMG!)
Bug? Yes, but useful
"Did main.css finish
loading within 5 seconds?"
After the resource has
finished loading
This is according to spec

7. Timing-Allow-Origin: must be *
Spec states: T-A-O must be either origin-list-or-null
(RFC 6454) or *
In both browsers, only * works.
This does not work today:
● host: www.aaronpeters.nl
● scheme + host: http://www.aaronpeters.nl/
● scheme + host + port: http://www.aaronpeters.nl:
80/

8. Detect browser disk cache hits
Yes, you can!
if(
requestStart == fetchStart &&
requestStart == responseStart &&
responseStart != responseEnd
) { // disk cache hit }
Note: IE10 Dev Tools shows 304 when
actually is a disk cache hit.
Yes, you can!
if(
domainLookupStart != 0 &&
requestStart == 0
) { //disk cache hit }
Chrome says it's a bug, I
say it is a feature

9. Browser memory cache hits?
Not exposed by the API:
there is no data for the
resource
This is a bug
???
I have no idea how to test
for a memory cache hit in
IE10

10. Detect 4xx/5xx responses?
Not exposed by the API:
there is no data for the
resource
This is a bug
Data available via API
Looks same as cross-origin
200 response without
valid T-A-O header: all
timing attributes equal
zero, except startTime,
fetchStart, duration and
responseEnd

11. domainLookupStart = 0, huh?
Sometimes, in Chrome, domainLookupStart = 0,
even when a valid Timing-Allow-Header is present.
This is always impossible.
if(domainLookupStart < fetchStart){ // abort! }

12. DNS lookup & Connect times
unavailable in IE10
Values of the 4 relevant attributes are
always zero.
It's a bug.

13. IE10, y u no show SSL time?
sslTime = connectEnd -
secureConnectionStart
Chrome's behavior is in
line with Navigation
Timing API behavior, but
Resource Timing spec has
conflicting info. That will
be fixed.
Not exposed by the API
secureConnectionStart
attribute is not present !
Actually, the attribute is
optional according to the
spec

14. Track 'wait time'
How long is a resource in queue, waiting to be fetched?
If many resources have high waitTime, there is an
optimization opportunity (domain sharding?)
if(connectEnd == fetchStart){
waitTime = requestStart - connectEnd
} else {
waitTime = domainLookupStart - fetchStart
}

15. duration is useless
Same origin resource ||
valid T-A-O header
Has no added value.
What specific insight can
be gained from duration?
Cross-origin resource
No insight in split between
'wait time' and 'load time',
so how can duration
possibly be informative?
duration = responseEnd - startTime

16. Ignore all data in Chrome Frame
Data is exposed by the API, but it's bad data.
Objects fetched over network 'look' like browser disk
cache hits
if(!window.externalHost){ // not Chrome Frame }

17. Bytesize is not exposed :(
You can't know how many bytes were transferred.
A deliberate 'feature', for security reasons.
I strongly disagree. Knowing the bytesize is essential
for understanding resource load time.
Why not make it opt-in to expose bytesize?
Let the publisher be in control!
This discussion with the Working Group is not finished!

18. Some final remarks

19. Chrome currently uses a vendor prefix, eg.
webkitGetEntriesByType("resource")
When they switch to Blink, the prefix will be gone
Firefox will support the API soon(-ish), likely sans prefix.
Low activity on bug 822480
Safari & Opera will likely not have the API anytime soon:
they don't even support Navigation Timing API !
Future browser support

20. if one value doesn't make sense, discard all values
Be safe

21. Thank you !
Aaron Peters
aaron@turbobytes.com
WebPerfDays Amsterdam, May 18 2013
www.aaronpeters.nl/blog/state-of-resource-timing-api