Current Web Design Resources

I’ve been steadily work­ing on a new web design project which will even­tu­ally become a custom Word­Press tem­plate. In the design process I’ve slowly man­aged to amass sev­eral browser win­dows full of tabs of related things that I was look­ing at for inspi­ra­tion on the site.

Safari is get­ting pretty slow with all of those tabs so I kind of needed to do a com­plete dump of the tabs. With­out fur­ther ado, here are the links (for my ben­e­fit as much as yours).

Wireframes

CSS Galleries

WordPress Themes (Inspiration)

Photoshop and Illustrator Tutorials

Other Stuff

Getting Geeky With YSlow

I spent a good amount of time over the last couple of days attempt­ing to make my site a little bit faster. I’ve been pretty neg­li­gent about it up until now, because I know that much of the slow­ness of my site can be directly attrib­uted to my web host­ing com­pany. 1 Even so, I decided to spend some time doing what I could to speed things up.

The first thing that I did was run a test in YSlow to see how my site was doing. Yikes! I got an F right off the bat. After some fur­ther review and research, I real­ized that this wasn’t nec­es­sar­ily some­thing that should have me freak­ing out. If you’re not entirely famil­iar with YSlow and what it does, Jeff Atwood’s arti­cle, “YSlow: Yahoo’s Prob­lems Are Not Your Prob­lems” on Coding Horror is a must-​read. Basi­cally, YSlow offers a lot of good advice that should be taken, but with a grain of salt.

With that said, here are the steps that I’ve taken to speed up my site.

Make Fewer HTTP Requests

The first time I ran YSlow, I dis­cov­ered that all of my pages were making a ridicu­lous number of HTTP Requests for JavaScript and CSS files. I was request­ing four CSS files: screen, print, IE hacks, and one for Light­box 2. Unfor­tu­nately, the IE hacks stylesheet is still nec­es­sary. Obvi­ously the screen an print ones are as well. After taking a look at the Light­box 2 CSS file, I decided that it was small enough to simply tack on to the bottom on my exist­ing screen stylesheet. That’s one down.

There were also quite a few JavaScript files being requested, includ­ing all of the files for Google Ana­lyt­ics, Mint, WP Stats and Light­box. What can I say? I like my track­ing software.

The first thing that I decided to do was to reduce the number of track­ing util­i­ties I was using to two. I love Mint and Google Ana­lyt­ics seems to be nec­es­sary, so I had to get rid of WP Stats. That wasn’t such a big deal for me. That’s another one down.

The next step was to take a long hard look at Light­box 2. I orig­i­nally installed this for my Gallery page, and then decided to include it on all my pages on the off chance that I might want to use it in a few posts. While it works and looks great, I’ve been decid­edly unhappy about how much bag­gage Light­box comes with. There are five JavaScript files that need to be included, just to have that neat little image trick. Even worse, the included Pro­to­type JavaScript library weighs in at a stag­ger­ing 124KB. What a waste.

I made a mental note to do some research to find a more light­weight solu­tion for my image gallery. Smash­ing Mag­a­zine has a good list of them, which I will inspect at a later point in time. For the time-​being, I com­pressed the Javascript files and was able to bring the total size of the Javascript files down to about 125KB from 196KB. I also decided to only include the scripts on my actual Gallery page. It seems like too much of a waste to require all those files when I rarely use them.

Put CSS At the Top and JS at the Bottom

When I first set up Light­box, I wanted to avoid using a Word­Press plugin for it, so I cooked up my own method of includ­ing it. Most of the work was simply trying to find a way around hard-​coding my tem­plate direc­tory in it and also using a func­tion to keep my header.php file clean and easy to read.

The first prob­lem with my orig­i­nal method was that all of those JavaScript files were at the top of the page, mean­ing that almost 200KB of JavaScript had to be loaded before any of the con­tent on my page started to load. That’s no good! The sim­plest thing to do was to move my func­tion down to the bottom of the page, right before the scripts for Google Ana­lyt­ics and Mint. The only other prob­lem was that the func­tion included the CSS file as well. Since I had already decided to merge the Light­box CSS with my main CSS, all I actu­ally had to do was remove the call to load the CSS.

Use Google’s APIs

Unless you’ve been living under a rock (or just don’t care), you’ve prob­a­bly heard that Google just released their AJAX Libraries API. This was pretty much per­fect timing for me since I was already look­ing at how Light­box used the Pro­to­type Frame­work and Scrip­tac­u­lous Effects Library. It makes a whole lot more sense to use a ver­sion hosted by Google than it does to require clients to down­load the same exact ver­sion of a stan­dard library from my slow web host. Ajax­ian has a good run­down of the fea­tures of this new API and why you would want to use it.

