Performance Engineering 101: Top 5 Things to Consider for a Blazingly Fast Website

Performance is essential to the user experience and can have a tremendous impact on your success – that’s the premise for us at Enterspeed. This post will not provide concrete answers on how you achieve perfect performance. Instead, our aim is to have you begin thinking critically about the technical challenges and opportunities you have in front of you.

1. Get the Page to the User ASAP
2. But Show Something, Fast
3. Help the Browser, Help You
4. A Budget for Your Performance
5. What Gets Measured, Gets Done

If you want to can also dive into why making a fast website is SUPER EASY 😏. Or something like that...

Get the page to the user ASAP

It’s all about getting the page to the users, so they can get on with the job. As a performance engineer, your priority is to do that as fast as you can. You have two goals:

1. Efficiency: do as little on the server as possible
2. Proximity: do it as close to the user as possible

French philosopher de Saint-Exupéry said, “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” This can also be applied to performance engineering; the less work the server needs to do, the faster it can deliver content.

The server’s capacity has historically been the first bottleneck we experience when working with website performance. In order to defeat this problem, you have to minimise the amount of work you ask the server to do before the page is ready to send to the user.

The least amount of work a web server can do is to serve a static file. Theoretically, you want your website to consist of static files, so your web server can serve as many users as possible. Static files are also easy to duplicate around the globe, so you can have your content as close to the user as possible, achieving at the same time your second goal regarding proximity.

But the problem is more nuanced than this. Your website is not completely static. You want to do updates at regular intervals or the users’ actions require feedback or other dynamic updates to the website – e.g. adding products to a basket or showing the latest price. Other times, you want to have highly personalised content.

So, you need to be dynamic to some degree. In order to be dynamic, you need to fetch data from a database or web service and process this at the server.

Finding the right balance between static and dynamic is highly dependent on the type of website and content you have as well as the geographical distribution of your audience.

Speed, agility, and customer experience are interconnected. Learn, how you can serve edge data at the front – to make you more agile.

But show something, fast

Users are impatient, and rightly so. Research shows that after 1 second, the user stops feeling in control and the UX recommendation is to show feedback for any operation that takes more than 1 second.

To translate that into website performance, it means that you have 1 second to show some meaningful feedback to the user before the natural flow of interaction is interrupted.

In the previous section, we talked about what happens on the server. This section is about what happens in the browser. However, the same rules apply, you need to reduce the amount of work that the browser needs to do before it can show meaningful visual feedback to the user.

You need to consider what content is the most important, and organise the delivery of the needed HTML, CSS, media, and JavaScript to show that content first.

There are loads of technical details to consider and many more techniques for optimising the delivery of the most important content. One universal concept to understand is the critical rendering path, so you know how to organise the delivery of HTML, CSS, and JavaScript without blocking the critical path to output your most important content.

Help the browser, help you

Browsers are actually pretty good at providing a fast user experience, but they need a little help to be really good. Yet again it’s all about doing less to become fast. There are three main focus areas:

• Caching
• Number of requests
• Size of the files

Caching is a classic computer science concept. Browsers also have multiple caching strategies, so they don’t need to load the same things again and again. But in order for browsers to know what to cache, you need to tell them.

You generally want all the static files to be cached in the browser:

• CSS
• Images
• JavaScript

But you also want to make sure that new versions are downloaded. You tell the browser what to cache and for how long by using the correct cache headers and then abort the caching by using the cache-busting technique.

Now we begin to come into the nitty-gritty details. Caching is one technique to keep the number of requests low, but only on the subsequent page views. Also, on the initial page view, we generally want to keep the number of initial requests as small as possible.

But this is a double-edged sword. A way to reduce the number of requests is to bundle CSS and JavaScript files, so the browser doesn’t need to open too many connections. This can result in large files and CSS or JavaScript that aren’t needed on this particular page view.

The – perhaps – obvious technique for decreasing the size of the files is compression. Both text (CSS and JavaScript) and images should be compressed. Text is relatively simple, but images must be delivered in the right size and quality which must match the user’s device (i.e. mobile or desktop). The browsers have various methods for you to define the needed sizes.

An important note about the size of each file vs. the number of files – with the widespread adoption of HTTP/2 and the upcoming HTTP/3, the number of requests is of lesser concern, as the newer HTTP protocols can download multiple files over the same connection.

Again, your particular platform and usage scenario must be taken into account when deciding on the concrete implementation.

A budget for your performance

One technique to help you manage all this complexity in the technical realm of performance engineering is setting a budget. This is a simple but powerful concept. We already know that we strive to provide the user with meaningful content within 1 second.

Let’s expand that goal with two more metrics, so we also consider the server response time and when the user can begin to interact with the page. When talking about a web performance metric, this is expressed as the following:

• Time To First Byte (TTFB): 100 ms
• Largest Contentful Paint (LCP): 1000 ms
• Time to Interactive: 2000 ms

(The exact numbers are only for demonstration purposes; they should be tailored to your specific circumstances).

Other performance metrics like Google’s Lighthouse performance score, the size of the HTML document, or a number of third-party scripts could also be included as budget targets.

A performance budget is useful for both the development team and when monitoring production.

What gets measured, gets done

Performance in one of those places, where you can’t take the eye off the ball. If you actively work with your website and add content, features, and new marketing efforts, you will almost certainly see your performance deteriorate over time.

There are two kinds of monitoring:

• Real User Monitoring (RUM)
• Synthetic Monitoring

We think they complement each other, but if you have to choose one, chose Real User Monitoring.

Real User Monitoring gathers data from your actual real-world visitors. This is important as the real experienced performance is affected by factors such as connection type, bandwidth, device size, and performance characteristics.

The best Real User Monitoring solutions allow you to correlate your performance metrics with your business metrics, so you can better evaluate which performance issues affect your business the most.

Synthetic Monitoring gathers roughly the same metrics, but the source of the data is either your own workstation or a computer in the cloud. The environment is, therefore, much more controlled; it’s easier to compare data over time as the variables are fewer.

Also, monitoring the metrics in one’s performance budget is often done using Synthetic Monitoring.

With continued monitoring, you can keep an eye on how the website performs against your budget.

How can Enterspeed help you improve performance?

In this post, we have covered everything from generating pages on the server, delivering them over the network, displaying meaningful content to the user to managing and monitoring the performance of your website. At Enterspeed, we are ready to help you with each of these steps.

Our data accelerator brings you blazingly fast data at the edge, so every request is fast and in proximity with your users. Our speed consultants can dissect your website and provide recommendations on your specific website, while our performance monitoring service helps you establish your monitoring setup and keep an eye on the ball for you.

And it's not just something we say ;) Here, you can read about a multi-store B2C franchise that serves a lightning-fast UX using Enterspeed 🚀

If you want to learn more, then please do not hesitate to contact us.