Faster Loading of Websites

(1)

Faster Loading of Websites

Strategies for optimizing loading of webpage components

MIKAEL RYDMARK

Master’s Thesis at CSC Supervisor: Olof Hagsand Examiner: Stefan Arnborg

(2)

(3)

Abstract

When loading a webpage on the Internet it is desirable that it loads as quickly as possible. This master thesis presents several strategies to try and improve the response time of a webpage by optimizing the loading of its component. The tests conducted in this master thesis showed that using compression will significantly improve the response time of a webpage and using caching for static components will greatly improve the response time for repeated visits of a webpage.

(4)

Snabbare Laddning av Webbsidor

När en webbsida laddas på Internet är det önskvärt att det går så fort som möjligt att ladda sidan. Den här rapporten redovisar flera strategier för att försöka förbättra laddningstiden för en webbsida genom att opti- mera laddningen av en webbsidas komponenter. Testen som genomförts och redovisas i rapporten visade att man kan minska laddningstiden för en webbsida signifikant genom att tillämpa komprimering. Testen visade också att man genom att cacha statiska komponenter kan spara mycket tid för återkommande besök av webbsidan.

(5)

Introduction

In this chapter the reader is introduced to the background of this master thesis. It is explained why the response time of a webpage is important and where most of the time is spent when loading a webpage. The problem statement, purpose and method of this master thesis are presented and what limitations have been chosen. The last part of this chapter describes the outline of this report.

1.1 Background

When a webpage is loaded on the Internet that webpage should load as quickly as possible. If a page loads slowly it will have a negative effect on the visitors and they will experience the page as unresponsive and slow.

One might think that with the continuing increase in download speed this problem would be solved, but that is not the case. As the download speed offered by ISPs (Internet Service Provider) increases, the complexity of the webpages on the Internet tends to increase as well, making it important to cut the response time of a webpage to make it available to visitors faster.

Response time is the time from that a user requests a webpage (i.e. the user presses the enter key after entering a URL in the browser) to the time when all the content of the page is downloaded and displayed in the browser for the user.

This topic is especially important for users using mobile devices that usually have a lower download speed.

The question is then where efforts to reduce the response time should be focused?

Research has shown that around 80% of the load time is related to loading the components of the webpage (see section 2.7) [14]. That is, loading of images, style sheets, scripts, flash etc. The other 20% of the load time is is spent requesting and downloading the HTML document.

Focusing on improving the loading of the components rather than the HTML document therefore seems like the best strategy because if the response time associated with them is reduced by 50% it will reduce the overall response time by 40%. Reducing the response time of the HTML document by 50% will only mean

(10)

an improvement by 10% on the overall response time. This master thesis focuses on strategies for optimizing the loading of the components of a webpage.

1.2 Problem Statement

The problem statement of this master thesis is:

• What strategies are most effective in optimizing loading of the components of a webpage?

1.3 Purpose

There are many factors that will affect the response time of a webpage such as geographical distance between the server and client, the server load, the size of the requested component and the number of components requested. The goal of this master thesis is to find ways to improve the response time of webpages by optimizing the loading of its components. By finding strategies to improving the response time of webpages web developers will be able to produce websites that are faster loading.

A faster loading website will be able to handle more traffic and the website will not be experienced as slow and unresponsive for the users of the website. This master thesis tries to find the answers to the following questions:

• Which are the best strategies for improving the response time?

• How much improvement in response time is likely for each strategy?

• What is needed to implement these strategies for use in web development?

• What pros and cons are there for the different strategies?

1.4 Method

The results have been obtained by performing automated tests of the loading process of a webpage using the software HttpWatch [22]. Running the tests several times ensures that the results are reliable. This has been investigated:

• Loading of a webpage with empty cache.

• Loading of a webpage with primed cache.

The response time for different key parts have been investigated:

• The time until the page’s onload event fires (this is when the page and all its images are done loading).

(11)

1.5. LIMITATIONS

• The time until the rendering starts (this is when the user gets a visual indi- cation that the site is loading).

• The time until the DOM (Document Object Model) is fully loaded (which means that it is available for use by scripts). HttpWatch is only able to measure this in Firefox.

• The time until HTTP load occurs (no more network activity for the page).

The page load time, with both empty and primed cache, is the primary focus of this master thesis.

1.5 Limitations

This master thesis focuses on strategies for optimizing the loading of components of a web page. I have not investigated strategies for optimizing code but instead focused on strategies that with limited effort would improve the response time. I have only investigated the response time for loading the start page of a web site and not a flow of pages. I have tested the strategies in Firefox 3.6 and Internet Explorer 8 only and I have used the same conditions for all tests.

1.6 Thesis Outline

The outline for the remaining part of the thesis is the following. In chapter 2 the background for this subject is presented. In chapter 3 strategies for reducing the response time of webpage components are explained. In the fourth chapter the design of the experiment is presented. Chapter 5 explains the implementation, chapter 6 presents the results and chapter 7 contains the evaluation and discussion.

The last chapter contains the conclusions.

(12)

(13)

Chapter 2

Background

In this chapter the background of this master thesis is presented including a ba- sic explanation of the HTTP protocol and those part of HTTP that concerns page loading. The chapter also includes a brief explanation of the most common web page components as well as a section explaining differences between different web browsers when page loading is concerned. Then we give a definition of response time followed by the Performance Golden Rule. The last section explains how a webpage is loaded.

2.1 Previous work

There are some previous work done in this field. Most notable by Steve Souders who is considered a pioneer within the field of web performance optimization. He has written the book High Performance Web Sites where he presents 14 different rules for reducing the page loading time of a web page[1]. Souders has also written another book called Even Faster Web Sites where he explores ways to improve asynchronous requests using javascript and some additional strategies for reducing page loading speed[2].

In their paper, Web Server Performance Optimization using Prediction Prefetch- ing Engine, S. Makker and R.K. Rathy explored web server performance optimiza- tion by using a prediction prefetching engine. Their idea was to try a predict what content the user would request next and then prefetch that content before the request is made and thereby achieving faster loading of a web page. They were able to achieve greater accuracy in predicting what content the user would request next by combining an array of different techniques and thereby reducing the page loading time of a webpage.[42].