After doing a rel­a­tively quick setup, I was able to call the Pro­to­type frame­work from the Google API. It came in from Google at only 29KB; that’s the same file that I was just com­plain­ing was 124KB. That’s a no-​brainer. Scrip­tac­u­lous was a bit more of a prob­lem though, since it takes a mod­u­lar approach. Light­box 2 actu­ally only uses two of the eight pos­si­ble mod­ules. As far as I can tell, there is no way to use the stan­dard type of of script tag to only include the libraries you want like this:

<script type="text/javascript" src="http://blog.nerdstargamer.com/wp-content/themes/positiveGrey-v2.0/js/scriptaculous.js?load=effects,builder"></script>

One of the com­ments on Ajax­ian by jdal­ton, addresses this:

Another issue google will need to work out is that MooTools, Scrip­tac­u­lous, and Dojo are mod­u­lar (mean­ing you don’t have to load the kitchen sink and can just load the parts you want). This can effect the file size foot­print as well. This may be beyond the scope of a CDN though.

Because I couldn’t find a way to only include the mod­ules I needed, I decided to con­tinue serv­ing them locally instead. So, my func­tion to include Light­box now looks like this:

function AKM_include_lightbox() {
    $templateDir = get_bloginfo('template_directory');

    $output = <<<EOT
<script src='http://www.google.com/jsapi'></script>
<script type="text/javascript">
    var tplDir = "${templateDir}/images/lightbox/";
    google.load('prototype', '1.6.0.2');
</script>
<script type="text/javascript" src="${templateDir}/js/scriptaculous.js?load=effects,builder"></script>
<script type="text/javascript" src="${templateDir}/js/lightbox.js"></script>
EOT;

echo $output;
}

Reorganize Template Directory

Although this doesn’t actu­ally have any­thing to do with the speed of my web­site, it seemed appro­pri­ate to take this oppor­tu­nity to reor­ga­nize my tem­plate direc­tory a little bit. I was striv­ing to create a more tra­di­tional web setup within my Word­Press tem­plate that included all CSS in a CSS folder, JavaScript in a JS folder, and images in an image folder.

This first issue to address was the Word­Press default style.css file. This file is nec­es­sary for Word­Press tem­plate to func­tion prop­erly, as explained in the Word­Press Theme Devel­op­ment Codex page. What I decided to do was to remove all of the actual styles from this file and simply leave the Word­Press information:

/*
Theme Name:Positive Grey
Theme URI:http://nerdstargamer.com
Description:A simple theme using a fluid 2 column layout with green and grey
Version:2.0
Author:Alissa Miller
Author URI:http://nerdstargamer.com
*/

/* See css/screen-x.x.css for styles */

I then moved all of the styles to a new file called screen-x.x.css in the CSS folder. This allows me to have all stylesheets (with the excep­tion of style.css) in the CSS folder. It also allows me to use ver­sion­ing in the file­name, which as we will see, will be impor­tant after I’ve imple­mented better caching and expires headers.

I pre­vi­ously put all of the Light­box files in their own folder, to keep things neat. I’ve now decided to roll those files into the normal direc­tory struc­ture instead of keep­ing them sep­a­rate. The CSS file got merged with screen.css and all of the Light­box JavaScript files got moved into the js folder. Light­box also includes sev­eral images, which I decided to put in images/lightbox/ so as not to con­fuse them with my own tem­plate images.

Gzip Components, Improve Caching

One of the rules for YSlow includes Gzip­ing com­po­nents. Some of my scripts are for Mint and JavaScript, which I can’t really con­trol. The others how­ever, along with my CSS are fair game. I had a little bit of trou­ble fig­ur­ing out how to do this since I did not want to use any of the more common php meth­ods to com­press my pages on the fly and was look­ing at just using either mod_gzip or mod_deflate. The YSlow page gives the fol­low­ing information:

Gzip­ping gen­er­ally reduces the response size by about 70%. Approx­i­mately 90% of today’s Inter­net traf­fic trav­els through browsers that claim to sup­port gzip. If you use Apache, the module con­fig­ur­ing gzip depends on your ver­sion: Apache 1.3 uses mod_gzip while Apache 2.x uses mod_deflate.

After some research, I fig­ured out that my web­site is hosted on Apache 2 (not ear­lier). I included this block in my root .htaccess file:

# GZIP CSS AND JS
<IfModule mod_deflate.c>
 <FilesMatch "\.(js|css)$">
  SetOutputFilter DEFLATE
 </FilesMatch>
</IfModule>

I also decided to make the move to using WP Super Cache instead of WP Cache. WP Super Cache is much like WP Cache but does offer some per­for­mance ben­e­fits. Once I got WP Super Cache con­fig­ured and run­ning, it seemed to have an imme­di­ate effect on the speed of my blog. Of course, that could have just been wish­ful think­ing on my part.

Add an Expires Header

