土日を使って、このブログをHugoで作りました。
なぜ静的サイトジェネレータなのか
ご存じない方もいると思うので軽く説明をすると、HugoとはGo言語で開発されている静的サイトジェネレータです。MarkdownをもとにHTMLを書き出してくれるので、それをアップロードするだけでホストができます。このブログは、そのHugoを用いて制作しました。
このブログを作るにあたって、最初からWordPressのように動的なCMSは使わないと決めていました。
1つ目の理由は、ホストが複雑になるからです。一昔前は、変更を反映するためにデプロイをしないといけない静的サイトジェネレータの方が管理が面倒な気がしていましたが、最近は状況が異なってきています。NetlifyやFirebase Hostingなど、静的サイトを簡単にホストできるサービスが増えているからです。静的サイトジェネレータはMarkdownの集合なのでGitで管理される場合も多いと思いますが、それと連携してPushするだけでデプロイができます。
このブログもGithub + Netlifyでホストしていますが、デプロイの設定はnpm scriptsにHugoのビルドコマンドを書いて、あとはNetlifyの管理画面からnpm run buildを指定しただけです。
2つめの理由は、表示速度の問題です。一般論として、リクエストを受けてからコンテンツを生成する必要がないため、静的サイトの方が早いと言われています。しかし、WordPressでいえば最近のPHPは遅延をほとんど感じないほどパフォーマンスが高いですし、本当に表示速度を上げたいなら大きなサムネイルなんてやめるべきです。
決め手となったのは、CDNの問題でした。秋からアメリカに行く予定なのですが、Netlifyなどの静的サイトはCDNが簡単に効くので世界中どこでも快適に閲覧できます。日本語で書くつもりなので日本の方に読んでもらうことを想定しているので、CDNを使わないと自分か読者かどちらかが太平洋分の遅延を感じることになってしまいます。動的サイトでもCloudFlareなどを使えば良くなるのかもしれないですが、静的サイトの方がヒット率が高いのは間違いないでしょう。
最後に、できることの問題です。これは特にWordPressの話ですが、プラグインによって文字通りなんでも実装できてしまいます。ミニマムに使えばいいだけの話ではあるのですが、自分がプログラムが書けるので拡張したくなってしまいます。静的サイトであれば、複雑なことを実装するのは不可能ではなくても非常に面倒なので諦めがつきます。
なぜHugoなのか
静的サイトジェネレータと一口にいっても、本当に様々な種類があります。Hexoや話題のGatsbyも検討しましたが、Hugoを選んだのは
- パフォーマンス
- テンプレートの書式
- シンプルさ
といった理由によります。
HugoはGoで書かれているのでパフォーマンスには定評があります。コンテンツが少ないこともありますが、現在のところビルドは一瞬で終わっています。ライブリロードもミリ秒単位で終わるので、プレビューをしながら記事を書くことも快適です。
また、Goのテンプレートを使うことになるのですが、これが好みでした。{{}}で囲む書き方がAngularっぽいのもありますが、謎にJavaScriptが登場するHexoや、そもそもJSXのGatsbyよりも個人的に良かったです。
Gatsbyのアドバンテージは、サーバーサイドレンダリングによる2ページ目以降のロードの速さだと思います。dev.toの速さが少し前に話題になりましたが、確かにSSR+CDNは速いです。
しかし、SSRをするためにはLambda的なものであれサーバーが必要になりますし、そもそも私はSSRは人類にはまだ早いと思っているので、ここはHugoになりました。
人類がSSRをする準備ができたら、Gatsbyに以降するかもしれないです。
テーマを作った
Hugoのデメリットとして、よく「公開されているテーマが微妙」と言われます。Hugoのテーマディレクトリを見ると、「まあ確かにな…」という気持ちにもなります。
ただ私はゼロからデザインを作るセンスはないので、今回はColorlibで配布されているStuffというHTMLテンプレートをベースにHugoのテーマに移植しました。
元々はBootstrap3, jQuery, スライダーのプラグインなどに依存しているのですが、Bootstrapは4にアップグレードし、jQueryは必要なものはVanilla JSで書き直して駆逐しました。テンプレートにはSCSSが付いているのでそれを利用し、Webpackを使ってビルドしています。
モバイル表示における上部のメニューは、移植が大変そうだったのでMicromodal.jsを使って横からのスライドではなくオーバーレイとして実装しました。
久しぶりにBootstrapを使いましたが、必要な部分だけインポートして使えばサイズも抑えられて便利だと思いました。複雑なコンポーネントを使わなければ、jQueryも必要ないみたいですね。
画像を変換するCLIも作った
静的サイトジェネレータを使うにあたって、一番どうするか悩んだのが画像の管理です。
WordPressであれば、テーマでサイズを指定しておけばアップロードしたときに画像のリサイズは自動でやってくれます。愚直にやると
- Photoshopでリサイズと圧縮する
- 書き出したファイルを
staticフォルダに移動する - Markdownに
と書く
という手順を踏むことになるのですが、普通に面倒です。そこで、VorpalというNode.jsのライブラリを使って
- 出力サイズを候補から選択
- 画像のリサイズ(Sharpを利用)
- 年月を入れたディレクトリへの移動
- マークダウンにコピペできるスニペットの出力
をやってくれるCLIを作りました。
このように、image [画像へのパス]とタイプすると、事前に指定してあるサイズ群から1つを選択し、そのサイズにリサイズして、マークダウンにコピペできる形式で出力してくれます。
他にも、post [パーマリンク] [タイトル] [サムネイル画像へのパス]でサムネイルとタイトル付きのポストを生成してくれたりもします。
blog.jsとしてGistに貼ったので興味がある方は試してみてください。vorpalとsharpだけdependenciesとして必要です。
本当はテーマごと公開したいのですが、結構オレオレな仕様が多くなってしまったので、それをマトモにするか、ちゃんとドキュメンテーションするかしてからにしようと思います。
さいごに
テンプレートを使ったこともあって、なかなかキレイにできたのではないかと思っています。
ネックだった画像処理も、時間はかかりましたが自分でツールを書いたことでかなり快適になったので、サクサク更新できそうです。
Vorpalは、そのままだとasync/awaitに対応してなかったり微妙な部分もありますが、軽いツールを作るには良さそうです。JavaScriptもサクサク書けていいですね。
環境は整ったので、更新できるようにがんばります。
Thumbnail Photo by Lee Campbell on Unsplash Lee Campbell