W3C home > Mailing lists > Public > public-web-perf@w3.org > January 2013

Re: Adding protocol information to Resource Timing

From: Arvind Jain <arvind@google.com>
Date: Wed, 30 Jan 2013 07:12:16 -0800
Message-ID: <CAOYaDdMaxf51Bukyg4ima7XFMYmpdz6MNkwg-YsY0+7emNvo5g@mail.gmail.com>
To: "McCall, Mike" <mmccall@akamai.com>
Cc: James Simonsen <simonjam@chromium.org>, William Chan (陈智昌) <willchan@chromium.org>, "public-web-perf@w3.org" <public-web-perf@w3.org>, "Jain, Shakesh" <shjain@akamai.com>
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 (陈智昌)
> ><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 (陈智昌)
> >><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/ERaEDaTnt7w
> >>> >>>
> >>> >>>
> >>> >>
> >>> >
> >>
> >>
> >
> >
> >
> >
> >
> >
> >
>
>
Received on Wednesday, 30 January 2013 15:12:47 UTC

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