Website Optimisation by managing client-side performance

Section 1, Understanding client-side performance

Section 2, Specific techniques to improve performance

Section 3, Tools and analysis

Section 1, Understanding client-side performance

These days a user’s expectations from a website are high. Users are not just looking for greater functionality and a good user interface, as they were only a few years ago. Many businesses have been increasing their e-commerce footprint by migrating to powerful e-commerce platforms, and users are spending more time online, browsing for what they want.

Web sites get more complex, as businesses deliver a more interactive, customised experience, to show their products and services in the best possible light.

It is also worth noting that users have become less tolerant of poor performance. Capacitas research shows significant drops in conversion rates as response times degrade, even at relatively low levels.

So faster websites provide significantly higher customer satisfaction, which directly translates into higher revenue.

Whenever we discuss performance of a web site, our clients talk first about the server or back-end performance. Often that’s the only area tested. The IT department is focused on how many servers it needs to handle the demand – after all, they cannot upgrade the hardware used by the potential customer.

However, even though the back-end processes the requests fast enough, most of the time it is the client-side processing that drives up the overall response time, and therefore drives away business.

Approaches to optimising Client-side performance:

Steve Sounders’ from SpeedCurve studied the Alexa top 10 ranked websites, and reports: “80%-90% of the end-user response time is spent on the frontend. Start there."

This is great advice!

There are three layers for any website:

The presentation layer
The business layer
The data layer

In this paper, we will focus on presentation layer, which is the customer interaction layer. There are two strategies to optimise the performance of this presentation layer:

Bottom-up approach:
In this approach, before starting with actual development work, requirements are established based on the Service Level Agreements. These are then followed throughout development life cycle, with best practice in mind.

Top-down approach:
This approach is a more reactive strategy, where websites are developed before considering any performance requirements, and performance issues are identified in final stages of development. This is a much more expensive approach.

Research by Capacitas and others has consistently shown that it is much cheaper to fix problems at early stages of development.

Section 2, Specific techniques to improve performance

In this part, we will examine twelve specific techniques to improve response times.

1. Avoid redirects:

What are redirects? Redirects occur when we try to access a particular website URL (Uniform Resource Locator), and the request is redirected to another URL. Each redirect costs an extra http request-response cycle to a server, which directly affects overall website response time. In some cases, we can see single page redirects where only one extra http round trip occurs. However, in other cases there may be many redirects, with a severe impact on the customer experience.

The key point here is that redirects always slow down user experience. No other components of the page can be downloaded, (such as stylesheets, JavaScript, images etc), until the browser downloads the HTML document.

2. Limit the number of http requests :

To access each page component, such html documents, stylesheets, JavaScript, and images, the browser needs to send one request to the server for every file. The more http requests, the more time to get all those resources from the servers. This directly affects overall response times.

3. Enable Gzip compression to transfer less data on network:

Enabling compression can reduce the amount of data transferred by up to 90%. All modern browsers support Gzip. You should always enable compression, which speeds up the download time for all components of a page, reducing overall rendering time. This also helps to reduce the network cost, as server need to transfer less data to client-side.

Remember, there are always likely to be customers on slow connections.

4. Use a browser cache with an expiry header:

Downloading resources over the network is slow and expensive. For each component, the browser needs a round trip to server.

If a proper caching policy is implemented, components do not need to be downloaded every time, and customers can be served with local copy, improving overall responsiveness.

5. Use a Content Delivery Network (CDN) :

If the web application is hosted in one part of the world and users try to access from anther region, it adds extra network latency to transfer data and degrades overall response time for end user.

CDN’s solve this problem by caching all static data for the web application locally to the user. All static content is delivered locally, and only dynamic data has to come directly from the servers. This delivers a major improvement in overall response time.

It also reduces server costs, as workload is taken up by the CDN.

6. Format java scripts and style sheet files to reduce file size :

For web applications, a difference of few bytes per file have a large cumulative impact on overall page size. Minimising the size of java scripts and CSS files helps to reduce overall page size downloaded from the servers. Try to remove spaces, blank lines, and comments from JS and CSS files to help reduce file sizes.

7. Place JavaScript at the bottom of the html page:

JavaScript blocks parallel downloads, and while a script is downloading, the browser will not start to download any other elements. Therefore, to help pages load faster, move scripts to the bottom of the page if they are deferrable.

8. Place stylesheets at top :

Move style sheets to the top of an HTML document, (the head element). This helps pages start to load quicker as it allows pages to render progressively.

As components are downloaded they can be processed based on CSS in parallel without waiting for stylesheet, and the user will see content they are interested in start arriving much faster.

9. Do not set dimensions of images in html page:

Web page designers sometimes set image dimensions by using the width and height attributes of the HTML image element. This is done so that images in the browser can by dynamically resized.

While this may be convenient, it means that larger images are sent to the browser, increasing the amount of data transferred.

For example, if your page requests the image “myicon.png” , with dimensions 480x720 pixels, but displays it with dimensions 240 x 360 using the width and height attributes, the browser will download an image with four times the required pixels, and probably about 4 times the size in bytes too.

10. Minimize number of DNS (Domain Name System) lookups:

The Domain Name System (DNS) converts hostnames to an IP address. When you type URL www.gmail.com into the browser, the browser connects to a DNS server that coverts and returns the server's IP address. DNS lookups add a cost in range of 20 to 120 milliseconds to the response time.

Until the hostname is converted to an IP address, the browser is unable to download any more components from the server. More DNS lookups add more latency, delaying when the user starts to see the content they want.

11. Limit cookie size:

Cookies are information stored in files at browser level. Every time the user loads the website, the browser sends the cookies back to the server to notify the user's past activity. Each request contains cookies in the header, and the size of these cookies adds extra overhead if not limited.

It is also worth noting that for many users, their upload speed is much less than their download speed, so the impact of this factor is disproportionately severe.

12. Avoid CSS Expressions:

CSS expressions are used for dynamically setting up Stylesheet properties, such as changing font or background colour. These expressions need to be evaluated each time the page is loaded, or resized, or there is a keyboard / mouse event. The browser may end up evaluating this expression hundreds or even thousands of times.

Section 3, Tools and analysis

In this third part, we examine tools to analyse and improve response times.

Analysing the time spent in Front-end Vs Back-end

We often help our clients optimize performance. Here is a real world example, from an e-commerce platform, (the key source of revenue for the company in question).

The waterfall chart below shows a breakdown of response time by activity.

The client received the first byte after 316ms, and the rest of the time was spent accessing other resources like js , css , png and rendering activities. By focussing mainly on optimising the front-end, we were able to deliver a 70% improvement in overall web portal performance.

Front-end Performance Testing Tools

A few years ago, it was not an easy task for a web developer or performance engineer to figure out what was actually happening after a user submitted a request from their browser. Now there are several good open source tools available, which can measure the activity.

These tools generally provide the following information:

Grade a web page based on a predefined rule set, or a user-defined rule set
Offer suggestions for improving the web page's load time
Summarise the web page's components
Displays statistics about the web page

Here is a comparison of features available in four popular tools, DynaTrace, AgileLoad, Page Speed, and Y-Slow.

The chart shows that Ajax DynaTrace outperforms other open source tools in market with 88% coverage. This tool provides the most coverage of KPIs, making it easy to test and analyse client-side performance before you start focusing on optimising it.

Summary:

Optimising client-side performance and resources delivers the best improvements in overall response time, for the best user experience. It is a misconception that web application response times can be improved largely by addressing server side performance issues. Research has showed that 80-90% of page load time is spent on client-side and 10-20% on server side. Web Page response time can be improved by 40-50% just focusing on front-end of the application.

Many studies have shown that response times directly impact conversion rates, for example, see this Capacitas Webinar:

Examples from other companies:

Amazon calculated that a page load slowdown of just one second could cost it $1.6 billion in sales each year.
Google has calculated that by slowing its search results by just four tenths of a second they could lose 8 million searches per day—meaning they'd serve up many millions fewer online advertisements.

Conclusion

These days, client-side technologies for websites and heavy use of java script is widespread, for rich web application design and content. Online competition continues to grow, and users are spending more time and money online. Rapid response times are required by users.

Dtjohnnymonkey-Stopwatch-no-shading.svg.png