Andrew B. King has a wider perspective in his book Website Optimization where he looks at a lot of different areas where you need to optimize to have a successful website such as search engine, optimization, optimization of conversion rates, pay per click optimization but he also explores web performance optimization through HTML, CSS and JavaScript optimization aimed to reduce response time

(14)

of a website[3].

Peipei Ling’s paper Based on Web Application Front-end performance optimiza- tion focuses on front-end performance optimization divided in four main categories, transmission optimization, quantity of transmission, browser caching and optimization on the client side. The thesis resulted in a number of guidelines for developers to take into consideration when developing a website. [43].

Nicholas C. Zakas explores JavaScript optimization in his book High perfor- mance JavaScript by going through subjects like minification of files, improving scripts by understanding how JavaScript stores and accesses data and how to iden- tify problematic code and replacing it with faster alternatives.[4].

2.2 Quality of Service

Quality of Service on the Internet, or QoS, is the performance of the network experienced by the users. The service quality consists of different measurements such as delay, jitter, bandwidth and reliability.

Delay is the time it takes for a packet to be sent over the internet until it is received by the user requesting it. A high delay can be caused by large amounts of data being transferred, a large distance between sender or receiver or congestion in the network.

Jitter is the variation in end-to-end latency between the packets being sent between the sender and receiver. A high variation can cause the TCP protocol to increase the estimated round trip time of the packets resulting in an inefficient transmission.

Bandwidth is the maximum data transfer rate between sender and receiver in a network.

Reliability can be though of as the average error rate of the network. Errors can be packets arriving at the receiver out ot order or being dropped on the way forcing the receiver to request the lost packets again.

In this master thesis the focus will be concentrated on delay and ways that delay can be reduced when loading a web page thus increasing the level of service quality [44, 45].

2.3 HTTP - Hypertext Transfer Protocol

2.3.1 Overview

HTTP is the protocol used by browsers to communicate with servers on the Internet.

HTTP/1.1 is the most common version on the web today but some servers still use the older HTTP/1.0. HTTP is a client/server protocol working with requests and responses. A client makes an HTTP request for a specific component located on a server and then the server replies by sending an HTTP response.

(15)

2.3. HTTP - HYPERTEXT TRANSFER PROTOCOL

HTTP Request HTTP Response

Client Web Server

Figure 2.1. HTTP communication.

The protocol uses a plain text format. HTTP supports a number of different types of request including GET, POST, HEAD, PUT, DELETE, OPTIONS and TRACE.

The most common request is the GET request which is the focus of this master thesis. A GET request specifies the URL for the requested component followed by headers. The response includes a status code, headers and a body [1, 23].

The following example shows an HTTP request from a client (browser) followed by the HTTP response from the server hosting the requested component.

The requested component in this example is the image logo-small.png hosted by www.kth.se. The HTTP response contains the status code 200 OK which means that the component was found and is included in the HTTP response sent back to the client.

An HTTP Request

GET /img/logo-small.png HTTP/1.1 Host: www.kth.se

User-Agent: Mozilla/5.0 (...) Gecko/20101012 Firefox/3.6.11 ...

An HTTP Response HTTP/1.1 200 OK

Last-Modified: Thu, 14 Oct 2010 14:02:24 GMT Content-Length: 3468

Content-Type: image/png ...

For a complete specification of the HTTP protocol please refer to RFC 2616 [23].

2.3.2 Caching

When a browser has a component in its cache but does not know if it is still valid it will send a conditional GET request to the server. It includes the header If-Modified-Since where it includes the last modified date. The server then checks

(16)

if its copy of the component has been modified since that date. If the component has been modified it will send the new version back to the client and if it has not been modified it will send a HTTP response with the status code 304 Not Modified and skip sending the body of the response containing the component. This makes the HTTP response size smaller reducing the response time.

The HTTP Request

GET /extern_chrome/84a5e2c4afa982fd.js HTTP/1.1 If-Modified-Since: Thu, 14 Oct 2010 15:02:29 GMT ...

The HTTP 304 Response HTTP/1.1 304 Not Modified

Last-Modified: Thu, 14 Oct 2010 15:02:29 GMT ...

Getting a 304 response is better than receiving a new copy of the component but this still consumes one HTTP request and one HTTP response to check the validity of the component. There is another header called Expires that will help eliminate the round-trip to the server altogether. When a browser sees an Expires header it keeps the component in its cache until it expires and it uses the copy of the component until the date of expiration thus elimination a round-trip to the server.

An Expires Header HTTP/1.1 200 OK

Expires: Thu, 27 Oct 2011 00:00:00 GMT ...

An alternative to the Expires header called a Cache-Control header was introduced in HTTP/1.1. The Cache-Control header is similar to the Expires header but with the difference that it specifies the number of seconds the component is fresh instead of using a date. Using a Cache-Control header eliminates the need for a strict clock synchronization between the server and the client.

A Cache-Control Header ...

Cache-Control: max-age: 2592000 ...

The Cache-Control header above specifies the freshness in seconds of a component to 2592000 seconds (30 days). The client will use the copy of the component in its cache until the 30 days are at an end [1].

(17)

2.3. HTTP - HYPERTEXT TRANSFER PROTOCOL

ETags

An ETag (Entity Tag) is a HTTP header mechanism used by web servers to validate cached components and was added as a more flexible way for validating components than the last-modified date. The server includes the header in its response using the Etag header as shown below.

An ETag Header ...

Etag: "10c24bc-4ab-457e1c1f"

...

When the client needs to validate its component it includes the header If-None-Match header. If the Etag matches the server replies with a 304 Not Modified status code.

An If-None-Match Header ...

If-None-Match: "10c24bc-4ab-457e1c1f"

...

2.3.3 Persistent Connections

