Airlines Fail At Web Site Performance - Quick Tips to Make Them Faster

Before you read any further I want to apologize up front to anyone who works on a major airline's web site because this article should hurt a lot. But honestly someone had to tell you and be direct and that person is me.

If you have attended one of my web performance talks over the past year you know I beat up on because it violates so many easy to fix web performance optimization issues. I mean I love the airline, I think it is the absolute best, but the web site drives me nuts far too often.

As I was waiting for a Texas Rangers, Seattle Mariners game to start the other night I decided to do some quick research at various airline web sites on They are all horrible! So I thought I would point out some very common issues I see everyday both on consumer and enterprise line of business applications. These issues are not limited to the airline industry, they are just plain common issues that are easily avoidable, but cost companies billions everyday.

I am not going to pick on every site I visited in this post, just a few that had some stand out issues. I visited 19 airline sites all together and they all suffer from these issues to one degree or another. I will post links to the analysis at the bottom for the other sites I tested. They can all benefit from making some basic changes I highlight here as well as several other issues I don't cover today.

Before I get into the issues let me quickly explain It is an online tool where you can enter a URL, select a client location, browser version and it will do a basic web performance evaluation. The URL must be publically available, so no behind the firewall apps for the online tool. It gives you a lot of valuable information like the time to first byte, or how long it takes for the first byte of the markup to hit the browser from your server to how long it takes for the full page to be completely loaded. Using this tool I can make some quick analysis and know where to dig a little deeper. scorecard

Do the Header in Pure HTML & CSS

I would consider this an intermediate change with some very measurable impact. The current header is a large image sprite, actually two when you count the rollover version for a combined size of 60kb. It is a good thing they created a single image sprite instead of a bunch of smaller images. This is a good trick from the old web, which is what the site is designed for. I think they updated the header about 4 years ago and at the time this was probably the best option. But things have changed quite a bit since then.

Today the majority of customers will use a modern browser that supports HTML5 and CSS3. The entire header can be completely redone using only markup, CSS and a glyph font like Font Awesome, Today CSS3 gives us rounded corners and shadows so the 3D like effects done in Photoshop can now be done in pure markup.

I wish I had time to put this together, maybe I will make another post showing how to do this soon. But doing this will eliminate at least 1 HTTP request and replace the other with a request for the font awesome font. If you are wondering what they should do when someone visits with an obsolete browser (IE 8 for example), detect it on the server and send them to the existing site (slow), built for older browsers and let everyone else have the better version.

Inline JavaScript

By my count I found a dozen inline SCRIPT tags on the home page. Just a quick trip through the site it seems those script blocks are repeated on every page. Inline scripts are bad for many reasons. They cannot be cached and the content is redownloaded each time a page is loaded, thus increasing the size of the page. In general you never want that many script blocks on a page, either inline or external, because they are a blocking event.

A blocking event is when the browser hits something it has to suspend all other operations. JavaScript causes the browser to halt everything it is doing so it can read a script, evaluate it and execute it before continuing. The primary cause is the use of document.write, a method that is more or less obsolete in the context of today's web. But because the browser cannot know if document.write is being used it needs to stop everything and assume the script will alter the DOM structure, forcing it to reevaluate the entire page again.

Document.write is the reason why scripts are blocking resources, here All Nipon is guilty

It looks like the Southwest web team is probably passing variables from the server to the client in many of these script blocks. This is a very common practice and I have been guilty of it in the past. But as I became more JavaScript savvy I realized I did not need to pass variables this way. There are many other ways to get values and configuration information to the client-side scripts. You can use hidden input fields or make an AJAX call to the server in most cases. This could eliminate most of these inline scripts in my opinion.

When should you use inline scripts? I am starting to warm to the idea of inlining scripts for single page apps. There are several techniques with this strategy. One where you set the script type to a non-script value so it will not be evaluated at load time and then change it via a bootloader technique. I am starting to do some research on this technique and see the benefits. However, for a traditional web site where new markup is loaded for each page, like, inlining is a very bad idea. scorecard

Gzip Resources

This is a very simple fix because it typically requires a quick change to the web server to auto compress static files like CSS and JavaScript. The performance improvement can be amazing because the bandwidth requirements will immediately go down, often at least half what they were before. It is a good idea to gzip the content once and cache that in the web server. IIS will do this for you if you turn on compression.

Document.write is the reason why scripts are blocking resources, here All Nipon is guilty

Looking at the waterfall you can see most of the site's text resources are simply not compressed. They do compress the three largest files, which is great, but it does not look like the remaining 49 scripts are compressed. There is a total of 414kb of juicy JavaScript being downloaded to the client. Compressing the 3 largest files makes the data reduce from 335kb to 208kb, a significant savings. Why not compress the balance?

FWIW 200+kb is the jQuery UI library, which in my experience can easily be replaced and is often included when it is never used in most sites. So honestly they should reconsider using it at all and replacing it with a more efficient micro library or just pure markup & CSS.

Combine JavaScript

Everyone needs to reduce the number of HTTP requests and American Airlines is no different. I picked them for this item because they have so many JavaScript files, many which are measured in bytes, not kilobytes. The site has 49, yes 49 JavaScript file requests. I am just blown away by that staggering number. Most of the files are only 1 or 2 kb in size. Combing these files will obviously reduce the number of HTTP requests, but it will drastically reduce the amount of bandwidth needed to download the scripts.

It looks like they are also victim of a third party twitter widget. Just glancing at the home page I don't see anything that would benefit from a twitter widget, but it sure does load the script files. They can probably completely eliminate those scripts. The remaining scripts that actually drive the site should be combined, into 1 file. This would eliminate 48 HTTP requests and keep the server's disk drive from thrashing, also reducing the number of servers needed!

