Skip to main content

Running web performance experiments

DebugBear experiments allow you to run a site speed test with modified page HTML.

For example, you can:

How to run an experiment​

  1. Open the results of the page you want to test
  2. Select the Experiments tab

Test result with experiments tab

  1. Provide a name for your experiment, for example "Remove Google Tag Manager"
  2. Edit the HTML document and click Run Experiment

Form with document HTML and name of the experiment

  1. Wait for the test to complete

You can then see the impact of then change. In this example, where Google Tag Manager was removed, for fewer requests were made on the page.

Result of the site speed experiment showing reduced page weight

Blocking network requests​

In addition to modifying the page HTML you can also block network requests that match a certain pattern, for example a file extension or a domain name.

Use commas to apply multiple URL patterns.

Request blocking in experiments

The relevant requests will then show up as blocked in the results and the page weight will be lower.

Removed requests

Examples of site speed experiments you can run​

Adding priority hints​

Priority hints can tell the browser which resources are important and should be loaded early. For example, images responsible for the Largest Contentful Paint should be loaded with high priority.

You can use the request waterfall to identify the URL of the LCP image, and then modify the image tag to add a fetchpriority="high" attribute.

Removing render-blocking resources​

Render-blocking resources have a big impact on website performance as no content will show up until they are loaded.

Modify the page HTML to remove these resources or add async attributes to script tags to make them no longer render-blocking.

Adding or removing resource hints​

Resource hints like preload and preconnect can tell the browser about resources that it wouldn't otherwise discover until later.

For example, let's say you load a Google Fonts CSS file that references a font file. Normally the browser wouldn't discover the font file until after the CSS has loaded.

Adding a preconnect hint to the <head> of the page HTML could establish a server connection to fonts.gstatic.com as soon as the page starts loading, so the connection can be used immediately when the font file is discovered.

<link rel="preconnect" href="https://fonts.gstatic.com">

Resource hints can slow down your website if used incorrectly, so you can also try removing them to see how that impacts performance.

Adding CSS styles​

Cumulative Layout Shift issues can often be addressed by adding a min-height to elements that change size when content is loaded, for example images.

Simply insert a style tag into the HTML to try out your optimization.

<style>
#my-container {
  min-height: 200px;
}
</style>

Interpreting the results of experiments​

When an experiment is run you will not see a breakdown of the document request. Instead of showing a server connection only a single long HTTP request will be shown.

You may also see other changes, such as a change in compression format or protocol.

Document request is broken up into separate round trips normally, but experiment shows only TTFB

Your website likely experiences a significant amount of background performance variation. If the performance impact of a change is small, it may not be noticeable.

If your HTML content is large it will load more quickly in an experiment than in a real test. In that case, first run an experiment with no changes to the page and then compare that to the performance experiment.

Last updated on