Find file History
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.

Stand-alone HTTP/2 prioritization test

An online version of this page is hosted at for use when testing.

This is a test page for testing the support for HTTP/2 prioritization on arbitrary hosts. All you need is a single image hosted on the server or service you are trying to test (preferably somewhere close to 100KB in size).

Recommended test conditions

THe test is designed to work in Chrome and leverages prioritization logic that is specific to Chrome in the testing. It also works best when tested on a low-bandwidth, high-latency connection.

DO NOT use the connection emulation built into Chrome's dev tools. It will not work correctly for testing for network-level prioritization issues.

Using WebPageTest, the recommended configuration is:

  • Location - Any location with Chrome available (Dulles, VA generally recommended).
  • Browser - Chrome.
  • Connection - 3G (1.6 Mbps/768 Kbps, 300ms RTT).
  • Runs - 3 (or more) to make sure the results are consistent.

Test Options

Generating the test URL

You provide the URL for the image to test as an image= query parameter to the page (make sure to url-encode the URL or the test will not run). The image MUST be hosted over HTTP/2 (or QUIC) otherwise the results of the test will be invalid. The test appends random query strings to the end of the image URL and will only work if the server still returns the image (most do but some like Twitter's image CDN do not).

i.e. Assuming you want to test the system hosting the image:

You would url-encode the URL to get the encoded version:

Then add the query parameter to the test page to get the URL for the page to test:

Interpreting Results

The test will:

  • Load the HTML Page (request #1).
  • Load the image twice, one at a time (Requests #2 and #3).
    • Establishes a connection to the server and warm up the TCP connection.
    • Each image gets a unique hash appended to the image URL to make sure they are all fetched over the network and not served from cache.
  • Request the image 30 times concurrently at a low priority (Requests #4-33).
  • Wait for two of the low-priority images to finish loading.
    • This gives the server a chance to fill any output buffers with the image data.
  • Request the image at a high priority and wait for it to complete (Request #34)
  • Request the image at a high priority (Request #35)

The goal is for the two high-priority requests to complete as soon as possible and as close to the reference time of request #3 as possible.

A passing server will complete both high-priority requests well before the rest of the images complete:

Optimal Waterfall

A failing server will take much longer for each of the requests (even if the individual requests don't take the full test time):

Fail Waterfall

The worst-case is when the first high-priority request (Request #34) doesn't return until after all of the low-priority requests have completed:

Epic Fail Waterfall