Geek Speak Decoded

Factors Influencing Page Speed (How Web Pages are Downloaded, and How to Improve Speed)

How Web Pages Are Downloaded

In order to understand and join discussions around web page performance, i’ts important to have a basic understanding of how a web page is downloaded and drawn in a web browser application like Internet explorer, Firefox, Chrome, etc. It’s not a complex process, but there are many repetitive steps – and each of these steps has an opportunity for download and drawing time improvement.

When you point a web browser at a website by clicking on a link, or typing in a URL to your favorite web browser, you initiate a complex multi-step process. A web page is assembled from at least four (4) different types of information formats, and each of these four types of information will be split across many individual files (there are more, but these are the major ones). For example, to build a popular websites home page, eighty-one (81) different files are downloaded and assembled by the browser application; Image files containing the pictures and icons on the screen, files containing the text and layout instructions of the screen (for example, HTML, aspx, jsp, or php), files containing the font, colors and position of elements on the screen (CSS files),  files containing the code to execute when the page downloads (Javascript files), are the main information file types that make up common pages, but there are often more. Having fewer files is an obvious win, Google use this approach – notice the lack of images on their pages.

To describe the page download process step by step, one initial call to the server is carried out to get the page code, this is in a language called HTML and contains all of the instructions to the web browser on how to draw a page. Once received, the browser interprets this file and requests all of the other files required – some in parallel, some one after the other. The web page actually starts appearing after the HTML file is analyzed, and some of the necessary files are downloaded – not every file is needed for the user to begin reading and clicking on that page. Smart companies pay close attention to the order files are coded into the HTML file, so that the web browser can get the earliest start. Figure 1  shows a very simplistic page download process, from getting the main page content HTML file, to retrieving all of the other resource files required to draw the complete page. When the user first sees and can interact with the page is indicated by the upside-down triangle at the top right of the time line – its somewhere after the main page HTML is retrieved, and sometime before all of the resource files are downloaded (you will see our job is to not only get the complete page downloaded faster, but also to make the page appear usable in the window the customer can see as early as possible). Figure 1 also contains a pie-chart of an example mix of file types and their size downloaded for a common website.

 

 

In the early days of the Internet, back in the 1990′s, pages were very simple and mostly text based. This allowed most of the page to be contained in the initial HTML file (average 80% text, 20% graphic in the early days). This is most definitely not the way pages are built today. Pages today have many graphic elements, and a lot of embedded code (written in a language the web browsers can interpret and run client side), reversing the percentages into 20% of the page being text, and 80% other resources. Now pages are hundreds of times bigger in file size, and download an average of forty support files to draw their final rendition.

There are multiple “taxes” paid in speed when downloading each file required for a page rendition. One for the amount of data transferred based on the file sizes being sent and the client’s connection to the Internet. And the second tax is the overhead of requesting a separate file, and the logistics of setting up a connection between two servers across the Internet. Combine these two Internet taxes and we have the two main components that drive sluggish page download performance. A third tax that is smaller, but becoming more prevalent is the time taken to interpret and draw the page in the browser window. With the increase in complex styling, and the process of interpreting the Javascript code that allows interactive behavior to apply in the web browser without coming back to the server, is emerging as a factor to be considered (but only after  minimizing the size and number of files to download).

Understanding basic construction of a request to a page being displayed in the users’ browser is the first step to understanding why pages perform poorly. The only guaranteed ways to reduce page speed that we can draw at the moment are -

• Fewer images and support files to download means a faster page (Google take this to an extreme)
• Smaller images means a faster page (do we really need a full resolution image?, and yes, these third party Flash banner adverts are huge)
• Fewer calls to third party analytics or advertising platforms means a faster page

Factors Influencing Page-Speed

Diving into more detail on factors influencing web page download speed from an end customer perspective, we need to categorize some of the more important ones. The following short list is what I’ll cover in this section -

