Setting up a consistent, well-organized website is kind of like building a new house. You can rush in, sticking bricks and mortar hither and yon with wanton abandon, and wonder why a few months down the track your roof leaks and visitors are hit by falling debris.
Or you can plan ahead, and make up a blueprint for your site, keeping expandability in mind at all times. After all, what designer doesn’t want to add new content? And what site doesn’t sometimes need to change its underlying technology?
Sadly enough, a frequently overlooked step in this process is the structure of your links—the actual URLs you’ll be using to point to items on your site. Here are a few handy tips.
YOUR FRIEND, THE TRAILING SLASH
Chances are, you’ve come across an example of poor link structure in your many travels online. The problem is that most of the time, developers don’t even realize that they’re needlessly taxing their server (even if it’s just a smidge).
Let’s look at an example link.
This appears to be kosher; you’ve got your
http://, you’ve got your quotes where they’re needed, you’re closing the tag, and everyone’s happy, right?
Not entirely. The process goes a little something like this, depending on your server and setup:
Browser: Give me ‘subdirectory.’
Server: Just a minute; first I’ll try to find a file called ‘subdirectory.’ ... Wait a second; it’s not there! How about a directory called ‘subdirectory?’ ... Ah, here we go. Okay. And next time, please use a trailing slash.
Browser: Roger that.
But by changing our link just a little bit:
...everything becomes hunky dory. The server won’t have to guess whether ‘subdirectory’ is a subdirectory or a file; it will know.
Why should we bother? Because:
- We’re doing ourselves a favor, as this is the correct way to do things.
- We’re doing our server a favor, as this means less disk access.
- And most importantly, we’re doing our visitors a favor, because they’re no longer losing a few seconds while our server tries to find first a file and then a directory. And in this industry, you and I both know that a few seconds is a long, long time.
DIRECTORIES AND FILES
Let’s take another example link.
There’s nothing actually wrong with this link—not in the validation sense. Nor will a link like this add extra loading time to your site; it’s just a damn link.
But now we’re being picky and talking about semantics. I propose a change to the above link, like so:
Why? Why should you go ahead and change a perfectly happy link to one that points to a directory (virtual or otherwise)? Glad you asked.
What if you, or the company you work for, decide to upgrade (or simply change) your site to use a different technology—for instance replacing your PHP–built site (about.php) with a system developed in ColdFusion (about.cfm)?
If you stick to a directory structure URL (/about/), the page’s web address remains consistent, regardless of how the site is actually put together. And that’s gold; links don’t break, time is not wasted, and joy abounds.
Build a neat directory structure from the get–go, and you’ll be thanking yourself down the track.
You may not want to expose the particular technology you’re using on your site to the rest of the world. By using a neat directory structure, you don’t have to.
You don’t even need to actually use physical directories on the server; you can map the URLs on your site in any way you like, using mod_rewrite (a personal favorite). If you’re unfamiliar with mod_rewrite, see Till Quack’s How to Succeed With URLs, from ALA Issue 123.
Keeping to a neat, concise, and structured directory layout benefits everyone, and ensures that your site will not break when management decides to install the latest content management system developed in yet another emerging web–based development environment.
Keep it /’d.