The Complete Front-End Performance Testing Guide-1

The Complete Front-End Performance Testing Guide

As we dive into the festive season, keeping an eye on the performance of websites for businesses like retailers, publishers, and financial companies becomes super important. Initially, our teams work hard to make our sites speedy, but the real challenge comes in maintaining that speed once our application is out there in the real world.


I often chat with developers and testers who are wrestling with questions like how to keep track of their site’s speed over time and understanding the impact of new code releases on front-end performance.


So, I’ve gathered some top-notch advice from performance experts, like Andy Davies, the brain behind “Using WebPageTest: Web Performance Testing for Novices and Power Users.” 


Let’s delve into:


  • The psychology behind response times.
  • Why front-end performance is a big deal.
  • Different ways to measure how well your application performs on the client side.
  • Check out some free tools and paid alternatives.
  • A practical workflow for your developers.

Transport yourself back to 1968 when Bob Miller was exploring how we react to delays. He discovered that if you get a response within a tenth of a second after taking an action, your brain registers it as instantaneous. For instance, press a button, and if a light turns on within a hundred milliseconds, it feels immediate.


As the delay stretches to about a third of a second, you start noticing the lag. If the response comes within a second, you can smoothly continue without feeling disrupted.


Check out this graph showing response times and our perception of delays:

Table of contents
Response time and how we perceive delays

However, the longer the delay, the higher the likelihood of people bouncing. In 1968, the limit was found to be around ten seconds. Fast forward a few years, Microsoft conducted similar research and found the limit extended beyond the seven or eight-second mark. It’s a fascinating journey into understanding how our perception of time influences our online experiences!

Why does the response time of a webpage matter?

Well, let’s talk about money!


If your website keeps people waiting or delivers a slow experience, it can seriously hurt your business. Real data shows that user experiences on websites directly influence their behavior. Take a look at this chart from a product that tracks real business experiences and how they affect user behavior:

peed affects how visitor's behave

As you can see, folks with fast website experiences tend to view more pages. For retailers, that means more product views and potentially more sales. If you’re in the publishing world relying on ads, it means more story reads. The speed of your site can make or break its success. Keep reading to understand how to keep your website in the fast lane!

And how successful our sites are

In the chart above, pay attention to the orange line—it signifies the bounce rate.


What’s the bounce rate? It’s a measure of how many people land on your site, check out one page, and then bounce away. A high bounce rate indicates that visitors are leaving without taking any action. Not ideal.


Notice that the bounce rate is at its lowest around the three-second mark but steadily rises after that. The longer you keep people waiting, the more likely they are to simply view one page and exit.


Now, let’s shift our focus to the blue line, which represents the conversion rate.


The conversion rate reflects how many people make purchases or spend money on your site.


Observing the chart, you’ll notice very few conversions happen in the first three seconds—probably because not many pages load completely in that time. However, as we extend the waiting period, the likelihood of conversion decreases.


In the critical four-to-seven-second range, our conversion rate drops from five to four percent. That means a significant loss in revenue. 🙁

Improvements can nave a nuge payback

Take a look at the chart above, showcasing an actual scenario where Andy provided assistance to a retailer in enhancing their site’s speed.


Initially, the retailer was focusing exclusively on Android users. With Andy’s expertise, he implemented a few tweaks that resulted in a remarkable four-second improvement in the median experience for these Android visitors.


And here’s the exciting part—just with that minor adjustment, the revenue generated from these Android users skyrocketed by an impressive 26%! It goes to show how even seemingly small changes in site speed can have a substantial impact on user experience and, ultimately, the bottom line.

Why you need to focus on more than just your backend performance

It’s common for teams to invest a significant amount of resources in optimizing backend performance—fine-tuning server farms, databases, and testing capacity to ensure a speedy delivery of the initial HTML payload to website visitors.


Let’s delve into some examples from various UK sites with a graph depicting front-end load times:

Over 80% of load-time is on the front-end

In this graph, the pink band represents the time it took for the backend to generate the initial response. The blue, on the other hand, encompasses all the other resources—images, scripts, stylesheets, essentially everything needed to complete the payload.


While it’s crucial not to overlook backend performance, it’s equally important to recognize that the majority of the work affecting user experience occurs in the browser.


Before the backend delivers a response, there’s no action for the front end to take. However, the critical work influencing the user experience happens in the browser.


To effectively measure front-end performance, it’s essential to adopt a mental model that aligns the metrics gathered with the actual business experience. The model illustrated below is one commonly used:


Understanding this model helps in comprehending how the metrics collected translate into the real user experience and aids in making informed decisions to enhance overall website performance.

