Faster Loading of Websites

Strategies for optimizing loading of webpage components

MIKAEL RYDMARK

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

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. Referat

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. Contents

1 Introduction 1 1.1 Background ...... 1 1.2 Problem Statement ...... 2 1.3 Purpose ...... 2 1.4 Method ...... 2 1.5 Limitations ...... 3 1.6 Thesis Outline ...... 3

2 Background 5 2.1 Previous work ...... 5 2.2 Quality of Service ...... 6 2.3 HTTP - Hypertext Transfer Protocol ...... 6 2.3.1 Overview ...... 6 2.3.2 Caching ...... 7 2.3.3 Persistent Connections ...... 9 2.3.4 Compression ...... 10 2.3.5 Cookies ...... 10 2.4 Webpage Components ...... 11 2.4.1 HTML ...... 11 2.4.2 Stylesheets ...... 11 2.4.3 Javascript ...... 11 2.4.4 Images & Flash ...... 12 2.5 Web Browsers ...... 12 2.5.1 Connections ...... 12 2.5.2 Script Downloading Behavior ...... 12 2.5.3 Heuristic Expiration in Firefox ...... 13 2.6 Response Time ...... 14 2.6.1 Webpage ...... 14 2.6.2 Components ...... 14 2.7 Performance Golden Rule ...... 15 2.8 Loading of a Webpage ...... 15

3 Strategies 17 3.1 Overview ...... 17 3.2 Reduce the number of HTTP requests ...... 18 3.2.1 Image maps ...... 19 3.2.2 CSS sprites ...... 19 3.2.3 Inline images ...... 20 3.2.4 Combining scripts and style sheets ...... 20 3.3 Optimize Caching ...... 20 3.3.1 Use a Cache-Control or Expires header ...... 20 3.3.2 Make Scripts and CSS external ...... 21 3.3.3 Use ETags with care ...... 21 3.4 Reduce the size of the HTTP response ...... 21 3.4.1 Gzip components ...... 21 3.4.2 Minify JavaScript, CSS & HTML ...... 21 3.4.3 Optimize images ...... 22 3.5 Reduce the time spent waiting ...... 23 3.5.1 Use a Content Delivery Network ...... 23 3.5.2 Avoid redirects ...... 24 3.5.3 Flush the document early ...... 24 3.5.4 Reduce the number of DNS lookups ...... 24 3.6 Other ...... 24 3.6.1 Use cookie free domains when serving static content . . . . . 24 3.6.2 Put style sheets at the top ...... 24 3.6.3 Put scripts at the bottom ...... 25 3.6.4 Remove duplicate scripts ...... 25

4 Design of Experiment 27 4.1 Strategies Tested ...... 27 4.2 Test Environment ...... 28 4.2.1 Experimental Setup ...... 28 4.2.2 Test Settings ...... 28 4.3 Websites ...... 29

5 Implementation 35 5.1 CSS Sprites ...... 35 5.2 Combining scripts and style sheets ...... 35 5.3 Use a Cache-Control or Expires header ...... 36 5.4 Gzip Components ...... 36 5.5 Minify JavaScript, CSS & HTML ...... 36 5.6 Use cookie free domains when serving static content ...... 36

6 Results 37 6.1 CSS Sprites ...... 38 6.2 Combining scripts and style sheets ...... 38 6.3 Use a Cache-Control or Expires header ...... 39 6.4 Gzip Components ...... 39 6.5 Minify JavaScript, CSS & HTML ...... 40 6.6 Use cookie free domains when serving static content ...... 40

7 Evaluation & Discussion 41 7.1 CSS Sprites ...... 41 7.2 Combining scripts and style sheets ...... 41 7.3 Use a Cache-Control or Expires header ...... 42 7.4 Gzip Components ...... 42 7.5 Minify JavaScript, CSS & HTML ...... 42 7.6 Use cookie free domains when serving static content ...... 42

8 Conclusion & Future Work 45 8.1 Recommendation ...... 46 8.2 Future Work ...... 46

Bibliography 47

Appendices 50

A Mathematical statistics 51 A.1 Formulas ...... 51

B Complete results 53 B.1 No strategies applied ...... 53 B.1.1 tre.se ...... 53 B.1.2 3.dk ...... 53 B.1.3 ncc.se ...... 54 B.1.4 svenskaturistforeningen.se ...... 55 B.1.5 vasakronan.se ...... 55 B.2 CSS Sprites ...... 56 B.2.1 tre.se ...... 56 B.2.2 3.dk ...... 56 B.2.3 ncc.se ...... 56 B.2.4 svenskaturistforeningen.se ...... 57 B.2.5 vasakronan.se ...... 57 B.3 Combining scripts and style sheets ...... 58 B.3.1 tre.se ...... 58 B.3.2 3.dk ...... 58 B.3.3 ncc.se ...... 58 B.3.4 svenskaturistforeningen.se ...... 59 B.3.5 vasakronan.se ...... 59 B.4 Use a Cache-Control or Expires header ...... 60 B.4.1 tre.se ...... 60 B.4.2 3.dk ...... 60 B.4.3 ncc.se ...... 60 B.4.4 svenskaturistforeningen.se ...... 61 B.4.5 vasakronan.se ...... 61 B.5 Gzip Components ...... 62 B.5.1 tre.se ...... 62 B.5.2 3.dk ...... 62 B.5.3 ncc.se ...... 62 B.5.4 svenskaturistforeningen.se ...... 63 B.5.5 vasakronan.se ...... 63 B.6 Minify JavaScript, CSS & HTML ...... 64 B.6.1 tre.se ...... 64 B.6.2 3.dk ...... 64 B.6.3 ncc.se ...... 64 B.6.4 svenskaturistforeningen.se ...... 65 B.6.5 vasakronan.se ...... 65 B.7 Use cookie free domains when serving static content ...... 66 B.7.1 tre.se ...... 66 B.7.2 3.dk ...... 66 B.7.3 ncc.se ...... 66 B.7.4 svenskaturistforeningen.se ...... 67 B.7.5 vasakronan.se ...... 67 Chapter 1

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 prob- lem 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 as- sociated 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

