wicg/contentperformancepolicy

A set of policies that a site guarantees to adhere to, browsers enforce, and embedders can count on.

contentperformancepolicy's Issues

Specify Enforcement Policy

According to the current state of the document, using CPP might result in breaking some features when the user agent enforce the policy. But the feature might be critial.

example: my website promise is to load less than 800ko (resource-limit). If an heavy image is added, resulting in a violation of the directive, web browsers would block data after that the 800ko threshold has been reached. What if the block content is an essential JS or a CSS?
I think this behaviour would be a major issue.

Same goes for max-internal-blocking-size: I can't imagine how a browser could enforce the promise without resulting in major troubleshooting

Specifying a default Enforcement Policy for each directive would be great, and for some it would be usefull to override with a custom Enforcement Policy (eg: browser can only block images)

Can this be archived?

@yoavweiss @tkadlec this work morphed into something else, right? Can we archive this repo?

Should a parent document have a way to specify directives on specific iframes?

There's some overlap with the ideas here and sandboxed iframes. Should there perhaps be an attribute on iframe to allow a parent document to subject a particular child frame to greater limits than it wants for itself? Eg. maybe it's reasonable to cpu-throttle and ad frame?

Definying thresholds for RWD websites

I think it make sense to be able to define several thresholds for the same directive, according to the context in the case of an RWD website.

Resource-limitfor instance would probably vary between desktop or mobile version.

Neither a HTTP header declaration nor meta tag one seems to fit this need, but I may miss something.

Mechanism to indicate desire to opt OUT of a CPP?

There are some things here (eg. passive-listeners-only) which we're planning on having an intervention to enable when we believe that the benefit is substantially greater than the compat risk. In such cases it may be useful to have a way for a page to indicate that it prefers to explicitly disable a CPP policy. This may not always be honored, but can provide a migration path. Eg. I could imagine saying that passive-listeners-only is enabled by default for pages that perform below a threshold, but can be explicitly disabled for a few releases (or maybe by pages that are relatively close to the defined threshold).

Is there anything similar for CSP? I'm not aware of anything. Worth considering here?

Passive listener option(s) should be specific to event types

It's not very useful to require that ALL listeners be passive. Eg. it's not unusual to want to cancel a mousedown event and there's nothing really wrong with that. Also it can be harder to avoid non-passive wheel listeners than it is to avoid non-passive touch listeners (because there's not yet a wheel equivalent of touch-action), but often the biggest benefits are for touch.

And a minor nit, it's the listeners that can be passive, not the events (one event may have a mix of passive and non-passive listeners).

So I propose the passive-events-only directive is replaced with touch-listeners-passive-only (which actually should probably apply only to touchstart and touchmove) and wheel-listeners-passive-only.

Also, maybe the spec should link to the passive listener explainer for context or something?

CPU quota for external scripts

On a page that I maintain I have to include a really, really bad 3rd party script (nearly O(n^2) traversal of entire DOM kind of bad).

Fixing or removal of the script is impossible: it's owned by a vendor who has no incentive to improve it, and the management accepts awfulness of the script as a necessary evil to bring revenue.

So I'd like to have an ability to reduce negative impact of this script without completely breaking it (if it breaks a little that's fine - it breaks in many cases already).

Here are some whacky ideas:

