Hugo と Netlify の相性が抜群
wordpress & レンタルサーバー時代(2016年初頭)
そもそもこのブログは最初は wordpress で作られていました。
wordpress 遅いし、PHP でいじるのも面倒そうだし、セキュリティのよくない噂を聞くし… と思っていたのですが、ブログシステムを作ったことがなかったので、最初としては良いかと思い、半年ほど運用をしていました。
しかし、wordpress & レンタルサーバーだといくつか面倒なことがありました。
- レンタルサーバーを安くしようとしていたため、FTP サポートくらいしかなく、ファイルのアップロードが面倒だった
(そのために rsync スクリプトとか色々とツールを作ろうとしたのは懐かしい思い出) - wordpress のプラグインをインストールするにつれて、サイトが重く & よくわからない挙動が表れた プラグインは最初から問題になると思っていたため、厳選してプラグインを導入していたのですが、それでもキャッシュ周りや認証、セキュリティ周りに手を加えたら、徐々にブログがノロノロに…
wordpress とレンタルサーバーの名誉のために言っておくと、wordpress も本腰入れて理解すれば十分に速くて安全なサイトを作れる のと、 レンタルサーバーも月額 1000円払えば十分なリソースと使いやすいファイルアップロードを有効にできました
しかし、個人のブログをホスティングする上では、wordpress の学習コストやチューニング、プラグインの動作確認や、月額 1000円の支払いというのは大げさな気がしました。
wordpress を導入して勉強になったことは、
- セキュリティ設定に注意を向けないと容易に攻撃をうける。
実際、僕のサイトも管理者用のログイン url にロシアやアメリカからのアクセスが残っていました。もちろん、パスを変えていたのとクレデンシャルのプラグインを導入していたのでログインはされてませんが。 - キャッシュがとても重要。だが面倒
wordpress のような動的 webサイトはデフォルトだとリクエストのたびに html を生成してしまいます。すると弱いレンタルサーバーだとまずレンダリングが遅いのと、クライアント数が多いと非常に遅くなりました。 そこで、CloudFlare の CDNを無料で使ったのですが、これにより相当 webページを見るのが早くなりました。
また DNS の設定やキャッシュの更新ポリシーなどについて学ぶ機会になり、いじるのは結構楽しかったです。 - プラグインは気をつけてインストールすればめっちゃ便利
wordpress がこれほど普及した要因としてプラグインのインストールが簡単というのがあると思います。特にフロントまわりのプラグインはブログ作成時に便利で、コードスニペットや数式、テーマなどを簡単にインストール、アンインストールできるのが良いです。
また上記のようなセキュリティ、キャッシュまわりのプラグインも無料で提供されているものがあるのは、学習コストの低下に役立っています。
Jekyll & レンタルサーバー時代 (2017年初頭)
2017年にもなってですが、ブログはログインだったり、ショッピングカートのような状態を持たないため、静的 webサイトで良くない? とふと思い立ちました(GitHub Pages - Wikipedia によると 2008 年にリリースされている)
GitHub Pages で利用されている Jekyll を試してみたところ、「あ、これでやりたいことが十分できるじゃん」と判断し、wordpress で作っていた記事をすべて Jekyll へ移しました。
このとき、wordpress でも markdown で記事を書くようにしていたため、Jekyll では yaml の meta 情報を追加するだけで記事の内容は移動できました(画像などの assets は後の hugo でも移行に苦しむのですが…
まず、静的 webサイトにすることで、セキュリティとキャッシュについてはほとんど考える必要がなくなりました。 静的な html として出力されている以上、管理者用のログイン画面もなければ、html 自体でキャッシュできるため、オリジンサーバーにはほとんど負荷がかかりません。
それに伴い、格段にページ表示速度が上がったのが大きなメリットです。
ただブログの記事を public なリポジトリで公開したくなかったため、カスタムドメインを設定できるものの、GitHub Pages は使いませんでした。GitHub の有料プランを利用している方は GitHub Pages でのホスティングが楽だと思います。
引き続きレンタルサーバーでほそぼそとブログの記事をアップロードしていたのですが、やはり、FTP での限界を感じ、これはいよいよ別のものに移行する必要があると考えました。
そんなとき、偶然知ったのが Netlify でした。
Hugo & Netlify 時代 (2017年後半)
Netlify はまず bitbucket の private repo をフックさせて自動でデプロイでき、しかも無料 だというのが衝撃的でした。 2018/12/16 現在も無料で、正直どんなビジネスモデルなのか気になるくらいです。
個人ブログで最低限必要なカスタムドメインの設定や、https 証明書(Let’s Encrypt) もサポートしており、申し分ありません。これまでつかっていたレンタルサーバー、なんだったんだ…
Netlify ではいくつかの静的 webサイトの自動ビルドがサポートされており Jekyll も例にもれずに利用ができました。しかし、いくつかネットの記事をあさっていると Hugo をホスティングしている例が散見されました。
Hugo に着目したのは、普段業務で使っている Go 言語で作られているからです。
静的 webサイトの問題点は記事の数が増えていくに連れて、目次の生成や複雑なレイアウトの理解に時間がかかるようになっていきます。 そのとき、コンパイル言語である Go で作られた Hugo であれば、Jekyll と比べて速度が期待できると考えました(もちろん、実際はアルゴリズム次第なので、XX 言語だから速いという話ではないのですが)
正直、Hugo を導入してから思ったのは「レイアウトやテンプレートの仕様が理解しづらい」というものでした。今でもレイアウトのカスタマイズなどで詰まることがあります。Ruby 好みという方は Jekyll で良いと思います。
Hugo は基本的に英語のドキュメントがメインで、カスタマイズを考えるとホームページのたくさんのドキュメントに目を通す必要があります。また、バージョンがまだ 0.X のため、仕様が完全に固まっているという感じではないので、それに伴う苦労もありましたが(後述)、いまは基本的なところ理解し、どんどん自分の好みの webサイトに仕上げていっています。
参考:
着手できた機能
記事のテンプレートを作成する Python スクリプト
「なぜ Python?」 と思われた方、すみません、個人的な趣味です。
gen_hugo_template.py — Bitbucket
$ python gen_hugo_template.py post -a you -f article-url -t "記事メインタイトル" -s "記事サブタイトル" --tags タグ1 タグ2
とすると、
---
author: "you"
date: 2018-12-22T10:40:26Z
title: "記事メインタイトル"
subtitle: "記事サブタイトル"
header_img: "img/post-bg-006.jpg"
tags: [タグ1, タグ2]
---
#
というテンプレートを作ってくれます。image や author 部分はご自身のでカスタマイズされてみてください。
スライド on web
スライドって画像の配置とか面倒なので、簡単なものは markdown で書きたいなと思っていたのですが、reveal.js で markdown スライドづくり でだいたい期待通りに web サイトでスライドを見せられるようになりました。
これでブログの url さえ共有できれば発表も行えるので非常に便利。 (過去スライドの一覧機能に見落としがあって、半年ほど表示できてなかったというのはここだけの話。今は Slides – Think Abstract で確認可能)
記事検索
2 年間以上ブログを作っていると、流石に過去の記事をたどるのが厳しくなります。
Google サイト内検索を導入すればよいのですが、一端のエンジニアとして検索エンジンとして、lunr.js を試しました。
実は 2018/8 くらいに導入していたのですが、Netlify の hugo のデフォルトバージョンが 0.17 であることに気づいたのが遅く、期待通りに反映されたのは 2018/12 でした…
HUGO_VERSION を 0.52 (2018/12 最新) の環境変数を設定して正しくビルとできるようになりました。 (古いバージョンの hugo は layouts の見る順番や場所がやや違いそう…)
参考:
- Hugo に全文検索を取り付けた | the right stuff
めちゃくちゃ参考になりました。ありがとうございます。
改善待ち案件
パフォーマンス改善
Lighthouse | Tools for Web Developers | Google Developers を利用して、パフォーマンスを極限まで上げたいなと考えています。
そのためには、画像の作り方から変えていく必要があったりと道は険しそうですが…
コメント
DISQUS って誰がつかってるの? って感じなので、これは Facebook コメントなりに変更したいなと考えています