1. Customer geography (with respect to where the servers are located) – Some countries and regions are less adorned with Internet access speed around the world. Where your servers are located, and where the customers request a page will impact web-page speed.
2. Server side execution time- Some pages require a lot more work to build than others. If the content on the page is static (doesn’t need to be computed), or dynamic (build per request), different page speed goals need to be considered. Server side code often makes calls to databases, or even call other companies web services, and these computations and transmission costs take time.
3. Resource transfer time - The main response from your server describing the page contains links and instructions on what else is required to render the page. Images, videos, and code to be executed in the web browser itself need to be obtained. This is often the majority of the time, and not all of it is required for the page to be usable.
4. Client side speed and rendering time - Once the resources have been downloaded (or at the same time in most cases), the web browser starts to build the final page layout on the customers screen. This involves interpreting the main page’s instructions, executing any code in the browser that is required, and putting text and images in the right location, using the right typeface, color and size. As pages get more interactive and complex this becomes more important to optimize. Every brand (and version of brand) of browser does this slightly differently, so it is important to profile all of the major ones.
5. Third party content – Advertising banners, and analytic tracking beacons have emerged as an area causing page speed degradation beyond acceptable limits. In most cases, this is peripheral content, and should be organized in a way to load after the main customer useful page content.

Customer Geography

Understanding how pages are built should make this constraint self-evident. The further the end-customer is from the servers hosting a web page, the larger the transmission losses, and the longer the setup time and transmission time for data across the network channel. Customer geography impact is determined first by the connectivity into the Internet backbone for the country the user is in, and then the connectivity that customer has to their local Internet Service Provider (ISP) and telecommunications provider.

Some countries have good connectivity to the global Internet backbone, but data flowing around the world still has an upper limit of being sent at the speed of light – fast, but this adds up given that if your servers are in North America, but the customer is in London. Underwater cables form the basis of most Internet traffic transfer between countries, and due to geography, some countries get a better connection into North America than others. North America is the hub of most connectivity owing to the way the Internet rolled-out,and  is still the epicenter and hub of most connectivity to other nations or traffic. This isn’t to say always put your servers in North America alone. Positioning your servers closer to the majority of your customers is obviously faster than hosting in another country, but this isn’t always convenient or cost efficient. In an ideal world, putting a data-center next to each major customer population is best, but if you have to have one, put it in the USA for North American traffic, Japan for an Asian hub, or UK for Europe to be closest to the main communication cable landing locations. The rationale is that there is most bandwidth into and out of these locations because a lot of traffic moves past these locations (the downfall is that a lot of traffic moves past these locations, but I’m hoping that commercial pressures means that these locations keep up with demand). To understand the Internet bandwidth connections between countries, visit the Telegeography.com website and view their maps indicating underwater cables and connectivity between regions.

 

 

The second inter-country factor and the last mile to your customer are much harder to predict. However, in China for instance, there is poor connectivity between the North of the country and the South – and its factors like this that you need to research if a country has a particular density of customers in your case. In general – if a customer has poor Internet connectivity, they will have a poorer experience. If your customer population is in the developing world (communication wise, with poor or expensive high-speed Internet access to the general population), then you need to work extra hard to reduce the bandwidth used to send supporting resource files, and to send fewer files in general. If your website is highly graphically rich with video and complex pictures, then launching into Internet connectivity poor countries will require a website redesign – or local country hosting.

Some vendors offer servers in many countries to host the images and scripts on a server physically in-country to the requesting customer. When a customer asks for a web-page by name, the first part of that string, the www.google.com gets converted to a set of numbers called an IP address, this IP address is what is used to open a connection between the customer browser and your servers. This look-up conversion from friendly name to number sequence is performed by what is called Domain Name Servers (DNS). The service offered by some vendors is to is host your domain name (normally just for these assets), and return to the customer a server physically closer to them, whilst letting your original servers in your home territory keep the master copy and serve the basic page information. This is called a Content Data Network (CDN). This avoids you having to cover the costs of having your own servers in-country for the dynamic parts of the page, whilst reaping the benefit for the larger number of elements requested by the customer’s browser. The major players in ths market are Akamai, and Limelight Networks, although many new players are entering the market (Amazon Cloudfront and Microsoft Azure CDN to name a couple of the smaller ones). Figure 3 shows the basic concept of a CDN; the main content comes from your origin server wherever that may be, and after the first ever request from a customer in a particular region (depending on your CDN vendor), that content is servers from in-country closer to the customer from that time forward.

 

 

Server side execution time

