Questions about design

[addyosmani]

It seems like one of the primary motivators for transfer-size is (per the README), enforcing size policies on content. In the current shape, transfer-size doesn't appear to actually perform the enforce step, deferring this behavior to the end developer in ontransferexceeded. Do we know what this was? (pardon if this is a redundant question).

As a result of this, transfer-size seems minimally useful unless you also have the Pause Document API. It's unclear to me as someone that would like the control to enforce size policies why the ability to pause the document loading is not something baked in. e.g ontransferexceeded=pause without having to jump back into JS to get this behavior.

Logging, while useful, provides questionable utility when we're talking about ads as each ad-based iframe payload can wildly vary. Perhaps I guess it's useful to beacon back to analytics how often your ads are breaking their budgets?.

I could see granularity/control being something we can do in a very limited way declaratively, thus a JavaScript API that supports doing this during runtime would make more sense. Especially since Pause Document supports doing this for rendering, loading and script. `ontransferexceeded=pause-script, pause-rendering' is likely going to be too clunky.

Mostly trying to understand some of the design decisions here :)

[jkarlin]

RIght, it's not an enforcer. We leave that up to the site author because there are so many enforcement options you might want.

Agree that PauseDocument is important for this proposal. However you have the alternative of unloading frames that grow too large and are of limited importance to the site.

In terms of ads and logging, don't forget the ad-network is also likely to want to track the creatives they show and which of them exceed limits and by how much.

[jkarlin]

I should note that, in my mind, this explainer is out of date. I'd like to shift to a TransferSizePolicy that automatically enforces limits by gradually throttling the network requests of the frame after the limit is exceeded. There would be no event at all. The primary reason for this change is to limit leakage of x-origin size information.

[addyosmani]

@jkarlin Could you expand on how you see gradual throttling working in practice? e.g origin foo.com exceeds a budget of 500KB and continues to request more resources. Would each subsequent request or set of requests simply be fetched slower? This model is much simpler than the one previously summarized here but I think it's still of high value and makes sense in the context of avoiding x-origin leakage of size data.

I'd love to learn more about the timelines for our plans here (given other types of policies have already started to land for feature policies V1).

[jkarlin]

Yes, the ongoing and subsequent requests would slow down a little bit, ramping down to 2G speeds (or perhaps less) after awhile. I'm afraid I haven't really thought about specifics. I worry about details like, what if you set the budget to 10KB, does it even make sense that it won't throttle down to 2G speeds until the frame is at (say) 1MB or more?

Timeline wise, I think we're more interested in using this as an intervention mechanism in Chrome, seeing how it works, and potentially exposing it via web api if we find it useful. So it'll be a bit down the road.