AWS News Blog

Improving Global Application Performance

Voiced by Polly

Today I would like to talk about ways to make your website run faster and more efficiently. There are several benefits from doing this including better search engine rankings, a better customer experience, and an increase in sales or conversions.

You can always improve your architecture, tune your database, and optimize your code. In each case you locate a bottleneck, figure out a way around it, and then proceed to do so. You basically spend your time answering the question “What part of my application is running too slowly and how can I speed it up?” This is the classical approach to performance tuning; many of the techniques to measure and to improve performance date back to the time before the web (you do remember those days, don’t you?).

In today’s web world, “where” can be just as important as “what.” Let’s talk about that.

The distance between the user and the application is a major factor in the performance of a website or a web-based application. Latency increases with distance, and increased distance also means that each network packet will take more “hops” through intermediate routers and switches as it makes its way from browser to server and back.

You probably can’t move your users closer to your application, but you can often deploy your application closer to the user. AWS provides you with two different ways to do this:

Choose a Region – You can put your application into any of four different AWS Regions. You should choose the AWS region that’s closest to the majority of your customers. As of this writing, you can choose to host your AWS-powered application on the east coast (Northern Virginia) or west coast (Northern California) of the United States, Europe (Ireland), or Asia Pacific (Singapore).

Use CloudFront Content Distribution – You can also speed up your application by using Amazon CloudFront to distribute web content (static HTML pages, CSS style sheets, JavaScript, images, file downloads, and video streams) stored in Amazon S3. Each user’s requests will be served up from the nearest CloudFront edge location. There are currently fifteen such edge locations: eight in the United States, four in Europe, and three in Asia.

You might be thinking that you run a “small” or “unimportant” site and that you don’t need or can’t benefit from CloudFront. Given that a lot of the value of the web is found in the long tail content, I disagree. There’s no harm (and plenty of potential benefit) from making your site quicker to load and more responsive. How do you think that the large, popular sites got that way? At least in part, they did so by being fast and responsive from the very beginning.

Or, you might think that CloudFront is somehow too expensive for you. Well, it’s not. I’ve been serving up all of the images for this blog from CloudFront for a while. Here’s my AWS account, reflecting an entire month of CloudFront usage:

That’s right, less than $2 per month to make sure that readers all over the world are able to get to the images in the blog as quickly as possible. If nothing else, think of this an inexpensive insurance policy that will protect you from overload in case your site shows up on SlashDot, Digg, Reddit, Hacker News, or TechCrunch one fine morning.

If you are interested in speeding up access to your application’s web content, start out by reading our guide to Migrating to Amazon CloudFront.This guide will walk you through the 5 basic steps needed to sign up for CloudFront and S3, download and install the proper tools, upload your content to an S3 bucket, create a CloudFront distribution, and link to the content.

If you are using a CMS (Content Management System), take a look at these:

  1. Joomla – CloudFront Joomla Plugin, Amazon WS Tools.
  2. Drupal – CloudFront Installation, CloudFront Drupal Module, Drupal Integration With Amazon CloudFront Streaming Video Demo.
  3. WordPress – Using Amazon CloudFront with WordPress and WordPress MU, W3 Total Cache, Simple Amazon S3 Upload Form, OSSDL CDN Off-linker, My CDN, and Amazon CloudFront CDN with a WordPress Blog.

If you are doing video streaming, take a look at Use your Amazon CloudFront account, How to Get Started With Amazon CloudFront Streaming, and S3 News from the CloudFront: Private Streaming Video.

Encoding.com has put together a guide to Apple HTTP Streaming with Amazon CloudFront. The guide includes complete step-by-step directions and gives you all the information you’ll need to stream video to an iPad or an iPhone.

Carson McDonald has also put some work into an HTTP Segmenter and Streamer for Apple’s HTTP Live Streaming Protocol. Learn more in his series of three blog posts.

Last but not least, don’t forget about Using the JW Player with Amazon Web Services. JW Player is a very popular open source video player that’s also easy to embed and use. Use the JW Player test page to experiment with the configuration and setup options.

There are a number of good testing tools that you can use to measure the speed of your site while you are in the process of migrating to CloudFront. Here are two:

  • Yahoo’s YSlow is a Firefox add-in and one of the best-known browser-based performance measurement tools. You’ll need to install FireBug and spend some time learning how to use YSlow and to interpret the results. YSlow will measure performance as seen from your desktop. If you plan to use YSlow, don’t forget to tell it that you are using CloudFront as a CDN by following these instructions.
  • Cloudelay measures and displays several different CloudFront performance metrics including request latency and network throughput.
  • BrowserMob‘s free Website Performance Test. I really like this one. You can run a test from four locations around the world and see how it performs when viewed from that location.

As an example of just how location affects perceived website performance, take a look at this chart from the BrowserMob test:

There’s a 4:1 ratio between the fastest and the slowest location. I compared the detailed output for two separate objects: the blog’s home page and the volcano picture that I posted last week. The results show that CloudFront produces results that are reasonably consistent, regardless of where the test is run from:

Location Home Page Volcano
Washington, DC 323 ms 140 ms
 Dublin 631 ms 227 ms
San Francisco 45 ms 210 ms
Dallas 200 ms 252 ms

You can also see the amount of time it takes to look up each item’s DNS address, the time until the first byte of data arrives, and the amount of time spent reading the data:

Still need more info? Take a look at some of these case studies:

  • UrbanSpoon – “CloudFront took a day or two to implement. Switching to CloudFront helped us stay within our bandwidth caps, which saves us several thousand dollars a month.”
  • Linden Lab – “The Second Life Viewer is an application that each Resident runs on their own computer to interact with the Second Life world. Downloads of the Viewer were ideally suited for CloudFront delivery. The Viewer can be downloaded over 40 thousand times each day by different users all over the world and using CloudFront helps Residents download their software faster by storing copies at edge locations close to them.”
  • Playfish – “Playfishs infrastructure operates 100% on Amazon Web Services (AWS), primarily using Amazon EC2, Amazon S3, and Amazon CloudFront.”

One more thing, and then I’ll shut up! We recently recorded a webinar, Increasing the Performance of your Website With Amazon CloudFront.

If you have a CloudFront success story of your own, please feel free to post a comment or send me some email (awseditor@amazon.com).

— Jeff;

Modified 2/1/2021 – In an effort to ensure a great experience, expired links in this post have been updated or removed from the original post.
Jeff Barr

Jeff Barr

Jeff Barr is Chief Evangelist for AWS. He started this blog in 2004 and has been writing posts just about non-stop ever since.