Follow the metrics that really matters with the Web Scenario view

First impressions: dashboard

On the landing page "Web scenarios" here are all the scenarios that have been created for your website. This first view is a dashboard of all your web scenarios. It allows you to analyse quickly and efficiently your website performance.


Firstly, you will find the availability (uptime, downtime) and the number of your incidents for each web scenario during the selected period.

You will also see the average, the variation and the grade for the 3 following performance metrics: 

Time to last byte:

Measuring the elapsed time between the very first HTTP request (web page request) sent by the browser and having received the full answer by this one. The content of this first request is basically the HTML code of the page.
This particular step of the page load time is critical because it can block everything else from loading. The reason for that is that while its not fully downloaded, the browser can only draw a blank page (or a loading sign if we were to clic on a link).
It is only after this step that the browser will be able to download all the images, css files, javascripts and so on. If too long (above 800ms), this first waiting time can be quite painful for a user and often leads to a high bounce rate and a damaged SEO ranking.
If fast (below 300ms), it shows the ability for your application and infrastructure to quickly produce and deliver the requested pages.

Speed Index:
Measuring the elapsed time between the browser web page request and the rendering of the visible part (above the waterline) of this one. This index provides an estimation of the time "felt" by your users and allows you to evaluate the complexity of displaying your web pages.

More precisely, this time is a mathematical calculation representing the progression of the pixels drawn on the screen during the loading time, in comparison with the final image of the page entirely loaded.

This time, measured in milliseconds, is much smaller if a majority of the visuals of the page are displayed quickly to the user, even if a few small elements are still missing and need a few more seconds to load for the page load time (OnLoad) to be complete.

It is this difference that makes Speed Index a metric much closer to the user's feeling during the loading time. Because, in the end, if 95% of the page is already displayed, the user tend to consider that it is loaded. The last 5% can take a bit more time, this will not impact much the user experience.


Measuring the elapsed time between the browser web page request and the loading of all the elements inside (main document, images, scripts, third-party tags, etc.). It means the required time to obtain, display and dynamize the entire requested web page.

In comparison with the Speed Index, the onLoad can be much impacted by a single missing element of a page. Considering the growth of the average number of elements inside a page (especially for e-commerce stores), we can see that statistically this metric can be easily damaged due to a single element that slows down the page load time.

This phenomenon can also occur because a big part of the many elements composing a page are often hosted outside the main website platform. A common example would be tags of third party apps (tags for AB tasting, tracking, attribution) that could slow down the page load time because an incident occurs on one of the third party's platform, somewhere else on the internet.

In conclusion, if the OnLoad time goes very high, it is important to look into more details to spot if a particular element is causing the delay.

Grades are from A to F, A the fastest, F the slowest. Grades consider the configured bandwidth into your web scenarios. In fact, a user on his smartphone with 3G connection, does not expect the same performance than someone using a fiber connection on his laptop.

Go further

For each listed metric above, you can click on the "more details" icon at the end of each line. You are going into a more detailed view introducing your web scenario steps and the measure points recorded during the selected period of time into a chart. Each tab allows you to see a different metric.



Then for each step you have again a higher level of details which allow you to obtain performance measurements also on the application, the network exchanges, the navigation performance data as well as the resources'division and weight of your pages.

Charts are dynamic, you can modify the displayed period using the Calendar (top right, as in Google Analytics). The period is applied to all the graphs of the page and common to all the features of the app, by changing the section in the app you always keep the same time scale.

 You can easily zoom in and out by dragging left to right on the graph (zoom in) or right to left (zoom out).

On the vertical axis you will find the total time that our probe took to browse all of your pages (which are color coded as indicated below the chart). On the horizontal axis you will find the exact time of each event.

Below the chart, you will find the loading time details for each of your pages. We report the minimum (min), average, and maximum (max) that Quanta have measured during the selected period.

So how do I interpret this?

  • When your website is stable and below defined thresholds, this is Quanta's "sweetspot" and the bar above the graph will be green when this is reached.
  • An orange bar appears, you are in average acceptable performance, but optimizations are possible to improve the loading time and the user experience

  • If your bar is red your site is not optimized for a good user experience, impacting conversion and SEO!

  • Beyond thresholds, you’re losing vital conversion and optimisation should be a strong priority. Fortunately, at this rate the potential optimisations are huge. Think about it this way, reaching our sweetspot would mean a big reduction in your page loading time!


Have more questions? Submit a request


Please sign in to leave a comment.