TuningSchmuning

One of my summer goals was to get our web sites tuned up a bit, fixing the design issues that were almost corrected before my hard drive crash swallowed them whole (). Helping the site analysis is YSlow, a browser plug-in for Firefox by Yahoo! that analyzes pages for speed and offers performance improvement recommendations. Sitting at the bottom of the browser, technical advice on the current page is just a click away. YSlow requires the Firebug toolbox, so there are two things to install in order to use it.

The ugly results from the initial test of the BlogSchmog home page: F (34).

To qualify this failing grade a bit, this blog is powered by an open source project on a hosted server. Several of the recommendations to speed things up are either not feasible in this configuration or not practical to still maintain the ease-of-upgrade a platform like WordPress offers. That said, Yahoo! offers some good rules about improving the speed of a site, including:

1. Minimize HTTP Requests—”80% of the end-user response time is spent on the front-end. Most of this time is tied up in downloading all the components in the page: images, stylesheets, scripts, Flash, etc.”

   By reducing the number of external HTTP requests required to render a page and simplifying the page design, the speed improves.

   1. When graphics are next to each other, use image maps. The size is about the same, but the number of requests is reduced.
   2. Combine all images into one big image, and use CSS properties (background-image, background-position) to selectively reveal what to show.
   3. Combine external files, such as style sheets and scripts.
2. Add an Expires Header—”A first-time visitor to your page may have to make several HTTP requests, but by using the Expires header you make those components cacheable. This avoids unnecessary HTTP requests on subsequent page views.”

   Yahoo! traffic is very high, so increasing caching will have a big impact. The use of a far future expire headers (combined with including version numbers in the file names) saves basic HTTP calls for component data in about 3/4 of all page visits. Bad Penguin explains how to cache from the code end.

3. Put CSS at the Top—”Front-end engineers that care about performance want a page to load progressively; that is, we want the browser to display whatever content it has as soon as possible.”

   When a page loads progressively, it means that content is displayed as soon as possible, providing visual feedback to the site visitor. When stylesheets are placed at the bottom of the page, the browser waits for them to load so it doesn’t have to redraw content. Firefox trades this problem for one of uneven presentation when content flashes an unstyled appearance.

4. Move Scripts to the Bottom—”With scripts, progressive rendering is blocked for all content below the script. Moving scripts as low in the page as possible means there’s more content above the script that is rendered sooner.”

   Scripts also block parallel downloads, even if files are hosted on other domain names.

5. Make JavaScript and CSS External—”JavaScript and CSS that are inlined in HTML documents get downloaded every time the HTML document is requested. This reduces the number of HTTP requests that are needed, but increases the size of the HTML document. On the other hand, if the JavaScript and CSS are in external files cached by the browser, the size of the HTML document is reduced without increasing the number of HTTP requests.”

   This advice is strongly tied to effective caching. If the caching is minimized, then a lower number of HTTP requests is needed to speed up the page load. In some cases, a home page template (which is viewed just once in a session) might be faster with inline scripts. If that is the case, it may benefit future page loads in the session by also downloading the external files for the other pages into the browser cache after the home page has finished loading.

6. Reduce DNS Lookups—”DNS has a cost. It typically takes 20-120 milliseconds for DNS to lookup the IP address for a given hostname. The browser can’t download anything from this hostname until the DNS lookup is completed.”

   Caching this lookup information is done at the user’s end, with their ISP, LAN, computer or browser. When a cache expires, all of the hostnames used in a page have to be looked up again. There is a trade-off, though, between DNS lookup and parallel downloading. Yahoo! recommends no more than four hostnames to strike a compromise.

7. Minify JavaScript—”Minification is the practice of removing unnecessary characters from code to reduce its size thereby improving load times. When code is minified all comments are removed, as well as unneeded white space characters (space, newline, and tab).”

   Obfuscation can produce bugs but adds to the minification process changes to variable names to minimize the amount of text in the source code. There is a nice tool, JSmin, that will help. The longer the code, the more benefit from minification. The trade-off is in readability and annotation for later changes.

The big advantage to using WordPress plug-ins is that the installation is easy. Someone (else) has spent the time programming the functionality, making it possible for novices to spend about 10-15 minutes adding it to their blogs. Not all of these plug-ins try or can adhere to the above rules without requiring more from the blogger, so the downside is: more functionality = slower pages.

Similarly, CSS is often poorly constructed in theme and plug-in design. It is much easier to make a brand new class for a very specific style change and tweak that than to re-examine the full CSS inheritance to re-use or edit the style for the whole site. Plug-in authors won’t know the base CSS usage anyway. To make their mini-app portable, the CSS sometimes needs to be fragmented. It is up to the blog administrator to explore the code to see if HTTP requests can be minimized or existing style choices applied to the plug-in.

Although I’ve yet to find the time to sit down and rework this blog design (it’s about time for an upgrade), it looks like some of these speed problems can be addressed just by dropping a couple key plug-ins, like SphereIt and code for enhanced Amazon links. The page score shot up to 54 by making those two simple changes. Checking the W3C validator, though, there’s quite a bit of coding to clean up.