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

Re: Adding protocol information to Resource Timing

From: James Simonsen <simonjam@chromium.org>
Date: Tue, 29 Jan 2013 17:07:11 -0800
Message-ID: <CAPVJQika9D+Ygc3=9vshkdoVbxRkEro3UaTf5TS7bJiW0JHEmA@mail.gmail.com>
To: William Chan (陈智昌) <willchan@chromium.org>
Cc: Arvind Jain <arvind@google.com>, "McCall, Mike" <mmccall@akamai.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>, "Jain, Shakesh" <shjain@akamai.com>
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 01:07:41 UTC

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