1 CHAPTER 1. INTRODUCTION 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).

2 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.

3

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 re- quest 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

5 CHAPTER 2. BACKGROUND 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 optimiza- tion 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 ex- perienced 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.

6 2.3. HTTP - HYPERTEXT TRANSFER PROTOCOL

Client Web Server HTTP Request

HTTP Response

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) fol- lowed 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

7 CHAPTER 2. BACKGROUND 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 intro- duced 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].

8 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 spec- ifying 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].

9 CHAPTER 2. BACKGROUND

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]

10 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].

11 CHAPTER 2. BACKGROUND

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 re- sponse 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 exe- cute them in the correct order. The browser implementations differ in this respect.

12 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-

13 CHAPTER 2. BACKGROUND 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].

14 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

15 CHAPTER 2. BACKGROUND 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.

16 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 com- ponents. 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

17 CHAPTER 3. STRATEGIES

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.

18 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

19 CHAPTER 3. STRATEGIES

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:[][;base64],

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].

20 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 compo- nents. 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 host- ing 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].

21 CHAPTER 3. STRATEGIES

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].

22 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].

23 CHAPTER 3. STRATEGIES

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, cre- ating 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 web- page 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

24 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].

25

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

27 CHAPTER 4. DESIGN OF EXPERIMENT

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].

28 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.

29 CHAPTER 4. DESIGN OF EXPERIMENT

Figure 4.2. tre.se.

30 4.3. WEBSITES

Figure 4.3. 3.dk.

31 CHAPTER 4. DESIGN OF EXPERIMENT

Figure 4.4. ncc.se

32 4.3. WEBSITES

Figure 4.5. svenskaturistforeningen.se.

33 CHAPTER 4. DESIGN OF EXPERIMENT

Figure 4.6. vasakronan.se.

34 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.

35 CHAPTER 5. IMPLEMENTATION

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.

36 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.

37 CHAPTER 6. RESULTS

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

Website Internet Explorer 8 Firefox 3.6 tre.se 98% 101% 3.dk 127% 118% ncc.se 104% 105% svenskaturistoreningen.se 99% 99% vasakronan.se 93% 95%

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

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).

38 6.3. USE A CACHE-CONTROL OR EXPIRES HEADER

6.3 Use a Cache-Control or Expires header

Website Internet Explorer 8 Firefox 3.6 tre.se 57% 118% 3.dk 50% 113% ncc.se 53% 113% svenskaturistoreningen.se 42% 122% vasakronan.se 49% 115%

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 im- provement 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

Website Internet Explorer 8 Firefox 3.6 tre.se 73% 74% 3.dk 61% 80% ncc.se 63% 54% svenskaturistoreningen.se 74% 77% vasakronan.se 67% 67%

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

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.

39 CHAPTER 6. RESULTS

6.5 Minify JavaScript, CSS & HTML

Website Internet Explorer 8 Firefox 3.6 tre.se 95% 96% 3.dk 94% 95% ncc.se 101% 97% svenskaturistoreningen.se 99% 101% vasakronan.se 103% 90%

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

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

Website Internet Explorer 8 Firefox 3.6 tre.se 125% 128% 3.dk 99% 97% ncc.se 75% 73% svenskaturistoreningen.se 99% 98% vasakronan.se 93% 101%

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

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.

40 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.

41 CHAPTER 7. EVALUATION & DISCUSSION

7.3 Use a Cache-Control or Expires header

Using a Cache-Control or Expires header does not require much work to imple- ment 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 ap- plied 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

42 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.

43

Chapter 8

Conclusion & Future Work

This last chapter of this master thesis presents the conclusions of the tests as well as a recommendation about which strategies to use. It also contains thoughts about future work in this field.

In this master thesis six different strategies for reducing the response time of a websites components were selected for testing. They were tested on five different websites using two different browsers. The strategies selected for testing were:

• CSS Sprites

• Combining scripts and style sheets

• Use a Cache-Control or Expires header

• Gzip components

• Minify JavaScript, CSS & HTML

• Use cookie free domains when serving static content

The conclusion of the tests conducted in this master thesis is that there are a lot of strategies for reducing the response time of website components, all with varying degree of impact on the response time, depending on the composition of the website and also on the browser used to visit the website. Out of these six strategies two had a significant impact on the response time. Gzipping components showed an improvement of about 30% on average and did not require much in terms of implementation. Using a Cache-Control or Expires header improved the response time with as much as 50% in some cases. The other strategies tested did just show slight improvements in response time or even an increase in response time. The strategy of combining scripts and stylesheets did not show great results in these tests but might still be good to implement because of the likely improvement

45 CHAPTER 8. CONCLUSION & FUTURE WORK in older browsers due to their script downloading behavior. Using cookie free do- mains when serving static components is also a strategy to consider if the website in question uses cookies and the users are likely to navigate to other pages on the web- site (The tests conducted in this master thesis only focused on loading of the start page of a website). Minify JavaScript, CSS & HTML showed a slight improvement in most cases and will reduce the total size of the components of a webpage. The strategy CSS sprites is probably not worth the trouble to implement unless you can make sure the sprite is made smaller than the combined size of the images making up the sprite. This strategy is the one strategy tested in this master thesis that required the most work to use as well.

8.1 Recommendation

Since websites have different compositions and different usage and user behavior it is always a good idea to think through if a certain optimizing strategy is likely to render improved response times for the website in question. Judging from the results of this master thesis the following strategies are recommended to be used on any website:

• Configure the website to use far future Cache-Control headers for all static components (30 days at least).

• Make sure the web server uses compression for plain text files.

8.2 Future Work

This master thesis has shown that strategies that were highly effective a few years ago, like combining scripts and style sheets, do not have the same effect in today’s browsers. It is likely that tomorrow’s browsers will make some of the other strategies less effective and new strategies might show greater promise. It is therefore of great importance to constantly re-evaluate the established strategies and look for new ones.

46 Bibliography

[1] Steve Souders. High Performance Web Sites - Essential Knowledge for Front- end Engineers, 2007. O’Reilly.

