Website Optimization Measures, Part VI

Published on March 10, 2009 (↻ February 5, 2024), filed under Development (RSS feed for all categories).

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

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’s 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 posts!

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, 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 in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Please be critical, interpret charitably, and give feedback.)

Comments (Closed)

1. On March 12, 2009, 9:56 CET, Francesco said:

   First of all, thanks for this really interesting article!

   If the Google Analytics code you mentioned is really the only JavaScript code I use on my website, would it be more correct to create an external script and include it into the HTML code or directly include the JavaScript code? Because including it directly would save a HTTP request, right?

2. On March 13, 2009, 17:17 CET, Amber Kimball said:

   This explains a lot to a “newbie” such as myself, so much to learn with so little time, your guidance is valuable, thanks so much and I’ll be back to learn more as I move along.
   Best Wishes,
   Amber Kimball

3. On March 15, 2009, 16:28 CET, Jens Oliver Meiert said:

   Francesco, that’s right. However, that scenario would ask you to balance performance and maintainability. Just one instead of two script files would be faster; the Analytics configuration in a script file versus having it in each HTML template or doc would be more maintainable.

   Amber, you’re very welcome.

4. On March 17, 2009, 0:04 CET, Francesco said:

   What exactly is this useful for?

   if (_gat && _gat._getTracker) {
   try {
   …

   I mean I see that it checks if _gat and _gat._getTracker is true but why would I like to do this? Why not only use this code for my initAnalytics function and nothing else?

   var pageTracker = _gat._getTracker(”UA-XXXXXX-X”);
   pageTracker._initData();
   pageTracker._trackPageview();

5. On March 17, 2009, 10:56 CET, Kroc Camen said:

   I would go as far as saying - dump just about everything from the header. Most sites clutter the crap out of the head.

   - Don’t use a favicon link. /favicon.ico is assumed by all browsers automatically.

   - Don’t use keywords/description. Google works. I don’t have any meta keywords/description and it has not inhibited indexing, not people finding my site one iota.

   - Don’t use Content-type. Set your server to automatically add a UTF-8 header.

   Check my site’s head element out. Three lines. Title, stylesheet, RSS and that’s it. All you need.

6. On March 17, 2009, 16:59 CET, Jens Oliver Meiert said:

   Francesco, that if statement just makes sure that the Google Analytics script is present (by looking for the _gat object)… or did I misunderstand?

   Kroc, easy 😉 Interesting thought regarding the favicon… admittedly, I still reference it due to IE problems in the past, though it’s long that I last tested how IE behaves here. Concerning the encoding, well, the advantage of having it specified within the file is that you don’t run into any issues when accessing the file outside server context (e.g. locally, or when stored on any data carrier). Must not but might influence the technical approach.

7. On March 19, 2009, 22:11 CET, Francesco said:

   Are there any drawbacks hosting the ga.js file locally?

8. On April 1, 2009, 22:53 CEST, Jonas said:

   @ Francesco: Probably not, if you have a mechanism to keep it up-to-date (cronjob or simmilar).

9. On April 1, 2009, 23:01 CEST, Jonas said:

   Oh, and checking for the Google Analytics functions to be present before calling them is good practice, since some people block certain scripts for privacy reasons. So they don’t get a javascript error. I’m not sure why Google doesn’t have that check in their code examples/recommendations.

10. On May 10, 2009, 17:07 CEST, Rick Daley said:

    You have a very nice website that is very informative on website optimization .
    And I also agree about what you said about Making Google Analytics code more maintainable
    Thanks for the info.
    Rick

11. On May 25, 2009, 13:53 CEST, Alan Buchanan said:

    Thanks alot for some of the great ideas ive found in this series of articles. Its some pretty basic things i would never have thought of.
    Hey… Its all part of the learning curve eh?

    Thanks alot Jens.

12. On August 4, 2009, 14:36 CEST, Markus said:

    Would you rather recommend to host the ga.js file locally or to include it from Google Analytics directly?