Why do some pages blink into place like they have a hyperdrive installed; and others dawdle their way into existence? The former likely have some simple tricks figured out. Those tricks are actually easy to figure out and the benefits are broad. They improve the user experience and they make search engine optimization easier. A couple of these tips may be a little more server intensive (like Keep-Alive), but some of them can actually make your site easier to deliver.
Start this on the server side. HTTP, the defacto protocol used for web traffic, is stateless. It lives in a state of perpetual amnesia. With each web request your client forgets where it found the resource and looks again. This amnesia is good in that it’s doesn’t memorize a path between the server and the client, but it finds the best available path each time. Opening a connection, finding a source and getting that response is expensive in terms of time-- it uses up a lot of client time waiting and searching. Keep-Alive keeps the connection alive (simple, huh?). Instead of opening and shutting the route, it opens it, does the file moving via the same route for multiple files, and then closes the connection after all of the files are down.
If you want a snappy reaction, your server has to be set-up with Keep-Alive “On.” It means that the server has to keep the connection available and be open much longer. That means a busy site can get slammed from the concurrent number of open threads. One site I know that has modulitis (see below); it can deliver pages quickly but sometimes it overloads and the server crashes. Keep-Alive is a blessing and a curse.
Why aren’t all servers set to have this on? It’s more processing intensive, so hosts that run many sites off of one server will turn this off. It’s more economical to pay for more bandwidth for open and closed connections than it is to pay for more servers to house fewer sites capable of managing traffic peaks.
You can min-max how this works if you get into a multi-server envirnoment. Static files come via a Keep-Alive because plain files are simple. Then dynamic files (dynamic web pages, dynamically built images, etc.) come via a non-Keep-Alive server to keep the interaction transient.
If you’re looking save money at the expense of a snappy user experience keep Keep-Alive off. If delivery and the quality of the user experience is paramount: turn it on.
Flush Your Output
Hang time is a killer when you’re waiting for a web page. Maybe that website has gone missing and you’re just sitting there like a schmoe. How is a user to know? Some content management systems (cough-- Drupal) allow for a crazy amount of hang time before the page delivery begins. By default, PHP can wait for a good length of time before delivery but you can urge it to begin earlier than otherwise by executing a flush() function call to push what is ready to deliver to the output. I do this by putting the flush() call at the top of the page.tpl.php file. If you’re about to output the themed data, you’re ready to deliver content, so I say push it out as soon as you can, even starting the process before the page.tpl.php is populated and served. One thing to note: flushing content may not be a tactic that plays well with GZip.
Fewer File Downloads
Keep in mind that if you have lots of plug-ins and widgets on your site that you a) cannot aggregate those; and b) you have to wait for those you do come down before your page is considered “downloaded”-- that's an eternity and you may question whether you want a super slow but tricked out site, but sometime that’s a little lean and mean.
CSS sprites use portions of a larger image to fulfill some graphical need on your web page. Spriting isn’t a new concept-- I probably built my first sprite for a video game over 25 years ago. But its role in web design is comparatively new.
In pursuit of fewer file downloads, you can lump multiple elements into a single image and then use CSS to slice that image for use. There is a lot of finesse to how you slice up an image with CSS. You need to pay attention to how the image will be used and you need to be comfortable using CSS backgrounds with cropping and the repeat concepts figured out. We have more information on how CSS sprites work, here.
There are a number of design decisions that won’t compromise your final product but will improve it will delivery.
Embrace CSS3 - Rounded corners, shadows, angled text: those are all available with CSS3. If you’re worried about the pain of picking up CSS3 or getting it to be cross browser compatible, have no fear, http://css3generator.com/ is here. You would be surprised with what you can accomplish. CSS3 is more flexible, it relies on styling controls in lieu of images. Look for all of the ways you can replace images with CSS: shadows on text and div tags; tilted text; multiple columns, gradients, et cetera. Cooler still-- text in its raw form can be indexed easily by search engines. The same effect, if done with images, would need alt and title tags. And, it would take longer to deliver, and images are less flexible. And. And. And. Give CSS3 a try.
Consider inline images - Something cool: you can make a text reference in lieu of calling an image file, call the data for that image. Images are files of characters. Instead of calling the file, you can load through the data. Here are two links on how to do it:
Encode your images here
Steve Souders has written a lot of good stuff on the topic of web site performance. He's not only written the book on it-- he's done that twice:
After you carry out these steps check if they’re helping. I recommend two sites you can use to benchmark your performance:
http://www.webpagetest.org/ -- really good at the metrics of success
http://websitegrader.com/ -- good at the SEOworthiness of your site.
Look at your keywords. If you want tips on "Dressing For Success" Click Here.
Do you need a hand with speeding up your site?Click Here!