TL:DR : This series of posts details my migration of this blog from Wordpress to Hugo. Over the course, I intend to detail all the Technical and SEO related requirements I’ve considered along the way and how I achieved them. Part 1 covers the compliance requirements of hosting a blog and how the rising costs of my previously underperforming blog instigated this migration.

 

Cost vs Conformity

Maintaining your own discoverable, personalized corner of the Internet - like a blog - is becoming increasingly more complex these days. Don’t get me wrong - there’s always Medium and Tumblr and Facebook Notes for all that socialized goodness - but nothing beats having your own setup. A digital abode where you get to pixel push till kingdom come and not be bound by the artificial imposition of the preferred type of content you are ‘encouraged’ to produce.

Freeform writing, with custom design and content ownership is where its at. Who isn’t motivated to write just the way they want, and in the form that they prefer, after reading an issue of NextDraft by Dave Pell. The guy’s a genius!

Despite so - recent and the continually growing requirements from the giants of discovery like Google and Facebook tends to leave most of us in a conundrum of cost vs conformity.

This post is a precursor to a series of how I went about migrating my Wordpress instance to a Hugo powered blog. The following will cover the basic cost vs conformity requirements that I considered.

Cost Conformity
Custom Hosting either at a CMS as a Service provider eg: WP Engine, Flywheel OR Own Server at Digital Ocean Little to no hosting cost but reliant/restricted to provisioned services eg: Medium, Facebook Notes
May need to fork out extra for CDN like capability to serve media faster No CDN cost requirements but again - limited to service offering
Full design flexibility, minimal to no restrictions Little to no design flexibility, restricted to publisher format
May incur cost to add-on SSL and/or HTTP/2 Compliance No additional cost required since its the Publisher’s best interest to increase discoverability
Full content ownership Partial to no direct content ownership

  

Prioritizing ‘Data Ownership’ means you need to comply

My approach to the above (which may or may not vastly differ from yours), was to place a significantly higher weightage on ‘Data Ownership’. This wasn’t necessarily related to the value of the content I was producing but more about learning to control its provisioning and presentation within mediums and channels of choice.

I wanted to understand the nuances to running and maintaining a somewhat discoverable (though not necessarily popular) blog.

This however comes with its own cost and compliance requirements.

To maintain a fairly discoverable and compliant blog these days, you’d have to ensure the following criteria is fulfilled to the best of your abilities:

Source: GT Metrix

Google PageSpeed

  • Minify JavaScript
  • Leverage browser caching
  • Enable Keep-Alive
  • Inline small JavaScript
  • Minify CSS
  • Enable gzip compression
  • Minify HTML
  • Avoid bad requests
  • Avoid landing page redirects
  • Defer parsing of JavaScript
  • Inline small CSS
  • Minimize redirects
  • Minimize request size
  • Optimize images
  • Optimize the order of styles and scripts
  • Put CSS in the document head
  • Serve resources from a consistent URL
  • Serve scaled images
  • Specify a cache validator
  • Specify a character set early
  • Combine images using CSS sprites
  • Avoid CSS @import
  • Prefer asynchronous resources
  • Specify image dimensions
  • Avoid a character set in the meta tag
  • Remove query strings from static resources
  • Specify a Vary: Accept-Encoding header

 

YSlow

  • Add Expires headers
  • Use a Content Delivery Network (CDN)
  • Compress components with gzip
  • Make fewer HTTP requests
  • Reduce DNS lookups
  • Minify JavaScript and CSS
  • Make AJAX cacheable
  • Remove duplicate JavaScript and CSS
  • Avoid AlphaImageLoader filter
  • Avoid HTTP 404 (Not Found) error
  • Reduce the number of DOM elements
  • Use cookie-free domains
  • Use GET for AJAX requests
  • Avoid CSS expressions
  • Reduce cookie size
  • Make favicon small and cacheable
  • Configure entity tags (ETags)
  • Make JavaScript and CSS external

and this is just for base performance.

To give you an indication of my current level of compliance post migration, I ran the above scan and yielded the following results:

Link to PDF Document hosted on Google Docs: GTMetrix Scan Report for BrianRitchie.me

You’ll notice in the report that Browser caching and Expiry Headers are scored lower - and that’s because I have intentionally not implemented it yet. I’m still rapidly editing the blog and want the most recent changes to be loaded when a post is viewed.

I’ll however ensure that a post in this series covers the implementation of asset caching within the host of my choice.

   

How exhorbitant are the ‘so-called’ costs I speak off?

In all honesty, not that much - but it does add up.

For the longest of times, I use to maintain my Wordpress blog over at DigitalOcean (DO) on their $5/month droplet. This gave me a 512MB server with 20GB of Disk Space and 1TB of Data Transfer. This was wayy more than I needed…well except maybe the memory.. but it was plenty for a rather sparsely maintained blog.

I originally configured my Wordpress installation myself and while it was extremely fast with my Apache-Nginx-Varnish-MariaDB stack, it turned out to be too rigid over time for quick and easy maintenance. I had severely locked down the filesystem and deployment options to keep the instance secure but this of course resulted in me having to spend that much more time getting updates deployed and content published.

At the beginning of January 2017 - I switched over management to ServerPilot - which while extremely simple to setup and get going, resulted in me having to take a dip in performance because I didn’t necessarily opt for the paid caching plugins recommended and didn’t want to upgrade my DO droplet with more memory primarily because I couldn’t justify paying more for a blog that I hardly maintained but still wanted to keep alive.

It is also important to mention that neither of these hosts have any issues - in fact, I continue to remain massive fans of both of them, amazing Service Levels and Support Teams and had I not been geeky enough to consider a migration, I’d still be hosting my site on one of them.

On January 18th 2017 - I received an email from WordFence detailing a new compliance requirement which essentially detailed that with the release of the Chrome browser version 56, all sites without SSL would essentially be labelled ‘Non-Secure’. This bothered me - A LOT. I started researching how to implement SSL for the then Wordpress site. Implementing it via ServerPilot’s native interface would involve an additional $10/month - again for a blog I hardly maintained - which while perfectly justified for their product offering, didn’t really make economical sense for me.

Fortunately, thanks to the amazing service provided by Let’s Encrypt and some extensive research, I found some rather ‘hackish’ ways to implement SSL for Free on my ServerPilot configured instance. The whole process however, left a rather sour taste in my mouth. At this point, I had a DO-hosted, ServerPilot configured, personally ‘hacked’ Wordpress blog that was still grossly underperforming.

The Pingdom snapshot below will give you an indication of how bad the then performance of this blog was before migration:

Pingdom Scan of BrianRitchie.me on Wordpress

Something had to be done and quick - because for every hour that my DO droplet was running - I was essentially incurring cost for something I was essentially not really satisfied with.

  

Enter Hugo - The Static Site Generator that Saved My Blog

Hugo is a modern static website generator engine written in Go by Steve Francia aka spf13. To summarize Hugo in two words - while a rather egregious disservice - is rather apt. Its AWESOME!

Hugo is fast. Hugo is simple. More importantly - Hugo just works.

Its being actively developed and has a rather accepting community surrounding it - I believe primarily due to Steve himself being very open and accessible.

Their documentation is top-notch and given its wide adoption - finding resources to address some of my initial queries and concerns was as simple as doing a Google search.

Thanks to Julia Evans blogging about her migration to Hugo, I decided to take the plunge.

In my next post - I’ll detail out the technical aspects of the migration.