[2] Steve Souders. Even Faster Websites: Essential Knowledge for Frontend Engi- neers, 2009. O’Reilly.

[3] Andrew B King. Website Optimization, 2008. O’Reilly.

[4] Nicholas C. Zakas. High Performance JavaScript, 2010. O’Reilly.

[5] The Exceptional Performance team at Yahoo. Best Practices for Speeding Up Your Web Site. Web page. Visited 2010-09-09. URL: http://developer.yahoo.com/performance/rules.html

[6] Steve Souders. High Performance Web Sites: The Importance of Front-End Performance. Web page. Visited 2010-09-09. URL: http://developer.yahoo.net/blog/archives/2007/03/high_perform anc.html

[7] Google. Web Performance Best Practices. Web page. Visited 2010-09-09. URL: http://code.google.com/intl/sv-SE/speed/page-speed/docs/rules _intro.html

[8] Christian Heilmann. Website Performance: What To Know and What You Can Do. Web page. Visited 2010-09-09. URL: http://www.smashingmagazine.com/2010/01/06/page-performance- what-to-know-and-what-you-can-do/

[9] Aaron Hopkins. Optimizing Page Load Time. Web page. Visited 2010-09-09. URL: http://www.die.net/musings/page_load_time/

[10] Jacob Gube. 10 Ways to Improve Your Web Page Performance. Web page. Visited 2010-09-09. URL: http://sixrevisions.com/web-development/10-ways-to-improve- your-web-page-performance/

47 BIBLIOGRAPHY

[11] Steve Souders & Tenni Theurer. 14 Rules for Faster-Loading Web Sites. Web page. Visited 2010-09-09. URL: http://www.scribd.com/doc/49362/High-Performance-Web-Sites

[12] Patrick Killelea. Top Ten Web Performance Tuning Tips. Web page. Visited 2010-09-09. URL: http://www.oreillynet.com/pub/a/javascript/2002/06/27/web _tuning.html

[13] Jakob Nielsen. Response Times: The 3 Important Limits. Web page. Visited 2010-09-09. URL: http://www.useit.com/papers/responsetime.html

[14] Tenni Theurer. What the 80/20 Rule Tells Us about Reducing HTTP Requests. Web page. Visited 2010-09-09. URL: http://yuiblog.com/blog/2006/11/28/performance-research- part-1/

[15] Tenni Theurer. Browser Cache Usage - Exposed!. Web page. Visited 2010-09- 09. URL: http://yuiblog.com/blog/2007/01/04/performance-research- part-2/

[16] Tenni Theurer & Patti Chi. When the Cookie Crumbles. Web page. Visited 2010-09-09. URL: http://yuiblog.com/blog/2007/03/01/performance-research- part-3/

[17] Tenni Theurer & Steve Souders. Maximizing Parallel Downloads in the Carpool Lane. Web page. Visited 2010-09-09. URL: http://yuiblog.com/blog/2007/04/11/performance-research- part-4/

[18] Julien Lecomte. High Performance Ajax Applications. Web page. Visited 2010- 09-09. URL: http://yuiblog.com/blog/2007/12/20/video-lecomte/

[19] Kristopher William Zyp. Ajax performance analysis. Web page. Visited 2010-09-09. URL: http://www.ibm.com/developerworks/web/library/wa-aj-perform/

[20] Max Kiesler. How To Minimize Your Javascript and CSS Files for Faster Page Loads. Web page. Visited 2010-09-09. URL: http://www.maxkiesler.com/2007/11/04/how-to-minimize-your- javascript-and-css-files-for-faster-page-loads/

48 [21] Jacob Gube. 15 Tools to Help You Develop Faster Web Pages. Web page. Vis- ited 2010-09-09. URL: http://sixrevisions.com/tools/faster_web_page/

[22] HttpWatch 7.0: Seamless HTTP monitoring for IE and Firefox. Web page. Visited 2010-10-22. URL: http://www.httpwatch.com

[23] Hypertext Transfer Protocol – HTTP/1.1. Web page. Visited 2010-10-28. URL: http://www.w3.org/Protocols/rfc2616/rfc2616.html

[24] Inline Images with Data URLs. Web page. Visited 2010-10-28. URL: http://www.websiteoptimization.com/speed/tweak/inline-images/

[25] Alexa the Web Information Company. Web page. Visited 2010-10-28. URL: http://www.alexa.com/

[26] HttpWatch Help - Page Level Time Chart. Web page. Visited 2010-10-28. URL: http://help.httpwatch.com/

[27] Browserscope. Web page. Visited 2011-02-21. URL: http://www.browserscope.org/

[28] Two Important Differences between Firefox and IE Caching- HttpWatch Blog. Web page. Visited 2011-02-23. URL: http://blog.httpwatch.com/2008/10/15/two-important-differences- between-firefox-and-ie-caching/

[29] Behrouz A. Forouzan. TCP/IP Protocol Suite, 2007. McGraw-Hill Higher Ed- ucation.

[30] HTTP cookies explained | NCZOnline . Web page. Visited 2011-02-28. URL: http://www.nczonline.net/blog/2009/05/05/http-cookies-explained/

[31] HTML 4.01 Specification . Web page. Visited 2011-02-28. URL: http://www.w3.org/TR/1999/REC-html401-19991224/

[32] Cascading Style Sheets, Level 2 . Web page. Visited 2011-02-28. URL: http://www.w3.org/TR/2008/REC-CSS2-20080411/

[33] ECMAScript Language Specification. Web page. Visited 2011-02-28. URL: http://www.ecma-international.org/publications/files/ ECMA-ST/ECMA-262.pdf

[34] WANem : The Wide Area Network Emulator. Web page. Visited 2011-03-01. URL: http://wanem.sourceforge.net/

[35] ASP.NET Configuration. Web page. Visited 2011-03-01. URL: http://msdn.microsoft.com/en-us/library/aa719558.aspx

49 BIBLIOGRAPHY

[36] Closure Compiler - Google Code. Web page. Visited 2011-03-04. URL: http://code.google.com/intl/sv-SE/closure/compiler/

