On 13.07.2014 12:54, Ilya Grigorik wrote:
On Fri, Jul 11, 2014 at 10:59 AM, Podjarny, Guy <gpodj...@akamai.com
<mailto:gpodj...@akamai.com>> wrote:
Preload hints are for the *current* page. As a result
they are cancelled as part of onunload. If you need the
request to span across navigations, you should be using
prefetch, which is used to load resources for next
navigation.
Damn auto-correct... I meant should preload block *onload
*(the load event of the current page). Seems less obvious
to me, but my vote is still no, unless they resource was
discovered as a full resource further down.
Ah, hmm, interesting. I'm inclined to say that if you're
loading resources via preload hint *and* they are not used
before onload, then you shouldn't be using the preload hint
for those resource anyway? The idea for preload is to help get
the pixels on the screen faster by fetching critical resources
sooner.. if you have resources that are not used until after
onload, you're just creating unnecessary contention and you're
probably better of scheduling them as part of "regular" page
render process?
I think preloading resources which are /likely /needed would be a
fair use of this feature. This may be because you have two
resources and expect one to be used, and/or if you suspect you
have the time to get them as you’re waiting for the page to load
anyway. Either way, I don’t think that should be the guiding
factor here.
IMO once a resource is used, it takes on the attributes of the
actual resource, including changing its priority and any onload
related behavior. If it’s not used, though, I think it shouldn’t
block onload.
And I think the spec should state it explicitly.
I think the behavior you are describing is already covered by "lazyload":
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html#attr-lazyload
<link rel="preload" href="thing.js" lazyload>
I see the discussions on whether prefetch should be merged with
prerender. Now I am starting to think that prefetch should be merged
with preload instead and lazyload be supported by both preconnect and
preload. Both could trigger after the onload event and this would mean
that both could be supported for next page navigation optimization. As
it is today it is likely the preconnect would be optimized away by
having too many preconnects for one pageload, but that would be less of
a problem if they were triggered after onload. Of course a preload could
implicitly include preconnect, but using that may not always be desirable.
Building up these behaviors from small and reusable primitives is a
better path than creating exceptional cases.
I think this is especially important for prefetch. If a
web dev wants it cached, they should specify a cache
private instruction.
I think I created unnecessary confusion with "cache grace"
language.. should be fixed now.
I understand this isn’t a cache in the traditional sense, but at
the end of the day it’s still logically a cache no matter what you
call it. If you fetch content ahead of time, and don’t know how
much time will elapse before you’ll use it, the website *must
*have control over how long the fetched resource will be gvalid
for. You can do this by making this “grace TTL” a configured
parameter, but IMO the best path is simply to not have a grace
TTL, and use the standard caching instructions.
If a resource is not cacheable, even on a browser, it shouldn’t be
prefetched/pre-rendered. You may need heuristics when you do this
unilaterally, but when someone enters an explicit hint into the
page, I think the requirement is on them to ensure it’s cacheable.
History lists come to mind and I'd argue that pre{fetch,render} belong
in that same bucket:
http://tools.ietf.org/html/rfc7234#section-6
"no-store" seems like the right directive that would/could abort a
pre{fetch,render}. That said, afaik, the implemented browser behavior
for no-store differs even there for history lists, and the HTTP spec
language is (intentionally) loose.. Mark, any thoughts or suggestions?
As an aside, a scan over recent HTTP Archive run shows that ~24% of
HTML responses advertise "no-store".
* What about srcset and the picture element (e.g.
Native conditional loading mechanisms)?
I don't see any concerns here. If you have conditional
loading then you must evaluate those conditions.. With
native <picture> those conditions will be executed by the
preparser (yay) if the main doc parser is blocked... Yes,
you may not be able to stick a Link header hint or put a
<link> hint in the head of the doc, but such is the cost
of conditional fetches. On the other hand, if you *know*
you need a specific file regardless, feel free to hint it.
Isn't srcset short enough to consider here at least?
What about srcset? The preload scanner (or regular doc parser)
will find it, evaluate it, and initiate the right fetch. Or,
am I missing your point?
What I meant was: can’t we support prefetch of srcset, by having
the context/type state “srcset”, and having the URL hold the
srcset-format text? Same thing for the Link header.
It feels like an overkill to fit Picture into this format, but
srcset seems light enough to make it reasonable.
I think this is what you're actually after:
https://github.com/igrigorik/resource-hints/issues/11 - right?
ig
