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.
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 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 leepenney.com > 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.
PS Rank (Mobile)
PS Rank (Desktop)
WPT First Byte
WPT Fully Loaded
WPT Bytes (KB)
GTMet Load Time
GTMet Size (Mb)
As you can see, some stats remained the same, a couple were worse and some improved. A bit of a mixed bag.
Assuming you don’t have issues with your OS and/or have NodeJS already installed.
A paid tier is available.
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.
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.
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.
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…
Having decided to move leepenney.com 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.
I decided to use three different services to track my progress:
The site would remain on the original host, part of my package supplied by Vidahost, so DNS and server times should be consistent.
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.