One of the last things I did was add an expires header in my root .htaccess file. This tells the client browsers not to look for a new ver­sion at all if the one in their cache hasn’t expired yet.

Now, I obvi­ously don’t want to do this to the dynamic Word­Press files (com­ments and posts would never update!), but that’s okay because WP Super Cache is taking care of those files already. What I do want to do is add the expires header to all of my images, JavaScript and CSS files. None of these will really change except for the CSS files. For­tu­nately, when I reor­ga­nized my tem­plate files, I gained the abil­ity to append ver­sion num­bers to my CSS files. So now I can go ahead and add that expires header to my CSS files, and then simply change the file name when I need to make changes in my CSS. The new file will down­load like normal, and it’s good prac­tice to get some sort of ver­sion­ing underway.

Here is the code that I put in my .htaccess file:

### ADD FAR OUT EXPIRES HEADDER TO STATIC CONTENT ###
<ifmodule mod_expires.c>
  <filesmatch "\.(jpg|gif|png|css|js)$">
       ExpiresActive on
       ExpiresDefault "access plus 1 month"
   </filesmatch>
</ifmodule>

After some thought I decided that one month was an appro­pri­ate length for my pur­poses. This depends entirely on what type of con­tent it is, and how often you are going to change it.

After doing all of the pre­vi­ously men­tioned fixes, I had improved the page load time quite a bit for most of my site. The only remain­ing bot­tle­neck seemed to be my Gallery page. That wasn’t par­tic­u­larly sur­pris­ing con­sid­er­ing that the page includes 25 thumb­nail images. The total size of all of the images, at full size, weighs in at a hefty 2MB. This page was also still using the Light­box scripts.

One of the things I noticed while using YSlow was that some of my thumb­nail images seemed to be unnec­es­sar­ily large. Some of them were as big as 40KB for a 150×150 pixel image! Upon fur­ther inspec­tion I decided that all of the thumb­nails were too large. I had used WordPress’ fea­ture to auto­mat­i­cally create thumb­nails of images to set this up. I’m not sure exactly how Word­Press does this, but after taking a look at the file sizes I’m sure that it sucks. I recre­ated all of the thumb­nails in Pho­to­shop and the biggest one is now only 17.6KB.

I had also orig­i­nally set up the gallery page in WordPress’ admin screen (using the file browser and things like that). Once I was no longer using the dynam­i­cally gen­er­ated thumb­nails, it didn’t make sense to lay out the page in WordPress’ page sec­tion. Instead I cre­ated a page tem­plate called gallery.php, which includes all of the images and code for the page.

I also copied all of the full size and thumb­nail images into my tem­plate image folder. This way the links to the images are no longer being stored in my database.

Conclusion

After all of these changes my web­site does seem to be a little bit faster. These types of exer­cises are good prac­tice for any web designer/developer. Having a slow web host is no excuse for not doing what you can on your end to make the site faster.

As always, any tips or improve­ments from more expe­ri­enced devel­op­ers in this area are greatly appreciated.

  1. You get what you pay for, right?

Gallery of Doodles in Lightbox 2

Nerd­StarGamer now has a new Gallery page that fea­tures my doodles:

Screenshot of Doodle Gallery

All of the images have been set up as a list of thumb­nails which use Light­box 2 to dis­play large versions.

I spent a little extra time to set up Light­box on this blog with­out using a plugin. I’ve been on a steady cru­sade to get rid of most of my plu­g­ins for quite some time. Set­ting up Light­box in Word­Press was fairly straightforward.

After down­load­ing the Light­box 2 files, I cre­ated a new direc­tory in my tem­plate direc­tory called lightbox and dropped all of the light­box files into it. I then put a func­tion call into the header.php file right before the line that reads <?php wp_head(); ?>.

<head profile="http://gmpg.org/xfn/11">
    ...some other tags...

    <?php AKM_include_lightbox(); ?>
    <?php wp_head(); ?>
</head>

The AKM_includ_lightbox(); func­tion is just a short little func­tion that I wrote and put in the functions.php file of my tem­plate. Here is the function:

function AKM_include_lightbox() {
    $lbDir = get_bloginfo('template_directory') . "/lightbox";

    // Echo out some file path variables for images used lightbox JS
    $output = '<script type="text/javascript">' . "\n";
    $output .= "\t" . 'var tplDir = "' . $lbDir . '";' . "\n";
    $output .= '</script>' . "\n";

    // Echo links to js and css for lightbox
    $output .= '<script type="text/javascript" src="' . $lbDir . '/js/prototype.js"></script>' . "\n";
    $output .= '<script type="text/javascript" src="' . $lbDir . '/js/scriptaculous.js?load=effects,builder"></script>' . "\n";
    $output .= '<script type="text/javascript" src="' . $lbDir . '/js/lightbox.js"></script>' . "\n";
    $output .= '<link rel="stylesheet" href="' . $lbDir . '/css/lightbox.css" type="text/css" media="screen" />' . "\n";

    echo $output;   
}

