Today, large web applications are often assembled from many independent pieces, which all load their own data and resources. When all these pieces compete for the same network connection, congestion can build up and the user experience can suffer.

To address this problem, we’re excited to introduce a new feature which web developers can start testing in Microsoft Edge today: Network Efficiency Guardrails.

If you’re a web developer, improving the load performance of your app starts with knowing what to focus on first. However, when your web app embeds a mix of first-party and third-party content from different sources, optimizing performance depends on each of these pieces—not just on what you built. That’s why identifying the resources that need to be optimized to improve your app’s load time is crucial, and that’s exactly what the Network Efficiency Guardrails feature does.

So, if you’re working on an app that embeds content, read on to learn more about Network Efficiency Guardrails and start using them.

Detecting bad resource-loading patterns

Based on our own experience working with large web-based applications, we know that there are certain resource-loading patterns which have a disproportionate impact on performance. For example:

• Very large images
• Uncompressed resources
• Large data: URLs

With the Network Efficiency Guardrails feature, you can ask the browser to monitor your app’s network resource usage. Once network monitoring starts, the browser automatically identifies inefficient resource-loading patterns and reports them to you. You can then use this information to optimize your app for all your users.

In practice, you first opt into the feature by setting a Document Policy. Once you’ve done that, the offending loading patterns which the browser detects are reported as policy violations through the Reporting API, a web platform mechanism that lets you send structured reports back to your server when something notable happens at runtime.

What gets reported

Currently, when you opt into the Network Efficiency Guardrails feature, Microsoft Edge will use the following criteria to identify policy violations:

• Text-based resources that are not HTTP-compressed.
• Images larger than 200 kB.
• data: URLs larger than 100 kB.

These are our initial criteria, and we believe they are effective at flagging resource usage patterns that are atypical for well‑performing apps.

We chose these criteria based on aggregate, real‑world data, established industry best practices, and Web Almanac findings. To learn more about how these values were chosen, you can read about it in our feature explainer document. We expect to make changes to these values as we continue to gather more feedback and data.

Try Network Efficiency Guardrails today

The feature is available in Microsoft Edge, starting with version 146. To try it, you’ll first need to enable it:

1. In Edge, go to edge://flags.
2. Type “Experimental Web Platform features” in the Search flags text box at the top.
3. Under the Experimental Web Platform features section, select Enabled in the dropdown menu.
4. Restart Edge.

Enable the document policy on your site

Next, opt into the feature by enabling the document policy on your site, which you can do in either of these two ways:

• Set the document policy by sending the following HTTP response headers from your server:

  Document-Policy:network-efficiency-guardrails; report-to=neg-endpoint
Reporting-Endpoints: neg-endpoint="/neg-reporting/"

  The report-to endpoint name and value are not important yet. They’re only required so you can start seeing reports, but you don’t need to have the server endpoint running yet.

• Or set the above response headers by creating a local override in DevTools instead. To learn how to do this, see Override HTTP response headers.

  This can be helpful to quickly get started since you don’t have to modify your server code.

View the reported violations

Now that you have everything set up, you can use your app as normal, and the browser will start reporting problematic network usage patterns to you. You can view the reported violations either in DevTools, or on your server.

Using DevTools for this is a simple way to get started. As violations get detected, they’ll appear in the Console tool as error messages:

And you can also see them in the Application tool, under the Reporting API section, where you can find more details about each report:

Viewing the reports in DevTools is a great way to get started. However, if you want to use Network Efficiency Guardrails in production, and receive real reports from your users’ devices, you’ll also need to configure a reporting endpoint on your server.

Configure a reporting server endpoint

To collect reports in production, use the report-to field in the Document-Policy header, giving it the name of your choosing. And then specify the value for this server endpoint in Reporting-Endpoints:

Document-Policy: network-efficiency-guardrails; report-to=neg-endpoint
Reporting-Endpoints: neg-endpoint="/neg-reporting/"

Now, configure the /neg-reporting/ endpoint on your server and make sure it can receive the reports, as well as accept preflight requests if you’re using a cross-origin endpoint.

To learn more, read the Reporting API documentation at MDN, and our feature explainer.

View reports client-side

You can also retrieve violation reports on the client with JavaScript code. The reports are exposed to the document where they got created, through the Reporting client-side API.

Use the ReportingObserver interface to access these reports as they are raised, and look for reports that have ReportBody.featureId === "network-efficiency-guardrails".

Let us know what you think

The Network Efficiency Guardrails feature is in its early stages of development, and we’d love you to try it and share your feedback with us.

Learning about your app’s specific network usage patterns can help us design the right API for you.

We’re actively exploring the following open questions, so now is a great opportunity to try the feature and help us improve it:

• Fine-tuning existing guardrails: help us better detect the network usage patterns based on your data and feedback.
• Adding new guardrails: are there additional patterns that we should be considering?
• Cross-frame reporting: how should a parent frame monitor a child frame? Should bidirectional monitoring be possible? How should guardrails be enforced on embedded frames?

Checkout out the Network Efficiency Guardrails explainer and let us know your feedback by opening a new issue.