Our Ken-Hardin sat down with our technology VPs at IT Business Edge, Troy Atwood and Steve Hardin, to discuss the steps we’ve taken over the past several months to move up about 35 percentile points in Google’s site-speed ranking – which we think is pretty good.
Some of the tactics involve infrastructure, some are basic housekeeping, and some are still in the works, but overall we’ve found that optimizing site performance is an ongoing initiative that you never entirely master.
Click through to see 10 tips that we found useful in optimizing our site’s performance.
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.
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.)
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.
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.
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.
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.
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.
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.
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.
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.