HTTP is built on top of TCP (Transmission Control Protocol). In early versions of HTTP you had to open a new socket for every component you required. This is not efficient since opening and closing sockets takes time (3-way handshake, TCP slow start)[29] and many components are requested from the same server. By using a persistent connection the same socket can be used for many components eliminating additional socket connection to the same server. In HTTP/1.0 this is done by specifying a Connection header that indicates support for Keep-Alive. In HTTP/1.1 the inclusion of this header is not needed since it uses a persistent connection by default however many browsers and servers still include it.

A Connection Header ...

Connection: keep-alive ...

There is another even faster method for sending and receiving components for the same server called pipelining. When pipelining is used multiple requests can be sent to the server using a single socket without having to wait for the response.

Unfortunately the support for pipelining in popular browsers is not yet common.

Until pipelining is more widely adopted a persistent connection should be used.

This is especially important for HTTPS because establishing a secure connection consumes even more time than a regular connection [1, 9].

(18)

2.3.4 Compression

Using compression will decrease the size of the HTTP response which will have a positive effect on response time. The server must however perform the compression which will increase the processing time of the response. When a client sends a HTTP request it can include the header Accept-Encoding to specify what forms of compression it supports. If the server supports the same form of compression it will then send a compressed copy and specify which compression method it uses in the Content-Encoding header of the HTTP response. Gzip is the most used compression method today and is the type of compression supported by most web servers and clients.

An Accept-Encoding Header

GET /extern_chrome/84a5e2c4afa982fd.js HTTP/1.1 Host: www.google.se

Accept-Encoding: gzip,deflate ...

A Content-Encoding Header HTTP/1.1 200 OK

Content-Encoding: gzip

Content-Type: text/html; charset=UTF-8 Content-Length: 5409

2.3.5 Cookies

A cookie is a piece of text that can be stored on a users computer by its web browser.

The cookie can be used for authentication, shopping cart contents, personalized settings etc. It is a way to deal with HTTP being a stateless protocol. The server can include a HTTP response header Set-Cookie followed by name-value pairs. The cookie can have an expiration date and will then be kept on the users computer until it expires or the user removes it. If a cookie does not have an expiration date it will expire as soon as the browser session is terminated.

When a client wants to make an HTTP request for some component it will first check to see if it has any cookie for that domain. If it does it will include the HTTP request header Cookie with name-value pairs. This way the server can know it is a previous user and take whatever action is appropriate. Usually the cookie is just an ID that the server will recognize and use to retrieve information about the user from a database. As a client it is therefore not possible to know just by looking at the cookie what information is saved about the user. [30]

(19)

2.4. WEBPAGE COMPONENTS

A Set-Cookie Header ...

Set-Cookie: customerID=1234; expires=Sat, 31 Dec 2011 21:40:56 GMT ...

A Cookie Header ...

Cookie: customerID=1234 ...

Above the cookie with the name customerID is set by the server with the value 1234. This cookie is then included by the client in every request to that domain.

Cookies can also be set by using other methods such as javascript.

2.4 Webpage Components

This master thesis focuses on reducing the response time of a website’s components.

The most commonly found components of a webpage are briefly explained below.

2.4.1 HTML

The HTML (Hyper Text Markup Language) document is the document that informs the browser how it should render the webpage. HTML elements are the building blocks used to construct a web page. In the HTML it is specified what other components such as scripts, stylesheets, images etc that are needed for displaying the webpage [31].

2.4.2 Stylesheets

Stylesheets are used to specify the style and layout of the webpage. This is usually done with CSS (Cascading Style Sheets) which can be found in an external file or inline in the HTML document. In the style sheet you can then specify fonts, colors, background images and the like for the different parts of the HTML document [32].

2.4.3 Javascript

Javascript is a scripting language that is downloaded and executed on the client computer. These scripts are commonly used to enhance the user experience such as making mouse-over effects, pop-up windows and validating form input. Since the script runs on the client computer it can respond to the user actions quickly [33].

(20)

2.4.4 Images & Flash

Most websites contain images. Each image is a component that will have to be requested from the server. Flash movie is another common media type.

2.5 Web Browsers

This section explains the differences between different web browsers when page loading is concerned.

2.5.1 Connections

HTTP/1.1 introduced persistent connections by default with the suggestion that a browser should be able to open two connections per host. This means that a webpage containing say 20 components from the same host will download a maximum of two components at a time. Since the drafting of the HTTP/1.1 specification the Internet has evolved and many browsers now allow more connections than two per hostname as shown by the table below. There is also a question of the total number of connections a browser will open at a time across all hostnames which is also shown below [27].

Browser Connections per Hostname Max Connections

Chrome 9-11 6 35

Firefox 2 2 24

Firefox 3 6 30

Internet Explorer 7 2 57

Internet Explorer 8 6 35

Opera 11 8 32

Safari 3 4 60

Safari 4 6 60

Safari 5 6 30

Table 2.1. Number of connections per Hostname/Max for popular browsers.

The table above shows that most browsers today allow 6 connections per host allowing more components to be downloaded in parallel.

2.5.2 Script Downloading Behavior

The way a browser handles the downloading of scripts can greatly impact the response time of a webpage. The browser must respect the order in which the scripts are placed in the document when it comes to execution order. But there is no reason why it cannot download the scripts in parallel and just make sure to execute them in the correct order. The browser implementations differ in this respect.

(21)

2.5. WEB BROWSERS

Older browsers usually block all downloads when a script is downloaded while newer browsers download components in parallel. Table 2.2 shows different browsers and if they download components in parallel with scripts [1, 27].

Browser Script Stylesheet Image Iframe

Chrome 9-11 yes yes yes no

Firefox 2-3 yes yes yes no

Internet Explorer 7 no no no no

Internet Explorer 8 yes yes no no

Opera 11 no no no no

Safari 3 no no no no

Safari 4-5 yes yes yes no

Table 2.2. Ability to download component in parallel with script.

The table above also shows that no browser is perfect in this respect and Internet Explorer 7, Opera 11 and Safari 3 do in fact block all other downloads when a script is downloading [27].

2.5.3 Heuristic Expiration in Firefox

