W3C home > Mailing lists > Public > public-web-perf@w3.org > July 2014

Re: cache hints and preresolutions

From: Peter L <bizzbyster@gmail.com>
Date: Tue, 8 Jul 2014 13:57:49 -0400
Message-Id: <CC7E1D3B-15DA-4EC6-952A-2F3313883C30@gmail.com>
Cc: Peter L <bizzbyster@gmail.com>, Yoav Weiss <yoav@yoav.ws>, "public-web-perf@w3.org" <public-web-perf@w3.org>
To: Ilya Grigorik <igrigorik@google.com>
I was arguing that hints will have a bigger impact on page load time than push but it seems you are commenting on the idea of cache hinting, unless I'm misunderstanding.

Your example is an important one -- frequently changing third party resources. Our learning algorithm needs to be smart enough to detect a frequently changing resource and either not send cache hints for it or send them with a correspondingly short TTL. Cache hints must not violate the http cache RFC.

Also, you seem to assume cache hints for third party resources need to be injected by proxies. This is not necessarily the case as a web server plus a page rewriting module like Pagespeed allow hints to be learned and injected directly into the top level html, or the http response headers for the root object.



> On Jul 7, 2014, at 5:35 PM, "Ilya Grigorik" <igrigorik@google.com> wrote:
>> On Mon, Jul 7, 2014 at 1:50 PM, Peter L <bizzbyster@gmail.com> wrote:
>> I don't understand what you mean. The point I'm making is that we can't push the jquery javascript resource used in your subresource example here: https://code.google.com/p/chromium/issues/detail?id=312327. Push is only for same origin sub- resources, which means its potential impact on improving concurrency is much lower than hints. See this blog post for further argument on the importance of prefetching non same domain resources: http://caffeinatetheweb.com/what-makes-the-web-great-also-makes-it-slow/.
> Say I've included "thirdparty.com/widget.js" on my site. Said third party keeps a low TTL (60m) such that they can push quick updates, security patches, and so on. In fact, such update is in the process of being rolled out.. except, a malicious proxy comes along and embeds an "integrity" hint on behalf of the third party leading the client to believe that the (bad / outdated) script in its cache is, in fact, valid and good... Not a happy outcome and reason why the proxy should not be allowed to push on behalf of third parties, or claim things about the integrity of cached third-party resources. If you want to address this, you should host the third party resources on the same origin.
> ig
Received on Tuesday, 8 July 2014 17:58:20 UTC

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