The customer will see a blank screen until their browser gets the main HTML file, and it goes without saying that this should be as short as possible. Some web pages need substantial server side computing power to build the data they need to send to the customer. A common example is when you need to do real-time price or availability calls on third-party service providers. For example, if your website allowed people to book air tickets, you might need to call a third party service to get itineraries for the customers request. This can take many seconds, and in looking at some popular booking sites five (5) to twenty (20) seconds to even get initial results. Leaving the customer unsure what is happening viewing a white screen is a sure way to have them bail on your website.

My rule here is that if the server side computations will jeopardize the two-second rule of giving acknowledgment to the customer, then I redirect through a status page first to give the user clear feedback that the click registered, and that data is being gathered to give them valuable information in a few more moments. Clever use of new patterns involving using the client-side programming language to request and build a page in parts (called AJAX), is the newer way to achieve this purpose – any kind of fake it until you make it strategy serves the purpose. The actual patterns for achieving this user experience vary, and I’ll cover those in a later more detailed technical post [add cross reference link here when its written]. For now, it’s just important to make it clear that long-server side requests do occur, sometimes beyond your development teams ability to tune further – and if these requests might cause the customer to see a blank white screen for longer than two (2) seconds, address the issue with a progress page, or load the logo, borders and template for the page first, then download and draw the content progressively.

Optimizing the server side calls for these length computationally, or third-party content pages is important. Some common practices if you are dependent on a third-party data source (or your own, but outside of your web development teams immediate control to speed up), is to store a local copy of that data for your web servers to call on subsequent requests for identical data. For example, if a page returns the weather for Seattle, Washington – making a third-party call to another website for the seven day forecast more than a few times an hour is redundant. Instead, consider storing the returned result in a local database using the call parameters required to make it unique, and when subsequent calls to your site ask for the Seattle, WA weather, avoid the lengthy third party call and retrieve it locally from disk. The coding pattern goes something like this – 1. Do we have a local copy that is less than x minutes old? If so, return that local copy, 2. If we don’t have a local copy, retrieve the data externally and save a local copy of it timestamped, and with a unique identifier (normally by joining together the elements that make this call unique, for example ‘SEATTLE-WA-USA’). This issues to solve are how long until the data in the local storage cache becomes out of date, and this varies depending on your data. Figure 4 shows the most basic server side content caching to improve end customer response. The downside of all caching is that the data get stale and might cause incorrect data to be shown to the customer. Setting the expiry rules, reducing the caching refresh time, and making sure the correct set of parameters control whether a cached data is the same as required from the user’s requirements need to be carefully considered.

 

 

Resource transfer time

Resource transfer time offers the largest opportunity for speeding up customer experience. Banner advertising and complex graphics take time to download, so the first obvious choice is to reduce that clutter (or balance versus how much revenue they generate). Fewer images and eye-candy is the clearest way, and Google make an art-form of minimalist page clutter. In fact, when they had to put a link on the home page to their privacy policy, it is reported that the CEO made them find another word to remove (they change ‘Copyright (c) 2010′ to just ‘(c) 2010′). I’m not saying that is the best choice for other sites, but if there is opportunity to reduce the design aspects of the page to contain fewer images, then you should. Making the images the lowest resolution as possible without losing clarity, avoiding background images (that aren’t smaller images tiled) are some other easy strategies to keep pages lighter.

Size is one aspect of resource transfer time, the other aspect is the number of requests for files. When making data transfers across the Internet, it is faster to make a single call for a 10,000 byte file rather than ten calls for 1,000 byte files separately. There is setup time for each call, and this adds up, especially when the country of origin isn’t near the customer. There are numerous techniques your developers can employ – combining many files into one larger file for images (this is a process called ‘Spriting’, the webpage needs to know how to pull the right tile out of the larger-image to get the smaller images), style-sheets and the client side Javascript language files. This is a best practice, but often not performed because it is difficult for the developers to keep track of where individual resources are located when editing and making changes. One way around this is to have the servers do this step automatically when publishing changes, or to have a server do this transparently on your behalf on-the-fly (this is an emerging area – Strangeloop Networks, Aptimize, are example companies with tools for this).

