Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance control of embedded content #911

Open
wants to merge 21 commits into
base: main
Choose a base branch
from

Conversation

nishitha-burman
Copy link

First draft of explainer for performance control of embedded content.

Performance control of embedded content/explainer.md Outdated Show resolved Hide resolved
Performance control of embedded content/explainer.md Outdated Show resolved Hide resolved
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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Performance control of embedded content/explainer.md Outdated Show resolved Hide resolved

* 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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Performance control of embedded content/explainer.md Outdated Show resolved Hide resolved
Performance control of embedded content/explainer.md Outdated Show resolved Hide resolved
Performance control of embedded content/explainer.md Outdated Show resolved Hide resolved
Performance control of embedded content/explainer.md Outdated Show resolved Hide resolved
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants