Slash Forward (Some URLs are Better Than Others)

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#section2

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.

A 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?

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:

A link

…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:

1. We’re doing ourselves a favor, as this is the correct way to do things.
2. We’re doing our server a favor, as this means less disk access.
3. 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#section3

Let’s take another example link.

About

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:

About

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.

a) EXPANDABILITY#section4

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.

b) SECURITY#section5

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.