[37] cssmin.js / Stoyan’s phpied.com. Web page. Visited 2011-03-04. URL: http://www.phpied.com/cssmin-js/

[38] SpriteMe. Web page. Visited 2011-03-04. URL: http://spriteme.org/

[39] Gunnar Blom et al. Sannolikhetsteori och statistikteori med tillämpningar, 2005. Studentlitteratur AB.

[40] Akamai. The State of the Internet, 2010. Web page. Visited 2011-02-28. URL: http://www.akamai.com/stateoftheinternet/

[41] Bredbandskollen. Web page. Visited 2010-09-24. URL: http://www.bredbandskollen.se/mobile.php

[42] Silky Makker et al. Web Server Performance Optimization using Prediction Prefetching Engine, International Journal of Computer Applications (0975 Ð 8887) Volume 23Ð No.9, June 2011

[43] Peipei Ling Based on Web Application Front-end performance optimization, School of computer and science technology, Changhai, China, 2011.

[44] P. Ferguson and G. Huston Quality of Service on the Internet: Fact, Fiction or Compromise?, Inet 98, 1998.

[45] N. Bhatti, A. Bouch and A. Kuchinsky, Integrating User-Perceived Quality into Web Server Design, Computer Networks, vol. 33, no. 1, pp.1-6, June 2000.

50 Appendix A

Mathematical statistics

A.1 Formulas

This master thesis uses normal approximation to calculate a confidence interval Iµ for the expected value µ of a page load event.

λ λ I = (¯x − α d, x¯ + α d) µ 2 2 s d = √ n v u n u 1 X s = t (x − x¯)2 n − 1 i i=1 The theory behind these formulas can be found in Sannolikhetsteori och statistikteori med tillämpningar [39] or similar mathematical statistics books.

51

Appendix B

Complete results

The tables below show the mean value of each event together with a 99% confidence interval for those variables.

B.1 No strategies applied

B.1.1 tre.se Empty Cache Event Internet Explorer 8 Firefox 3.6 Page load 3,84s (3,77, 3,91) 3,43s (3,38, 3,48) Render start 2,11s (2,03, 2,19) 2,07s (2,05, 2,09) DOM load N/A 2,36s (2,26, 2,47) HTTP load 3,88s (3,82, 3,95) 3,41s (3,36, 3,46)

Primed Cache Event Internet Explorer 8 Firefox 3.6 Page load 1,82s (1,77,1,87) 1,06s (1,05, 1,08) Render start 0,82s (0,80, 0,85) 1,04s (1,02, 1,05) DOM load N/A 0,77s (0,76, 0,79) HTTP load 1,87s (1,83, 1,92) 1,05s (1,03, 1,06)

B.1.2 3.dk Empty Cache Event Internet Explorer 8 Firefox 3.6 Page load 4,46s (4,15, 4,76) 5,32s (4,99, 5,65) Render start 2,92s (2,60, 3,23) 2,85s (2,56, 3,14) DOM load N/A 3,54s (3,25, 3,84) HTTP load 4,75s (4,38, 5,12) 5,58s (5,25, 5,91)

53 APPENDIX B. COMPLETE RESULTS

Primed Cache

Event Internet Explorer 8 Firefox 3.6 Page load 1,79s (1,57, 1,99) 2,88s (2,72, 3,03) Render start 0,79s (0,73, 0,85) 0,98s (0,96, 1,00) DOM load N/A 1,17s (1,12, 1,22) HTTP load 2,21s (2,09, 2,34) 3,13s (2,97, 3,29)

B.1.3 ncc.se

Empty Cache

Event Internet Explorer 8 Firefox 3.6 Page load 7,04s (6,93, 7,14) 7,21s (7,05, 7,37) Render start 3,67s (3,49, 3,84) 4,61s (4,31, 4,91) DOM load N/A 5,45s (5,27, 5,63) HTTP load 7,05s (6,94, 7,16) 7,78s (7,61, 7,95)

Primed Cache

Event Internet Explorer 8 Firefox 3.6 Page load 1,45s (1,40, 1,50) 1,15s (1,14, 1,16) Render start 0,76s (0,71, 0,80) 1,14s (1,14, 1,15) DOM load N/A 1,04s (1,03, 1,06) HTTP load 1,52s (1,47, 1,58) 1,68s (1,66, 1,69)

54 B.1. NO STRATEGIES APPLIED

B.1.4 svenskaturistforeningen.se

Empty Cache

Event Internet Explorer 8 Firefox 3.6 Page load 4,98s (4,76, 5,19) 4,85s (4,55, 5,15) Render start 2,46s (2,23, 2,69) 3,21s (2,90, 3,52) DOM load N/A 3,24s (2,92, 3,55) HTTP load 5,02s (4,80, 5,24) 5,14s (4,85, 5,44)

Primed Cache

Event Internet Explorer 8 Firefox 3.6 Page load 2,38s (2,31, 2,44) 1,50s (1,48, 1,52) Render start 0,99s (0,95, 1,03) 1,20s (1,15, 1,24) DOM load N/A 1,26s (1,24, 1,27) HTTP load 2,59s (2,52, 2,65) 1,90s (1,85, 1,94)

B.1.5 vasakronan.se

Empty Cache

Event Internet Explorer 8 Firefox 3.6 Page load 5,62s (5,28, 5,95) 5,36s (5,05, 5,67) Render start 3,30s (3,06, 3,54) 3,67s (3,42, 3,93) DOM load N/A 3,54s (3,23, 3,85) HTTP load 5,59s (5,26, 5,92) 5,35s (5,05, 5,66)

Primed Cache

Event Internet Explorer 8 Firefox 3.6 Page load 1,82s (1,78, 1,85) 1,27s (1,24, 1,30) Render start 1,32s (1,27, 1,37) 1,26s (1,23, 1,29) DOM load N/A 1,03s (1,01, 1,06) HTTP load 1,80s (1,76, 1,84) 1,27s (1,23, 1,30)

55 APPENDIX B. COMPLETE RESULTS

B.2 CSS Sprites

