Re: Media Queries and optimizing what data gets transferred

Henri, I believe we're going in circles at this point.

As a quick summary:

(1) I'm all for markup based solutions.
(2) Your "nolive" proposal doesn't actually address what I'm after, as
several others have already pointed out.
(4) Even if we have (1), and we don't, this is not an argument against HTTP
negotiation. There is a time and place for both.
(5) Cache "fragmentation", whether based on unique URLs or on Vary is the
same - stuffing parameters into URLs doesn't magically increase cache
hit-rates.
(6) We can't rely on cookies.
(7) You shouldn't have to buy a commercial database to perform content
adaptation.
(8) See (1), then (3).

ig



> In your proposal, server negotiation involves putting data in a
> request header. How would the browser's HTTP stack have more
> information than its preload scanners, etc.?
>

HTTP requests are scheduled by the preloader.


> I think the argument that's bogus is saying that Vary makes stuff
> cache-friendly if what it ends up doing is making cache entries
> practically never valid without checking with the origin server.


Lookup the difference between maxage and revalidation. I think therein lies
our disconnect. Vary does not force revalidation on every request.


> Well, obviously, since the client-side functionality is not there at
> present. Your solution is not there currently, either. That sites are
> using the option(s) currently available to them is no proof that your
> currently non-deployed solution that is similar to the currently
> available solution is better than and different presently non-deployed
> solution.
>

I have already run the proposal by half a dozen CDN vendors - they're all
interested in leveraging it, assuming the browser is able to provide the
hint.


> > Once again, let's not pose CDN's as an adversary - they're not. Instead,
>
 > they are the ones who can help us make the web faster.
>
> Currently, if you tell people to make their sites https, they
> complained that CDNs charge more for https. Surely, CDNs will charge
> more for solutions that involve content negotiation on the CDN than
> for solutions that involve a 1-to-1 mapping between URLs and bytes to
> serve.
>

Sure, which is why it's great to have open-source servers that can do this.


> I'm not saying that what you suggest could not be implemented on the
> CDNs. I'm saying that a solution where the choice of representation
> happens on the client and the bytes served for each URL don't depend
> on server-side negotiation can be deployed without the participation
> or changes on the CDN side.
>

Agreed. And that's great. I'm not saying CDN's MUST do this. I'm saying, if
the CDN's were to adopt it, then many sites would see significant benefits.


> > For opt-in, a mechanism similar to Alternate-Protocol can be provided:
> >
> http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2#TOC-Server-Advertisement-of-SPDY-through-the-HTTP-Alternate-Protocol-header
>
> This requires an HTTP round-trip to the server, so this kind of opt in
> does not solve the problem of varying the top-level HTML in the
> low-latency way upon first contact. I thought addressing that problem
> was in scope for Client-Hints and one of the main motivators of
> choosing a solution that puts stuff in the HTTP request.
>

Alternate-Protocol is a sticky hint. You default to off on a site you've
never seen before. Once the hint is provided, the browser remembers it and
provides the header on all future requests.


>
> Even if it doesn't overflow the congestion window, do you have an
> explanation for how it wouldn't matter towards data metering unmetered
> mobile connections?
>

Let's do the math: 80 requests on an average page, half of them images.
Let's say CH adds 50 bytes per request.. That's ~2KB in upstream. The same
page (1200kb avg -- HTTP Archive), has 60% of bytes in images. So, to
offset those 2kb, I would need <1% improvement in saved bytes in
downstream. In practice, mod_pagespeed offers ~30% .. today. If you're
really concerned about metered connections, then this a slam dunk.


> "You don't need to use it" does not refute the learnability argument.
> If there are more solutions to choose from, you need to learn about
> them in order to make the choice what not to use.
>

That's not an argument, it's your opinion. If you don't want to leverage
HTTP negotiation, don't.

ig