SpeedCurve Synthetic is built on top of the leading open source web performance testing framework WebPageTest, so our synthetic metrics are the same as what you're used to seeing in WebPageTest. Synthetic also tracks unique metrics, such as Hero Rendering Times.

SpeedCurve LUX tracks the same real user monitoring (RUM) metrics you may already be familiar with, as well as unique metrics like Interaction Times.

Both Synthetic and LUX allow you to create and track custom metrics. 


Sometimes also called "First Byte". The time from the start of the initial navigation until the first byte of the base HTML page is received by the browser (after following redirects). This typically includes the bulk of backend processing: database lookups, remote web service calls, stitching together HTML, etc. This is a good approximation of the time it takes your server to generate the HTML on the server and then deliver it over the network to the user's browser.

Custom metrics

Custom metrics allow you to measure the performance of specific page elements that you've identified as essential to the user experience for your own pages. The W3C User Timing spec provides an API for developers to add custom metrics to their web apps. This is done via two main functions: 

There are other User Timing APIs, but mark and measure are the main functions. SpeedCurve supports custom metrics, so once you've added marks and measures on your pages, you can collect data with both SpeedCurve LUX (RUM) and Synthetic.


The backend time is the time it takes the server to get the first byte back to the client. The frontend time is everything else. This includes obvious frontend phases like executing JavaScript and rendering the page. It also includes network time for downloading all the resources referenced in the page.

Fully Loaded

The Fully Loaded time is measured as the time from the start of the initial navigation until there was 2 seconds of no network activity after Document Complete. This will usually include any activity that is triggered by javascript after the main page loads.

Hero Rendering Times

Hero Rendering Times are a set of synthetic metrics that are unique to SpeedCurve. They measure when a page's most important content finishes rendering in the browser. 

Largest Image Render identifies when the largest image in the viewport finishes rendering. This metric is especially relevant to retail sites, where images on home, product, and campaign landing pages are critical elements.

Largest Background Image Render is for those pages where the background image is just as – or more – important than the largest image. We created this metric to ensure that you're not missing out.

H1 Render measures when your first H1 element finishes rendering. This metric is especially useful to media and informational sites. Because the H1 tag is usually wrapped around header copy, there's a reasonable assumption that this is copy you want your users to see quickly.

Hero Element Timing – which is based on the Hero Element Timing API – lets you select and annotate specific hero elements on your pages, such as search boxes, image carousels, and blocks of text. Right now, if you're a SpeedCurve user, you can follow the instructions in the API spec to annotate your pages, and see the results in your SpeedCurve results. (As a bonus, when browsers inevitably catch up and adopt the spec, you'll be ahead of the game.)

Page Load

The Page Load time is measured as the time from the start of the initial navigation until the beginning of the window load event (onload). While Page Load can be a useful metric it can also be deceiving as depending on how the page is constructed it doesn't always represent when content is rendered to screen and the user can interact with the page. Unfortunately many organizations and other monitoring tools still default to reporting Page Load as an important performance metric. It's in no way a good measure of the user's experience and something the industry needs to move on from.


The Google PageSpeed Insights score is a number out of 100 based on a set of best practise coding rules developed and updated by Google. A score over 85 indicates a page that is performing well.

Speed Index

The Speed Index is the average time at which visible parts of the page are displayed.  It's dependent on size of the view port. It represents how quickly the page rendered the user-visible content (lower is better). Speed Index is often the metric we show by default as it best represents the user's experience as the page rendered over time from starting completely blank to the viewport being visually complete. 

In WebPageTest, the Speed Index is expressed in milliseconds. In SpeedCurve, we convert it to seconds, to make it consistent with your other metrics. 

You can find out more about how WebPageTest calculates Speed Index below.

Start Render

The Start Render time is measured as the time from the start of the initial navigation until the first non-white content is painted to the browser display. Any CSS and blocking JS you have on the page has to be downloaded and parsed by the browser before it can render anything to screen. This is called the critical rendering path and the Start Render metric is very important in understanding how long users have to wait before anything is displayed on screen.

Visually Complete

Visually complete is the time at which all the content in the viewport has finished rendered and nothing changed in the viewport after that point as the page continued loading. It's a great measure of the user experience as the user show now see a full screen of content and be able to engage with the content of your site. 


  • Does SpeedCurve measure Time to Interact or Time to First Meaningful Paint? Short answer: No. Here's why not, along with suggestions for metrics we think you should use instead.
  • Brief history of performance metrics. This post includes a side-by-side analysis of current rendering metrics.
Did this answer your question?