W3C home > Mailing lists > Public > public-web-perf@w3.org > February 2014

RE: Notification for new navigation timing entries

From: Jatinder Mann <jmann@microsoft.com>
Date: Wed, 26 Feb 2014 18:54:23 +0000
To: Arvind Jain <arvind@google.com>, Joshua Peek <josh@joshpeek.com>, "Tobin Titus" <tobint@microsoft.com>
CC: public-web-perf <public-web-perf@w3.org>
Message-ID: <bad118e3257948d48616b8205eb2e52b@BLUPR03MB504.namprd03.prod.outlook.com>
It sounds like a good idea to me as well. I suppose this would be most useful for the Resource and User Timing specs, as the Navigation Timing data is unlikely to change once the page has loaded. Should we consider a single event in Performance Timeline that indicates that any new PerformanceEntry has been added or should we do individual events in each of the specs? Seems like a single event may be sufficient.

Another piece feedback I’ve heard on the Timing APIs is that it would be great if we provided the ability to “annotate” entries with app-specific meta data. For example, if someone wanted to add in specific information on what the server was doing during a certain time period they could annotate the timeline so you can see the complete client and server side interaction. Additionally, one could also annotate why a measure might have taken as long as it did (e.g. how many items were rendered, which column was sorted, etc.). Something like performance.annotateMeasure(“measureName”, “keyName”, “value”). Does something like this sound remotely interesting?


From: Arvind Jain [mailto:arvind@google.com]
Sent: Tuesday, February 25, 2014 9:52 PM
To: Joshua Peek
Cc: public-web-perf
Subject: Re: Notification for new navigation timing entries

Seems like a good idea. Does anyone else have comments?

On Mon, Feb 17, 2014 at 9:33 AM, Joshua Peek <josh@joshpeek.com<mailto:josh@joshpeek.com>> wrote:
Navigation and user timings have been useful to gather and analysis on
the server side. Though, its a bit tricky to build tools that just
take that data and upload it to a server. Theres no notification when
new performance entries have been recorded. This requires invasive
code to recheck the performance entries buffer.

    var seen = 0;
    function reportPerformance() {
      var entries = performance.getEntries();
      var newEntries = entries.slice(seen);
      seen = entries.length;
      if (newEntries.length) {
        navigator.sendBeacon("/stats",
          JSON.stringify(newEntries));
      }
    });

    // gather all entries from initial load
    window.addEventListener("load", function() {
      reportPerformance();
    });

    // report script timing after async script loads
    var script = document.createElement("script");
    script.src = "/async-script.js";
    script.onload = reportPerformance;
    document.head.appendChild(script);

    // report user timing
    window.performance.mark("mark_fully_loaded");
    reportPerformance();

And knowing when its safe to read performance.timing stats has a small
edge case.

    window.addEventListener("load", function() {
      performance.timing.loadEventEnd; // 0
      setTimeout(function() {
        performance.timing.loadEventEnd; // 123
      }, 0);
    });

It would be helpful to receive an event or callback when the browser
knows there are new performance entries available. This should cover
any resource and user timings. Anything that will add new entries to
`performance.getEntries()`. The notification should not even be
synchronous. Batching and throttling the notification would be up to
the browser.

As of the NavigationTiming2 spec, the Performance interface is already
an EventTarget. Heres an example of using a fictitious event name with
to log client performance timings back to a server backend.

    performance.addEventListener("entries", function(event) {
      navigator.sendBeacon("/stats",
        JSON.stringify(event.newEntries));
    });


And maybe even add an event or promise for navigation timing readiness.

    performance.timing.ready().then(function() {
      navigator.sendBeacon("/stats",
        JSON.stringify(performance.timing));
    });

Received on Wednesday, 26 February 2014 18:54:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:38 UTC