Boost Your Page Load Times with Performance Engineering, Part 1 of 5

Nobody likes long load times — especially not your end users. When faced with poor loading experiences, they’ll become frustrated and leave your site, leading  to increased bounce rates and decreased revenue across your web presence. Even worse, if a competitor's site is faster, that revenue loss may be permanent. 

That’s why the onus is on you to continuously optimize your page load times. Read on for an in-depth look at performance engineering and the solutions for leveraging it to bolster your users’ digital experiences.

Unpacking today’s web performance challenges

In 2021, Google published an analysis of the Renault Group's conversion rates after adjusting one performance metric, Largest Contentful Paint (LCP). Their findings were staggering: an increase in wait times of approximately three seconds decreased conversion rates by 50%.

So, why the massive drop? The answer is simpler than you might think. In 2013, Tammy Everts, a former researcher, writer, and solution evangelist at Radware, published research that used electroencephalography and eye-tracking technologies to prove that slow-loading pages increase user frustration and decrease engagement. Users who were served poor browsing experiences felt less inclined to make purchases, lost brand affinity, and ultimately decided not to visit those sites again in the future.

Then, in 2020, the Nielsen Norman Group published an article compiling surveys and research papers from several major websites that measured the ways poor site performance leads to decreased revenue. 

Data presented in Nielsen’s report shows that performance engineering can improve an organization’s bottom line. For example, the BBC found that they lose 10% of users for every extra second of site load time — which yields a significant blow to revenue.

Connection speeds increase, but wait time remains the same

The problem, as illustrated by Nielsen’s report, is that websites grow more and more bloated every year. Despite mobile connection speeds growing sevenfold in the last 10 years, page load times — the average time the user waits between clicking a link and seeing any results — have remained roughly the same.

Put another way, while network capacity increased, download rates remained the same as websites became more and more unwieldy. The solution to this problem? Leveraging performance engineering techniques to streamline your website and enable far quicker loads.

What is web performance engineering?

Web performance engineering is the branch of software development that studies the causes of — and solutions to — slow websites. Generally, there are two main causes of bad performance:

1. Unoptimized front-end code attributed to a lack of understanding of a web browser’s single-threaded nature
   
2. Slow connections, whether temporary or permanent
   

In fact, roughly 85%–90% of performance problems are caused by unoptimized and buggy front-end code, which is why we’re focusing the post on HTML, CSS, and JavaScript browser code. We’ll also be looking at slow connections and how to measure them, but these are harder problems to solve, since website developers can't control user connection speeds and quality.

When front-end code impacts performance, web developers must identify the specific problem at hand. Observing synthetic and real-time performance metrics can aid in this task.

What are performance metrics?

The purpose of performance metrics is to tell web developers how much time it takes to load website actions and functionalities, such as visuals appearing on screen and user-input reactions.  These metrics help web developers by providing time and latency measurements that they can improve in the future.

But rendering a site — downloading code, images, and videos, then correctly arranging and displaying the resulting page — is a complicated process with many moving parts. 

And, of course, knowing that a site is slow doesn't help developers determine the problem’s cause. After all, it could be anything: a networking problem, assets loading in the wrong order or without strategic deferring, a script inefficiency that forces browsers to re-render several times — or just a single large asset using valuable resources. One number alone won’t reveal the answer.

Enter performance metrics, which were created to quantify all kinds of problems and circumstances. 

Managing the metrics’ powerful insights

Developers can unlock powerful insights from these metrics — so they shouldn’t limit themselves to just a single one. In fact, improving one metric is usually quite easy, but can leave out large portions of the website experience. When images load quickly but user interactions such as clicks or taps are sluggish, the website’s overall performance is still poor. It's best to improve both image loading and user interactions.

The problem with metrics is that there are so many of them that people new to performance engineering frequently become overwhelmed and confused by all the abbreviations and technical terms. Typically, web developers pick three metrics to follow. After a major change, they compare the three metrics to previously recorded values to quantify the change’s impact.

Illustrating the importance of Google’s Core Web Vitals

To help web developers select relevant metrics, Google created the Core Web Vitals: three metrics that indicate how well a website performs according to users. These are: 