B.2.1 tre.se Empty Cache Event Internet Explorer 8 Firefox 3.6 Page load 4,16s (3,94, 4,37) 3,75s (3,60, 3,90) Render start 2,07s (2,03, 2,11) 2,06s (2,03, 2,09) DOM load N/A 2,42s (2,13, 2,71) HTTP load 4,13s (3,93, 4,34) 3,72s (3,57, 3,86)

Primed Cache Event Internet Explorer 8 Firefox 3.6 Page load 1,74s (1,67, 1,81) 1,07s (1,05, 1,09) Render start 0,79s (0,77, 0,81) 1,05s (1,04, 1,06) DOM load N/A 0,75s (0,74, 0,76) HTTP load 1,78s (1,72, 1,83) 1,05s (1,04, 1,06)

B.2.2 3.dk Empty Cache Event Internet Explorer 8 Firefox 3.6 Page load 3,92s (3,69, 4,14) 5,59s (5,07, 6,12) Render start 2,82s (2,57, 3,06) 2,74s (2,46, 3,02) DOM load N/A 3,55s (3,34, 3,76) HTTP load 4,55s (4,31, 4,80) 5,58s (5,05, 6,11)

Primed Cache Event Internet Explorer 8 Firefox 3.6 Page load 1,31s (1,24, 1,39) 2,98s (2,82, 3,13) Render start 0,83s (0,69, 0,98) 0,91s (0,90, 0,93) DOM load N/A 1,17s (1,12, 1,22) HTTP load 2,44s (1,55, 3,34) 2,97s (2,81, 3,12)

B.2.3 ncc.se Empty Cache Event Internet Explorer 8 Firefox 3.6 Page load 7,15s (6,98, 7,33) 7,18s (7,03, 7,33) Render start 3,86s (3,74, 3,98) 4,57s (4,29, 4,86) DOM load N/A 5,41s (5,31, 5,50) HTTP load 7,15s (6,97, 7,33) 7,63s (7,63, 7,96)

56 B.2. CSS SPRITES

Primed Cache Event Internet Explorer 8 Firefox 3.6 Page load 1,43s (1,39, 1,48) 1,16s (1,14, 1,19) Render start 0,75s (0,71, 0,79) 1,15s (1,13, 1,18) DOM load N/A 1,05s (1,03, 1,08) HTTP load 1,49s (1,42, 1,55) 1,69s (1,66, 1,72)

B.2.4 svenskaturistforeningen.se

Empty Cache

Event Internet Explorer 8 Firefox 3.6 Page load 5,86s (5,61, 6,11) 5,15s (4,97, 5,33) Render start 2,78s (2,56, 3,01) 3,21s (2,94, 3,48) DOM load N/A 3,21s (2,94, 3,48) HTTP load 5,89s (5,66, 6,13) 5,44s (5,26, 5,62)

Primed Cache Event Internet Explorer 8 Firefox 3.6 Page load 2,47s (2,39, 2,55) 1,96s (1,95, 1,97) Render start 1,02s (0,96, 1,08) 1,66s (1,62, 1,70) DOM load N/A 1,73s (1,72, 1,74) HTTP load 2,68s (2,59, 2,77) 2,31s (2,26, 2,37)

B.2.5 vasakronan.se

Empty Cache

Event Internet Explorer 8 Firefox 3.6 Page load 5,85s (5,50, 6,21) 5,53s (5,10, 5,95) Render start 3,38s (3,04, 3,71) 3,69s (3,44, 3,94) DOM load N/A 3,54s (3,29, 3,79) HTTP load 5,82s (5,47, 6,18) 5,50s (5,06, 5,93)

Primed Cache Event Internet Explorer 8 Firefox 3.6 Page load 1,47s (1,44, 1,49) 1,16s (1,15, 1,17) Render start 1,30s (1,26, 1,34) 1,15s (1,14, 1,16) DOM load N/A 0,96s (0,95, 0,97) HTTP load 1,44s (1,41, 1,47) 1,16s (1,15, 1,17)

57 APPENDIX B. COMPLETE RESULTS

B.3 Combining scripts and style sheets

B.3.1 tre.se Empty Cache Event Internet Explorer 8 Firefox 3.6 Page load 3,75s (3,69, 3,81) 3,46s (3,39, 3,53) Render start 2,01s (1,99, 2,03) 2,07s (2,05, 2,09) DOM load N/A 2,35s (2,21, 2,49) HTTP load 3,80s (3,74, 3,85) 3,44s (3,37, 3,52)

Primed Cache Event Internet Explorer 8 Firefox 3.6 Page load 1,75s (1,70, 1,80) 0,99s (0,97, 1,01) Render start 0,68s (0,66, 0,71) 0,96s (0,95, 0,97) DOM load N/A 0,70s (0,69, 0,71) HTTP load 1,80s (1,75, 1,84) 0,97s (0,96, 0,98)

B.3.2 3.dk Empty Cache Event Internet Explorer 8 Firefox 3.6 Page load 5,66s (5,08, 6,23) 6,26s (5,82, 6,71) Render start 3,86s (3,53, 4,20) 3,64s (3,33, 3,96) DOM load N/A 4,42s (4,18, 4,67) HTTP load 6,09s (5,42, 6,76) 6,51s (6,07, 6,96)

Primed Cache Event Internet Explorer 8 Firefox 3.6 Page load 2,03s (1,64, 2,43) 2,93s (2,82, 3,05) Render start 0,75s (0,66, 0,85) 0,95s (0,94, 0,96) DOM load N/A 1,29s (1,24, 1,34) HTTP load 2,11s (1,75, 2,44) 3,18s (3,07, 3,30)

B.3.3 ncc.se Empty Cache Event Internet Explorer 8 Firefox 3.6 Page load 7,31s (7,03, 7,60) 7,60s (7,44, 7,76) Render start 3,80s (3,59, 4,01) 5,21s (4,79, 5,63) DOM load N/A 5,75s (5,62, 5,89) HTTP load 7,35s (7,07, 7,61) 8,21s (8,02, 8,39)

58 B.3. COMBINING SCRIPTS AND STYLE SHEETS

