- From: Eli Perelman <eperelman@mozilla.com>
- Date: Wed, 12 Nov 2014 09:10:01 -0600
- To: Ilya Grigorik <igrigorik@google.com>
- Cc: "Aaron Heady (BING AVAILABILITY)" <aheady@microsoft.com>, Edmund Huber <edmund.pgh@gmail.com>, Ben Maurer <ben.maurer@gmail.com>, public-web-perf <public-web-perf@w3.org>
- Message-ID: <CAJ3X4n95_xZxMLZk_pyBxDBLnV2-Z9phphgzt035c8979esouA@mail.gmail.com>
Bringing my comments from the gist to here: I really like this proposal, but I do find keeping the values as durations to be somewhat limiting. Just as we have performance marks and measures, I feel that being able to provide both durations and timestamps to the client would be useful. A specific use case: On Firefox OS, it would be valuable to specify in this header when the user initiated to open an application. The "home screen" (acting as the server in this proposal) could specify in the header that at a certain timestamp, the user tapped on an icon, and the application (acting as the client) would then be able to make a more deterministic evaluation for how long it actually took load. Drawback: not sure of the implications of introducing timestamps or possible negative values into the timeline of an application, but that is something we could discuss. Thoughts? Eli Perelman On Tue, Nov 11, 2014 at 11:56 AM, Ilya Grigorik <igrigorik@google.com> wrote: > > > On Mon, Nov 10, 2014 at 1:25 PM, Tobin Titus <tobint@microsoft.com> wrote: > >> I’ve been thinking about this since I took on the task of integrating >> server-side information into timing spec per our TPAC discussion. >> >> >> >> One concern is that it has the potential to add significant weight to the >> headers. I’m not necessarily opposed because the actual document is allowed >> to add as much weight as it wants as well. And further, I would expect that >> some of this information might not be sent unless the developer had opened >> up dev tools. >> > > Right, I would expect the general case to be very light - you probably > don't want to expose sensitive data (e.g. database time, etc) to every > visitor. However, if some auth / debug cookie is present, you could emit > more detailed data. As long as we keep the data model simple - i.e. flat, > with no nesting, etc - I think we're in good shape. > > >> However, I would suspect that analytics packages might be picking this >> data up, and then beaconing it back. It seems strange to send data to the >> client just to send it back to the server again. But again, those are >> choices left up to the developer. >> > > Not entirely, since you may not be sending this data to the same server :) > > >> While working on the user timing spec this past week, I too was heading >> toward a per-resource header that would better fit in resource timing. So, >> in general, I’m not opposed to writing this into its own spec instead of >> integrating it into user timing. Just let me know if you’d like me to >> continue working or if you’d like to take this. >> > > Yep, let's discuss on the conf call tomorrow. > > On Mon, Nov 10, 2014 at 1:51 PM, Aaron Heady (BING AVAILABILITY) < > aheady@microsoft.com> wrote: > >> Concur with: I would prefer if server timing values could be >> alphanumerics, rather than having to encode datacenters as numbers as >> discussed earlier. >> > > Yeah, I think we should seriously consider the annotations proposal, I > think it solves this particular problem in a much nicer way. > > ig >
Received on Wednesday, 12 November 2014 15:10:29 UTC