Surface failed fetches in the performance timeline #19
Conversation
- fetches that are blocked (CSP, CORS, etc) are omitted - fetches aborted due to network/other errors must be included - failed fetches must surface initialized attributes up to point of failure Closes #12.
| </p> | ||
|
|
||
| <p>All resources <a title='fetch' href="http://www.w3.org/TR/html5/infrastructure.html#fetch">fetched</a> by the current <a href="http://www.w3.org/TR/html5/browsers.html#browsing-context">browsing</a> [[!HTML5]] or worker [[!WORKERS]] context's MUST be included as <a href="#performanceresourcetiming">PerformanceResourceTiming</a> objects in the <a href="http://www.w3.org/TR/performance-timeline/#sec-performance-timeline">Performance Timeline</a> of the relevant context. Resources that are retrieved from <a href="http://www.w3.org/TR/html5/browsers.html#relevant-application-cache" title='relevant application cache'>relevant application caches</a> or local resources MUST be included as <a href="#performanceresourcetiming">PerformanceResourceTiming</a> objects in the <a href="http://www.w3.org/TR/performance-timeline/#sec-performance-timeline">Performance Timeline</a> ([[!performance-timeline]]). Resources for which the <a title='fetch' href="http://www.w3.org/TR/html5/infrastructure.html#fetch">fetch</a> was initiated, but was later aborted (e.g. due to a network error) MUST be included as <a href="#performanceresourcetiming">PerformanceResourceTiming</a> objects in the <a href="http://www.w3.org/TR/performance-timeline/#sec-performance-timeline">Performance Timeline</a> and MUST contain initialized attribute values for processed substeps of the <a href="#processing-model">processing model</a>.</p> | ||
|
|
There was a problem hiding this comment.
Can we avoid extremely long lines in the future? It makes it so much harder to review changes.
|
LGTM, but interested in @mikewest's opinion as well. |
|
How do you deal with redirects? That is, do you expose the endpoints to which redirection directs, or do you tie everything to the original url that the UA fetched? |
|
@mikewest currently, we don't expose redirection end-points (see step in 19 for full details). That said, we do have an open discussion to change this, see: https://lists.w3.org/Archives/Public/public-web-perf/2015Feb/0059.html |
|
LGTM |
Surface failed fetches in the performance timeline
|
Re, redirects, see: #21 |
|
Was Chrome ever updated to reflect this spec change?
For comparison, here is what the Performance Timeline API returns for HTTP 404 img requests:
|
|
For 404 at least it was supposed to be fixed, per https://bugs.chromium.org/p/chromium/issues/detail?id=883400. Please comment on that issue if you're not seeing that fixed in a recent Chrome version. |
failure
Closes #12.