Introduction

You opened a web page, wait it loading for a few seconds, get bored, close it!

How many times you face this problem?

I’m sure that you are facing it too many …

We as software engineers keep working on our web services (or websites) for some time, and step by step getting folded with the customisation, tickets, new CRs, and forget about taking care about performance. On the other hand, we as regular users, if there are more than one website offering the same service, we visit the fastest more.

This clue takes our minds to think about performance as a feature of our websites. As we need to take care with functionality bugs, clients CRs, customer feedback, we need to take care about how speed is our website. In this detailed article, we will talk about how to take care about the prformance of our websites. So let’s take the first step inside.

What’s web perofrmance

First of all we need to agree on a clear definition about what’s the web performance?

There are too many online definitions, but the one which we will use here is that web performance is the objective time of when a request for content is made until user can interact with that requested content. It’s not only about delivering the webpage’s content to the client side, but also about making sure that it’s in an interactable form.

Keep in your mind that in some forms of web elements, you can start interacting even before the content is fully rendered as we will discuss later.

Objectively, it is the frames per second the main thread is not available for user interactions.

Subjectively, it is the user’s perception of whether the time it takes between the time the user requests the content and the time until the he feels the content requested is available and usable feels slow or fast. So now we can say that web performance optimization is all about increasing both the objective and subjective performance.

Web performance includes how long it takes to load the content required, how long it takes to parse, execute, display, and make content usable in the browser, and how responsive and smooth the site is to user interaction. Is the scrolling smooth? Are buttons clickable? Are pop-ups quick to open up, and do they animate smoothly as they do so? Web performance includes both objective measurements like time to load, frames per second, and time to interactive, and subjective experiences of how long it felt like it took the content to load and how responsive the application feels, which is more difficult to measure but often more important.

The lifecycle of an HTML page has three important events:

  1. DOMContentLoaded – the browser fully loaded HTML, and the DOM tree is built, but external resources like pictures and stylesheets may be not yet loaded. At this point the handler can lookup DOM nodes, initialize the interface.
  2. load – not only HTML is loaded, but also all the external resources: images, styles etc.
  3. beforeunload/unload – the user is leaving the page. Now we can check if the user saved the changes and ask them whether they really want to leave.

There are many other in between events, but when we are talking about web performance those three are the most important events to take care of.

Why do we care about web perofrmance

To recognize the impact of the web performance, we can say that start building a website without taking care of it’s performance is like opening a cafe without taking care about the service. As well as you need to serve your visitors in the cafe, you need to serve your web visitors. Not only that. Building a website with not information about the maximum number of users who can access it in a single point of time is like opening a cafe with no preparation for the over visits of the weekend. The prepared cafe for a crowded weekend can increase his staff faster, modify his decore to receive more visitors more flexible, keep the tension level as minimum as possible in the rush hours, and so on. It’s identically the case for your website…

Now let’s take CNN website as a case study.

Loading CNN.com, makes over 400 HTTP requests costing about 22.6MB. Now imagine loading that same site while using mobile data on public transportation or loading it on his 9-year-old. Also, imagine one of your site’s users loading your site on a $35 Huawei device in India. A 22.6 MB site can take up to 83 seconds to load, with DOMContentLoaded at 31.86 seconds, on 3G, and costs 11% of the average Indian’s daily wage. If this site was loaded on a mobile device in Mauritania, it would cost the user two full days of their average salary. However, if this site was loaded on a US carrier’s international roaming plan, the costs will make you cry.

In the language of numbers, here are some statistics from the real market which shows you how crucial is a small improvement in the performance of your website in milliseconds…

And here are other case studies where low performance had a negative impact on business goals:

We discussed from a business overview why you should take care of your system’s performance. Now let’s take a different look from a technical perspective.

How to care about web performance

Now after we talked a lot about the importance of the high performance of a website. Let’s talk a little bit about how to care about the performance of your website as a developer. And since I’m not a developer, so this section will be just a straight forward points without so much details. But if you are more interested to know about the development perspective, you can find further readings in the references section.

Performance testing types

There are a lot of performance testing types. If you keep searching the web, you will find tens of them. But generally, whatever the type of your business, most probably you will find the type you need in this list:

Here is a test case which shows the difference between the above four types. Let’s say that you are building an e-commerce website and you are expecting 10,000 user at the peak time.

How long is too long

At this point, it’s important to put some borders to identify how much your website is slow or fast. Actually, there are no obvious rules indicates what’s a slow loading time and what’s fast. On the other hand, there are some specific guidelines for indicating content load, idiling time, animating time, and reponsive time. Let’s discuss quickly each one of them.

We mean here by load time the maximum amount of time to indicate to a user that the request for new content was made and will load, such as the browser displaying the page title and the background color of the page displaying. As you may know the first asset retrieved from a request is usually an HTML document, which then makes calls for additional assets. When HTML is received, browsers immediately start processing that HTML, rendering the content as it is received rather than waiting for additional assets to load. Yes, one second for loading is the goal, but it’s something few sites achieve. Expectations differ… a ‘hello world’ on the corporate network would be expected to load in milliseconds, but a user downloading a cat video on a five-year-old device over an edge network in kenia would likely find a 20-second download speedy. In optimizing for performance, do set an ambitious first load goal, such as 5 seconds over the mobile 3G network and 1.5 seconds on an office internet line, with even more ambitious page load goals for subsequent page loads, leveraging service workers and caching.