Mental Model for Software User Experience

What are we thinking when a page is loading_

The image above illustrates the visual cues that indicate to a visitor that everything is functioning correctly.


In this instance, we observe the change in the website’s address in the browser bar. But the question arises: when does the page truly become useful? Is it when the hero image appears in the center?


This point varies for different websites.


For a news site, usefulness might begin when someone can start reading the news. For an online retailer, it could be when the product image materializes, confirming to the visitor that they’re on the correct page.


Another factor to consider is when the page becomes usable. In the given example, usability might be delayed as the menu button is not immediately accessible.


When addressing front-end performance, the focus is on understanding how long it takes for a page to load before it becomes genuinely useful and usable. What transpires in the initial phase is crucial.

How to Measure How Your Front-End Pages Performance

There are two broad ways of measuring how pages perform.


To gauge the performance of your front-end pages, there are two primary methods:

Synthetic Testing

  • Conducted in controlled, lab-style environments with predefined test setups under known conditions.
  • Mimics scenarios to assess performance under specific circumstances.

In the Wild Testing

  • Carried out in real people’s browsers, using the devices and networks they typically use.
  • Provides insights into actual user experiences in diverse conditions.


Both approaches have their significance, but this post will focus on the lab approach. This method closely aligns with how we initially integrate performance considerations into our workflow.

For a more comprehensive understanding, check out this list of free Application Performance Monitoring (APM) tools to enhance your performance measurement toolkit.

Where to start thinking about front end performance?

When it comes to front-end performance, the crucial starting point is to embed performance considerations into your Software Development Life Cycle (SDLC) from the get-go. Early integration is key!


Here are key situations during which you should be mindful of performance:


  • Planning Phase: When in the initial planning stages, contemplate the size and composition of your pages.
  • Build Testing: Run tests on each build to evaluate whether the site has become faster or slower.
  • Release Tracking: Monitor releases using external Application Performance Monitoring (APM) tools to understand how performance changes post-release.
  • Monitoring in the Wild: Use synthetic and real-user-experience monitoring tools to comprehend what users are experiencing in real-world conditions. Adjust strategies based on this feedback.
  • Optimizing Resources: If your application includes a plethora of fonts, scripts, and images leading to slow response times, reconsider your choices and streamline your site.
  • Continuous Integration/Delivery Pipelines: Integrate performance testing into your continuous integration/delivery pipelines. Test against performance Key Performance Indicators (KPIs) to ensure a consistently high-performing user experience.


By weaving performance considerations into these stages, you lay the foundation for delivering an optimized and responsive front-end experience to your users.

So, how can you start building performance into your SDLC?

To integrate performance engineering into your development workflow, follow these steps:


  • Explore Synthetic Testing Tools: Start by identifying tools suitable for synthetic, lab-type performance testing environments.


  • Incorporate Tools into CI/CD Process: Integrate these performance testing tools into your Continuous Integration/Continuous Delivery (CI/CD) pipeline. This ensures that with each code check-in, you can evaluate the impact on performance.

Introduction to Google Lighthouse

Begin with Google Lighthouse, a powerful tool for assessing performance. It is seamlessly integrated into Chrome DevTools. If you have Chrome installed, you can immediately start experimenting and exploring its features.


  • Using Google Lighthouse in DevTools: Open Chrome DevTools, where you’ll find the Lighthouse option (formerly known as the Audit panel). Activate Lighthouse, and it will analyze the page’s performance, accessibility, and SEO best practices.


  • Mobile and Desktop Testing: Lighthouse provides flexibility for testing in both mobile and desktop scenarios. You can emulate a mobile device with a smaller screen, a slower CPU, and a reduced network speed, or opt for desktop testing.

Reuse Existing Automation Tests

Leverage your current automation tests to capture performance data using Google Lighthouse. Tools like Cypress.io offer a Cypress-audit plugin, allowing seamless integration with Lighthouse.


By following these steps, you not only gain insights into your web application’s performance but also establish a systematic process for continuous performance evaluation within your development workflow. The incorporation of tools like Google Lighthouse and Cypress.io makes the process efficient and, as you rightly pointed out, cool!

What’s Your Performance Number?

Let’s take the UK version of Amazon as an example site to demonstrate Lighthouse’s features.


After Lighthouse completes its audit, it generates a report resembling the one below:

What’s Your Performance Number_

In this example, the performance score is 20, which may not be excellent, but having a metric that can be tracked over time is valuable. It serves as a useful point of discussion with your company stakeholders regarding performance.


You can use this number as a benchmark to monitor improvements or declines over time. It can also be a useful metric for comparing your performance against that of your competitors.


