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.