こんにちは、全力開発部の @konoka-iori です。
今回、WordPressからHugoにブログを移行したので、移行を決断した理由や技術の選定、記事の移植、移行後の運用、これからの課題などを書いていきます。
なぜWordPressからHugoに移行したのか
この項目では、なぜWordPressからHugoに移行することを決断したのか、その理由を説明します。
WordPressの運用における課題
まず、WordPressからHugoに移行する理由の前に、WordPressをどのように運用していたかを説明します。
- 独自ドメインを取得。
- 日本国内のレンタルサーバー上にWordPressをインストール。
- Team Parity のサイト部門に所属する2～3人程度で記事の執筆・公開。
作業フローとしては、次のような感じです。この間、常にTrelloやGuildedなどで情報共有や意思疎通が行われていました。
- Trelloで新しい記事を申請し、承認をもらう。
- WordPressにログインして記事を作成し、レビューを依頼する。
- 担当者がレビューする。
- レビューが通れば公開する。
ほかにも記事の執筆や公開に関するルールやガイドラインがあり、それらの管理は Guilded やストレージサービスで管理していました。
このように外部サービスを多用していたため情報が分散してしまい、管理が煩雑になるだけでなく、記事を執筆する際にも複数のサービスを行き来する必要がありました。
運用面では、WordPress本体の更新やプラグインの更新、テーマの更新、バックアップ、セキュリティ対策など、WordPressを安全に運用するためには多くのコストがかかり、もはや技術的な負債となっていました。
Hugoに移行するメリット
そこで、WordPressからHugoに移行することで、次のようなメリットがあると考えました。
- GitHubでほぼすべてを管理・完結できる。
- 高速かつセキュアな静的サイトを構築でき、運用コストを削減できる。
- お馴染みのMarkdown形式で記事を書けるため、記事の執筆がしやすくなる。
これらのメリットに惹かれて、WordPressからHugoに移行することを検討しはじめました。
懸念事項
一方で、次のような懸念事項もありました。
- Hugoをはじめとする静的サイトジェネレーターに関する知識・知見がない。
- WordPressのプラグインで実現していた機能をどのようにHugoで再現できるかわからない。
- 作ったサイトをどこでホスティングすればよいかわからない。
やはり、WordPressの強みはなんといってもプラグインの豊富さと、視覚的に管理がしやすいことです。これらをどこまでHugoで実現できるかが重要だと考えました。
技術選定
これらのメリットと懸念事項に悩みつつも、Hugoに移行するためにはどんな技術が必要なのかを洗い出しました。
- Hugo: メインの静的サイトジェネレーター。
- GitHub:
- サイト本体のバージョン管理。
- 記事のバージョン管理。
- CI/CDの実行。
- Cloudflare:
- ドメインの取得・管理。
- サイトのホスティング。
静的サイトジェネレーターとしてHugoを選択した理由は、単純に有名で情報量が多いからです。 サイトの作成や記事の執筆・管理がGitHubで完結するからという理由もあります。
バージョン管理やCI/CDの実行にGitHubを選択した理由は、日頃愛用しているのがGitHubだからという理由もありますが、GitHub Actionsを使ったMarkdownの自動チェックなどを行えるからです。
ドメインの取得・管理やサイトのホスティングにCloudflareを選択した理由は、無料で利用できる機能が豊富に揃っているからです。
- Cloudflare Registrar
:
.devドメインが格安で取得できる。 - Cloudflare Pages : GitHub Actionsと連携して、静的サイトを無料でホスティングできる。
- Cloudflare Fonts : Google Fontsよりもプライバシーやパフォーマンスに優れたフォントを読み込める。
- Cloudflare Email Routing : 疑似的に独自ドメインでメールを送受信できる。
ほかにも、さまざまな機能が無料で利用でき、 HTTP/3(QUIC) などの最新技術にも対応していて、非常に魅力的でした。
Cloudflareのネットワークに最適化することで、サイトのパフォーマンス向上が期待できます。
開発環境の構築
Hugoへの移行を決断したころ、ちょうどDockerの勉強をしており、すでに取り組んでいたほかのプロジェクトもコンテナー化が進んでおりました。
DockerとVS Codeの拡張機能であるDev Containerを使って、HugoとWebサイトの構築に必要なツールの数々をセットアップして開発環境を構築しました。
Dockerについて学んだことをまた別の記事で詳しく書こうと思います。
Hugoのテーマ選定
Hugoに移行するにあたり、テーマも選ぶ必要があります。
数々のサンプルページを見て回りましたが、最終的には PaperMod に決定しました。
理由としては、以下の点が挙げられます。
- ダークモードに対応している。
- シンプルで読みやすいデザイン。
- 採用実績が多く、カスタマイズに関する情報量も多い。
- 活発に開発されている。
- ドキュメントが丁寧。
などが挙げられます。お気に入りのテーマを見つけることができてとてもうれしいです。
テーマのカスタマイズ
PaperMod をベースにかなりのカスタマイズを行いました。
このサンプルページ と比べると、ベースを残しつつも細部に違いが見られます。
カスタマイズした項目は次の通りです。
-
ライトモードの色調整
若干やわらかい色調に変更しています。 -
目次をサイドバーに移動（画面の広いデバイスのみ）
画面の広いデバイス（PCやタブレットなど）で目次をサイドバーへ移動させ、スクロールにあわせて目次が追従するようにしました。 -
見出しのデザインを変更
見出しのデザインを変更し、より目立たせるようにしました。 -
フォントの変更
以下のフォントを採用しています。要素 フォント名 選定理由 読み込み先 本文 Noto Serif JP 明朝体で美しく読みやすいから Cloudflare Fonts 見出しなど Noto Sans JP 定番のゴシック体で読みやすいから Cloudflare Fotns コードまわり Myrica M VS Codeで愛用しているフォントをそのまま採用 サーバー上のローカルフォント -
コードブロックにファイル名を表示
コードブロックの上にファイル名（言語名を書くことも可）を表示するようにしました。 -
「クリップボードに記事タイトルとURLをコピーする」ボタンを実装
記事下にあるSNSシェアボタンたちの上に記事タイトルとURLをコピーするボタンを追加しました。 -
ブログカードを実装
URLをそのまま貼り付けるだけでは可読性が悪いため、ブログカードを実装しました。 -
脚注や警告を実装
重要な情報を強調する際に使用できるブロック（デザインは GitHub風 にしました）を実装しました。 -
ボタンの色調整
ボタンの色や、マウスを乗せたときの色を変更しました。 -
その他の超細かい微調整たち。
正直、かなり細かいところまで調整を加えたのですべてをご紹介することはできません。そのうち余裕ができたら別の記事にしようと思います。
記事の移植
WordPressの記事は当然Markdown形式ではありませんので、まずはこれを変換する必要があります。
記事数自体はそこまで多くないので、Copilotに手伝ってもらいつつ手動でMarkdownにすることもできましたが、やはり面倒だったので自動化できないものかと考えていたら素晴らしいツールを見つけました。
ほかにもいくつか方法があるようですが、今回使わせていただいたのはこちら。（ちなみにこれが先述したブログカードです）
なんということでしょう。WordPressのバックアップから記事のデータを取り出し、Markdown形式に変換してくれます。これは素晴らしい。 おかげさまで節約できた時間でやるゲームのレベリング周回もはかどります。
おまけにカテゴリやタグなどのフロントマターもいい感じに変換してくれました。
今回の移行にあわせて古い記事を断捨離し、残った記事も一部手を加えたりカテゴリやタグを変更したりしたので、どうしても手作業は発生しましたが、それでもこのツールのおかげでかなり効率的に作業を進めることができました。
画像の移行
基本文字ベースのサイトではありましたが、いくつかの記事では画像も使用していました。
WordPressではPNG形式でアップロードして、プラグイン等でWebP形式への変換など軽量化・最適化を行っていました。
Hugoでは最新のAVIF形式と、WebP形式/JPEG形式を併用しようと思っていたのですが、画像の最適化処理を実装したらサイトが崩壊したのでひとまずAVIF形式でのみ対応することとしました。
AVIF形式は 主要なモダンブラウザで対応している ようです。AVIFは非常に高い圧縮率を誇り、画質を落とさず軽量化できるためより積極的に活用していきたいと思っています。
移行後の運用
移行後、サイト本体と記事の管理はすべてGitHubに集約され、これまで外部ツールに分散していた情報もGitHubのリポジトリ内にまとまりました。
執筆者の作業フローもGitHubですべて完結するようになり、より効率的な作業が可能になりました。
簡単に作業フローを説明すると次のようになります。
- Issueで新しい記事の申請を行う。
- 承認されたら、ブランチを切って記事を作成する。
- プルリクエストを作成してレビューを依頼する。（ここでGitHub Actionsが走り、チェックを行う）
- レビューが通ればマージして公開する。
GitHubをよく使っている人にとって、この作業フローは比較的馴染みのあるものだと思います。
また、GitHub Actionsを使ってMarkdownの自動チェックを行うことで、品質を保ちながら効率的に運用できるようになりました。
GitHubを使ったサイト本体や記事の管理・運用の詳細についてはまた別の記事を書こうと思います。
これからの課題
移行を終えたものの、課題は山積しています。
- カテゴリやタグの管理
現状、カテゴリやタグの管理は手動で行っているため、表記揺れやミスが発生しやすい。 - ショートコードの管理
ブログカードや脚注、警告などのショートコードは手動で記述しているため、（とくに慣れていないうちは）ミスが発生しやすい。 - プレビューの改善
現状、記事を執筆しているときはMarkdownのプレビュー機能を使うしかなく、ショートコードの確認や、実際の画面でどのように表示されるかを確認するのが難しい。
移行してみて
課題はまだまだ残っているものの、WordPressからHugoに移行してよかったと感じています。
全力開発部のメンバーからはよりテックブログらしいデザインになり、使い慣れたテキストエディターで記事を書けるようになって作業がしやすくなったと好評でした。
運用面ではGitHubを使った作業フローが効率的で、記事の品質を保ちながら運用できるようになりました。情報をGitHubに集約できたのも大きなメリットです。
WordPressのメンテナンスから開放され、記事の執筆や品質向上により集中できるようになったのはうれしいです。技術的な負債も解消されました。
これからも日々学んだことなどを発信していきたいと思います！