• Largest Contentful Paint (LCP)
• Cumulative Layout Shift (CLS)
• First Input Display (FID)

Part 2 of this series on web performance will dig more into these Core Web Vitals.

To ensure web developers would pay attention to their Core Web Vitals, Google decided that these three metrics would influence website search rankings. An poor performance score would relegate the site to lower rankings, while faster, optimized sites would display higher in search results. Whether or not this has played out accordingly is debatable. Stay tuned for part 2, where we will investigate this matter further.

Either way, web developers who are new to performance engineering should follow Google’s three Core Web Vitals metrics to improve site performance and (potentially) search rankings.

Optimizing for users’ “impatience timers”

In addition to improving site performance, web developers can condition users into thinking their sites load faster than they actually do. To understand this idea, you need to think like a user.

Users find links to websites and click them. They then expect the site to quickly load so they can scan it to see if it fulfills their needs. They’ll wait a short while, but not too long.

Of course, exactly how much waiting is too much is disputed. In 1993, Jakob Nielsen estimated that users will retain their attention span for about one second, while Google Data found that the majority of users won’t wait for longer than three seconds. As such, all websites should load and display something within one second and should be completely loaded in three seconds. This expected length of time can be thought of as a user’s “impatience timer.”

The moment when a user clicks a link is known as Navigation Start. This is the starting point for many performance metrics. Each of these metrics calculates how much time elapsed between Navigation Start and event X, where X is the specific thing being measured, such as the first byte to arrive or first element the user sees on the screen.

Resetting the impatience timer

For users, Navigation Start has a slightly different meaning as it resets their impatience timer to zero. If a site doesn't load within a reasonable time frame, the user’s impatience timer begins. Once the timer times out, the user abandons the page — and may visit a competitor's site instead.

So, back to that idea that you can condition users into thinking their sites load faster than they actually do. If solving the site’s performance problem is too difficult or time-consuming, you can reset the user's impatience timer to zero by having something happen on the screen. If that's executed well, users may sit through a long load without becoming impatient enough to leave.

Akamai web performance architect Tim Vereecke calls this principle the Frustration Index and believes that, rather than focusing on single metrics, it’s better to watch the gaps between metrics: The bigger the gap, the bigger the chance a user will get frustrated.

Websites as restaurants: an attention analogy

As a thought experiment, let’s imagine that guests enter your restaurant at a time when the kitchen is very busy. Your servers then have to figure out how to buy the kitchen staff time without making the customer feel like they’re waiting too long.

The solution is to do everything slowly but steadily. Servers first show the customers to their table, let them get settled in, then take drink orders. After a few minutes, the server delivers drinks, and then waits another few minutes before returning with the menu. This approach gives customers plenty of time to decide.

When servers deliver each interaction at the moment the customers' impatience timer is about to run out, they can successfully buy the kitchen staff 15 to 20 minutes while making the customers still feel they're being attended to. When that’s the case, the diners are perfectly happy to reset their timers.

Web developers should strive for the same effect with their website's performance. Even if the website takes five seconds to load completely, they can reset the user's impatience timer by ensuring some visible progress takes place. In the next article, we’ll further unpack this process by studying Google’s First Contentful Paint (FCP) and LCP metrics.

Summary 

So far, we’ve seen how poorly performing sites can cost companies significant revenue — and how performance engineering can improve load times to boost the bottom line. To solve common performance challenges, we identified key metrics that web developers should know.

Of course, there are too many metrics for any one developer to manage. Typically, they choose three to focus on— and developers new to performance engineering should choose Google's three Core Web Vitals. 

Finally, there's a psychological aspect to performance engineering, since websites that reset users' impatience timers benefit from users’ acceptance of longer wait times.

Up next: more performance engineering tips to know

Our next article in this series will detail Google’s Core Web Vitals, and our third article will take a look at other useful performance metrics web developers should know. In the last two articles, which will conclude this series on web performance, we’ll look at 15 of the most common performance metrics, as well as their purposes and use cases, and give performance engineers vital details on how web browsers work.

Better websites with insights

Want to know more about Google’s Core Web Vitals? Learn from Akamai Lead Technical Solution Architect Oliver Hunt how we’re helping customers by using these vital metrics.