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 Southwest.com 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 WebPageTest.org. 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 WebPageTest.org 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 WebPageTest.org. 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.
Do the Header in Pure HTML & CSS
I would consider this an intermediate change with some very measurable impact. The current Southwest.com 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, http://fortawesome.github.io/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.
By my count I found a dozen inline SCRIPT tags on the Southwest.com 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.
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 southwest.com, inlining is a very bad idea.
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.
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 aa.com 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 GruntJS.com site to learn more about it, I highly recommend it.
The USAAir.com 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.
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.
Cache Static Content
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.
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.
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.
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 EasyJet.com 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, firstname.lastname@example.org. 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 WebPageTest.org 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.
Sun Country - http://www.webpagetest.org/result/130827_7P_12E/
Air Canada - http://www.webpagetest.org/result/130827_S5_1A8/
Korean Air - http://www.webpagetest.org/result/130827_NR_1B8/
Ana (Japan) - http://www.webpagetest.org/result/130827_XB_1C3/
British Airways - http://www.webpagetest.org/result/130826_3K_188A/
Air France - http://www.webpagetest.org/result/130826_CM_189F/