Once you have your performance number, you can begin focusing on strategies to enhance it and continuously work towards improving your website’s overall performance.

Other Google Lighthouse Features

Beyond the primary performance score, Google Lighthouse provides additional metrics that offer insights into the visitor’s experience during page loading.

Other Google Lighthouse Features

Here are some key metrics:


First Contentful Paint: Indicates when content begins to appear on the screen. This metric helps assess how quickly the initial content is rendered.

Speed Index: Measures the time it takes for the visitor’s screen to transition from blank to fully complete and stable. A faster speed index contributes to a better user experience.

Time to Interactive: Aims to measure when a visitor can actively interact with the application, such as clicking, scrolling, or entering text into a text box.


These metrics provide a nuanced understanding of the visitor’s experience on your site.


While the total “Performance” score serves as a high-level metric for tracking relative performance over time, these lower-level metrics offer a deeper analysis. They help you identify areas for improvement or potential issues.


Additionally, Lighthouse generates suggestions for enhancements, and in the diagnostics section, it provides insights into why a particular score was given.


In summary, Google Lighthouse provides both a top-level performance metric for tracking and sub-metrics that allow you to delve into specific aspects, aiding in the continuous improvement of your page’s speed and overall performance.


There are several cost-effective commercial tools available that can assist you in tracking your Lighthouse scores over time. Let’s explore a few of them:


DebugBear runs Lighthouse regularly on the web pages you provide and generates dashboards showcasing key front-end performance metrics. These dashboards make it easy to observe how your performance metrics are evolving over time.


Treo is another tool that creates Lighthouse dashboards and tracks performance changes over time. It provides snapshots of scores, timings from the latest test, and the main score, allowing you to visualize changes over time.


Often referred to as the Swiss army knife of performance testing tools, WebPageTest uses real browsers, not just Chrome. It supports testing in various browsers like Firefox, Edge, and Chrome, as well as on real mobile devices. WebPageTest allows testing from multiple locations globally.


After completing a test, it generates a report with a slightly lower level of detail compared to Lighthouse but offers a rich and wide set of metrics. The video film strip view in the report is particularly effective for illustrating key performance areas and building empathy for the visitor’s experience.


Just like commercial variants of Lighthouse, there are also commercial equivalents of WebPageTest.

SpeedCurve and Calibre

SpeedCurve and Calibre are two such products that use the same engine as WebPageTest. They allow you to track performance over time, providing insights into your site’s performance in both staging and live environments.


Both SpeedCurve and Calibre enable hourly or daily tracking of your site’s performance, aiding in continuous improvement.


By utilizing these tools, you can not only make snapshots of your performance but also integrate them into your SDLC to effectively track and understand how your performance evolves over time, enabling proactive measures for improvement.

The Power of APIs in your CI/CD

The power of APIs in your CI/CD pipeline is significant, especially when considering tools like DebugBear, Treo, SpeedCurve, and Calibre that offer API capabilities. The ability to initiate tests on-demand and retrieve results seamlessly enables integration into your build processes and development lifecycle.


By incorporating these tools with APIs into your CI/CD pipeline, you can track the impact of changes on performance metrics such as Lighthouse scores, raw timings in WebPageTest, SpeedCurve, and Calibre. SpeedCurve and Calibre, in particular, have the added advantage of tracking performance over time.


While open-source tools are available, Andy emphasizes the importance of vendor-paid solutions for accessing advanced functionality and insights. Integrating front-end performance testing into the continuous integration cycle is a valuable practice to ensure consistent attention to performance.

Wrapping up

For those starting with front-end performance engineering, Andy suggests beginning with simple tools like PageSpeed Insights, Lighthouse, or commercial services. Establish baseline metrics, monitor changes, and gradually progress to more advanced speed improvements over time.


The impending use of performance as a ranking factor in Google’s search algorithm underscores the growing significance of front-end performance. Incorporating performance considerations into your workflows now positions your business for better user experiences and potential SEO advantages in the future.

Frequently Asked Questions

Front-end performance testing involves evaluating the speed, responsiveness, and overall user experience of web assets such as websites and web applications.

Front-end performance directly impacts user experience, as slow-loading websites or apps can lead to frustration and abandonment, while fast-loading sites tend to have higher engagement and conversion rates.

Common front-end performance issues include render-blocking resources, unoptimized images, excessive JavaScript, and poor server configuration.

Front-end performance testing should be conducted regularly, especially before major releases or updates, to ensure optimal performance and user satisfaction.

Integrating performance testing into CI/CD pipelines allows for automated and consistent testing throughout the development lifecycle, enabling early detection of performance regressions and faster resolution of issues.