• force the script to run in a CPU-throttled Worker that looks and works like main document (with all globals visible), but only has a read-only DOM snapshot (or read-write, but race-condition-causing-async and without causing layout flush).
• Hide areas of DOM from the script, or make a "chroot jail" for DOM, so that a <div> designated for the script looks like <body> from perspective of that script
• Alternatively ability to have a CPU-throttled iframe with unidirectional access (so that top-level context can mess with it, but framed scripts can't escape the frame), so that I can implement the above ideas myself.

How does read-write batching work exactly?

fastDOM relies on the app to indicate when it's read vs. write phase is. What would dom-read-write-batching do exactly? Enter the read phase on the start of a frame, switch to the write phase on first write, and throw if a read is attempted during the write phase? There probably needs to be an additional API to co-ordinate this (maybe an event saying the write phase has been entered), right?

No overlays - too strict

I realize this will not be a popular position to take, but preventing all overlays is too strict.

Yes, the overlay that pops up seconds after you arrive on the site to offer an ebook for your email address is annoying. But there are many other valid use cases for overlays, including

• Disclaimers
• Age verifications
• Details, such as those on a page full of board members photos
• Promotional notifications like a one day sale
• Solicitations for donations
• ...and more

I realize you could provide a non-overlay alternative to every one of the cases above, but, in my experience, you would be going too far, and you would have a difficult time getting publishers to get on board.

Instead, I suggest creating a set of guidelines and rules for overlays, such as size, triggers, timing, and perhaps content if this standard is to go that far.

Full disclosure: I am a developer for two prominent digital magazines with multiple properties in Dallas, Houston, Austin and surrounding cities. I am also the guy behind SethsPopupCreator.com. The latter is a hobby business and has taught me all the ways overlays get used.

You may now throw a tomato at me. 🍅

How do directives impact sub-frames?

If a directive (say passive-events-only) is specified on the root document, when does it also apply to sub documents? There are definitely cases where the main document will want to recursively enable the policy for all sub resources. But can that be fixed per directive, or does the language need a way to indicate the desire?

Can policies be specified in a meta tag?

Most CSP policies can be provided via either an HTTP header or an <meta http-equiv> tag. I assume either approach is fine here, right? Should the spec say this explicitly somewhere?

Unclear text

"A directive can indicate that this is not the case, either because the site is not using Web fonts, or because it is using techniques that render the fallback font first. (e.g. font-display: swap)"

What is "this" mean in the above?

ProTip: always avoid the word this, as it's usually ambiguous.

Lazy loading of images

I see in this draft a section about lazy loading of images, which is really nice!

I know —thank you @hteumeuleu for this tweet— that IE11 and Edge already support a lazyload attribute, but they are alone and the draft spec has been abandonned, inviting us to look at resource hints… which don't seem to contain anything on this topic.

So, thanks a lot for this, I hope it will come soon to every browser!

Ok, that's not really an issue… ;-)

Directive for no modal dialogs?

alert etc. provide a poor user experience, provide a directive for disabling them?

Is this about performance or features?

Performance is a very fuzzy / statistical thing. AMP works because it disables a lot of FEATURES, without which it's much harder to build a page with a poor experience (performance or otherwise). There's already a number of directives here that really have nothing to do with performance. Maybe the framing should be shifted a little to be in terms of disabling features / footguns?

@ojanvafai had some more thoughts along these lines.

Profile(s) of directives?

Currently there are 11 directives listed. If this project goes on, the final result may be 6 directives (others not making the cut because implementers are wholly uninterested), 12, or maybe 18.

It might be worthwhile to offer one, or maybe several named profiles that activate selected directives.

For instance:

• baseline: a subset of directives (with default values if some accept values)
• strict: baseline plus another subset of directives

For instance if there are 12 directives, 5 may be marked as "baseline" and "strict", 4 others as "strict", and 3 others deemed too specific to fit in a standard profile so developers have to call for them explicitly.

Syntax-wise, it might be useful to allow asking for a profile and adding other directives (but not possible to cancel directives from the profile):

Content-Performance-Policy: baseline; other-directive; another-one

Maybe two profiles is over-the-top, and just one would be alright.

Just a thought. :)

abstract could be improved

I tried to rewrite it a bit...

This specification defines a set of CSP-like directives that de-prioritize the loading of resources that negatively impact the user experience of a web application. These author-imposed "interventions" can help improve the loading performance of an application's primary content by deferring (or outright stopping!) the loading of first or third-party content that would otherwise harm the user experience (e.g., a web-font that takes too long to load).

