Re: [Resource Hints] Negative Hints

+patrick

On Mon, Apr 24, 2017 at 10:57 AM, Brendan Riordan-Butterworth <
brendan@iabtechlab.com> wrote:

> Philip,
>
>
>
>   I agree, checking document.visibilityState for 'prerender' addresses
> JavaScript based no-prerender scenarios.  Checking for 'hidden' is a
> mostly functional equivalent.
>
>
>
>   However, using document.visibilityState puts the onus on the script
> author rather than the web site owner – and these two mightn’t be one and
> the same.  Additionally, having prerender control exclusively available in
> JavaScript promotes the use of JavaScript over HTML, even when HTML might
> otherwise be a better option.
>
>
Practically speaking, shouldn't the onus be on the script author? The
standard way to deploy a third party integration—analytics, ads, etc—is to
include their script (or a tag manager, which then injects the script),
which then gathers the required data and loads the appropriate resource. As
a site owner, I actually have little to no knowledge of what resources most
of these scripts will load -- e.g. analytics beacons add parameters to
URLs, ad vendors inject iframes pointing to whoever wins the auction, and
so on. As a result, even if there was a mechanism to opt-out explicit
resources.. I'm not sure that a website author would be in a position to
take advantage of the feature?

Related to above, it's not just prefetch and prerender. I imagine you'd
want the same behavior for when the user opens a background tab (e.g.
cmd-click on a link, or long press and open in background on mobile)..
opt-out pattern would be a no-op there because it's a user initiated
action, but I think you'd want the same behaviors as you outlined above?
Page Visibility API covers this case already and, afaik, most analytics
vendors successfully account for it -- if they don't that's a bug on their
end.

Re, FF prefetch behavior (cc'ing Patrick for comments): from reading their
code, it looks like non-cacheable resources are excluded from predictor
memory. This behavior makes sense to me.. If you don't want the browser to
remember and prefetch the resource in the future, don't make it cacheable?

I guess I'm arguing that the combination of Page Visibility API and
Cache-Control policies already provides all the necessary tools? :)

ig


>
> /brendan.
>
>
>
> *From:* Philip Tellis [mailto:ptellis@soasta.com]
> *Sent:* Monday, April 24, 2017 1:17 PM
> *To:* Brendan Riordan-Butterworth <brendan@iabtechlab.com>
> *Cc:* public-web-perf@w3.org
> *Subject:* Re: [Resource Hints] Negative Hints
>
>
>
> If these resource requests are initiated from JavaScript, then that
> JavaScript should just use document.visibilityState to determine if the
> beacons or ad iframes should be requested or not.  This is what boomerang
> has been doing for several years to good effect.
>
>
>
> On Mon, Apr 24, 2017 at 12:52 PM, Brendan Riordan-Butterworth <
> brendan@iabtechlab.com> wrote:
>
> Resource hints present a thoughtful and balanced means for web sites to
> inform web clients about opportunities to speed presentation of resources
> to the user.  However, when directing a web client to prefetch or prerender
> a resource with sub-resources (like scripts or images on an HTML page),
> there’s no obvious method of excluding some of these sub-resources from
> being prefetched or prerendered.
>
>
>
> It’s my opinion, as an expert in the digital advertising supply chain
> technology, that some sub-resources shouldn’t be prefetched or
> prerendered.  Resources that should not be prefetched include most if not
> all static images that are web beacons, and some advertising iframes.
> Resources that should not be prerendered include a wide range of
> time-sensitive advertising and web-analytics related scripts.
>
>
>
> Motivated by Firefox’s move to enable predictive prefetch
> <https://www.fxsitecompat.com/en-CA/docs/2017/predictive-prefetch-makes-duplicate-http-requests-in-iframes-causing-false-ad-impressions/>,
> the ad industry is looking for a means to identify links to sub-resources
> that should not be requested while the parent resource is in the prefetch
> or prerender context.
>
>
>
> I suggest that two additional resource hints be defined to allow
> sub-resources that should not be requested while in the prefetch and
> prerender contexts: no-prefetch and no-prerender.  Suggested text appears
> at the end of this message.
>
>
>
> The ability to exclude sub-elements from a prefetch or prerender increases
> the opportunities for a web site to suggest a prefetch or prerender.  It
> also heads off the need to develop more complex scripting by ad and
> analytics systems to detect and handle an early (and, potentially, false)
> impressions.
>
>
>
> Rough suggested text:
>
>
>
> 2.5 No-Prefetch
>
>
>
> The no-prefetch link relation type is used to identify a resource that
> should not be fetched as a part of a resource that is being prefetched or
> prerendered.
>
>
>
> EXAMPLE 5
>
> <link rel="no-prefetch" href="//example.com/timesensitivebeacon.gif">
>
>
>
> The user agent should not fetch resources identified as no-prefetch until
> the next navigation has shown actual need for the resource.
>
>
>
> 2.6 No-Prerender
>
>
>
> The no-prerender link relation type is used to identify a resource that
> should not be fetched and executed as a part of a resource that is being
> prerendered.
>
>
>
> EXAMPLE 6
>
> <link rel="no-prerender" href="//example.com/analytics.js">
>
>
>
> The user agent may prefetch the resource but should not execute it.
>
>
>
> /brendan.
>
>
>
> *Brendan Riordan-Butterworth*
>
> Senior Director, Technical Standards
>
> IAB Tech Lab
>
> (212) 609-3734
>
> brendan@iabtechlab.com
>
>
>
>
>
> --
>
>
>
>
>