Primed Cache Event Internet Explorer 8 Firefox 3.6 Page load 1,37s (1,34, 1,41) 1,15s (1,14, 1,17) Render start 0,69s (0,67, 0,71) 1,14s (1,13, 1,16) DOM load N/A 1,00s (0,99, 1,01) HTTP load 1,53s (1,49, 1,57) 1,68s (1,66, 1,70)

B.3.4 svenskaturistforeningen.se

Empty Cache

Event Internet Explorer 8 Firefox 3.6 Page load 4,92s (4,66, 5,17) 4,82s (4,50, 5,15) Render start 2,49s (2,25, 2,72) 2,87s (2,55, 3,18) DOM load N/A 2,88s (2,56, 3,20) HTTP load 4,98s (4,73, 5,22) 5,11s (4,78, 5,43)

Primed Cache Event Internet Explorer 8 Firefox 3.6 Page load 2,21s (2,17, 2,25) 1,31s (1,28, 1,34) Render start 0,80s (0,75, 0,85) 0,93s (0,89, 0,98) DOM load N/A 1,02s (0,98, 1,03) HTTP load 2,50s (2,36, 2,65) 1,61s (1,54, 1,68)

B.3.5 vasakronan.se

Empty Cache

Event Internet Explorer 8 Firefox 3.6 Page load 5,23s (4,97, 5,49) 5,08s (4,83, 5,33) Render start 3,01s (2,93, 3,10) 3,31s (3,15, 3,47) DOM load N/A 3,33s (3,07, 3,59) HTTP load 5,21s (4,95, 5,46) 5,07s (4,82, 5,32)

Primed Cache Event Internet Explorer 8 Firefox 3.6 Page load 1,49s (1,47, 1,52) 1,08s (1,05, 1,12) Render start 0,91s (0,87, 0,96) 1,08s (1,04, 1,11) DOM load N/A 0,90s (0,87, 0,93) HTTP load 1,48s (1,45, 1,51) 1,08s (1,05, 1,12)

59 APPENDIX B. COMPLETE RESULTS

B.4 Use a Cache-Control or Expires header

B.4.1 tre.se Empty Cache Event Internet Explorer 8 Firefox 3.6 Page load 3,85s (3,77, 3,92) 3,44s (3,37, 3,50) Render start 2,07s (2,04, 2,09) 2,06s (2,03, 2,08) DOM load N/A 2,34s (2,24, 2,44) HTTP load 3,89s (3,81, 3,97) 3,42s (3,35, 3,48)

Primed Cache Event Internet Explorer 8 Firefox 3.6 Page load 1,04s (1,02, 1,06) 1,26s (1,23, 1,28) Render start 0,57s (0,53, 0,60) 1,21s (1,20, 1,22) DOM load N/A 0,97s (0,96, 0,98) HTTP load 1,09s (1,07, 1,11) 1,23s (1,22, 1,24)

B.4.2 3.dk Empty Cache Event Internet Explorer 8 Firefox 3.6 Page load 4,57s (4,16, 4,97) 5,91s (4,99, 6,82) Render start 2,77s (2,50, 3,04) 2,81s (2,46, 3,16) DOM load N/A 3,52s (3,16, 3,87) HTTP load 4,91s (4,49, 5,33) 6,17s (5,26, 7,08)

Primed Cache Event Internet Explorer 8 Firefox 3.6 Page load 0,90s (0,73, 1,06) 3,25s (2,86, 3,64) Render start 0,56s (0,45, 0,67) 1,15s (1,14, 1,16) DOM load N/A 1,37s (1,32, 1,42) HTTP load 1,72s (1,52, 1,92) 3,52s (3,13, 3,91)

B.4.3 ncc.se Empty Cache Event Internet Explorer 8 Firefox 3.6 Page load 6,93s (6,83, 7,03) 7,25s (7,09, 7,40) Render start 3,53s (3,37, 3,69) 4,91s (4,50, 5,33) DOM load N/A 5,49s (5,35, 5,63) HTTP load 6,93s (6,83, 7,03) 7,82s (7,67, 7,98)

60 B.4. USE A CACHE-CONTROL OR EXPIRES HEADER

Primed Cache Event Internet Explorer 8 Firefox 3.6 Page load 0,76s (0,72, 0,81) 1,30s (1,29, 1,31) Render start 0,72s (0,64, 0,80) 1,30s (1,29, 1,31) DOM load N/A 1,15s (1,14, 1,16) HTTP load 0,77s (0,73, 0,81) 1,85s (1,84, 1,86)

B.4.4 svenskaturistforeningen.se

Empty Cache

Event Internet Explorer 8 Firefox 3.6 Page load 5,17s (4,88, 5,46) 4,88s (4,54, 5,23) Render start 2,68s (2,44, 2,93) 3,24s (2,90, 3,57) DOM load N/A 3,27s (2,93, 3,60) HTTP load 5,22s (4,93, 5,51) 5,18s (4,83, 5,52)

Primed Cache Event Internet Explorer 8 Firefox 3.6 Page load 1,01s (0,97, 1,05) 1,83s (1,80, 1,86) Render start 0,85s (0,66, 1,03) 1,43s (1,41, 1,45) DOM load N/A 1,53s (1,50, 1,52) HTTP load 1,01s (0,97, 1,05) 2,12s (2,09, 2,15)

B.4.5 vasakronan.se

Empty Cache

Event Internet Explorer 8 Firefox 3.6 Page load 5,74s (5,28, 6,19) 5,19s (4,86, 5,53) Render start 3,16s (2,86, 3,45) 3,57s (3,19, 3,95) DOM load N/A 3,49s (3,10, 3,88) HTTP load 5,71s (5,25, 6,17) 5,18s (4,84, 5,52)

Primed Cache Event Internet Explorer 8 Firefox 3.6 Page load 0,88s (0,85, 0,92) 1,46s (1,44, 1,48) Render start 0,90s (0,88, 0,93) 1,45s (1,43, 1,47) DOM load N/A 1,22s (1,21, 1,23) HTTP load 0,87s (0,84, 0,90) 1,46s (1,44, 1,47)

61 APPENDIX B. COMPLETE RESULTS

B.5 Gzip Components