Conforming user agents modify their behavior to enforce these directives, and ignore "slow path" resources or behaviors. Web Applications that embed external documents, or link to them, can use these directives as guarantees that prevent degradation of user experience: in effect, if a non-critical resource is adversely affecting the user experience, the user agent can ignore, de-prioritize, or defer it (depending on the directive).

The primary aim of the directives defined in this specification is to target performance anti-patterns caused by first or third-party resources: that is, where those resources are not in control of the application's author, but there is a risk that those resources could negatively affect the user experience of the application in a way the author cannot directly control. Deploying directives that guarantee performance aspects could serve as a signal to increase a site's ranking in search engines - as well as serve as a signal to users that the site won't unnecessarily sacrifice the user experience. Furthermore, content blockers could use those guarantees in order to make their decision whether to automatically block a certain resource or not.

Promising vs Validating performance

1.1.1 No synchronous external scripts nor blocking external stylesheets

This can be validated, it does not need to be a policy.

1.1.3 No text-blocking external Web fonts

With 1.1.1. in place, this can be validated by checking for either font-display: swap or absence of web fonts.

1.1.5 Document layout not dependent on resource download

This can be validated, no?

1.1.2 Size limited inline scripts and styles

Why? AFAIK, AMP imposed some restrictions to guarantee that the first 14KB contains enough data to render some content after 1 content RTT. As such, the restriction is not on the size, but for optimizing the critical path. That's not to say that I want to encourage big inline blobs, but this restriction seems spurious.

---

For the above, a validation mechanism could be: fetch the first ~14KB and attempt to render content:

• If the first 14KB does not contain any content that can be rendered (e.g. due to large inline blobs in the head), validation fails.
• If you're unable to do render immediately due to blocking external resources (scripts/stylesheets), then validation fails.
• If @font-face is inlined then it should have font-display: swap.
• If content is missing dimensions, validation fails.

With above checks in place, you guarantee a fast first-render (modulo network latency). Further, none of these require "CPP opt-in" from the site. An embedder can run these checks against any site they want to link or display and verify the above properties.

---

1.1.4 No default-overriding events

@RByers have there been any discussions about providing a global opt-in for all handlers on the page? Drawing a parallel from font-display.. This seems less of a CPP policy, than a missing feature where I can "default" all of my event handlers to passive mode. The validator would just check for this opt-in.

1.2.1 Lazy loading of images

I still stand by earlier comments on... "Long story short, I think this space is too complex to reduce it to one or several keywords that you sprinkle on your elements." - see https://discourse.wicg.io/t/a-standard-way-to-lazy-load-images/1153/12.

1.2.3 Resource size limits

What's the goal here? Is this a promise to the embedder/linker that this page will/should not consume more than X bytes? If so, that's easy for embedder to validate on their own. Or, is this a mechanism for the site to enforce limits on third-parties? If its the latter, they can already do that via ServiceWorker.

1.3.1 No auto playing video and audio

No auto play in background tabs. Autoplay in foreground tab is valid and useful to the user.

1.3.3 No overlays

I'm not sure how this can be enforced. There are a million ways to deliver these, and some of them are valid use cases -- e.g. I navigate to a page that shows an overlay saying that it's outdated and user should go elsewhere.

1.3.4 No popunders

Browsers already block these and this can be validated.

1.2.2 Throttling CPU consumption on the main thread
1.3.2 Certain page components are limited to paint only on certain parts of the viewport

Conceptually... yes, but how and under what conditions can the above be enforced?

---

Stepping back.. I'm not convinced that CPP is necessary as a first class concept. It's a useful framework to help us think through "what conditions need to be true for us to have some upfront knowledge about its render and runtime performance", but I'm not convinced that the site needs to explicitly declare these.

Declaring that "i'm fast" doesn't make you fast. Having a mechanism to verify certain "agreed upon" best-practices—and in the process uncovering gaps in our API's—is where we want to get. That is, tell embedders: if you verify these criteria (and, maybe even: here's a "validator tool"), you'll be linking to a page that delivers a fast render + other guarantees that we deem necessary.