Intent to Prototype: SoftNavigation performance entry

[Yoav Weiss]

Contact emails

yoav...@chromium.org

Explainer

https://bit.ly/soft-navigation
https://docs.google.com/document/d/1eUyQg3YLEmYjrTMC3p-F1MilECwCynhM6WIbIo05SPU/edit

Specification

Not yet! 

Summary

Exposes (experimental) soft navigation heuristics to web developers, using both PerformanceObserver and the performance timeline.

Blink component

Blink>PerformanceAPIs

Motivation

Web developers have been asking for a way to take "soft navigations" - JS-driven navigations in Single Page Apps (SPA) - into account when exposing performance metrics. This exposes a browser heuristic to that effect. Doing that would enable developers to initially validate the heuristic compared to their own application- and framework-specific heuristics. Once validated, they can start relying on it when calculating the performance impact of various routes in their SPAs.

Initial public proposal

TAG review

Not yet. Once we validate that the heuristic makes sense and move on to specify it (and the underlying Task Attribution concept, which will be a heavier lift), it would make sense for the TAG to review this. I'll file one as early as possible, but once they actually have something to review :)

TAG review status

Not yet!

Risks

Interoperability and Compatibility

Gecko: No signal for now. Will file later.

WebKit: No signal for now. Will file later.

Web developers: Some excitement! 

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

Debuggability

Is this feature fully tested by web-platform-tests?

No

Flag name

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1338390

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5144837209194496

This intent message was generated by Chrome Platform Status.

[Arthur Hemery]

Hi Yoav!
We went through this in the OWP security&privacy review and I wasn't sure what kind of mitigation we had in place for credentialed third party sub resources timing. Do we have none and need to make sure the heuristic cannot be abused or can we rely on a safety net?
Thanks!
Arthur

[Yoav Weiss]

Can you expand more on your concern? Are you afraid that sites will trigger the heuristic frequently, resulting in frequent FCP/LCP reporting, which will reveal paint information of elements impacted by arbitrary cross-origin resource characteristics?

[Arthur Hemery]

Yes, that was the concern, having information about load timings deduced from FCP/LCP metrics. But my question was, what mitigations do we have for regular navigations? Let's say we have a main page with zero content but a third party iframe, can we time it's load time via FCP/LCP or do we exclude third party paints altogether? If not, the change might make things easier, less visible to users, etc.

[Yoav Weiss]

Thanks for clarifying!

Currently, the heuristic exposed doesn't (yet) expose FCP and LCP for those soft navigations. But let's assume that it does, and that is the eventual plan.

Currently FCP includes any cross-origin paints in the same context, but doesn't provide any details about them other than the fact that they happened.

So if we have a page where the only contentful element is a cross origin image, FCP would reveal when that image provided *any* data that enabled something to be painted.

The same would be true for soft navigation FCP - after a user click and corresponding "navigation", the FCP fired would enable the page to get timing data on the initial decodable buffer of an image.

I don't think that's worse than what FCP enables today.

One can think of potential mitigations (e.g. not fire FCP when the only paint is the result of a cross-origin image) for current FCP. The same mitigations can apply to soft navigations.

For LCP, we only include its render timing when TAO passes, and that would continue to be the case. So LCP won't expose any rendering data, even if triggered multiple times. Similarly, we have Element Timing that exposes the exact same data. 

[Yoav Weiss]

On Wed, Sep 21, 2022 at 1:35 PM Yoav Weiss <yoav...@chromium.org> wrote:

Thanks for clarifying!

Currently, the heuristic exposed doesn't (yet) expose FCP and LCP for those soft navigations. But let's assume that it does, and that is the eventual plan.

Currently FCP includes any cross-origin paints in the same context, but doesn't provide any details about them other than the fact that they happened.

So if we have a page where the only contentful element is a cross origin image, FCP would reveal when that image provided *any* data that enabled something to be painted.

The same would be true for soft navigation FCP - after a user click and corresponding "navigation", the FCP fired would enable the page to get timing data on the initial decodable buffer of an image.

I don't think that's worse than what FCP enables today.

Also, that doesn't seem significantly different than the time in which the cross-origin image's dimensions are available, which is already exposed, as they impact layout and can be queried through various JS APIs.

[Yoav Weiss]

Also also, to be more explicit about iframes, FCP does not expose any information about them, as they are not considered contentful. It only exposes paint information about the document's context, not any nested ones.

[Arthur Hemery]

Thanks for the details! Let me sum up for other readers and to make sure we're on the same page:

- FCP is not very useful for cross-origin resources. It only provides the timing of the first bit of answer. Some cross-origin resources already expose more, like the size of a painted image, which can be repeatedly queried to get paint timing.
- LCP requires the Timing-Allow-Origin header for cross-origin resources.
- Iframes are completely excluded from timings, as they are considered non contentful.

I think that's enough on the security side to go ahead.