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.
|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
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:
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.