Re: Adding protocol information to Resource Timing

With HTTP vs HTTPS, it's easy to determine which was used by looking at
the protocol used in the URI.  With SPDY/HTTP2, this isn't possible
because the URI's protocol doesn't look different.

Of course, I understand that Resource Timing is absolutely about timing
metrics, but the protocol used does make a difference in performance, and
one that content owners and infrastructure providers would be interested
in tracking ("are resources served by SPDY faster for my end-users than
those served by HTTPS?").  It's currently impossible to get per-resource
protocol information for resources served via SPDY, as Chrome's
loadTimes() interface only provides protocol information about the base
page, and Firefox exposes it via a faux HTTP header, which makes it nearly
impossible to collect via JavaScript.

Also, as an aside, there is a separate thread[1] about adding the
resource's size to Resource Timing that appears to have some support for
Resource Timing 2, which seems to be somewhat contradictory to James'
earlier concern that this is information the server already knows.  So
maybe some clarification on what the policy is in regard to adding new
items to the Resource Timing spec would be useful?

Mike

1. http://lists.w3.org/Archives/Public/public-web-perf/2013Jan/0032.html


On 1/30/13 10:12 AM, "Arvind Jain" <arvind@google.com> wrote:

>Even before we worry about spdy/http2, we have http vs. https, and we
>didn't make it part of Resource Timing. We didn't think of including this
>as the API is primarily about timing metrics.
>For a third party RUM provider, it doesn't seem that burdensome to upload
>the protocol info separately from the Resource Timing object. Is it a big
>issue for you right now?
>
>Arvind
>
>
>
>On Wed, Jan 30, 2013 at 6:59 AM, McCall, Mike <mmccall@akamai.com> wrote:
>
>But isn't this exactly the problem we're facing here?  Only the client
>sees the fully assembled page, and knows which protocols were used for
>each resource on that page.  I don't fully understand the argument that
>this repeats data the server already knows, seeing as how many resources
>on web pages nowadays come from sharded first-party domains or third-party
>domains.  This feels like novel information to me, and something that
>website owners would be interested in, especially once SPDY/HTTP2 gets off
>the ground.
>
>
>Having a separate interface that enumerates each resource on the page and
>provides protocol information doesn't feel right to me either, seeing as
>how we already have much of the information we'd need for RUM in Resource
>Timing.
>
>Mike
>
>On 1/29/13 8:07 PM, "James Simonsen" <simonjam@chromium.org> wrote:
>
>>Yeah, I don't think this is a candidate for Resource Timing. At least not
>>how I see it. As I see it, the goal for the various web-perf timing specs
>>is to reveal novel information that can't be collected by anything except
>>the client and make that available to the document.
>>
>>We'd probably want to come up with another solution for this RUM case.
>>
>>James
>>
>>
>>
>>
>>On Tue, Jan 29, 2013 at 4:53 PM, William Chan (³ÂÖDzý)
>><willchan@chromium.org> wrote:
>>
>>I appreciate the back channel concern. I just wanted to understand the
>>statement that Resource Timing should not repeat information that the
>>server already knows. From the spdy-dev email:
>>"""
>>We, at Akamai, are working on using real-user monitoring (RUM) to
>>measure server's,
>>SPDY vs. HTTP, performance. With variety of protocols (http/spdy2/spdy3)
>>in use it is hard to figure out how many components were fetched over
>>what
>>protocol in a given page and that makes it hard to understand/trust
>>performance measurement results without digging deep into what is on the
>>page.
>>"""
>>
>>As I understand that email, one server wants to know about resources
>>being served by other servers. That's the only reason I asked for
>>clarification since I didn't see how James' response to the original
>>email addressed the desired use case.
>>
>>On Tue, Jan 29, 2013 at 4:41 PM, James Simonsen <simonjam@chromium.org>
>>wrote:
>>> The server that serves the resource knows which protocol it used to
>>>serve
>>> the resource.
>>>
>>> In case this is where you're going... The thing I want to avoid is
>>>using the
>>> hundreds of millions of clients on the web as a back channel for
>>>relaying
>>> information from the resource's server back to the main document's
>>>server.
>>>
>>> James
>>>
>>>
>>> On Tue, Jan 29, 2013 at 3:56 PM, William Chan (³ÂÖDzý)
>>><willchan@chromium.org>
>>> wrote:
>>>>
>>>> Sorry, I'm less familiar here. Can someone clarify which server knows
>>>> what?
>>>>
>>>> On Tue, Jan 29, 2013 at 3:32 PM, Arvind Jain <arvind@google.com>
>>>>wrote:
>>>> > I agree with James. There's the case where RUM collection is done by
>>>>a
>>>> > third
>>>> > party but even there, this info could be collected outside of the
>>>> > resource
>>>> > timing API.
>>>> >
>>>> >
>>>> >
>>>> > On Tue, Jan 29, 2013 at 2:52 PM, James Simonsen
>>>><simonjam@chromium.org>
>>>> > wrote:
>>>> >>
>>>> >> I can't speak for everyone, but my opinion is that Resource Timing
>>>> >> should
>>>> >> not repeat information that the server already knows. You should be
>>>> >> able to
>>>> >> record the protocol on the server side.
>>>> >>
>>>> >> James
>>>> >>
>>>> >>
>>>> >> On Mon, Jan 28, 2013 at 7:09 AM, McCall, Mike <mmccall@akamai.com>
>>>> >> wrote:
>>>> >>>
>>>> >>> After some internal discussions, a colleague recently started a
>>>> >>> thread[1] on the spdy-dev mailing list, asking about having an
>>>> >>> interface
>>>> >>> for developers to leverage to determine whether or not a web page
>>>> >>> resource
>>>> >>> was fetched via SPDY (or in the future, HTTP 2.0).
>>>> >>>
>>>> >>> Since the Resource Timing specification already enumerates the
>>>> >>> resources
>>>> >>> for a
>>>> >>> given page, it seems like it would make sense to also include
>>>>which
>>>> >>> protocol was used to fetch a given resource.
>>>> >>>
>>>> >>> What does the group think?
>>>> >>>
>>>> >>> Thanks,
>>>> >>>
>>>> >>> Mike
>>>> >>>
>>>> >>> 1.
>>>> >>>
>>>> >>>
>>>>https://groups.google.com/forum/?fromgroups=#!topic/spdy-dev/ERaEDaTnt7

>>>>w
>>>> >>>
>>>> >>>
>>>> >>
>>>> >
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
>

Received on Wednesday, 30 January 2013 15:44:29 UTC