In ASP.NET you can use the bundling and minification infrastructure, which is great. Personally I like to use GruntJS and the Uglify contrib extension. This will perform this operation and can easily be added as one of your build steps. GruntJS is a web build system that uses NodeJS to execute a wide variety of tasks based on your configuration. Visit the site to learn more about it, I highly recommend it.

USAir scorecard

Minimize Resources

The site only downloads 805kb of data, which is relatively good. Only 279kb is images, which in today's world is extremely commendable. That leaves 530kb as text, which could be minimized. Minification is the removal of unnecessary white space, like carriage returns. Basically minification removes characters needed to make the code readable by humans. Computers on the other hand do not care how the code is tab structured or new lines. It looks for semi-colons instead. Good scripts, CSS and honestly HTML has those characters removed, often reducing the file size 10-30%. It all adds up to a better user experience. And let's face it your customers don't really need to be poking around your code and most likely wont. Hackers, like me, also find it much hard to reverse engineer your site once minification is done because long human readable variable names are obfuscated to simple 1 or 2 character names. Just look at the minified version of jQuery as an example.

Document.write is the reason why scripts are blocking resources, here All Nipon is guilty

Again less data means faster load time. It also means your bandwidth bill will be lower. Also consider mobile visitors loading your site over a 3/4G connection. Data rates, while typically affordable are still much more expensive than a fixed line to your home or office. So don't make your customer spend more money downloading your home page than it costs to buy a product from you.

Virgin America (Now owned by Alaska Air) scorecard

Cache Static Content

Adding expires headers to static content is extremely important because it prevents the browser from requesting the file over and over every time the user loads the page or navigates to a new page that uses the same resources. Images, CSS and JavaScript files should have extremely long time to live Cache headers defined. By long time I mean at least a year.

If you are worried about your content not being updated when it changes, don't worry you can always append a version number in the query string. But in most cases the server will let the browser know with a 304 response code if the file is requested.

<script src="js/myapp.js?v=.02"/>

EasyJet scorecard

Combine Images

When I first looked at the waterfall chart I could not believe what I was seeing, 119 images. But more importantly I noticed they had tiny individual images for each country's flag in a drop-down selector. Scrolling further down the list I noticed tiny images for the numbers in the image slider.

All the flags can be combined into a single image and CSS sprites used to make the image display correctly. Another option is to use a data URI. Either way it will eliminate at least 17 image file requests.

Document.write is the reason why scripts are blocking resources, here All Nipon is guilty

Why is reducing HTTP requests important? The obvious first reason is it reduces the amount of data crossing the wire. Instead of 18 individual file packages being wrapped in HTTP packaging goodness there is only 1 box. Fewer requests also means the browser can use those parallel request opportunities to download other resources, faster now they do not need to wait.

But here is a big one, it reduces the number of times the web server needs to hit the disk. Disk I/O is very expensive and can really tie up your computer's CPU, use more energy, etc. It is actually not that hard to make a web server thrash because it needs to read and write from the disk too much.

Document.write is the reason why scripts are blocking resources, here All Nipon is guilty

As for the numbers in the hero slider, they can be completely replaced with HTML and CSS using rounded corners. Poof, 10 HTTP requests eliminated.

I also want to point out ANA, the Japanese airline, is probably worse. They have 90 images on the page and almost all of them can be replaced with CSS borders, gradients and good old fashion text. I reviewed every image on the site and feel pretty confident those 90 images can be reduced to a single, yes just 1 image. It would be a sprite containing about a dozen or so images, but yet just a single image in about the 300kb range, compared to 492kb spread over 90 HTTP requests.

Another thing I noticed is they are using ASP.NET Http Handlers to return images. I can't for the life of my think whey they would do this. I understand when you may want to avoid leechers from using images say on Craig's list or EBay, but flag icons and site promos? Using the Http Handler adds a lot of server-side overhead as it will invoke all the ASP.NET pipeline each time the image is requested. Put the images on a CDN and get them completely off the main web server where server-side logic is used.

One reason why this technique became popular is when images were being stored in SQL Server. Which at times had made sense to me, but those were some very specific scenarios. The images on the site do not fit those scenarios. So eliminating the image Http Handlers can only improve the overall site's experience.

There are always more things to improve. These are some low and intermediate hanging fruits that would result in immediate impacts to airline site performance numbers. Of course we know faster sites earn more money and make customers happier. And since airlines suffer from consistent low consumer satisfaction scores taking a day or two to implement these changes will only result in very positive results and lower operating costs.

If you are interested in having me perform and audit on your web application, public or line of business please feel free to contact me, I will provide a very through evaluation and action item report so you will know where to apply changes and why. I will be presenting a session on Web Site performance at DevConnections this October where I will dive into the subject deeper and cover other best practices for web performance optimization.

Airline Scorecards

If you want to the the rest of the sites I evaluated the other day, here they are, with links to the actual results and individual scorecards.

AirTran - scorecard

Sun Country - scorecard

Air Canada - scorecard

Korean Air - scorecard

Ana (Japan) - scorecard

Delta - scorecard

British Airways - scorecard

Luftansa - scorecard

Air France - scorecard

Alitalia - scorecard

Ryan Air - scorecard

US Air - scorecard

Jet Blue - scorecard

Alaska - scorecard

United - scorecard

Share This Article With Your Friends!

Googles Ads Facebook Pixel Bing Pixel LinkedIn Pixel