Performance control of embedded content #911
Conversation
|
|
||
| ## Goals | ||
| With global web usage continuing to rise and more companies relying on the web as a primary platform to deliver their applications, performance has become a critical factor for success. As more users access websites through mobile devices and lower-powered hardware, the need for fast responsive web experiences is non-negotiable[^1],[^2]. | ||
| 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. |
| ## Goals | ||
| With global web usage continuing to rise and more companies relying on the web as a primary platform to deliver their applications, performance has become a critical factor for success. As more users access websites through mobile devices and lower-powered hardware, the need for fast responsive web experiences is non-negotiable[^1],[^2]. | ||
| 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: |
There was a problem hiding this comment.
This isn't showing up on a new line in the rich diff.
|
|
||
| ## Goals | ||
| With global web usage continuing to rise and more companies relying on the web as a primary platform to deliver their applications, performance has become a critical factor for success. As more users access websites through mobile devices and lower-powered hardware, the need for fast responsive web experiences is non-negotiable[^1],[^2]. | ||
| 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. |
There was a problem hiding this comment.
If this was meant to be a separate paragraph, it doesn't look like this is showing up as such in the rich diff. You may need to add an extra line
| 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.
|
|
||
| ### Scenarios | ||
| * Embedded widgets: Weather forecast, stock tickets, etc. | ||
| * Embedded Ads: Embedded ads from networks like Google AdSense or Bing Ads. |
There was a problem hiding this comment.
I would avoid adding specific company products (same with the line below)
|
|
||
| * 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.
| Using Document Policy for this proposal has limitations and challenges, including 3pp violation reporting, opt-in requirement, budget-based state leaks. A custom mechanism was briefly considered, but the following was determined for such approach: | ||
|
|
||
| * 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. |
There was a problem hiding this comment.
Might be worth relisting them out to be clear which challenges apply and why
There was a problem hiding this comment.
And were there any other approaches considered that didn't have these same challenges?
There was a problem hiding this comment.
Added more details on the challenges.
| ### Alternatives considered | ||
|
|
||
| #### Custom attributes and headers | ||
| Using Document Policy for this proposal has limitations and challenges, including 3pp violation reporting, opt-in requirement, budget-based state leaks. A custom mechanism was briefly considered, but the following was determined for such approach: |
There was a problem hiding this comment.
For those unfamiliar (like myself) it may be worth going into more detail on what a custom mechanism is and what that would look like in comparison
| * Changes to iframe HTML element represent additional standards work. | ||
|
|
||
| #### Levels vs categories | ||
| It was considere to have a single configuration point based on “levels” which would restrictions on top of each other, but this was discarded due to increased difficulty to introduce new values in the future. |
| * The challenges in Document Policy are still applicable with a custom mechanism. | ||
| * Changes to iframe HTML element represent additional standards work. | ||
|
|
||
| #### Levels vs categories |
There was a problem hiding this comment.
Might be worth going into more details on what this means and what it would look like in comparison.
I also think it could be worth expanding on why it would be difficult to expand the value set in the future
There was a problem hiding this comment.
Expanded on the "levels" approach and difficulty in adding criteria in the future.
First draft of explainer for performance control of embedded content.