
I Moved My Blog Back from Hatena Blog Pro to Hugo
Table of Contents
- Top
- Purpose of Migration
- Wanted to reduce running costs
- Wanted to manage content in markdown
- Wanted to increase display speed
- Want to open-source in the future
- Other Efforts to Cut Corners
- Using iframely
- Using AddToAny
- Using cloudinary
- Future Plans
- Fine-tuning the design
- Open-sourcing
- Properly uploading articles
- Summary
A few years ago, I was using Hugo+Netlify to create my blog, but for some reason, I migrated to Hatena Blog Pro. In the end, I returned to Hugo and hosted it on Amplify Console, so I want to leave a memo to avoid making the same mistake.
Purpose of Migration
- Wanted to reduce running costs
- Wanted to manage content in markdown
- Wanted to increase display speed
- Want to open-source in the future
Let's look at each of these reasons.
Wanted to reduce running costs
With Hatena Blog, a Pro contract is required to use a custom domain.
At 1,008 yen/month (equivalent to 600 yen/month with a two-year contract), it's quite expensive.
If I were fully utilizing the Pro features and updating daily, it might be justified, but I felt it was wasteful as I was hardly using them.
...Why did I migrate in the past?
Moreover, there are now various options available, including Hugo.
So, this became a major reason for migrating.
However, Hatena Blog's own ranking, star, and subscription features are powerful.
If you find value in these, migration might be difficult.
Wanted to manage content in markdown
Hatena Blog's editor and dashboard were painful for a modern programmer.
I was constantly battling the fear of accidentally publishing or forgetting to save.
With Hugo-like markdown management, cross-article searching with grep and bulk replacements become extremely easy.
Also, if you just upload to Github, management is easy, and links can be written simply.
Wanted to increase display speed
Since this blog doesn't have much effort put into it, at least the display speed should be increased out of respect for visitors (probably).
Hatena Blog's AMP support has been in beta for a long time, and it doesn't seem to support HTTP/2.
Basically, there are no updates, which is good in terms of stability, but it's also true that new technologies can't be used.
Additionally, it's well-known that Netlify's free plan is slow because there's no edge in Japan for CDN.
As a result, I decided to make it a static site with Hugo and host it on AWS Amplify Console.
After migration, looking at PageSpeed Insights on mobile, the top page score improved dramatically from 35 to 96.
The scores for each page aren't as dramatic as the top page because Disqus seems to be blocking, but they improved by about 10 points overall.
Want to open-source in the future
I think "article revision history" and "subscription function" are difficult to implement on websites.
If the revision history is publicly available to visitors, it provides reassurance, but WordPress and Hatena Blog only provide history for editors.
Subscription is quite difficult, and it's currently challenging unless it's an established service like Hatena Blog or Qiita (people don't really click on "subscribe by email", right?).
Focusing on this site, these can be satisfied by publishing the site itself on Github.
Of course, you need a Github account to subscribe, but that's fine for an engineering blog (or one that claims to be).
With static site + Amplify Console, there's no need to put anonymous information in the repository, so it's easy to publish.
I've added "in the future" to check if there are any problems, but I plan to publish it soon.
Other Efforts to Cut Corners
Using iframely
Since there's not much PV, all card-type links are thrown into iframely for rendering.
The operation of just passing links to shortcode has low customizability, but it's easy and convenient for changes and enumeration.
Using AddToAny
Share buttons are another thing that can be troublesome to create yourself.
AddToAny generates nice share buttons just by pasting a link.
By the way, I also tried AddThis, but it was blocked by AdBlock, so I went with AddToAny.
Using cloudinary
I was already doing this, but I felt its convenience again during the migration.
Images are hosted on cloudinary, and links are pasted to them.
This means that even if the article production method changes, nothing needs to be done regarding images.
It's highly portable, so I recommend it.
Future Plans
Fine-tuning the design
I'd like to adjust the design when I feel like it.
Especially, I want to suppress the iframely cards that are very assertive.
Open-sourcing
As mentioned above.
Properly uploading articles
This is the most important thing.
Summary
If you have few PVs, you don't need to worry about most things