B.5.1 tre.se Empty Cache Event Internet Explorer 8 Firefox 3.6 Page load 2,82s (2,75, 2,88) 2,53s (2,51, 2,55) Render start 1,11s (1,08, 1,14) 1,32s (1,29, 1,34) DOM load N/A 1,53s (1,46, 1,59) HTTP load 2,86s (2,81, 2,92) 2,51s (2,49, 2,54)

Primed Cache Event Internet Explorer 8 Firefox 3.6 Page load 1,82s (1,77, 1,88) 1,08s (1,05, 1,10) Render start 0,83s (0,80, 0,85) 1,02s (1,01, 1,03) DOM load N/A 0,77s (0,76, 0,78) HTTP load 1,88s (1,83, 1,93) 1,04s (1,03, 1,05)

B.5.2 3.dk Empty Cache Event Internet Explorer 8 Firefox 3.6 Page load 2,70s (2,32, 3,07) 4,27s (3,76, 4,78) Render start 1,15s (1,10, 1,19) 1,51s (1,45, 1,58) DOM load N/A 2,46s (2,05, 2,87) HTTP load 2,79s (2,43, 3,14) 4,53s (4,02, 5,04)

Primed Cache Event Internet Explorer 8 Firefox 3.6 Page load 2,23s (1,72, 2,75) 3,07s (2,71, 3,43) Render start 0,85s (0,76, 0,94) 0,92s (0,91, 0,93) DOM load N/A 1,13s (1,08, 1,17) HTTP load 2,48s (1,99, 2,98) 3,32s (2,97, 3,68)

B.5.3 ncc.se Empty Cache Event Internet Explorer 8 Firefox 3.6 Page load 4,46s (4,29, 4,64) 3,90s (3,76, 4,03) Render start 1,83s (1,77, 1,88) 2,04s (1,98, 2,10) DOM load N/A 2,11s (2,06, 2,16) HTTP load 4,52s (4,32, 4,71) 4,66s (4,48, 4,85)

62 B.5. GZIP COMPONENTS

Primed Cache Event Internet Explorer 8 Firefox 3.6 Page load 1,49s (1,39, 1,59) 1,22s (1,07, 1,36) Render start 0,74s (0,67, 0,80) 1,14s (1,09, 1,19) DOM load N/A 1,06s (0,91, 1,22) HTTP load 1,53s (1,44, 1,63) 1,75s (1,60, 1,89)

B.5.4 svenskaturistforeningen.se

Empty Cache

Event Internet Explorer 8 Firefox 3.6 Page load 3,70s (3,52, 3,87) 3,76s (3,52, 4,00) Render start 1,18s (1,13, 1,22) 1,62s (1,50, 1,75) DOM load N/A 1,87s (1,48, 2,27) HTTP load 3,72s (3,56, 3,88) 4,12s (3,83, 4,41)

Primed Cache Event Internet Explorer 8 Firefox 3.6 Page load 2,47s (2,36, 2,59) 1,50s (1,49, 1,52) Render start 1,05s (1,01, 1,09) 1,22s (1,18, 1,25) DOM load N/A 1,26s (1,25, 1,27) HTTP load 2,60s (2,45, 2,76) 1,83s (1,81, 1,86)

B.5.5 vasakronan.se

Empty Cache

Event Internet Explorer 8 Firefox 3.6 Page load 3,75s (3,55, 3,96) 3,58s (3,41, 3,76) Render start 1,67s (1,61, 1,72) 2,14s (2,11, 2,18) DOM load N/A 1,90s (1,86, 1,93) HTTP load 3,73s (3,53, 3,93) 3,58s (3,41, 3,75)

Primed Cache Event Internet Explorer 8 Firefox 3.6 Page load 1,81s (1,72, 1,90) 1,24s (1,23, 1,25) Render start 1,36s (1,26, 1,46) 1,23s (1,22, 1,24) DOM load N/A 1,01s (0,99, 1,02) HTTP load 1,79s (1,70, 1,88) 1,24s (1,23, 1,25)

63 APPENDIX B. COMPLETE RESULTS

B.6 Minify JavaScript, CSS & HTML

B.6.1 tre.se Empty Cache Event Internet Explorer 8 Firefox 3.6 Page load 3,65s (3,60, 3,70) 3,28s (3,23, 3,34) Render start 1,90s (1,85, 1,95) 1,92s (1,89, 1,95) DOM load N/A 2,17s (2,07, 2,26) HTTP load 3,69s (3,65, 3,74) 3,26s (3,21, 3,32)

Primed Cache Event Internet Explorer 8 Firefox 3.6 Page load 1,86s (1,80, 1,92) 1,05s (1,03, 1,07) Render start 0,85s (0,80, 0,90) 1,03s (1,02, 1,04) DOM load N/A 0,76s (0,75, 0,77) HTTP load 1,91s (1,84, 1,98) 1,03s (1,02, 1,05)

B.6.2 3.dk Empty Cache Event Internet Explorer 8 Firefox 3.6 Page load 4,18s (3,64, 4,72) 5,04s (4,68, 5,40) Render start 2,43s (2,20, 2,67) 2,39s (2,12, 2,66) DOM load N/A 3,41s (3,03, 3,79) HTTP load 4,38s (3,92, 4,84) 5,30s (4,94, 5,66)

Primed Cache Event Internet Explorer 8 Firefox 3.6 Page load 1,78s (1,59, 1,98) 2,87s (2,47, 3,27) Render start 0,77s (0,70, 0,84) 0,91s (0,90, 0,92) DOM load N/A 1,10s (1,06, 1,14) HTTP load 2,07s (2,01, 2,13) 3,13s (2,74, 3,53)

B.6.3 ncc.se Empty Cache Event Internet Explorer 8 Firefox 3.6 Page load 7,09s (6,91, 7,28) 7,00s (6,88, 7,13) Render start 4,03s (3,74, 4,32) 4,71s (4,45, 4,97) DOM load N/A 5,20s (5,08, 5,33) HTTP load 7,08s (6,89, 7,27) 7,63s (7,48, 7,79)

64 B.6. MINIFY JAVASCRIPT, CSS & HTML

