Front-End Markdown Gallery Script

When I converted one of my sites from WordPress to static, I lost some things. One of those was the ability to easily generate a gallery of images; thumbnails that link to larger versions.

Markdown, which is what my posts are now written in, is great for writing without the overhead of a having to wrap everything in raw HTML or stop to select icons in a WYSIWYG, but it also lacks the ability to generate the code for a simple gallery. So my only option would have been to write HTML in the middle of the text.

Instead, I whipped up a bit of JavaScript to scan the page for lists that consist solely of images (linked or not) and adds HTML to make it easy to style them into a gallery (for example, wrapping the list in a div tag and converting the list items into figures and figcaptions).

You can find an example in this post.

More details and the script itself can be found on Github.

Hosting a Site on Surge

Having converted one of my sites to a static one, I decided to try out some of the alternative options to traditional hosting packages. I drew up a list of a few options and set about trying to get my site online.

Getting Started

I began with Surge because it looked easy (having started to wade through the Google Cloud Storage instructions, which did not). That didn’t exactly prove to be the case because the dev server I happened to have the site on is running Ubuntu Precise Pangolin (12.04 LTS) and the latest version of NodeJS in the registry is old.

I ended up following the instructions here to get it installed:

curl -sL | sudo bash -
sudo apt-get install -y nodejs

I still got a bunch of warnings from npm about deprecated this and that, so ran the suggested command:

sudo npm -g install npm@latest

Finally, I was able to install Surge.

Creating a Site

I switched to the folder path for my static site and used the following command to create a CNAME file:

echo > CNAME

I then typed in the surge command and followed the prompts to create a new account and away it went.

After it had loaded the files and they had propagated to the CDN I got a success message.

I then headed over to my domain registrar and set up some CNAME records as suggested here.

Within seconds I was up and running on Surge.


In my optimization post, I stated the results of various speed tests, which I ran again once uploaded.

Original hostTest host
PS Rank (Mobile)88/10088/100
PS Rank (Desktop)93/10093/100
WPT First Byte0.156s0.464s
WPT Fully Loaded2.892s5.051s
WPT Bytes (KB)1,0931,093
GTMet YSlow88%92%
GTMet Load Time2.5s1.5s
GTMet Size (Mb)1.051.05
GTMet Requests1515

As you can see, some stats remained the same, a couple were worse and some improved. A bit of a mixed bag.


Set-up difficultyGoodAssuming you don’t have issues with your OS and/or have NodeJS already installed.
Set-up timeGood
CostGoodA paid tier is available.

Final Thoughts

I’m not a massive fan of having to install things (the entire of NodeJS and npm in this case) just to upload files, but once I managed that feat the process was very smooth and literally took seconds, so it was worth the effort.

The basic tier is free and there’s a paid one at $13 a month.

So far, so good. The site was loaded 27th Jan and I’ll run it for a few weeks to see how it goes before heading off for the next host.

Experiments in Alternative Hosting

I’ve pretty much always hosted my sites in a shared LAMP environment. My host, Vidahost, has been great and their cloud hosting is the next step up from traditional cPanel fare. It’s been very reliable and is packed with features. With the re-emergence of static sites, the range of ‘hosting providers’ has increased though.

Many are non-traditional. In fact a large number are off-shoots of the gobs of storage and other services you can now find in the cloud, or are at least built on them. I have already dabbled with Github Pages, which is one example.

With that in mind, I set about drawing up a list of places to try with my newly static site. Continue reading…

Tips for Building a Site with Hugo

The documentation for Hugo is generally very good, but I ran into a few areas where it left me confused, or useful things were missing. I thought I would write up some of things I struggled with (and will possibly add to the official docs).

Some of these were down to migrating from an existing site and wanting to match things like URLs.

Variable Casing

I found it often confusing, sometimes bewildering, as to why certain variables weren’t appearing or evaluating, only to find the casing wasn’t correct.

In the layouts, variables are generally camel-cased (except for parameters in the front matter, which are all lowercase), but then you get things like RSSLink rather than RssLink and BaseURL rather than BaseUrl.

This is also true of the config file used to control the site. I found baseurl to work, rather than baseURL as stated in the docs (although the examples have it all in lowercase). A seemingly missing variable is rssURI, which defines the filename to use for the generated RSS feed (see below) and completely fails all the other ‘standards’ for variable names. Continue reading…

My Attempts at Website Optimisation and the Results

Having decided to move to a static site (using Hugo), I thought I would try and make a few improvements to help boost page loading times and share both my methodology and the results of what I did.

Measuring Progress

I decided to use three different services to track my progress:

  1. Google’s PageSpeed Insights
  2. Web Page Test
  3. GT Metrix

The site would remain on the original host, part of my package supplied by Vidahost, so DNS and server times should be consistent.

Round 1

Removing Unused CSS Styles

I started with a simple one: removing unused CSS styles from the stylesheet. You always end up with unused ones over time, more so in my case as I think I adapted it from a WordPress theme of some sort.

Method: I used the Audit tab in Chrome’s Developer Tools to do this. Continue reading…