An interesting difference between Firefox and Internet Explorer when it comes to caching is that Firefox will set an expiration date for a component that does not specify an expiration date itself. This is actually a recommendation from RFC2616 for the HTTP/1.1 specification. All it needs is the Last-Modified header. It then calculates the expiration time as:

Expiration time = Now + 0.1 * (Time since Last-Modified)

In the figure below Firefox has calculated a new expiration time for the component using the formula above.

Figure 2.2. Expiration time set by Firefox.

This means that Firefox will improve the page load time for second page loads where components do not have an expires header. But this can also lead to un-

(22)

wanted results. This means that Firefox will also cache the HTML document in the same manner. If you change the document, those clients that have the old HTML document in their caches will not get the new document until the old one expires in their caches. To have full control of what is cached and how long it is cached it is therefore always a good idea to explicitly set an expires header or cache control header. [23, 28]

2.6 Response Time

2.6.1 Webpage

The response time of a webpage is the time from the initial request for the HTML document followed by all components on the webpage to the receiving of the last requested component of that webpage.

2.6.2 Components

The response time of a component is the time from that the client (browser) requests a component from the server hosting the component to the time when it is received by the client. The response time can be divided into the following parts:

1. Blocked. Pre-processing such as cache lookup and time waiting for a network connection to become available.

2. DNS Lookup. Resolve a host name into its IP address.

3. Connect. Time required to create a TCP connection to the web server.

4. Send. This part is the actual sending of the HTTP request.

5. Wait. Time spent waiting for a response from the server. This part includes delays due to network latency and server processing time.

6. Receive. Time required to read the response from the server.

7. Cache Read. Reading content from the cache of the browser.

In Figure 2.3 the response time of the HTML document for www.ebay.com is shown.

The first (1) is a blocking part which is followed by a DNS lookup (2). When the IP address of the server has been resolved a TCP connection is established (3).

Then an HTTP request is sent (4) which in this case is a very small percentage of the total response time. When uploading something to a server this part will tend to grow. After the request is sent there is some waiting time (5) and finally the response is received and read by the browser (6). There is no cache reading time in this example. [26].

(23)

2.7. PERFORMANCE GOLDEN RULE

Figure 2.3. The different parts of the response time of the HTML document for www.ebay.com when accessed from Stockholm.

2.7 Performance Golden Rule

Table 2.7 shows the percentage of response time for the webpage spent downloading the HTML document on ten popular U.S. websites. It shows that almost all of these sites spend less than 20% downloading the document [1]. This shows that focusing on reducing the response time of the components of a webpage, that represents about 80% of the response time, is the right thing to do.

Website Empty cache Primed Cache

AOL 6% 14%

Amazon 18% 14%

CNN 19% 8%

eBay 2% 8%

Google 14% 36%

MSN 3% 5%

MySpace 4% 14%

Wikipedia 20% 12%

Yahoo! 5% 12%

YouTube 3% 4%

Table 2.3. Percentage of response time of the webpage spent downloading the HTML document.

Steve Souders, the author of High Performance Web sites and Even Faster Web Sites, formulates the Performance Golden Rule:

“Only 10-20% of the end response time is spent downloading the HTML document. The other 80-90% is spent downloading all the components in the page.”

When trying to improve the response time for a webpage it is a good idea to first profile the loading of the page and see if the Performance Golden Rule holds true.

If it does, applying the strategies discussed in chapter 3 will have a good chance of improving the webpage’s response time.

2.8 Loading of a Webpage

Figure 2.4 shows a waterfall diagram of the loading of the site www.yahoo.com [6].

Each bar in the figure represents an HTTP request made to the server. The first bar

(24)

is the initial request for the HTML document. The browser then parses the HTML document and requests the components on the webpage found in the document.

In this case fetching the initial HTML document only takes about 5% of the total response time. The rest of the time is spent waiting for components to download and HTML, scripts and style sheets to be parsed which is represented by the small gaps in time between the components. This means that in this case 95% of the time is spent downloading the components of the webpage which means that the Performance Golden Rule holds true for this webpage.

Figure 2.4. Time spent downloading http://www.yahoo.com.

(25)

Chapter 3

Strategies

This chapter explores the different strategies available for cutting the response time of a websites components. First there is an overview categorizing the strategies and then every strategy is explained in greater detail.

3.1 Overview

The strategies in this chapter tries to reduce the response time of a website’s components. They can be categorized as follows:

The first category deals with ways to reduce the number of HTTP request made to the server. These strategies are:

• 3.2.1 Image maps

• 3.2.2 CSS Sprites

• 3.2.3 Inline images

• 3.2.4 Combining scripts and style sheets

By fetching components from the cache a round-trip to the server can be eliminated which saves response time. Strategies that try to utilize the cache of the browser are:

• 3.3.1 Use a Cache-Control or Expires header

• 3.3.2 Make Scripts and CSS external

• 3.3.3 Use ETags with care

(26)

Then there are strategies that try to reduce the size of the HTTP response and by doing so reducing the response time of those components. These strategies are:

• 3.4.1 Gzip components

• 3.4.2 Minify JavaScript, CSS & HTML

• 3.4.3 Optimize Images

Another category of strategies are those that try to reduce the time the client have to wait for responses:

• 3.5.1 Use a Content Delivery Network

• 3.5.2 Avoid Redirects

• 3.5.3 Flush the document early

• 3.5.4 Reduce the number of DNS lookups

Then there are a few strategies that do not fall into any category. By using a cookie free domain when serving static content (3.6.1) the size of the HTTP request can be reduced. Putting stylesheets at the top of the document (3.6.2) makes sure the webpage renders progressively and putting scripts at the bottom of the document (3.6.3) minimizes the effect of blocked downloading behaviour. Removing duplicate scripts (3.6.4) ensures that data already received is not requested again.

3.2 Reduce the number of HTTP requests

The easiest way to reduce the number of HTTP requests would be to simplify the webpage by reducing the number of components and by that reducing the total page size. But the components are usually there for a reason so that is rarely a good solution. Fortunately there are techniques for reducing the number of HTTP requests and still keeping all components on the webpage. By reducing the number of HTTP requests, time spent waiting for a connection and latencies included in each request can be eliminated reducing the webpage’s response time.

