To Blog or not?

Martin Pool made some wise comments about what a blog is. Under those criteria, my site is a blog. I don't use a dynamic blogging system and instead just keep it simple with static HTML pages. I get the best of both worlds by having a static site which is great for performance, search engines and ease of maintenance, while processing the site with a script to get the advantages and attributes of a blog.

Note the site is not completely static, as each page is constructed dynamically, through a series of included files (Server Side Includes). This is done so that Common areas (sitebar on the left, adds, stylesheets, actions/info at end of each page, ...) are coded once and included where needed.

Dynamic Features

As mentioned above, the pages of this site are not served dynamically albeit for some server side includes. Also there is no dynamic process on the server to accept input like comments etc. To support dynamic features like these, I use a common piece of javascript on each page, which presents the links that link to external dynamic sites. Google groups for example is used to provide comment support. The javascript extracts the page title etc, and presents that to the appropriate forms on the external dynamic sites. Note this site doesn't use much javascript, and it degrades gracefully in the absence of javascript support.

[Update Apr 2008: There were a few problems with using the google group for comments, the main ones being one needed to login to google accounts to post, and also the correct list of comments for a post wasn't shown until google had indexed them, which I've noticed could take weeks. Therefore I wrote an application for the just released google app engine to store and retreive comments.]

Page layout

This site uses a 2 column fluid layout, based on http://jessey.net/simon/articles/007.html, with a sitebar on left and page on the right. I.E. Anything specific to the whole site and not just the page goes on the sitebar on the left. The sitebar is fixed, i,e, is always visible/available no matter how you scroll the page. Note the sitebar column is quite narrow (9em) and is not too much screen space to dedicate I think, especially given the trend towards wider form factor screens.

