Posted by Ken Hardin

10 Tips For Speeding Up Your  Site

.1 Move Your DNS  To The Cloud

Troy said this may well have been the single biggest step we took to improve our site performance metrics. By moving to a DNS provider with servers across the globe, our users no longer need to make calls all the way back to the main hosting center in the central United States to figure out exactly where they are headed. That initial call is localized now, and hence quite a bit quicker.

.2 Cache Your CSS and JavaScript

We dug a little deeper into the default settings on the Web servers and found that we were quickly expiring the CSS being served to client browsers via a page header value, thus making repeat visitors request it again and again. (We, like most publishing sites, have a fairly substantial CSS.)

.3 cache Your Images

This tactic falls in the same category as caching JavaScript and CSS: Make sure client browsers are not being told they need to download the same images time and time again every time they engage in a session with your Web site. We’re making special note of it here because of a simple trick that is also applicable to those cached assets, but seems more germane to images: Many sites have adopted a habit of making slight changes to names of image files (as well as the calls to them, obviously) to force browsers to re-download them, in case someone typo-prone is doing the artwork and qualitative fixes need to be made. Same with CSS updates, but those are seldom as frequent or glaring, unless you’ve done some major page reconstruction. Oh, and be sure your Web servers all have the same expiration settings.

.4 Serve Assets From Multiple Domains

Browsers tend to make concurrent calls for assets, like images and stylesheets, more effectively if they can do so to multiple domains. There’s the risk that one of the domains might fail, of course, but the Internet is a wild and wooly kind of a place. In addition to employing a dedicated image server (if you aren’t already doing that, then you have a little groundwork to do before you start seriously considering page load optimization), we plan to move our cached assets to servers that do not write cookies, which can be resource- (and hence, time-) intensive.

.5 Put ADS in i frames

If your site serves advertisements – or any other asset that might need to bounce between multiple third-party systems for fulfillment – it’s probably a good idea to put those calls into iFrames. This tactic is more human-facing than anything else, and might not register with benchmarking agents. Steve noted: “When we see heavy ads, Google tells us we have heavy pages.” The main effect is that it allows all the leading browsers to go ahead and assemble and display other page elements that you control more discretely as any vagrant ad calls go bouncing around the Internet.

.6 Use Gzip Compression

We accomplished this at the load-balancer level (“Let the server do what the server does well,” Troy said), but numerous current hardware and virtually all contemporary browsers support the GZIP compression scheme, which can smash data in transit by more than 50 percent.

.7 Make sure your backbone is solid

OK, it’s obvious, but data flows over your network first, so make sure the connections are hot. We went full gigabit between the database and web/app server – it made a big difference.

.8 Run a basic hygiene cheek again

Steve used a NSFW expletive to describe how most webmasters would react to this little piece of advice, but do it anyway. We found a few third-party widgets that simply weren’t doing anybody any good, and now they are gone. We’ve also found a few things tied into proprietary code that we can’t tweak right now, but we know they are there at least. Nothing’s perfect – know your flaws.

.9 Take a Hard Look at your images

We evaluated our image specs and settled on PNG-8 at 256 colors. If you are running the most beautiful Web site in the world, you may need really fat JPEGs. Otherwise, smash those things in Photoshop. They are a huge chunk of the data your servers are passing. A little optimization here can go a long way.

.10 minify your code

We haven’t done this just yet, but plans are afoot to minify our CSS and Javascript. The process, supported by numerous open source tools, removes unnecessary white space and comments, combines multiple CSS or Javascript files, and serves them with GZIP encoding. Google has been at the forefront of minification. Steve noted that a couple years ago, you could view source on a Google property and make perfect sense of the Javascript with just a glance; now, it’s so compressed as to be mostly undecipherable to humans. And smaller is better, when it comes to page load speed.