Performance control of embedded content #911
Conversation
| When it comes to optimizing performance, websites and apps are limited by the performance of the external content they embed, these can be 3rd party sites, 3rd party apps, and even content from other organizations within a company. As a result, being able to control the performance of embedded content is crucial to improving the overall performance of a site or app. | ||
| This proposal has two primary goals: | ||
| 1. Improve users’ satisfaction with their OS, browser, and applications via formalizing methods of constraining the resources available to web content. | ||
| 2. Provide information to help developers improve the performance of web sites and apps through reporting when performance is negatively impacting end-users and/or applications hosting the site in a frame. |
There was a problem hiding this comment.
I might swap the order of these two points, since the second goal is required to be achieved for the first goal to be achieved.
There was a problem hiding this comment.
I have it in that order to lead with and highlight the main driving factor, which is to improve end user experience. And you are right that the second goal is necessary to achieve the first. But I wanted to put emphasis on the end user impact.
|
|
||
| * Re-defines a mechanism for a problem already in the scope of Document Policy. | ||
| * The challenges in Document Policy are still applicable with a custom mechanism. | ||
| * Changes to iframe HTML element represent additional standards work. |
There was a problem hiding this comment.
I'm not sure additional standards work is a good reason to go with one approach and not another, so I'm not sure if that is worth listing
There was a problem hiding this comment.
The reasoning here was that even if we wanted to go with the custom mechanism option, we'd need to re-do a lot of the work that Document Policy already does. In particular, it seems like HTML spec changes are more challenging to get through, so defining our own would add that while not providing anything fundamentally better compared to Document Policy. I can remove this item.
|
|
||
| ## Non-goals | ||
|
|
||
| 1. Granular control of limits or individual criteria within a category. **The developer will not have control over granular values of each limit or individual criteria within a category. This is determined by the platform.** The key factor of this solution is there are predefined categories of focused, perf impacting features that embedder developers can choose to enforce restrictions on the embedded content in their app/site. This is to simplify the process and remove the burden from the embedder developer to determine individual constraints. |
There was a problem hiding this comment.
Nit: Referring to "criteria" and "category" feels a bit awkward before defining those terms. Can we make this more understandable for someone who hasn't read the whole explainer?
| | **C: Globals**<br>**Description:** Overall media and system resource usage constraints. | **- Cumulative resource consumption limits per interaction:**<br>* Caps on total media usage. No more than a total of X.<br>* Limits on iframe count. No more than a total of 10.<br>* Limits of iframe depth. No more than a depth of 10.<br>* CPU usage before first interaction: XMB. | - Report violations via Reporting API.<br>- Do not load media at all. <br>- Do not load iframes that surpass the depth. | | ||
| | **D: Script**<br>**Description:** Strict JavaScript restrictions. | **-Additional JS limits:**<br>* Long tasks in the main thread.<br>* High CPU usage.<br>* Workers with long tasks that exceed Xms.<br> | - Report violations via Reporting API.<br>- Stopping JavaScript if [in the background]. | | ||
|
|
||
| ### Discussion of different categories |
|
|
||
| #### Global budgets and side-channel attacks | ||
| The criteria proposed in this document includes budgets which are shared globally across documents. This could allow for documents to learn things about cross-origin documents, as described in the [Never Slow Mode explainer](https://github.com/slightlyoff/never_slow_mode?tab=readme-ov-file#global-limits). We consider the same alternatives as NSM as viable for this proposal: | ||
| * Require CORS |
There was a problem hiding this comment.
Agree with Alison - I don't think we should be referencing the NSM doc like this, we should take the contents we care about from it instead.
…hub.com/nishitha-burman/MSEdgeExplainers into performance-control-of-embedded-content
First draft of explainer for performance control of embedded content.