Website Optimization Measures, Part VI

Published on Mar 10, 2009 (updated Feb 5, 2024), filed under development, optimization. (Share this post, e.g., on Mastodon or on Bluesky.)

This and 133 other posts are also available as a 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).

This post is partially outdated.

Does this article series still need an introduction? I don’t know, but I’m willing to take a risk.

Utilizing Google Friend Connect. You probably noticed both the cute bar at the bottom of this site (and this site and this site) ~~as well as a recent post on GFC tips~~. At the same time you might want to learn more about why GFC is so cool and why I like it so much and think that especially the Social Bar is such a great thing. Mmh, maybe try for yourself while I debate publishing a GFC love letter.
Making Google Analytics code more maintainable. This post is not about Google, but it happens to cover Google twice. While I implemented the Social Bar on my sites I worked on improving the Analytics code, too (with some support from Keekim), making it a bit easier to maintain. What I did was, in short, moving the Analytics code into an external script:
```
function initAnalytics() {
  if (_gat && _gat._getTracker) {
    try {
      var pageTracker = _gat._getTracker("UA-209576-1");
      pageTracker._initData();
      pageTracker._trackPageview();
    } catch(err) {}
  }
};
```
…and to call that script on each page, including the following code of each page’s bottom:
```
<script src="http://www.google-analytics.com/ga.js"></script>
<script>
  initAnalytics();
</script>
```
That’s a bit too simple though: The initAnalytics(); part can go into the external script, too; the reason why I accepted to add it to each doc was the Friend Connect script, which is big enough so that it might otherwise stall processing of the Analytics script. Calling initAnalytics(); on each page and before initFriendConnect(); solved that.
If you run into any issues, please try reverse engineering first as I might not have the time to explain in more detail what I did and missed to clarify here. On the other hand, please let me know if you’ve got any suggestions. Scripting’s not my main focus area, and I can learn a lot in that regard.
Taking samples and giving pages some sanity checks. We already had this for contents, however it doesn’t hurt to take samples of web pages and to give the code a quick check, either. Especially in living projects that face many iterations, some things can be sticky, and it’s good to see if the refactoring that once happened was successful, or if there’s just something that you wouldn’t do anymore. What happened to me, to be more clear, was that I gave some of this site’s pages a closer look and felt the need to take care of some of the next items:
Removing @type where possible. Inspired by HTML 5’s section on determining resource types it’s already a few weeks or even months that I questioned all kinds of uses of the type attribute. To keep this short, you can omit @type fairly often. The two things to keep in mind (before I make a separate post out of this): Make sure to test that everything works (I had issues omitting type="application/rss+xml", for example), and to validate your documents.
Removing @charset rules. I advised against @charset in some projects but still used it in others. @charset, especially when used for UTF-8, is rarely necessary. There are other ways to specify the encoding of style sheets (for instance via AddCharset utf-8 .css in your server’s .htaccess). Also, at the end of the day, the CSS spec assumes UTF-8 anyway.
Checking for appropriate use of cite elements. it has been until I read the respective part of HTML 5 that I decided to give my projects a good scan to see whether all instances of cite made sense. It wasn’t the case, surprisingly. Sometimes I used it for marking up the author; something that had to be and thus has been corrected.
Removing ICRA labels. I had ICRA labels on several of my sites for years now, but it never occurred to me to question if they’re useful. I mean, overly protective parents or overly stupid filters might not block my sites just because they don’t use an ICRA label, right? How many sites use these labels? So I figured that ICRA labels might as well just waste bandwidth and potentially impair maintenance, and so they disappeared.

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

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m an engineering lead, guerrilla philosopher, and indie publisher. I’ve worked as a technical lead and engineering manager at various companies, including Google; I’m an open-source developer and a contributor to web standards (like HTML, CSS, WCAG); and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development and engineering management, but also with respect to politics and philosophy. Here on meiert.com I talk about some of my experiences and perspectives. (Please share feedback—interpret charitably, keep it friendly, but do be critical.)