QR Code contains TinyURL of this article.Reboot

I haven’t published anything here for a while. When my posting activity drops off it’s usually an indication that I am up to something behind the scenes. I tend to forget about content if I’m working on new features or a redesign. The recent period of inactivity is no different.

I determined to make the Perpetual βeta website more usable on mobile devices and, if possible, shave a couple of hundred milliseconds off the load time. A redesign was in order.

But this is more than just a cosmetic makeover. This is a complete re-factoring of the site.

In 2013 the average page-weight of 300,000 of the Web’s most popular websites was ~1.7MB. The average number of HTTP requests made was 96 per page. This seems ridiculous to me and, in a world where clients are increasingly browsing from mobile devices, often with limited data allowances, is disrespectful of the client and wasteful of expensive bandwidth (PDF).

While the previous version of this website was lean — average number of HTTP requests per page: 10; average page-weight: 200‍KB; load time: ~1s — I could see that there was still room for improvement. So I rolled up my sleeves, launched my editor and got to work.

The Purge

I have removed the following components from the previous version of the website in my quest for speed and an ethereal page-weight:

PHP / GetSimple CMS
I now use nanoc to locally generate the website, from Markdown sources, before I upload it to the server as a collection of static HTML pages and supporting files. There is no longer any need for a CMS on the server nor for the PHP interpreter to run it.
Google Fonts
I can’t justify the additional HTTP request(s) and increased page-weight that comes with using a web-font.
With my previous design I used jQuery to handle Ajax, keyboard navigation and visual effects. Both the Ajax and the visual effects were unnecessary, so I have removed them. I decided to keep the keyboard short-cuts as I feel their utility outweighs their cost. But, there is no longer a need for jQuery as I am handling the keyboard navigation with pure JavaScript, courtesy of Mousetrap.
I must have used Fancybox, or planned to use it, at some point. However, I wasn’t employing it anywhere on the website, so I’ve discarded it now.
Font Awesome
I love Font Awesome. I think icon fonts are a great idea and I particularly liked the style of the Font Awesome icon set. But, I was only using 6 of the 360+ icons in the set. There is obviously no point in having the overhead of an icon font to then only use ~1.5% of the available icons. I have now replaced those 6 icons with SVG equivalents. These are in-line to the HTML (no additional HTTP requests).
OpenStreetMap is a fantastic mapping service and is perfect for implementing GIS features on a website. I was using it to show the geographical location of where I took the photos featured in my Camera Roll. Realistically though, there was no real value to my readers in knowing precisely where I was when I took a photo. I generally provide location cues in my photo titles or descriptions. OpenStreetMap then, while undoubtedly cool, didn’t really justify its footprint.

Other Notes

The “flat” design, which is trending all over the Web at the moment, arises more from my twin aims of creating a responsive site and of decreasing page-weight than from any urge to follow a fashion.

I am using Pygments to handle the syntax colouring of code samples.

I found Apple’s iOS Simulator to be invaluable while developing the responsive aspects of the website. I also used Microsoft’s IE virtual machines extensively. I used ngrok to expose my local Apache instance to the Internet so that the iOS Simulator and MSIE VM‍s could access it.


I have replaced my PHP-based “Camera Roll” with a static gallery that I generate locally with a fast C binary — a modernised version of swiggle — that I am calling Toscani (after the famous Italian photographer). I have designed the Camera Roll to be responsive and, like the rest of the site, to use JavaScript only for keyboard navigation.

I have removed all unnecessary distractions from the Image Viewer to put the focus on the image itself. I have embedded basic Exif information for an image in the page source. Toscani renders images to fill the browser window — where possible — while maintaining their aspect ratio. I am presenting photos against a dark background as this has the effect of emphasising their colour.

You can retrieve the full-size version of any image by removing the .html suffix from the image page’s URL.


  • Base HTTP requests per page: 4 (the favicon and one file each for the HTML, JavaScript and CSS);
  • Average page-weight: 100‍KB;
  • Load time: ~300-600ms.

This represents a considerable improvement over the previous version.

Final Thoughts

Whilst rebuilding the website I have realised that I spend more time on coding and testing than I do on creating content. That’s because for me, that’s where the fun is. If I can improve something, then I will. If I can shave a couple of hundred milliseconds off the load time, then I will.

I have decided that, in the future, I will aim for a maximum page weight of 100‍KB.

Does it Work?

This is my first attempt at building a responsive website. I don’t doubt that I’ve made mistakes while doing so. If you find something that’s not working on your device then please let me know and I’ll fix it post-haste.

Updated: 5th April, 2014.

I had incorporated an inline Base64-encoded author image into the design. I noticed that this was visibly slowing page rendering on the initial paint. I have now replaced this with a standard JPEG image. This means that there is an additional round-trip to the server but it has resulted in an increase to the perception of speed. The image is cache-able so will only result in a single additional request, whereas the browser has to render the Base64-encoded image on each page view. It is clear then that the static image is superior in this case.