Browsers are single threaded (though background threads are supported for web workers). This means that user interaction, painting, and script execution are all on the same thread. If the thread is busy doing complex JavaScript execution, the main thread will not be available to react to user input, such as pressing a button. For this reason, script execution should be limited in scope, divided into chunks of code that can be executed in 50ms or less. This makes the thread available for user interactions.

For scrolling and other animations to look smooth and feel responsive, the content repaints should occur at 60 frames per second (60fps), which is once every 16.7ms. The 16.7 milliseconds includes scripting, reflow, and repaint. Realize a document takes about 6ms to render a frame, leaving about 10ms for the rest. Anything less than 60fps, especially an un-even or changing frame rate, will appear janky.

When the user interacts with content, it is important to provide feedback and acknowledge the user’s response or interaction and to do so within 100ms, preferably within 50ms. 50ms seconds feels immediate. The acknowledgment of user interaction should often feel immediate, such as a hover or button press, but that doesn’t mean the completed response should be instantaneous. While a slower than 100ms reaction may create a disconnect between the user interaction and the response, a 100 to 200ms transition for a response may help the user notice the response their interaction initiated, such as a menu opening. If a response takes longer than 100ms to complete, provide some form of feedback to inform the user the interaction has occurred. And we will talk more about this point in the client side performance section below.

So we can summarize this section saying that the goal for load time is 1 second, 50 ms for idiling, animating within 16.7ms, and responding to the user input in 50ms.

How often should you run a performance testing

Another important question before moving to the applicable part of this article is when and how much should you run the performance testing?

An important note to be pointed to here is that’s almost better to get your performance testing injected into the release pipline. So that, your performance testing plan will be automatically run before every release. But unfortunately, it’s not an easy task as it may seem. There are tons of challenges to build a performance testing pipeline. You may have been built a previous automation testing plipelines for unit testing or end-to-end automation testing. But the challenges here come more and more because you need to take care more about the infrastructure and the very specific details about the platforms the system will run on. Also another huge challenge here that your performance testing will definitly break the system and let it down many times. At this checkpoit, you need to configure your pipeline to get the system up again and make sure that it’s ready to receive the next load. This topic may be interesting to be the next post of this performance testing category in the future. So stay tuned :D

A look into client side performance

According to Yahoo, around 80% of application response time is spent downloading elements such as images, stylesheets, scripts etc. To speed up response time requires strong servers and a well prepared and tested application. That’s why we need to talk further about the client side performance.

For the past few years, we’ve been measuring page load times as a key metric for the usability of a website and the user experience it delivers. But a new performance metric has come on the scene that is less about measuring the actual time it takes for an entire page to load and more about measuring how long it takes for the page to deliver the experience the website visitor is seeking. Since the web development has got developed too much in the last few years, you now have the ability to load one or more web elements first and let the user being able to interact with them, and in background keep loading the other web elements. And here is a very important idiom shows. It’s Time To Interact or (TTI). It pinpoints the most critical moment in a page load; The moment the page’s primary interactive content is displayed and becomes interactive from the end user’s perspective. Let’s discuss the below chart to see how critical is to benchmark your TTI compared to your total load time.

You can see that there are three main categories in this chart.

  1. Websites with low TTI and low load time: Some exapmles from this category is the first three websites (abebooks.com, BHPhotovideo.com, CDUniverse.com). And when the load time is really small for those websites, so you can conclude that those websites performance can be either represented by the load time or the TTI. There will be no huge difference between the both. And it’s not the most important category in our example. This low load time either reached by the simplicity of the delivered service, so there are no much resources to be loaded. Or by a perfect optimization of loading process. So in those two cases (low resources, perfect load process) the TTI and total load time will be near to each others and you can use either of them to measure the performance of your website on going.
  2. Websites with average TTI and high load time: Some examples from this category is those three websites with more than 10 seconds total load time (Net-a-porter.com, Fineartamerica.com, Urbanoutfitters.com). Those websites can’t use the total load time to represent how much their website is user friendly when it comes to performance factor. There may be a reason which prevents you from getting the total load time of your website to minimal. And at this point, you need to find a way to get the lowest TTI possible. You need to let the user being able to interact with the most important elements he is visiting your websites mainly for and then keep loading the other assets in the background. So in this case (high load time and average or low TTI) you must use TTI to indicate how well is the performance of your website.
  3. Websites with average TTI and average load time: If you are trying to take care of the performance of your system as much as you can, most probably your website will fit in this category. Most of the msrket giants in different domains are in this category (as you can see amazon in the above chart). And in this case you need to keep working hard on improving your TTI. You may spent too much time optimizing the performance of the loading process so that the total load time isn’t that high. Now you need to go to the next challenge which is how to let your customer being able to interact with your page earlier and earlier. So in this case (average load time and average TTI) you must use TTI to indecate how will is the performance of your website. And a very small enhancement in TTI ma lead to huge business impact either positvely or negatively.

So we can conclude that load time is not always the most meaningful measure of a site’s performance. For example, while Amazon.com has a greater load time of seconds, it has a TTI which indicates that this site delivers a satisfactory user experience.

There should be a final section about the tools which you can use to measure the web performance. But it will be a very long post if they are included in this post. So it will be detailed in the next post hopefully :D Don’t hesitate to share this post if you find it worthy. And if there is any further discussion, please leave in the comments section below.

See you the next month…

References