Re: [resource hints] preconnect, preload, prender

Will the browser hints (e.g. preconnect) work with https?

From: Jonny Rein Eriksen <jonnyr@opera.com<mailto:jonnyr@opera.com>>
Date: Friday, November 22, 2013 4:16 PM
To: Ilya Grigorik <igrigorik@google.com<mailto:igrigorik@google.com>>
Cc: public-web-perf <public-web-perf@w3.org<mailto:public-web-perf@w3.org>>
Subject: Re: [resource hints] preconnect, preload, prender
Resent-From: <public-web-perf@w3.org<mailto:public-web-perf@w3.org>>
Resent-Date: Friday, November 22, 2013 4:16 PM

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.