Performance metrics: expose more useful performance.timing metrics

[ebidel]

I'm reading http://calendar.perfplanet.com/2016/prefer-defer-over-async/, and now want to test this on my site. But we don't expose enough interesting metrics in the report.

Some things worth adding:

const t = performance.timing;

const pageloadAt = t.loadEventStart - t.navigationStart;

const dnsLookupTime = t.domainLookupEnd - t.domainLookupStart;
const tcpTime = t.connectEnd - t.connectStart;
const ttfb = t.responseStart - t.navigationStart;

const DOMConstructionTook = t.domContentLoadedEventStart - t.domLoading;
const DOMInteractiveAt = t.domInteractive - t.navigationStart;
const DOMContentLoadedAt = t.domContentLoadedEventEnd - t.navigationStart;

Feel free to modify the suggested calculations.

We could also create audits based off some of these. For example, if we got the dns time for different resources on the page, we could recommend #873 based on some threshold.

[brendankenny]

For DNS stuff here, one thing I learned from taking a stab at #873 is that you unfortunately can't really use the DNS timing as (IIUC) Chrome defers to the OS-level DNS cache for lookups. Even if you load the site again in a completely blank Chrome profile, the DNS lookup will be much faster than when done with no previous visits on that machine.

[paulirish]

Working with Chrome Speed Metrics on the most useful metrics to provide.