(27)

3.2. REDUCE THE NUMBER OF HTTP REQUESTS

3.2.1 Image maps

Many websites today have a navigation bar on their webpage. Often this navigation bar is constructed using images associated with a destination. Every image in the navigation bar consumes one HTTP request each. One solution to reduce response time is to combine the navigation bar images into one image and then use image maps to specify areas of the image associated with a particular destination. This can be done using HTML. This way there is no difference for the user but the number of HTTP requests have been reduced by only downloading one combined image [1, 5].

Home About Us Services Contact Us

Figure 3.1. A navigation bar with combined button images.

3.2.2 CSS sprites

Another way of reducing the number of HTTP requests is to use CSS (Cascading Style Sheets) sprites. This is a more flexible solution than image maps because the images do not have to be located next to each other. With CSS sprites, multiple images are combined into one. In the style sheet the coordinates of the requested image in the image can be specified and set as a background image for a specific element [1, 5, 7, 8].

Figure 3.2. A CSS sprite used by www.google.com

(28)

3.2.3 Inline images

By using inline images the HTTP request is removed altogether. This is done by taking advantage of the data: scheme as shown below.

data:[<mediatype>][;base64],<data>

<img src="data:image/gif;base64,R0lGODlhEAAOALMAAOazToeHh0tLS/7LZv/0j vb29t/f3//Ub//ge8WSLf/rhf/3kdbW1mxsbP//mf///yH5BAAAAAAALAAAAAAQAA4AA ARe8L1Ekyky67QZ1hLnjM5UUde0ECwLJoExKcppV0aCcGCmTIHEIUEqjgaOR

CMxIC6e0CcguWw6aFjsVMkkIr7g77ZKPJjPZqIyd7sJAgVGoEGv2xsBxqNgYPj/g AwXEQA7"

width="16" height="14" alt="embedded folder icon">

Figure 3.3. The picture created by the data example above.

The drawback of this approach is that this will increase the size of the HTML document and the images will not be cached. This approach may not be a good idea for an image such as a company logo that will be displayed on all pages of the company’s website. Using an image which can be cached would be a preferable solution for this situation [1, 24].

3.2.4 Combining scripts and style sheets

Another way you can reduce the number of HTTP request is to combine scripts and style sheets. Many websites today have more than one script and one style sheet on its pages. Combining all scripts into one script and combining all style sheets into one style sheet will reduce the number of HTTP request making the webpage load faster [1, 7, 8, 10].

3.3 Optimize Caching

3.3.1 Use a Cache-Control or Expires header

Adding a Cache-Control header or a far future Expires header (see section 2.3.2) to static components makes sure that a user who requests a page a second time does not have to download these static components again but instead can load them from its cache. This will reduce the number of HTTP requests by the number of cached components [1, 5, 7, 8, 15].

(29)

3.4. REDUCE THE SIZE OF THE HTTP RESPONSE

3.3.2 Make Scripts and CSS external

One might think that making scripts and CSS files external would be a bad idea because it would generate a new HTTP request for every external file. While this is true there is a possibility to cache these components so that the next time the page (or another page using the same components) is requested the client will not have to download them from the server but can get them directly from the browser’s cache. If inline scripts (scripts written within the HTML document) are used the size of the HTML document will be bigger and the client will not be able to take advantage of the caching capabilities of the browser [1].

3.3.3 Use ETags with care

ETags (see section 2.3.2) are used by web servers as a way to validate cached components. If they are used without any special configuration they will include a string that is constructed from attributes that make them unique to a specific server hosting a component. The problem is when a website uses more than one server to host the components. A user may have a cached component with an ETag set from one server but this time the request is served from another server that will have a different ETag even though it is the same component. The user will download the component even though it has it in its cache. The lesson here is to not use ETags or configure them in such a way that the ETag for a specific component is the same for all servers hosting the component [1].

3.4 Reduce the size of the HTTP response

3.4.1 Gzip components

If the size of a components HTTP response can be reduced the response time of that component will also be reduced. This can be done with compression (see Section 2.3.4). What components should be compressed? The answer is all plain text files including HTML, scripts and style sheets. Compression of HTML is quite common but compression of scripts and style sheets is less common. Compression should however not be used for PDFs, images and the like since they are compressed already and the added compression might actually result in an increase in file size for that type of components [1, 7].

3.4.2 Minify JavaScript, CSS & HTML

Minification is the action of removing unnecessary characters from text files such as spaces and comments that are present to make the script humanly readable. By doing this the size of the text file is reduced which in turn will improve the response time of that component [1, 7].

(30)

3.4.3 Optimize images

There is a strong relationship between the page size and the page response time.

The larger amount of data that have to be requested and downloaded the longer the response time. A study of the top ten Alexa[25] web sites shows that about 50% of the page size is accounted for by images. By optimizing images and reducing their size the response time can be improved [2].

Crush PNGs

Pngcrush is a tool for optimizing images in PNG format (Portable Network Graph- ics). What it does is removing chunks of information not needed for web display.

Running this tool on a PNG image will improve the response time for that image since its size will be smaller. There are many other tools as well for doing this and if time is not an issue one could try a large array of tools for every image and see which one results in the smallest image size [2].

Strip JPEG Metadata

JPEG (Joint Photographic Experts Group) images contain some metadata that is not needed for display on the web. This includes comments, application-specific information and EXIF information (camera make, model, date when photo was taken, audio etc.). By using a tool such as jpegtran this data can be removed without losing any quality in the picture. Please note that removing metadata of images you do not own may mean that copyright information is removed which is illegal [2].

Convert GIF to PNG

Comparing GIF (Graphics Interchange Format) to PNG will show that PNGs have all of the features of GIFs except support for animation. PNGs have support for an alpha channel and generally compress better than GIFs. A GIF can be converted to a PNG by using the command line tool ImageMagick. After conversion the PNG should also be crushed as described previously [2].

Optimize GIF Animation