We previously covered using an external Content Data Network ( CDN) to store these static resources closer to the end customer when dealing with overseas calls. CDN do offer other benefits for local customers as well, because the vendor hosting the CDN content likely has servers on each coast near major population centers – improving response that little bit extra. In addition, it was traditional that web-browsers like Internet Explorer would only make five or ten parallel calls to the same domain name; If all the images are hosted on the same server, they share the same domain prefix (the google.com, or yourcompany.com part), but having some of this content on another domain increases the ability for the web-browser to do more calls concurrently. When you get to this level of change though, you are talking small parts of a second reduction in call time.

Client speed and rendering time

When a page and its other support files are downloaded, the web-browser needs to assemble, layout and draw the page. For all but the most graphic intensive website, this time is minimal. In the coming years, this might become a bigger issue as more native HTML is used for animation and advertising, and the use of Flash (a particular graphic file format that supports animation and complex interaction). Flash bases graphics was once the major tool for graphic intensive websites, but some companies (I’m thinking Apple here, and Google to some degree) have been forcing a more open-standard approach in the native language of the web-browsers. This change will mean that in the future spending extra time improving performance of this code might be needed.

It’s unlikely your pages suffers from rendering time issues at the moment, but when it does your first indication will be that some web-browser versions have more trouble than others. You should see that shopper conversion percentage might be lower from one browser version to another, and this is the only time you need to invest in this area. Web browser drawing speed and Javascript execution speed is a constant battle amongst the major vendors – Microsoft with Internet Explorer, Mozilla with Firefox, Google with Chrome, and Apple with Safari. These vendors jostle and improve rendering and execution speed with each release. At the moment, the browsers likely to have issues will be those two versions behind current – Internet Explorer 6, and Internet Explorer 7, and Firefox 2. Unless you have significant customers on these browsers – spend optimization time elsewhere (and put an upgrade your browser banner on your site to help customers upgrade to a more secure and performance web experience).

Third Party Content

A recent trend when analyzing pages my teams have been hunting for performance improvements has been the influence of third party content. Most companies don’t host their own banner advertisements, or analytics software. These parts of the page are included by calls to another vendor’s website, and problems arise when they block the main page content from being seen first.

This content should be added in a way that they download and show last, and in a way that doesn’t bump the other content around when a customer is reading that content. Work with your technical team to pick fewer vendors to handle analytic tracking and advertising positions with a few key vendors.

Questions to ask you technical team about web page performance

1. Do we have our servers in a geography closest to our customers?
2. Are we using a Content Data Network (CDN) for static resources like images and support files?
3. Can we reduce the number of images or reduce the resolution of the images smaller?
4. Can we reduce the number of Javascript, and CSS files by simplifying our design or compressing and combining these files?
5. Can we use server caching of external content to reduce response time?

Webpage Performance

I often hear comparisons of  a certain website’s speed versus competitors, apparently the entire fate of the company is website speed dependent. There is evidence that poor page speed decreases visitor conversion (the amount of visitors who shop, versus buy), but page speed isn’t the only factor influencing customer conversion and investing in page speed improvement has to be balanced against other potential revenue increasing work (adding new features for example), and holding up a release looking for an extra few milliseconds may not be the best use of the development team’s time.

Some search engines, Google for instance, have publicly stated that they will use page download speed as one element in determining page rank (although it will likely be after relevance has been established, and used as a tie-breaker), so as well as better customer conversion, potentially a better Google ranking is a benefit of spending some investment in web-page performance. Google hasn’t disclosed (and is unlikely ever to disclose) how much influence this factor has in its ranking equation – but it has some, and shouldn’t be left unchecked.

How Long is Too Long?

The controversial aspect to page speed discussions, is how long is too long. Some definitions might be -

• Longer than the users’ expectation

–Too long an impatient user leaves the site
–Too long an average user leaves the site

• Too long that it has a measurable impact on conversion
• Too long that it becomes a factor in search engine ranking
• Longer than the competition

These are all valid, but still mostly subjective (longer than the competition isn’t a constant and changes over time). It’s important that clear goals be set for proper effort to be allocated by the design and development team (covered shortly). The most logical discussion I’ve seen of this topic links customer behavior to the amount of time they have to decide if the content is enticing enough to stay a little longer. Here is the discussion -

“My rule of thumb is that you have 7 seconds to sell a prospect that they have reached a page of interest to them. You don’t have to make a sale in 7 seconds, you just have 7 seconds to keep them for a while longer.

