Skip to main content
Real User Monitoring

Top 10 Website Performance Metrics Every Developer Should Measure

John Demian John Demian on

There are 1.3 billion websites out there in the great unknown and it’s hard not to think about what makes them different from one another. Why do users flock to one website and ignore the other completely? One major differentiator is, of course, content. I’m not going to dwell on what type of content is better. Another reason why users stick to one website over another is the user experience.

Today we’ll be looking at a third major differentiator: Website Performance.

While simple websites are much easier to maintain and ensure peak performance, more complex web applications present a more difficult challenge when it comes to ensuring a smooth user experience on every level. To that end, I’ve compiled a list of some of the most important metrics you should track to measure website performance.

website performance metrics

 

1. User satisfaction and Apdex

Let’s start with something easy. And while it does sound like such a simple thing, there are complex concepts that can elude even the most advanced developers.

User satisfaction, or Apdex, is a measurement of your users’ level of satisfaction based on the response time of request(s) when interacting with your website or application.

There’s a simple mathematical formula that will help you calculate the satisfaction index for your web app and it looks like this:

apdex formula

Where T is desired or defined latency of request (as defined by you)

Satisfied count is number of samples (or requests) that received a response in T or less

Tolerating count = number of samples (or requests) that are 4 times T or less

Total samples = Total number of requests used to calculate your Apdex score

You’ve undoubtedly had a conversation with a developer who told you that based on their tests “the app loads in 2.5 seconds”. This is neither here nor there since tests performed under controlled environments aren’t going to show you real world data. People around the world will have different load times and they’re going to experience the app in a very different way.

This is why the user satisfaction index is one of the most important metrics for website performance – it’s based on the feedback received from your users and it will provide insight into how they are using the application.

2. FP/ FCP

First Paint (FP) and First Contentful Paint (FCP) is a performance metric that refers to the first pixels that are getting rendered after the users access your website and how long it takes for the user to see them. The difference between the two is that FP is the point when the browsers draw anything on the page, while FCP is the point where browsers start displaying pieces of content like text or images.

The most important parts of the website need to load first and fast. Google describes these parts as First meaningful paint (FMP) or hero elements and they need to be the priority. Here are a few examples:

perf metrics hero elements

Source: www.web.dev

How to Improve FP and FCP

Optimizing the FP/FCP is done by removing any render-blocking scripts and CSS from the Head of your document. You then identify the minimal set of styles you need to display the first important bits of your site. Using HTTP/2 server push on your app can result in incredible first paint times and it’s definitely worth a shot.

Server push is basically the ability of the server to send you multiple files to a single client request. Think of it like this, when you load your index.html you will probably need more files to render that page, like stylesheets or javascript file. What Server push does is that it packages those necessary files into one response so by the time the DOM is parsed your stylesheets and javascript will have already been loaded.

Here’s an example for Go version 1.8 and above where the server knows that app.js is needed for the page to be rendered. Therefore,it’s configured to load it before a traditional request for the file has been made on the client side.

   http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        if pusher, ok := w.(http.Pusher); ok {
            // Push is supported.
            if err := pusher.Push("/app.js", nil); err != nil {
                log.Printf("Failed to push: %v", err)
            }
        }
        // ...
    })

3. Time to interactive

The next thing you need to look for is the Time to Interactive (TTI) which measures the time until the application is rendered and can respond to user input.

Here’s a quick method to calculate your TTI:

  1. Start at First Contentful Paint (FCP).
  2. Search forward in time for a quiet window of at least five seconds, where quiet window is defined as: no long tasks and no more than two in-flight network GET requests.
  3. Search backwards for the last long task before the quiet window, stopping at FCP if no long tasks are found.
  4. TTI is the end time of the last long task before the quiet window (or the same value as FCP if no long tasks are found).

pasted image 0 1

Source web.dev

How to Improve Your TTI score

TTI optimization can be as simple as only loading scripts that provide interactivity only to the elements that have been loaded already. While this sounds simple in theory having apps that have content loaded but not interactive is quite common.

Nevertheless, there are certain things you can do to lower your TTI.

  • Minifying and compressing your code. It’s easy enough to do there’s really no cost involved.
  • Using Preload. When we use preload in the link tag it makes an early fetch request to get the resource. Mostly used to fetch high priority resources that are used in the current route.
  • Minimize the main thread work. The main thread is what turns code into a visual, interactive web page. It creates the DOM, parses the CSS and HTML and executes javascript. To reduce load on the main thread you can remove unused code, minimize your code and use Code spliting to make sure you are only running the code you are actually needing.

4. Page speed and load time

I’m talking about the moment the document.readyState has a status of “complete”. Page speed measures the time it takes to download and display the entire content of a web page. Over time, the page speed threshold has changed and it differs based on what type of site or webapp we’re looking at. For an eCommerce website, the accepted load time is between 2 and 3 seconds.

With the modern internet speeds and powerful machine, 2 seconds load time is pretty easy to attain. The challenge is in doing it over mobile networks, especially 3G. This is where the actual webapp performance comes in to play the most. You can’t use the same resources across all devices and expect the same result. The same website that loads in 2 seconds on your desktop is going to take up to 6 times longer on mobiles over 3G.

5. Time to first byte

Furthermore, your speed at which the first bits of information reaches your users is not consistent in all locations across the world. Your users from the United Kingdom will have a different experience than people in the United States.