When an animated GIF is involved conversion to PNG is not an option since PNGs do not support animation. But what can be done is optimization of the GIF by reducing all duplicate pixels in the frames of the animation (Some frames will not change in an animation from frame to frame). This can be done using a tool called Gifsicle [2].

(31)

3.5. REDUCE THE TIME SPENT WAITING

Do not scale images in HTML

It is not efficient to have a large image and then scale it using HTML. This will mean that the client will have to download a larger image than it needs. Images should be scaled to the required size first instead of letting the browser scale the picture [2, 7].

This is an example of an image that will be scaled by the browser to be rendered as an image of size 20x20 although the size of the image might be much bigger.

Favicon

Favicons are small images shown next to the URL in the browsers address bar and usually displayed next to the title of the webpage when tabs are used in a browser.

Figure 3.4 shows Google’s favicon. These images are small but their use can be optimized as well.

Figure 3.4. Google’s favicon.

First thing to know is that the browser will always request the favicon so making sure the website have one is important or the server will respond with a 404 Page Not Found HTTP response which is time consuming. Adding an Expires header to the favicon is an option that will ensure that the favicon is retrieved from the browser cache for returning users. But be aware, the name of the favicon cannot be changed. Therefore there is no way to make a user download the new favicon if it is changed. The user will have to wait until the favicon expires in its cache [7].

3.5 Reduce the time spent waiting

3.5.1 Use a Content Delivery Network

The idea of Content Delivery Networks is to have content distributed across multiple servers in different geographical locations. Then when a user requests a component the server with the shortest distance will be used which potentially will reduce the response time (This can be done by counting the number of hops between the client and the servers and choose the server with the fewest hops). This is a good strategy if you have a large website with lots of traffic and users from different geographical locations. [1, 11].

(32)

3.5.2 Avoid redirects

Redirects are used to reroute a user from one location to another. Redirects are used for different things such as tracking traffic flow, counting ad impressions, creating easier URLs and redirecting to a site redesign. But from a performance view redirects are costly and take time. Therefore, avoid redirects as far as possible [1].

3.5.3 Flush the document early

If the HTML document is dynamic and takes a long time to generate the client will just hold and wait for the document to arrive. What you can do is flush everything in the document up until the point in the HTML document that takes a lot of time.

This can be achieved with a call to a method called flush or similar depending on which framework you are using to create dynamic content. That way the client can interpret the start of the HTML document and start requesting additional components specified in the flushed part of the HTML [2].

3.5.4 Reduce the number of DNS lookups

When a client requests a component from a new hostname, the client has to do a DNS lookup which takes time. Reducing the number of DNS lookups in a webpage will help improve the response time. But decreasing the number of unique hostnames will reduce parallel downloading. By using 2-4 hostnames the number of DNS lookups are reduced but parallel downloading is still utilized. This is a good compromise. Using a persistent connection (see Section 2.3.3) eliminates additional DNS lookups for components from the same hostname.

3.6 Other

3.6.1 Use cookie free domains when serving static content

Static content such as images, style sheets and scripts should be served from a domain that does not allow cookies since those components have no use for cookies (see Section 2.3.5). By doing this the size of the HTTP request will be reduced which will improve the response time of that component [7].

3.6.2 Put style sheets at the top

When a webpage is loading progressive rendering is wanted. That way, as soon as the browser interprets something, it is displayed for the user. This will enhance the user experience and give the user visual feedback that the page is loading. But if you place a style sheet at the bottom of a page most browsers will not start rendering the page because it does not want to risk having to redo the rendering after the style sheet at the bottom is read. This results in a blank white screen displayed for the user until the page is fully loaded and then the fully loaded page pops up for

(33)

3.6. OTHER

the user. By putting the style sheet at the top of the page, progressive rendering is made possible [1, 7].

3.6.3 Put scripts at the bottom

When downloading the components of a webpage the browser tries to download several components in parallel (see Section 2.5.1). But when a script is downloaded it blocks the downloading of any other components in some browsers (see Section 2.5.2). This is because the browser needs to be able to guarantee that dependencies between scripts are kept. If you put two scripts after each other in a webpage you should be guaranteed that the scripts will execute in that order. Potential errors could occur if the second script is executed before the first one is downloaded and available. But there is only a need for a specific execution order, the downloading order is of no importance. This is why most of the newer browsers do not block parallel downloading when scripts are involved. But for older ones this will happen and that is why it is good practice to put your scripts at the bottom of the page [1].

3.6.4 Remove duplicate scripts

Make sure you do not include a script twice creating a second unnecessary HTTP request [1].

(34)

(35)

Chapter 4

Design of Experiment

This chapter presents the strategies that have been tested in this master thesis as well as the 5 different websites used in the tests. It also describes the test environment and how the tests were made.

4.1 Strategies Tested

Chapter 3 lists a whole range of strategies for reducing response time. Six of these strategies ware selected to be part of the tests conducted in this master thesis.

These strategies ware selected based on their expected effect on response time and their ease of implementation. The selected strategies are:

• 3.2.2 CSS Sprites

• 3.2.4 Combining scripts and style sheets

• 3.3.1 Use a Cache-Control or Expires header

• 3.4.1 Gzip components

• 3.4.2 Minify JavaScript, CSS & HTML

• 3.6.1 Use cookie free domains when serving static content

(36)

4.2 Test Environment

4.2.1 Experimental Setup

As shown in figure 4.1 the experimental setup consists of a server running IIS (In- ternet Information Service) 7.0 where the websites are hosted, a client computer making the requests and recording the response time, and between them, another computer running the software WANem which emulates network traffic character- istics typical for Internet communication.

Client WANem Test Server

Figure 4.1. Experimental setup

4.2.2 Test Settings

Akamai’s report State of the Internet [40] from the first quarter of 2010 shows that Sweden has an average bandwidth of 6,2 Mbit/s. But this report does not take mobile devices into account. The website Bredbandskollen [41] shows that the average bandwidth of mobile devices is 1,82 Mbit/s (in Stockholm). The WANem has therefore been configured to limit the bandwidth to 2 Mbit/s in these tests.

