Website Optimization Measures, Part I
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
nofollowbears 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
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
headsection 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
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 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!
I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for companies like Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly and Frontend Dogma. I love trying things, not only in web development, but also in other areas like philosophy. 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!
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… 😉
Maybe of interest to you, too:
- Next: Website Optimization Measures, Part II
- Previous: CSS: Selector Variables
- More under Web Development, or from 2008
- Most popular posts
Looking for a way to comment? Comments have been disabled, unfortunately.
Get a good look at web development? Try WebGlossary.info—and The Web Development Glossary 3K (2023). With explanations and definitions for thousands of terms of web development, web design, and related fields, building on Wikipedia as well as MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.