To measure this we use a metric called Time to First Byte (TTFB) which is the time the first byte of each file reaches the user’s browser after a server connection has been established.

Speed Average Time to First Byte US

Speed Average Time to First Byte GB

Screencaps courtesy of thinkwithgoogle.com

How to Improve TTFB

Not having a good TTFB is going to affect both your user experience as well as your SEO efforts, so the first thing that will come to mind is, ok, how do I improve these numbers and the answer is that you can improve your time to first byte but it’s not going to be an easy task. Nevertheless, here are a few things you can do in order to get that first byte loaded faster.

  1. Optimize your code. It seems like an obvious thing to say but one that gets looked over often. Things like load balancers, static caches, and dynamic content are a few of the best ways to go about getting a better performing application but without having a proper monitoring solution, none of these will be of use since you won’t be able to see any bottlenecks in your system.
  2. Use a server that is suited for your needs. Having a high CPU and RAM usage all the time will inevitably degrade your TTFB. Sematext can provide realtime CPU and RAM usage and will help you optimize your resources.
  3. Use a content delivery network. A good CDN will help you deliver static content like images and scripts faster to the users via a network of servers all around the world. This will reduce the stability of the speed difference between users living in different parts of the world.
  4. Reduce queries. You’ll have to first check to see how many HTTP requests your website makes and remove the ones that aren’t critical. Reducing the number of images you load and combining your CSS files as well as making your asynchronous JS calls will speed get you a better TTFB all around.

6. DNS Lookup time

DNS Lookup time is the time it takes for a domain lookup to happen while the browser loads the resource. DNS lookups can add a significant amount of load time to your browsers especially if your app loads a large number of third party scripts.

There are a large number of different DNS providers and it’s basically a matter of finding the right one for your needs. To help paint a clearer picture of the different DNS providers you can use this tool to check the top-performing ones.

pasted image 0

Here you can actually check the DNS speed of a specific site in real-time from 200+ locations all over the world.

pasted image 0 2

To optimize your DNS Lookup speed all you need to do is figure out which service will provide the biggest bang for your buck. If you are looking for a high-volume, programmable, authoritative name server using Google’s infrastructure, try Google’s Cloud DNS. Of course, Google is just one option among other services.

7. Error Rate

Error Rate is a performance metric that tracks the percentage of request issues you have in relation with the total number of requests. It’s important to keep an eye on this number as any spike will mean that you are looking at a major failure at some point soon in the future.

Errors can be the result of countless different things and there’s no good way to prevent them. The best thing to do is to make sure you get in front of them by closely monitoring your website or application using a real user monitoring (RUM) tool.

8. Peak Response Time

Peak response time (PRT) measures the longest response time for all the requests coming through the server. It will give you an idea of where your web application is underperforming or having difficulties fulfilling requests and also help you pinpoint the culprit easier.

When working with third-party APIs it is important to monitor how they perform under load and what their response time is for users that are further away from you. You could be using the fastest CDN and have an app that scales gracefully, but if you are using an API to parse loaded profile pictures for users logging in that’s created only to serve people in the US, in an efficient way, all your users from Europe or Asia will have a pretty bad experience.

9. Hardware utilization

You may be under the impression that hardware utilization does not fall under your responsibility and the hosting company or the service provider has to keep tabs on their machines themselves, but in reality, this is going to directly affect your website performance so keeping tabs on hardware is going to be a priority.

You have three main components to focus on:

  • The CPU
  • RAM Utilization
  • Disk space

Any one of these components can create performance bottlenecks that can lead to catastrophic failures like shutting your entire server down.

10. Uptime

This is not a performance metric per se, but nonetheless, it’s a crucial aspect of your website or application. Remember that little number that you saw on your hosting company pricing page and it was around 99%? That decimal is extremely important and you really need to pay attention to it. Let me put things in perspective:

  • 99%: means around 7 hours of downtime
  • 99.9%: means around 45 minutes of downtime
  • 99.999%: means around 30 seconds of downtime

How to Measure Website Performance Metrics with RUM Tools

Webapp or website performance is not something you do once and then you forget about, but rather a continuous task that without the proper tooling will be close to impossible to accomplish. One way to analyze website performance metrics is by using real user monitoring solutions, such as our Sematext Experience.

With Sematext Experience, you can monitor your Apdex score, optimize Single Page Applications (SPA), see underperforming resources and dig deeper into individual user interactions with the website to get a more granular idea of how your app is performing and how visitors use your service. You’ll also be able to set alerts, creating a simple early warning system that will trigger whenever certain parameters are met. This way you’ll be able to take the necessary precautions to ensure peak performance and optimal user experience throughout the application.

If you want to learn more about real user monitoring check out our RUM guide where we cover everything from what is and how it works to benefits and use cases, or dive even deeper and read about RUM best practices, how real user monitoring compares to synthetic monitoring, or about the differences between RUM and APM.

Final Word

At the end of the day, regardless of what type of industry you are in, you’ll be dealing with users that expect to interact with websites and applications quickly and easily. If you don’t prioritize measuring performance you’ll be risking your bottom line. So make sure you track these performance metrics, as well as other key UX metrics when setting up your monitoring strategy. Check out the various types of monitoring tools that can help you. It’s as simple as that.