The delay when requesting a component on the Internet depends on how great the geographical distance is between client and server among other things. The delay can therefore vary greatly. In these tests the delay has been configured to be 50 ms.

Every strategy has been tested for the 5 websites in both Internet Explorer 8 and Firefox 3.6 and with both empty and primed cache. For every combination of strategy, website, browser and cache setting, the websites have been loaded 20 times by using an automated test program written by the author. The test program collects data from each page load gathered by the software HttpWatch [22]. The program uses a formula to calculate a 99% confidence interval (see Appendix A) for every page load using normal approximation. By using normal approximation and a large enough selection the distribution does not need to be known and the confidence interval can be approximatively calculated [39].

(37)

4.3. WEBSITES

4.3 Websites

The experiment measures the response time for the different strategies applied to 5 different websites. The websites are tre.se, 3.dk, ncc.se, svenskaturistforeningen.se and vasakronan.se. These website’s start pages and their components have been copied to a server where the different strategies have been applied. These websites were copied in november of 2010 and may therefore not look like the actual live website do today. The different websites and their compositions are presented in table 4.1.

tre.se 3.dk ncc.se stf.se vasakronan.se

HTML 1 6 1 2 1

Javascript 12(13) 18(19) 13 15 16

CSS 3 7 3(4) 4(5) 7

GIF 17 27(26) 21 12 26

PNG 33 7 5 30(36) 1

JPG - 5(3) 4 13 7

Flash - 2 - - 1

Plain text - 1 - - -

Components 66(67) 73(71) 47(48) 76(83) 59

Table 4.1. Composition of the websites (The numbers in parenthesis represents Internet Explorer).

The website 3.dk actually gets its components from 19 (21 in Firefox) different domains when all the other sites only uses 3 different domains. All five websites have one domain hosting a large portion of the components. The websites make zero or one redirect while 3.dk makes 8 (10 in Firefox) redirects. Table 4.2 show the different sizes of the requests and responses for the different websites.

tre.se 3.dk ncc.se stf.se vasakronan.se Size of request (IE) 26 kB 32 kB 25 kB 39 kB 27 kB Size of request (FF) 29 kB 39 kB 23 kB 39 kB 27 kB Size of response (IE) 625 kB 520 kB 748 kB 697 kB 710 kB Size of response (FF) 566 kB 549 kB 747 kB 694 kB 742 kB

Table 4.2. Sizes of requests/responses for the websites.

(38)

Figure 4.2. tre.se.

(39)

4.3. WEBSITES

Figure 4.3. 3.dk.

(40)

Figure 4.4. ncc.se

(41)

4.3. WEBSITES

Figure 4.5. svenskaturistforeningen.se.

(42)

Figure 4.6. vasakronan.se.

(43)

Chapter 5

Implementation

In this chapter the implementation of each of the strategies tested in this master thesis is explained.

Before any strategy was implemented the websites were tested in their original state.

5.1 CSS Sprites

Applying the strategy of CSS Sprites required a bit of work. First it involved running the tool SpriteMe [38] combining all suitable images into one image and then changing all references in the CSS files. Below is an example of the CSS class smallpuffarrowlink before utilizing this strategy.

.smallpuffarrowlink {

background-image: url("/media/img/smallpuffarrow.png");

}

The example below shows the change for the same CSS class after the strategy has been applied. Instead of using the image smallpuffarrow.png as a background image it will instead use the sprite image spritencc.png. The background-position attribute makes sure the right part of the sprite is shown.

.smallpuffarrowlink {

background-image: url("/media/img/sprites/spritencc.png");

background-position: 125px -38.5px;

}

5.2 Combining scripts and style sheets

The strategy of combining scripts and style sheets involved combining all scripts that were placed in sequence after each other in the HTML document into one file.

(44)

The same was done with the CSS files. Then the HTML document was modified to use the combined scripts and stylesheets.

5.3 Use a Cache-Control or Expires header

Applying the strategy of using Cache-Control or Expires headers involves modifying the web.config file by specifying the headers and how long the components should be cached.

5.4 Gzip Components

The web.config file is a XML-based configuration file used by web servers running ASP.NET [35]. To enable the strategy of gziping components the configuration of the web.config file needs to be modified to allow static compression. This can be done by using the user interface of IIS (Internet Information Service) or by modifying the web.config file.

5.5 Minify JavaScript, CSS & HTML

Minifying JavaScript involved running Closure Compiler [36] on every javascript file creating new minified versions of them. Some files were already minified and therefor did not require any modification. Every css file was minified as well by using cssmin.js [37]. However the HTML files were not minified since it is still considered somewhat experimental to do so [7]. Then a modified version of the original HTML document referencing the new minified versions of the javascript files and the CSS files were created and used to test this strategy.

5.6 Use cookie free domains when serving static content

To use cookie free domains when serving static content there was a need to setup another domain to which all static components were moved. Then modifying the HTML document making it reference the components on the new domain instead of the original domain.

(45)

Chapter 6

Results

This chapter presents the results of this master thesis. It begins with an overview of the load times for the different strategies in comparison to when no strategy was applied. Then the results of every strategy are presented.

Figure 6.1 shows the mean values of the load times for each strategy tested in this master thesis in comparison to the load times when no strategy was applied.

Figure 6.1. Percentage of load times compared to when no strategy was applied

The rest of this chapter presents each strategy’s result for every website and for both browsers used when testing these strategies. For complete results for all page events see Appendix B.

(46)

Website Internet Explorer 8 Firefox 3.6

tre.se 108% 109%

3.dk 88% 105%

ncc.se 102% 100%

svenskaturistoreningen.se 118% 106%

vasakronan.se 104% 103%

Table 6.1. Percentage of page load time with an empty cache compared to when no strategy has been applied.

6.1 CSS Sprites

The results of the CSS sprites strategy were not good as seen in table 6.1. The main reason for this was that the size of the sprite was bigger than the combined size of the images making the sprite. This strategy would probably get better results in older browsers with fewer simultaneous connections (see Section 2.5.1).

6.2 Combining scripts and style sheets

tre.se 98% 101%

3.dk 127% 118%

