Website Optimization Measures, Part I

Post from February 10, 2008 (↻ August 3, 2022), filed under Web Development (feed).

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 (updated).

Focus on QA requires occasional website reviews, not necessarily immediate redesigns or relaunches. 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 few. 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 to make #1 on Digg, but admittedly, some entries looked like I babbled in order to say something. The removal has made maintenance a little easier (apart from the fact that I will need to remove a few redirects in the future). It didn’t affect many comments; few people commented on those posts, unsurprisingly. There’s no downside removing irrelevant stuff, not even in blogs.

• Editing and removing comments. Some might consider this another taboo but it has a few 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 and nofollow bears a larger risk of getting spammed without noticing (and 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, and decreased the likelihood of getting “penalized.” It benefits commenters in that it emphasizes and strengthens everyone’s contributions.

• Cleaning up the folder structure for “auxiliary” files. For style sheets, scripts, and images 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 only makes so much sense, and it doesn’t scale well, either. So I changed the architecture to

  • /media
  • /setup
    • /css
    • /js

  And while this appears to be much better than the former type of organization, I’ll watch how it 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 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 head section of documents to point to alternative versions (mostly translations) of the corresponding page. I dropped this, not due to eventual SEO advantages but for maintainability reasons. Adding rel="alternate" only to hyperlinks pointing to alternative versions now needs to suffice.

• Replacing Google and Yahoo verification meta elements by HTML equivalents. Using both Google Webmaster Tools and Yahoo Site Explorer I once decided to use the meta element 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 meta elements 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 and keep some arguments and explanations a little short. At least four additional measures are waiting in part II, however. 😊

This is a part of an open article series. Check out some of the other posts!

About Me

I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly. I love trying things, sometimes including philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.

If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!

Comments (Closed)

1. On February 12, 2008, 16:47 CET, Stefan Nitzsche said:

   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. 😊

2. On February 14, 2008, 22:41 CET, Jens Oliver Meiert said:

   Thank you, Stefan; you point out a few things other readers might wonder about as well:

   From my point of view, it makes sense to think about a blog post before you publish it, and not with hindsight.

   Of course. Alas, mistakes occur, and to quote Confucius: “A man who has committed a mistake and doesn’t correct it, is committing another mistake.”

   I think that users don’t like to comment on posts that will be possibly edited or deleted during a “blog review“.

   Maybe I didn’t make myself clear about that: Unless comments are “spammy” (or violate the comment guidelines), no comment gets edited or removed. I absolutely understand concerns about this measure, but it’s supposed to benefit everyone involved.

   And much more important: I would never touch a comment, because the writer meant it the way he wrote it.

   Neither spam nor offensive comments? (The latter didn’t appear in my blog yet, but I wouldn’t tolerate them.)

3. On November 3, 2008, 21:11 CET, Santhos said:

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