Engine Optimization Explained
Site Optimization Examples (Bad Ones)
Profit Technology Tips
advice on how to achieve great web site performance / speed
and explaination of technologies available - content delivery
networks, web caching, ssl
acceleration, compression, and site tuning.
Internet Site Performance
Great web site performance is more necessary than ever. Revenue is lost every
year because of poor site performance - many people won't wait 15 seconds to
for a web page to appear. This site discusses how to improve, monitor, and test
web site performance through third-party products, services, and common-sense.
1. Web Performance Technologies and Services
A. Content Delivery Networks
Content delivery network vendors like Akamai and Speedera provide "edge-caching" technologies.
Basically, they have multiple servers across the world and when a request comes
for www.yourcompany.com for example, the CDN "owns" the DNS for that name and
their edge server sends a request back to your web server transparently to another
domain (another.yourcompany.com) on the internet to retrieve the files. The files
sent back to their edge server and stored there and then sent to the client.
file is at their edge server, the client machine (requestor) gets the files from
their edge server. Thus if your web server is sitting in San Francisco and someone
from London wants to visit your web site, your site content can be served from
a CDN server in London instead of San Francisco, reducing response time. Obviously,
the time it takes for data to transfer within London is a lot less than from
London to San Francisco. CDNs can also provide live streaming functionality -
serving bandwidth intensive media from their content servers... something that
can be costly if you are a multimedia-rich company. Watch out for testing results
CDN companies give that are irrelevant to your site. Any test results of downloading
large single 300kb .gif files are not indicative of how well a CDN's service
is appropriate to you.
B. In-House Caching and Compression,
Load Balancing, and SSL Acceleration
Many times you've tuned your page as much as possible - but its still slow. There
are many different network appliances that can help speed up site delivery and
scale in increasing capacity. By appliances I mean machines that provide particular
(or all-in-one) network acceleraiton technologies. These technologies include
SSL Acceleration, Network Load Balancing, Caching, and Compression - services
that can greatly speed up your web site performance and increase capacity at
a fraction of the cost of adding additional web servers.
SSL Acceleration appliances (or cards) offload encryption/decryption processing
tasks from web servers to allow web servers to spend more processing on content
generation and delivery. When considering an SSL accelerator, take into consideration
the number of transactions per second (TPS) it can handle. TPS will be more important
on SSL Acceleration appliances than cards. For instance, if you buy an SSL Accelerator
Card that can handle 2000 TPS for a server that can only handle 500 TPS, then
you waste the money on the 1500 TPS you can't use. An SSL Acceleration hardware
appliance (box) can deal with transactions for all your web servers and scale
Network load balancing appliances allow network traffic to be intelligently
directed to the server in your server farm with the least load and can tell when
a server is down. The major network load balancing metrics include:
Round Robin - the traffic gets directed to each server, one by one in a sequence.
This type of balancing is not very load-sensitive.
Lowest Response Time - This algorithm takes into account which server can serve
the request the fastest. Sometimes some load balancing appliances don't do this
effective and the load balancer "falls in love" with one server who always serves
content quicker than the other, so that most of the traffic is directed to that
Least Connections - This is usually the best typical type of load balancing algorithm
as it keeps track of how many open connections there are with a web server. If
a web server can serve up and finish transactions faster, the number of its connections
will reduce quickly - meaning it is probably a fast server.
Proximity - If you need global server load balancing, you need this algorithm
to be able to determine which web server farm is the closest to the client. Global
server load balancing entails a load balancing appliance directing traffic to
the web server (farm) closest to the client, leading to faster response time.
If your server farms are all in one location or are geographically very close
to each other, this won't matter - you don't really need proximity based load
Web caching appliances allow for a central appliance near the network
files). This also reduces load on backend server farms - caching appliances they
are particularly optimized for fast HTTP request handling. Thus when multiple
clients request a certain object, such as an image file, the client will get
the object from that cache appliance instead of your web servers. The cache-ability
of content is determined by the file's cache-control header. Content can have
different forms of cache-control headers including "no-cache" which means the
object will not be stored in your browser or proxy caches, and cache expiry dates,
which tells when a browser or proxy should re-fetch the object. Dynamic data
ususally has a no-cache header, which means that a request for that web page
will result in a request and get across the internet instead of from your local
browser cache. Note that for objects that you request which are already stored
in your brower cache and haven't reached their expiry date, you will retrieve
from your browser instead of through the internet. Thus the second time you visit
others web pages in sites that have the same images over the site and have cache-control
headers set properly, you will get a faster response time because the referenced
image file is already in your browser cache.
Compression is the technology where HTML is compressed before being sent
through the network. Servers and compression appliances can tell if a browser
can compress through the HTTP headers a browser can send. If a browser sends
a "Accept-Encoding: gzip, deflate" heading, then the server will return back
compressed data. Most of the newest browers can support compression. MSIE, though,
is limited in that it won't get compression's benefit if MSIE has specified a
proxy and HTTP 1.1 connections, but not HTTP 1.1 through proxy. Netscape doesn't
have this problem. Compression can happen on multiple MIME types, but not all
browsers can handle compression for all MIME types. Compressed HTML can be significantly
(80-90%) smaller than the original file. There are both software and hardware
compression vendors - software ones must be deployed on every server you want
to utilize compression on, much like the problem with SSL acceleration cards
(one per server). Hardware compression appliances might not be worth it if you
have only one server needed to serve up traffic.
Do it yourself (DIY) solutions can be much cheaper in the long run, as two appliance
boxes can cost perhaps 3-4 months of the more expensive CDN service. However,
managed CDN services can take the headache out of operating more equipment. Array
Networks in particular, provides Caching,
Network Load Balancing, Compression, and SSL Acceleration all in one appliance.
2. Web Performance Monitoring and Benchmarking
There are a number of solutions that can help you monitor and measure the performance
of your site better than clicking on a link looking at your stop watch.
Keynote provides web site monitoring services.
They can let you see your site response times from various cities in the world.
Keynote is particularly helpful especially when you are testing the above CDN
and compression resources. You can go to my.keynote.com and
type in demo, demo to test their system.
3. Web Performance Capacity Testing
Microsoft provides a free tool to help you test the capacity of your system - Microsoft
Web Stress Application. This tool can help you simulate a number of client
systems at once and test your system capacity and where it degrades.
4. Common Sense Tuning
You can improve web site performance without spending money as well (or at least
more money). These simple tasks include:
- using Keynote's demo tool to capture site performance in a snap shot.
- using MS's stress tool to capture site capacity.
external sites (perhaps banner .gifs) and making sure they aren't causing a slow
your page (if its legal).
- making sure your total HTML + image size is less than 50kb, even less if you
have primarily a 28.8kb modem audience.
- reducing the number of images in your site. Use text instead of images when
- making sure images have been compressed. You may have some .jpg files that
you created which you forgot to compress before saving. Sometimes the image files
you reference in your Flash files are not compressed either.
- referencing the same images using the same names instead of different names.
- making sure your ISP is serving up your content in accordance to service level
agreements. I recently surfed a classy home listings web site and the performance
was terrible. When I checked with Keynote's diagnostic tool, their site basically
had a terrible DNS lookup and first byte download time. The images being served
up weren't large in themselves.
5. Web Site Performance Understanding
Make sure you look carefully at your site's composition - find where the bottlenecks
are. It could be that your web servers need more power (CPU, memory, disk speed),
need more web servers, your ISP isn't providing good service, or your web page
is just too big. Understand the different components of a web site download -
dns lookup, redirect, first byte download, base page download, content download.
image files. Thus on people's second visit, static content performance won't
be as important.
Do your research before asking the consultants to come in. If there are consultants
that offer services, ask them what they will deliver. Consider for yourself would
it be worth it for a consultant to be paid $$$ to put together a report with
pictures and charts of why to reduce the number of images you have on your page.
Depending on the kind of content you have (dynamic versus static, .html versus
image), how many servers you need to handle current and future traffic (one server
versus 25 servers), and where your traffic comes from (regional versus global)
some solutions will be better than others. Other factors such as how constant
your image files are across your web site (same nav bars over all web site) versus
a very heterogenous base of images (product images in eBay) also effects choice
of solution. A good web site performance consultant should be well versed in
all the aspects mentioned in this web site.
6. Other Web Site Performance Resources
Web Caching - a good site discussing
all aspects of web caching including CDNs and caching appliances.
mod_gzip - Apache compression -
discusses aspects of mod_gzip, a free Apache compression plug-in and other aspects
of compression, including browser compatibility.
SSL Acceleration - list of SSL
Acceleration vendors and information on the technology itself. HTTP
Header Information - Information on HTTP headers including "cache-control"
If your company is interested in improving web site performance and would be
interested in more detailed explanation and consulting before you make a decision,
please contact me at firstname.lastname@example.org.
If you have found this site to be helpful, please link to my site:
Web Site Performance Tuning and Analysis
Primer by Edward Tsai
Copyright September 2002 - Edward S. Tsai - All rights reserved.
Edward S. Tsai makes no claims about and is not responsible for the accuracy,
appropriateness, or effectiveness of the advice given and products and services
listed in this site. All information on this site is provided as-is with no guarantees.
All trademarks are property of their respective company.