This first line of the func­tion sets up a vari­able that includes the path to the Light­box files inside my tem­plate direc­tory. This is nec­es­sary because the lightbox.js file needs to ref­er­ence the images included in the Light­box folder. With­out this part, the pre­vi­ous, next and close images will not show up because the link will be going to your Word­Press uploads directory.

That second chunk of text in the func­tion echos out a small bit of JavaScript into your header that simply declares the vari­able tplDir and sets it to the path to your Light­Box instal­la­tion. The last chunk of text inserts all of the nec­es­sary Light­box JavaScript and CSS links into your header. I could have writ­ten all of this directly into the header.php file, of course, how­ever I felt that my file was get­ting a bit messy and that this approach was much more clear.

We also need to make a small edit to the lightbox.js file which is going to use that tplDir vari­able we set. Find the line in the begin­ning of the file like this (around line 49):

fileLoadingImage:        'images/loading.gif',     
fileBottomNavCloseImage: 'images/closelabel.gif',

Simply change those two lines to this:

fileLoadingImage:        tplDir+'/images/loading.gif',     
fileBottomNavCloseImage: tplDir+'/images/closelabel.gif',

That com­pletes the Light­box 2 setup in Word­Press with­out using a plugin. Now all you have to do is add the rel="lightbox" tag to any link you want to use Light­box. For exam­ple, if you have a thumb­nail image that links to a larger image like this:

<a href="images/full-size-image.jpg"><img src="images/thumbnail" /></a>

To add the Light­box effect, just add in the attribute like this:

<a rel="lightbox" href="images/full-size-image.jpg"><img src="images/thumbnail" /></a>

Be sure to check out the Light­box 2 page for more infor­ma­tion on what you can do with it.

Finding a Good CMS Solution

There is a pretty good dis­cus­sion going on over at 456 Berea Street about “Look­ing for open source CMS and portal soft­ware options“.

I’ve been think­ing a lot about this for the last couple of months. I’ve worked exten­sively with Word­Press (for this blog and a few others) and I really feel com­fort­able with it. I am con­fi­dent that I can work with it and bend it to do most things I want with a little effort.

Cur­rently I’m using Word­Press for a con­tract job to create a small­ish web­site man­aged by a CMS. The client wanted to use Word­Press, and I am rea­son­ably con­fi­dent that it will achieve their goals. That said, I think they’re get­ting uncom­fort­ably close to WordPress’s limits. There’s always a point when you are extend­ing soft­ware that you have to stop and con­sider, “Am I really using the right tool for this job?”

I’d really like to branch out and learn some other con­tent man­age­ment sys­tems that are more pow­er­ful than Word­Press and also more geared towards CMS rather than blog­ging out of the box. I tried using Drupal a few months ago, and like many of the peo­pling com­ment­ing on 456 Berea Street, I found the admin inter­face to be abso­lutly over­whelm­ing. It’s def­i­nitely designed with the men­tal­ity that more is better. I had a very clear vision in mind for what I wanted to accom­plish with my Drupal site, but I ended up stum­bling on some key things that felt like they should be very easy. Pri­mar­ily deal­ing with attach­ment links.

That said, I was very impressed in gen­eral with Drupal. It seemed liked the sky was the limit as far what could be accom­plished with it. The user roles were also a wel­come depar­ture from more restric­tive sys­tems like WordPress.

In the end, I was left with the impres­sion that given a lot of time and energy (to learn Drupal) I could make some very cool sites. I wonder, are there other solu­tions that are better?

WordPress Theme Hacks

WeDesign­er­Wall cur­rently has a pretty good list of Word­Press Theme Hacks. This is a good resource if you either trying to create your own theme or cus­tomize some­one else’s.

These is also a sec­tion on one way to get cus­tomized titles. They use this example:

<title>
    <?php
    if (is_home()) {
        echo bloginfo('name');
    } elseif (is_404()) {
        echo '404 Not Found';
    } elseif (is_category()) {
echo 'Category:'; wp_title('');
} elseif (is_search()) {
    echo 'Search Results';
} elseif ( is_day() || is_month() || is_year() ) {
    echo 'Archives:'; wp_title('');
} else {
    echo wp_title('');
}
?>
</title>

I per­son­ally use some­thing sim­i­lar for this page:

<title>
<?php /* Title for homepage is "blogtitle | blogdescription", all other pages get "pagetitle | blogtitle" */
    if (is_single() || is_page() || is_archive()) { wp_title('',true); echo ' | '; bloginfo('name'); } 
    else { bloginfo('name'); echo ': '; bloginfo('description'); } ?>
</title>