Primed Cache Event Internet Explorer 8 Firefox 3.6 Page load 1,48s (1,42, 1,55) 1,16s (1,14, 1,17) Render start 0,77s (0,74, 0,80) 1,15s (1,13, 1,16) DOM load N/A 1,05s (1,03, 1,06) HTTP load 1,55s (1,49, 1,60) 1,67s (1,66, 1,69)

B.6.4 svenskaturistforeningen.se

Empty Cache

Event Internet Explorer 8 Firefox 3.6 Page load 4,93s (4,69, 5,17) 4,90s (4,53, 5,28) Render start 2,47s (2,23, 2,70) 3,34s (3,08, 3,60) DOM load N/A 3,54s (3,15, 3,92) HTTP load 4,98s (4,75, 5,22) 5,21s (4,84, 5,59)

Primed Cache Event Internet Explorer 8 Firefox 3.6 Page load 2,43s (2,38, 2,48) 1,54s (1,53, 1,56) Render start 1,03s (1,00, 1,06) 1,24s (1,21, 1,28) DOM load N/A 1,29s (1,28, 1,30) HTTP load 2,64s (2,58, 2,70) 1,92s (1,88, 1,95)

B.6.5 vasakronan.se

Empty Cache

Event Internet Explorer 8 Firefox 3.6 Page load 5,79s (5,41, 6,17) 4,80s (4,61, 5,00) Render start 3,46s (3,28, 3,65) 3,21s (2,96, 3,47) DOM load N/A 3,12s (2,83, 3,41) HTTP load 5,76s (5,38, 6,14) 4,80s (4,60, 4,99)

Primed Cache Event Internet Explorer 8 Firefox 3.6 Page load 1,79s (1,75, 1,82) 1,22s (1,21, 1,23) Render start 1,29s (1,26, 1,33) 1,22s (2,21, 2,23) DOM load N/A 0,99s (0,98, 1,00) HTTP load 1,77s (1,74, 1,80) 1,22s (1,21, 1,23)

65 APPENDIX B. COMPLETE RESULTS

B.7 Use cookie free domains when serving static content

B.7.1 tre.se Empty Cache Event Internet Explorer 8 Firefox 3.6 Page load 4,80s (4,50, 5,10) 4,39s (4,04, 4,74) Render start 2,90s (2,63, 3,17) 2,96s (2,62, 3,30) DOM load N/A 3,23s (2,86, 3,60) HTTP load 4,85s (4,55, 5,15) 4,38s (4,03, 4,73)

Primed Cache Event Internet Explorer 8 Firefox 3.6 Page load 1,88s (1,83, 1,93) 1,07s (1,04, 1,09) Render start 0,90s (0,87, 0,92) 1,02s (1,01, 1,03) DOM load N/A 0,75s (0,75, 0,76) HTTP load 1,93s (1,87, 1,98) 1,04s (1,03, 1,06)

B.7.2 3.dk Empty Cache Event Internet Explorer 8 Firefox 3.6 Page load 4,42s (4,14, 4,71) 5,16s (4,85, 5,48) Render start 2,69s (2,47, 2,90) 2,90s (2,59, 3,20) DOM load N/A 3,39s (3,08, 3,69) HTTP load 4,76s (4,45, 5,06) 5,43s (5,11, 5,74)

Primed Cache Event Internet Explorer 8 Firefox 3.6 Page load 1,65s (1,39, 1,92) 2,93s (2,77, 3,09) Render start 0,85s (0,80, 0,90) 0,98s (0,97, 1,00) DOM load N/A 1,22s (1,18, 1,26) HTTP load 2,70s (2,45, 2,95) 3,18s (3,02, 3,34)

B.7.3 ncc.se Empty Cache Event Internet Explorer 8 Firefox 3.6 Page load 5,30s (5,03, 5,58) 5,23s (4,91, 5,54) Render start 3,31s (3,12, 3,51) 3,84s (3,63, 4,05) DOM load N/A 3,84s (3,65, 4,03) HTTP load 5,35s (5,07, 5,64) 5,79s (5,48, 6,11)

66 B.7. USE COOKIE FREE DOMAINS WHEN SERVING STATIC CONTENT

Primed Cache Event Internet Explorer 8 Firefox 3.6 Page load 1,53s (1,50, 1,56) 1,17s (1,13, 1,21) Render start 0,82s (0,79, 0,85) 1,16s (1,12, 1,20) DOM load N/A 1,07s (1,03, 1,11) HTTP load 1,58s (1,54, 1,61) 1,70s (1,65, 1,74)

B.7.4 svenskaturistforeningen.se Empty Cache Event Internet Explorer 8 Firefox 3.6 Page load 4,92s (4,66, 5,18) 4,76s (4,47, 5,06) Render start 2,43s (2,19, 2,68) 3,06s (2,74, 3,37) DOM load N/A 3,08s (2,76, 3,39) HTTP load 5,10s (4,80, 5,39) 5,05s (4,75, 5,35)

Primed Cache Event Internet Explorer 8 Firefox 3.6 Page load 2,48s (2,43, 2,53) 1,46s (1,44, 1,48) Render start 1,07s (1,03, 1,10) 1,17s (1,13, 1,22) DOM load N/A 1,23s (1,21, 1,24) HTTP load 2,86s (2,75, 2,96) 1,74s (1,73, 1,76)

B.7.5 vasakronan.se Empty Cache Event Internet Explorer 8 Firefox 3.6 Page load 5,22s (4,90, 5,53) 5,39s (4,99, 5,79) Render start 3,13s (2,89, 3,38) 3,93s (3,49, 4,36) DOM load N/A 3,94s (3,47, 4,40) HTTP load 5,19s (4,88, 5,51) 5,38s (4,99, 5,78)

Primed Cache Event Internet Explorer 8 Firefox 3.6 Page load 1,81s (1,78, 1,83) 1,30s (1,18, 1,42) Render start 1,33s (1,30, 1,35) 1,25s (1,22, 1,28) DOM load N/A 1,03s (1,00, 1,06) HTTP load 1,79s (1,76, 1,81) 1,30s (1,18, 1,42)

67