ncc.se 104% 105%

Combining scripts and style sheets did not get very good results as seen in table 6.2. In some cases there were a small improvements and in some cases the response times ware longer . The reason why it was slower in some cases could be because of the script loading behavior of the browser (see Section 2.5.2). When the scripts are combined the file needs to be fully downloaded before it can be parsed and executed.

When they are separated each script can execute once they are downloaded (as long as they are in the correct order). This strategy is likely to render better results in older browsers with fewer simultaneous connections allowed (see Section 2.5.1) and especially those who block downloading of other components when a script is downloading (see Section 2.5.2).

(47)

6.3. USE A CACHE-CONTROL OR EXPIRES HEADER

6.3 Use a Cache-Control or Expires header

tre.se 57% 118%

3.dk 50% 113%

ncc.se 53% 113%

Table 6.3. Percentage of page load time with a primed cache compared to when no strategy has been applied.

In table 6.3 we see that using a Cache-Control or Expires header shows great improvement in response time for Internet Explorer (average of 50,2%) but actually an increase in response time in Firefox. The reason for the increase in Firefox is due to that Firefox calculates and sets an Expires header when one is missing as explained in Section 2.5.3. This results in that all static content is cached, even the HTML document which is not the case when the strategy is applied. Because the HTML document is not cached when the strategy is applied is what cases the increase in response time.

6.4 Gzip Components

tre.se 73% 74%

3.dk 61% 80%

ncc.se 63% 54%

We see in table 6.4 that gzipping components showed great results for all websites and both browsers. The average load time was 69% of the load time when no strategies were applied. The effect of this strategy depends on how large the plain text files (HTML, javascript, CSS) are in comparison with the other components on the website. If the composition of the website is like the websites in these tests gzipping components is likely to render good results.

(48)

6.5 Minify JavaScript, CSS & HTML

tre.se 95% 96%

3.dk 94% 95%

ncc.se 101% 97%

The strategy of minifying JavaScript, CSS & HTML showed somewhat inconclusive results as seen in table 6.5. In most cases there were a few percents improvement but in some cases there were not. This might be because of uncertainty in the results and/or maybe the script loading behavior of the browser (see Section 2.5.2).

As explained in Section 5.5 some files were minified even before this strategy was applied. If that file took the longest to download the downloading of the other files although smaller would not impact the page load time of the webpage.

6.6 Use cookie free domains when serving static content

tre.se 125% 128%

3.dk 99% 97%

ncc.se 75% 73%

Using cookie free domains when serving static content showed interesting results.

Some websites showed some improvement but the website tre.se was significantly slower. This was probably due to that the cookies set for that domain were set late in the page loading process and did only affect a few components meaning the request size was about the same but the separate domain called for an extra DNS lookup and TCP connections. But in the case of ncc.se there was an significant improvement in response time. This was due to that cookies for the domain were set early in the page loading process and the request size was significantly smaller when the strategy was applied.

(49)

Chapter 7

Evaluation & Discussion

In this chapter the different strategies are evaluated. Likely improvement in response time, ease of implementation and pros and cons, of each strategy are discussed.

7.1 CSS Sprites

The results of using CSS Sprites were not good. In fact, the response time was actually increased in most cases (see Section 6.1). The reason for this was that the size of the CSS sprite was actually bigger than the combined size of the images making the sprite. Implementing this strategy proved to be a lot of work as well (see Section 5.1) at least if it was done as a separate task at the end of a web development project instead of a conscious choice during the development process.

If the sprite image is smaller or equal in size than the combined size of the images making the sprite this might still be a good idea at least as long as older browsers with fewer HTTP connections are in use.

7.2 Combining scripts and style sheets

Combining scripts and style sheets did not improve the response time considerably as seen in Section 6.2. The improvement in response time is likely to be greater in older browsers using fewer connections and especially those who block other downloads when downloading scripts. Since the implementation of this strategy was not that time consuming (see Section 5.2) and as long as there are people using older browsers such as Internet Explorer 7 this might still be a strategy worthwhile to implement.

(50)

7.3 Use a Cache-Control or Expires header

Using a Cache-Control or Expires header does not require much work to implement and the improvement in response time is likely to be great (see Section 6.3).

Although the results in Firefox were actually worsened when this strategy was applied it might still be a good strategy to use. The HTML document was cached by Firefox when no strategies were applied. If the HTML document is changed the client will not see the change until the HTML document expires in its cache. It will also potentially set shorter expires dates for components because the expire date is calculated from when the component was last modified. Using this strategy gives total control of which components are cached and for how long.

7.4 Gzip Components

Gzipping components proved to be a strategy resulting in great improvement in response time (see Section 6.4) This strategy requires very little effort to implement as seen in Section 5.4. It will however increase the load of the server which needs to compress the files before sending them. Gzipping should only be used for plain text files. If gzip is used for any other components than plain text files the size of those components are actually likely to increase.

7.5 Minify JavaScript, CSS & HTML

Minifying JavaScript, CSS & HTML did not impact the response time very much in the tests (see Section 6.5). This was because the total size of the webpage was only decreased slightly. If the website has a large amount of javascript files and CSS files it could impact the response time more. If an automatic script could be used to minify the resources in development there is no reason not to use this strategy even though it might not improve the response time considerably.

7.6 Use cookie free domains when serving static content

The results from the tests for using cookie free domains when serving static content were varied (see Section 6.6). Clearly this strategy is good in some cases and bad in some. What the test did not show is what happens on subsequent page views when cookies have been set for the domain. On subsequent page views all requests for components from the same domain will include the cookies meaning an increase in request size. Another benefit is that proxy caching can be leveraged.

When components have cookies set a proxy server shall not cache the component because the cookie can be specific for the user. By using a cookie free domain for static components proxy caching can be fully utilized. There is however some work involved in implementing this strategy such as setting up a separate domain (see

(51)

7.6. USE COOKIE FREE DOMAINS WHEN SERVING STATIC CONTENT

Section 5.6). If a website has a lot of static content this strategy might be worth considering.

(52)

Faster Loading of Websites