If your initial page takes 6 seconds to load, you have 1 second of selling time. If your initial page takes 1 second or less to load you have 6-7 seconds of selling time. Therefore to maximize sales you should give yourself maximum selling time. That means pages that load as fast as possible.”

Source: http://www.webmasterworld.com/forum116/41.htm

I think there is merit to this approach; I go a little further and set goals for initial confirmation (I heard you, I’m thinking, stop hitting F5 to refresh the browser), and then getting compelling data on the screen for the user to interact before the seven second clock goes off (my longest target is four (4) seconds, giving me three (3) seconds sell time).

Setting Clear Goals

Many target page load speed numbers floating around the Internet, two (2) seconds, four (4) seconds, seven (7) seconds. Google has set the pace, and when they launched their performance was so dramatically better than the competition that they become the defacto search engine overnight; Now a multi-billion dollar success story. Considering they can return ranked results for topics requested across hundreds of million (conservatively) almost instantly is amazing, but it does make the rest of us look bad! Try and not infuriate your technical team by comparing to Google – they have a few more resources and designed from the ground-up with up-most performance in mind.

It is vital that page speed goals be defined before the tech team starts developing. The decisions they make designing an approach will change dramatically based on these goals, and retrofitting optimizations at the end of the project is technically difficult and often delays projects. Without clear performance goals, technical staff may spend too much time in some areas, and not enough in others (like releasing and testing). Its important to prioritize the pages that need to be improved, and to make sure that these pages hit their target and stay that way over time. But, what is the best way to communicate these goals? Setting unrealistic goals is unwise – correct results must come before speed – make this point very clear.

Here are some suggestions to start the conversation with your teams -

Report cards – Having a consistent way to determine how a page rates, and if there is room to be improved is by using one of the online page speed checks. Make sure your staff have a way to measure page speed, and that they understand what is acceptable. One popular free tool is Webpagetest.org, which is an online website that gives you the ability to check for common coding errors (or improvements that might be made to improve performance), and the ability to measure response time from many different geographic locations. This website scored 90/100 which is quite good (see blow); anything below a ‘C’ rating or a total score less than 75 should be looked at urgently. Google also has page speed testing tools, that allow testing to be carried out within the Firefox browser.

Demonstrating progress quickly (the two second rule) - One goal to ask your tech staff to focus on is to quickly show a click has been accepted, and work is ongoing within two (2) seconds. Beyond this time it is likely that the customer is going to not realize a click event has been registered – either hitting again repeatedly, or just leaving your site thinking it has frozen. Your options here are to show an interstitial page (a progress page) and then redirect to the results. Alternatively, get the next page loaded with some content within the first two (2) seconds – then let the rest of the page download quickly after that. It is the acknowledgment ‘I heard you’, and then ‘I’m making progress’ perception that shape the user perception of speed.

Above the fold first (within four seconds – the four second rule); Progressive building the rest – Most pages are bigger than the window the customer is browsing. Putting the content in the portion the user can see (above the fold) is the highest priority. Make sure the technical staff focuses on getting content at the top most likely visible section of the page first. When you look at pages on your own website, mention to the developers when you see opportunities to get page content candy on the screen early for the user to read and comprehend whilst the remaining parts of the page download off screen.

Total download time – total download time is often the measurement quoted and compared, however, if the two second feedback rule, and the four second above the fold rule are followed, customer impact is likely to be low. Setting a clear goal on total download time is difficult and not likely to improve customer conversion. My suggestion is to set an upper limit, and re-enforce the point that after retrieving correct results, if a page takes longer than this – start brainstorming and trading off early. Avoid relying on tools that report total download time. It is likely that invisible third-party content, and banner advertising animations (large content sizes) will skew the results many seconds past when the page is perceived usable by the customer, and therefore not likely impacting conversion. Focus on the two second and four second rules!

This post has looked at the major factors influencing page speed, and the ways to determine if page speed is likely to cause major customer impact.

Questions you should ask your team about web-page performance are -

1. For our top x pages, do we regularly measure the page speed ratings of our website? Do we using webpagetest.org, or Google’s Page Speed tool?
2. For our top x pages, do we always give feedback within two (2) seconds?
3. For our top x pages, do we render above the fold within four (4) seconds?

In future posts we will discuss specific ways to measure page speed, and ways to improve page speed with specific coding patterns.