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

Re: [resource hints] preconnect, preload, prender

From: Jonny Rein Eriksen <jonnyr@opera.com>
Date: Fri, 22 Nov 2013 11:46:13 +0100
Message-ID: <528F35F5.8090202@opera.com>
To: Ilya Grigorik <igrigorik@google.com>
CC: public-web-perf <public-web-perf@w3.org>
On 21.11.2013 23:48, Ilya Grigorik wrote:
>
> On Thu, Nov 21, 2013 at 1:53 AM, Jonny Rein Eriksen <jonnyr@opera.com 
> <mailto:jonnyr@opera.com>> wrote:
>
>     Does the order of tags indicate importance, or should there be
>     other ways of indicating priority? Does that change if injecting
>     hints through js?
>
>
> I don't think the order should matter -- the type should determine 
> priority. Just because one <script> tag is above another in the doc 
> doesn't give it higher priority (short of just being parsed earlier), 
> I think same should apply for hints. When creating a hint via JS, 
> setting the type attribute should set its priority.
>
>     Could the hints also be used on subsequent loads to improve
>     performance?
>
>
> You mean preloading assets for next navigation? If so, both <link 
> rel="preload" lazyload> and <link rel="prerender"> are exactly that...

I was thinking about loading the same page over again, ie. cached load 
versus first load. So let's say we parse a js block and this has link 
rel="preconnect" to adserver1.com to optimize its connection to the 
adserver. We could then end up assuming that this hint is something we 
want to store and reapply the next time we load the same page. However, 
next time the same js block uses adserver2.com instead.

Maybe it makes sense to express whether a hint is cacheable and should 
be stored and reapplied for next load?

/Jonny

>     Would this be better than hints the browser could generate/store
>     itself?
>
>
> The browser should do as much as it can on its own. BUT, there are 
> cases where the app developer has specific app knowledge based on 
> navigation patterns, type of user, etc., and that's what these hints 
> are for. In short, we need both. It's not either/or.
Received on Friday, 22 November 2013 10:46:48 UTC

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