The sitebar is broken into 3. The top portion contains site content links (usually to the home page, or a menu to the site's content on the homepage), the middle portion contextual adds, and the bottom portion other site links. Using zorder, each portion is given priority as the page is shrunk vertically. The adds are the first to be hidden, and then the other site links in the bottom portion.

I use 3 shades of the same colour only, on the whole site.

The size of all text on the site is relative, so that one can shrink or grow as desired. The layout of the site since specified in EMs, will automatically adjust to any text size.

Performance

My main concern with performance is to get the page displayed on the client as fast as possible. I don't really have to worry about server CPU usage as my site only uses SSIs as mentioned above.

Note I use SSIs to help the client also, as rather than having the client do multiple round trips to retrieve each stylesheet, one can convert all client included stylesheets of the form:

<link rel="stylesheet" href="/layout.css" type="text/css" media="screen, projection"/>
to the SSI equivalent of:
<style type="text/css" media="screen, projection">
    <!--#include virtual ="/layout.css"-->
</style>
Note the media attribute of the style tag is supported since HTML 4 at least, and according to the spec "User agents may [use this to] load style sheets selectively". But I haven't noticed any loading stylesheets on demand. For example my print media stylesheet was always downloaded. So currently at least there is no performance disadvantage in including all stylesheets at the server.

I also compress HTML pages to clients that support it using the mod_deflate apache module. This reduces the bandwidth usage of my site significantly and also gets the pages to the client more quickly. Note, a nice side affect of including everything in a single page before sending to the client as described above, is that it all gets compressed together.

The apache settings for my site illustrate how I enable SSI and compression for HTML pages. Note my site is a virtual host on a machine serving multiple web site domains, which is the usual case.

<VirtualHost *>
        ServerName pixelbeat.org
        ServerAlias www.pixelbeat.org
        DocumentRoot /home/pixelbeat/public_html/
        CustomLog /home/pixelbeat/access_log combined
        ErrorLog /home/pixelbeat/error_log
        <Directory /home/pixelbeat/public_html>
                Options IncludesNoExec SymLinksIfOwnerMatch
                AddOutputFilter Includes .html
                AddOutputFilterByType DEFLATE text/html
        </Directory>
</VirtualHost>
[update June 2011: I changed the text menu at the top left of each page to a smaller line of icons. At first I used individual images for each icon which introduced latency, so to alleviate that I did each of these in turn: I did notice (using yslow) that the google "+1" button I also recently introduced is quite heavy weight and requests a few resources. I guess users will more likely have these cached as that service becomes more popular.]

favicon

You can see the favicon for the site at the left of your URL bar above, an expanded version of which is shown on the left. The format supported by most browsers and systems is the ICO format, which the gimp 2.2.7 at least has direct support for. I don't think it supports icon files with different sized icons within one file though, but I don't need that as I just created a 16x16 icon. Note the favicon is encoded as a data uri in each page, and when sent in the same compressed response, it's only an increase of about 130 bytes. Reasons for my favicon design were:
  • pb = Pixel Beat = Pádraig Brady
  • It looks like RGB pixels
  • It looks a bit like a graphic equalizer (pixelbeat)
  • It looks like drum score (pixelbeat)

Menu System

The menu system that I use on the top left of the home page is based on "A revised and simplified flyout menu with THREE sub levels" from Stu Nicholls from the 28th of July 2006. It's CSS only, cross browser and falls back to list of links on non css browsers. No javascript required.

Note the primary menu items are both hoverable and have clickable links that load index pages. This is so mouse users can use the quicker method, while keyboard users or IE 6.0 users can still navigate the page. Note index pages can't include a hoverable menu so if people click in error then they're brought away from the quick menu. An acceptable compromise for increased accesabililty I think. Also if people find the hoverable menu difficult to navigate then they can just click the primary menu items to get the subelements on a new page. It would be nice to delay the display and undisplay subelements, but that would require javascript I think.

Since menu items actually overlap the page (while hidden), it causes slow page scrolling on firefox 1.0 on linux at least. One can see the left part of the page (overlapped by the hidden menu items) scroll first, and then after a noticeable delay the rest of the page scrolls. You can see the tearing best if you expand the menu the whole way and use cursor keys to scroll the page. Not too noticable when my pentium-m is forced to 1.7GHz but a bit painful when running at the normal 600MHz. Could firefox be more clever in this case? Hmm larger screens are worse :( even on 3GHz P4. Therefore I'll only enable the menu on the homepage for the moment, where there isn't any scrolling required. Note also that this tearing is much less noticeable in firefox if one sets the general.smoothscroll option to false (in about:config).

Adsense

The site uses adsense for monetization, mainly to see how this process works. There are adds on the left, which convert when clicked. Also there are link units at the bottom of each page which require 2 clicks to convert. In my experience the link units give 75% of the clicks and 50% of the revenue. Note there are CPM adds displayed on the left sometimes by google, which don't require user clicks to convert. I also present the google firefox referral button to IE users only, with the [if IE] ... [fi] construct. Google used to send me a cheque every month but since Oct 2006 at least have supported EFT directly to my bank account in Ireland.

Security

The main security issue I have to actively worry about is leechers. I.E. people downloading the whole site repeatedly, and people hotlinking (usually from posts) from high traffic sites. I'm not sure why some people download the whole site in a loop, but when I notice it, it's quite easy to stop with an iptables firewall rule (I'm hosted on apache on linux) like: sudo /sbin/iptables -I INPUT -s $leechers_ip -j DROP. I usually remove this firewall rule after a day or so, in case that IP address would be reused by a legitimate user. Sometimes I get persistent requests from a user with a variable IP and so I have to drop the ISP like: sudo /sbin/iptables -I INPUT -m iprange --src-range 125.62.95.0-125.62.127.254 -j DROP.

To stop people hotlinking to large files from high volume sites, I use the .htaccess file. For example, to stop any myspace and byethost6 users linking to particular pictures on my site I use:

#Note 'Options +FollowSymlinks' required for mod_rewrite
RewriteEngine On
RewriteBase /

RewriteCond %{HTTP_REFERER} .*byethost6.com.* [NC,OR]
RewriteCond %{HTTP_REFERER} .*myspace.com.* [NC]
RewriteRule ms_mirth/.+$ - [F,L]
[Update Nov 2014: The site was moved from a centos 4 to a centos 7 machine, thus getting security updates until 2024. Also around that time, cloudflare started providing transparent SSL support. Therefore a https version of this site is available, and after tweaking things a little, all content including any adds etc. are served over SSL giving no warnings in browsers. Also ssllabs' excellent security and compatability checker gives it an "A" score (click through the IP address for details).]

Miscellaneous

I found the technique used on the home page to vertically center the list of last 10 items, using a standards compliant code quite tricky. The key is to use a table, and set the height of it and all it's containers to 100% using CSS as can be seen in this example page.

For translated parts of the site I present links in the local language name. For example English, 中文, etc. I found the ICU locale explorer an excellent resource for looking these up, as the locale database the comes with linux (glibc) is not complete. For completeness, one can look up the local representation of the language name on linux using the locale lang_name command. To do this for Chinese for example: LANG=zh_CN.utf8 locale lang_name.

IE (even version 7) interprets grey as green!

IE 6 ignores the max-width CSS attribute, used to constrain the width of pages on this site.

© Mar 5 2007