1. Use standards
This is probably the most flogged horse of a concept that there is in today’s web design circles but for good reason. Abiding by the standards laid down by the W3C shifts blame for your design not working on all browsers from you to the browser. It means that you can assume it will work on everything and then tidy up when some browser’s fail to comply.
This is a much better model than designing for one browser then fixing it in another browser and then another browser and another browser while successive hacks break the original design.
If you use some CSS along with your design you can also start to see drops in the amount of bandwidth your site is using and with time you should be able to separate your HTML from CSS so much that the HTML is just there to say what things are while your CSS handles all the placement and design.
Accessibility for your users is another factor that you should consider. There are many guidelines a google away telling you which tags to use for what and how you should structure your documents so any user (whatever their browser) can understand your content easily.
2. Design for your audience
I often see questions along the lines of:
- What’s the correct width for my site?
- How much should I compress images?
- Should I use AJAX?
The answer to all of those is always the same: It depends on your target audience!
If, however, your site demographic relates more to African children all sharing a 56k modem, you’re going to have to think very carefully how you do your media.
Finally if your demographic scales many types of user, you’d probably be wrong siding with the average user, as most people would. If you make the site good for 50% of your audience, you’re helping half of them but rubbing the other halfs’ faces in the mud. If any at all, you want fewer than 5% of your visitors suffering at the expense of your design.
3. Don’t overuse external resources
Every time your browser sees a external file embedded in a web page, or in a CSS document, it queues it up for download and processing. You need to remember that the request has both a processing and bandwidth overhead. Both those cost time to the user.
Given the choice between 10 files at 200kb or 1000 files at 150kb you should chose the smaller file-impact. This isn’t always the case but here are some common problems people make when structuring their website:
Splitting CSS files and using @import or having multiple head-links for structure’s sake is just nonsense. If you need to hide certain CSS from some people, so be it, but you should never make them request 20 CSS files (as I’ve seen done in some places) just so you can name your CSS files with beautiful logic.
Sinilarly, having multiple JS files when all of them are needed is just childish. Say you’ve got 280k of JavaSript in 3 files (a common thing for people using script.aculo.us). Is there any reason for them not to all be in the same file? Furthermore, if there any reason why they shouldn’t be in the same file and then compressed?
Using bloated scripts, again, such as script.aculo.us is bad for your users. Use something lean that just does the job you want it to, rather than having lots of extra things that you will never use. Mootools is a fine example of this. It does a lot that script.aculo.us does but you download it modularly, into one file with optional compression. Can anyone say “save 240k bandwidth per unique”?
All of these sins against your users will make pages take longer to load and end up costing you more in bandwidth. In extreme traffic spikes, the more you’re resourcing from the same server, the more likely it is to explode (metaphorically, of course).
The key to utilising JS safely is making sure it degrades well. Supporting multiple browsers is one thing but how about when the user has no JS option open to them? You do one of two things:
Ignore them. You don’t want traffic like this. Like Gucci (Armageddon) and Digg (you can navigate but you cannot vote).
Implement things the old-fashioned (with proper postbacks and everything) way and override them with new JS ways so that everybody can use your site.
There are only two reasons for choosing #1 there. You’re too lazy or your application is too complex.
5. Monetise but don’t punish
Another common problem with websites these days is advertising. It’s bad enough with the search engines being all spammed up but just an insult when you make it to the page you’re pretty sure you’re looking for and they’ve creamed the page with adverts.
I take no issue with people wanting to see some return for their effort but when that comes to effectively tricking users into clicking adverts, that crosses a line. Google do try and cull the users trying to game the system but then publishers just move onto lower-brow advertisers who have less inhibition to make adverts strobe and buzz at your users.
Sticking adverts in your content is fairly intrusive. It means people have to read around it. Putting adverts very close to features such as navigation is also a commonly used way into tricking people to mis-click.
You can read a 1001 different ways to get people clicking your adverts more but if you think you’re worth it, you’ll go with one of two options:
- Find another business model. Not very easy considering anything is going to effectively hurt the users who don’t pay unless you try a donation system that allows a few users to pay for everybody.
- Be “truthful” about your adverts. Have them in plain sight, where there is no chance of people just accidentally clicking one or (worse) people thinking they’re not adverts at all.
If you are going to stick with adverts, it makes good sense to address their placement from the very start. That way you can make sure they look like they’re supposed to be there and aren’t going to look like you’re just trying to suck money out of people.