Website Optimization Measures, Part I
Post from February 10, 2008 (↻ June 1, 2020), filed under Web Development.
This and many other posts are also available as a pretty, well-behaved ebook: On Web Development. And speaking of which, here’s a short treatise just about managing the quality of websites: The Little Book of Website Quality Control.
Permanent focus on QA requires an occasional website review, not necessarily always a “redesign” or “relaunch.” This week I spent some time analyzing, refactoring, and optimizing my personal sites. I thought to share a few things for inspiration and discussion:
Removing irrelevant posts. I did indeed browse this blog for irrelevant posts—and found a lot. While some might consider deleting posts “taboo,” I do not, if the posts in question decrease the average post quality. I accept that not every post needs makes it #1 on Digg, but admittedly, some entries looked like I just babbled in order to say something. The removal measure made maintenance a little easier (apart from the fact that I will need to remove a few redirects later). It didn’t affect many comments; few people commented on those posts, unsurprisingly. There’s no downside removing irrelevant stuff really, not even in blogs.
Editing and removing comments. Some might consider this another taboo but it has a few very good reasons too, some of them mentioned in the new comment guidelines. The most important reason was spam, and my tolerant approach to comments that avoids both moderation,
nofollow, and stuff just bears a larger risk of getting spammed without noticing (that despite I check everything Akismet does and what gets published). So I went through all comments, removed some, edited or “neutralized” others. While this measure meant a lot of work it increased this blog’s overall quality too and decreased the likelihood of getting “penalized.” It benefits all commenters in that it emphasizes and strengthens everyone’s contributions.
Cleaning up the folder structure for “auxiliary” files. For style sheets, scripts, images, and stuff I personally used to use a folder structure like “/bin/css”, “/bin/js”, and “/img”. Not anymore. The mentioned structure has been inspired by UNIX but doesn’t make real sense, and it doesn’t scale very well either. So I changed the architecture to
And while this appears to be much better than the former type of organization, I’ll observe how it really behaves—so far, it works and scales great. “/media” is not just for images and thus gives me the flexibility to throw in videos as well (something I didn’t really do before, not in my private projects), and “/setup” looked like a short name that would roughly legitimate hosting style sheets and the like. Anyway, if there’s something better, I’ll revise it again. Unless cost of problem gets too low, that is.
Revising use of
rel="alternate". I used to add
link rel="alternate"elements in the
headsection of some documents to point to alternative versions (mostly translations) of the corresponding page. I dropped this, not due to eventual SEO advantages but due to maintainability reasons. Adding
rel="alternate"only to hyperlinks pointing to alternative versions now needs to suffice.
Replacing Google and Yahoo verification
metaelements by HTML equivalents. Using both Google Webmaster Tools and Yahoo Site Explorer I once decided to use the
metaelement verification way in order to avoid additional stuff in the corresponding project roots. However, I noticed this had a downside, namely forcing homepage visitors to download these, for them useless, elements. By removing the
metaelements and verifying sites with the alternative HTML documents file size decreased again, and that is great.
As I’ll be leaving Bremen tomorrow for a few days of home search in Zurich and my next farewell tour in Berlin, I had to hurry a little bit and keep some arguments and explanations a little short. At least four additional measures are waiting in part II, however. 😊
If you have a question or suggestion about what I write, please leave a comment or a message.
From my point of view, it makes sense to think about a blog post before you publish it, and not with hindsight. I think that users don’t like to comment on posts that will be possibly edited or deleted during a “blog review“. And much more important: I would never touch a comment, because the writer meant it the way he wrote it. My changes would only affect the typographical, grammatical and orthographical correctness.
Live with your past babble and look forward to make it better. 😊
I just came in on part V and decided to start with part 1. Great serie of articles with finally not such a common approach to web optimization. You’re digging a little deeper then what I come across most of the time.
Folder structure is a good one. I do not always use the same map structure and that sucks… Especially when I sometimes copy and paste some stuff and find out half an hour later that some path is incorrect… 😉
Have a look at the most popular posts, possibly including:
Perhaps my most relevant book: CSS Optimization Basics (2018). Writing CSS is a craft. As craftspeople we strive to write high quality CSS. In CSS Optimization Basics I lay out some of the most important aspects of such CSS. (Also available in a bundle with Upgrade Your HTML and The Web Development Glossary.)
Looking for a way to comment? Comments have been disabled, unfortunately.