masyus.workをWordPressからNuxt3 + Nuxt Content v2へ移行しました [前編]
2024/07/06
masyus
2024年6月、このブログをWordPressからNuxt3 + Nuxt Content v2へ移行しました。個人開発として取り組んでいたため毎日約1〜2時間朝活して開発時間を確保し、約2~3ヶ月で移行完了しました。今回は移行した背景を紹介いたします。
WordPressを利用していた経緯
元々masyus.workは2018年頃に個人の技術ブログとして立ち上げました。当時WordPressを選定した理由は
- LAMP(Linux, Apache, MySQL, PHPの略語)を主体とした開発経験が多く、その経験が活きやすかったため
- 自分自身で様々なカスタマイズができるため
の2点があったためでした。WordPressはPHP製で且つMySQLを駆使するため、1.は特に大きな選定理由になったと記憶しています。
WordPressのメリット
1. 数多くのテンプレートがあり、ブログ公開までスピーディーにできる
無料・有料で様々なテンプレートが公開されており、自分にあったデザインをすぐに導入できるのが良いと感じました。反面、細かいデザインの調整を自力でやる必要があるのは面倒に感じるところではあります。
2. プラグインが便利
お問い合わせフォームやSEOのAll in oneパッケージがプラグインとして簡単に導入できるのが気楽でした。特にお問い合わせフォームはスパム対策等含め真面目に作り込む場合、相応の工数を要します。そうしたものがプラグインとして広く世に出回っているのは有り難かったです。
WordPressのデメリット
かくして、WordPressを採用してmasyus.workを構築・運営し5年が経過しました。ですが、長く運用する中で課題も沢山出てきました。以下に感じた課題を列挙します。
1. 地味にサーバー代がかかる
当時はXserverを活用していました。実務で活用した経験があったため選定したのですが、一番安いプランで毎月1,000円程度かかり、年額支払いにすることで安くしていました。
ただ、当初は気にしていませんでしたが年額支払いにすると年に1回突然1万円以上の請求が届き、「結構高いな。。」と逆に感じてしまうのです(とはいえ月額支払いよりも安くなってはいるのですが)。これが地味に手痛いと感じていました。
気持ち的には月額支払いに切り替えたほうが良かったのかもしれませんが、それ以前にシンプルに出費が気になるようになりました(我が家に子供が生まれて以降、家計管理を徹底するようになってからは特に)。
2. PHP, WordPress, MySQL等追随すべきバージョンアップデートが多く、管理が億劫になった
WordPressはデータベース(MySQL)を駆使して構成された、多様なニーズに応えられるCMSです。様々な機能を搭載しています。例えば運営するメディアの
- 記事数が多い
- 多数の記事執筆者がいる
- メンテナンスをする人が常時いる(エンジニア・非エンジニア問わず)
場合、管理観点でWordPressは候補の1つになると思います。
ただ、一個人でWordPressで運営する場合は話が変わってきます。個人開発の場合は特にメンテナンスに割ける工数も限られますし、WordPressで自動アップデートを適用していたらある日突然、PHPのWarningエラーが出るようになる等が発生することもあります(実際ありました)。
セキュリティや新機能の観点で考えれば自動アップデートに追随できるほうが望ましいですが、最新バージョンに追従する必要のある要素が多いのは考えものです。
3.プラグイン管理が辛い
導入時は最新バージョンで、コミュニティによるバージョンアップも積極的に実施されていましたが、
- いつの間にか更新が止まってしまった
- 脆弱性が見つかった
プラグインもあります。そのようなものが見つかったら早めに代替を探す必要があるのですが、これもやや面倒でした。ある程度の規模感で開発されているプラグインをなるべく使い、人気がない・もしくは個人が作成したプラグインはなるべく使わないようにすることで多少は回避できます。
前述したバージョンアップデートと同じことが言えるのですが、WordPressは世間に広く浸透していることもあり、日常的にアタックが来る(Apacheのログを見ていると毎日何らかのアタックと思しきアクセスがよく来る)のでセキュリティには敏感でいるほうが良いと思います。
4. Page Speed Insight(PSI)の向上が難しい
PSIに関しては導入するテンプレートに依存する部分が多く、SEO対策を考慮されたテンプレートであれば多少高い点数を弾き出せます。ですが、自前でコンテンツや機能をカスタマイズした状態で100点を目指す場合は地味に工数を割く必要があり、大変です。過去にやったことはありますが、JavaScriptファイルの読み込みやCSS・画像表示のチューニング等、対応すべき項目が多くあります。
5. ソースコードをGit管理しづらい
WordPressの場合、絶対にGit管理できないこともないですが、何のディレクトリはGit管理すべきで、何のディレクトリはGit管理すべきでないか(アップロードした画像等)を判断するのが面倒でした。特に頭を悩ませたのは
テンプレートやプラグインもGit管理したほうが良いのか(MySQLにデータを持っている場合、ソースコード管理だけでは足りないからどうするか?)
でした。これは真面目に向き合ったことがないからもありますが、未だ最適解を見出せていません。
6. ステージング環境を真面目に準備しようと思ったら結構面倒
個人でWordPressでブログ構築する場合、ステージング環境を準備するケースのほうが珍しいと思います。ですが本番環境でfunctions.php等を直接編集する場合、万が一シンタックスエラーが出たらブログ全体が500番エラーになることが普通にあります。編集頻度が多いほどそのリスクが高まります。
その点を踏まえるとステージング環境(もしくはローカル開発環境)を作るのが望ましいですが、ソースコードがGit管理されていないとWordPress構成の再現がしづらく、これまた頭を抱えました。
7. カテゴリーやタグをデータベース管理する必要ある?
正直必要ないと感じていました。個人で運営するブログの場合、カテゴリーやタグを新たに作成したりメンテナンスするにしても、ソースコードの中に定義するで十分に運用代替可能です。
WordPressにおいてカテゴリーやタグをデータベースによって管理されている背景はおそらくですが、WordPressの想定利用者が主に非エンジニアであることを考慮した結果、カテゴリーとタグをデータベースにて管理するスタイルにしたからではないかと考えています。ブログ運営者がエンジニアで、且つ自由にカスタマイズしたい要請が強い場合はその限りではないと思います。
8. WordPress APIが不要
WordPressをヘッドレスCMSとして使う場合は必要ですが、そうでない場合はAPIの機能自体が不要です。APIを構成するソースコードを削除できればサイト全体の読み込み速度も少し上がりそうですし、PSIの点数もひょっとしたら上がるかもしれません。
9. サーバーのお引越しするのが面倒
基本は移行専用のプラグインをインストールし、ソースコードとデータベースをまとめてダンプすると思います。但し
- 引越し頻度が少ないこと
- 移行専用のプラグインが引越しの度に新しいものを推奨されやすい(=引越し手順が変わる)
からか、移行作業は億劫になりがちです。日頃からデプロイ作業に慣れていれば、さほど気にならなくなります。
10. WordPressの仕様を細かく把握してブログをチューニングできたとして、そこから学んだことが実務に生きる機会が少ない
これは、1エンジニアとしてWordPressを管理・運用するモチベーションが上がらない最大の要因かもしれません。今の時代、CMSはたくさんあります。企業としてメディア構築する際、上記の課題を鑑みた結果、WordPress以外が選択されることも多いと思われます。また、ヘッドレスCMSを導入すればフロントエンドとバックエンドを分離して開発できるため、モダンなWebアプリケーション開発スタイルに合わせやすかったりします。
SSG構成のサイトによる解決
WordPressにおけるこれらの課題を解決方法を模索した結果、
Static Site Generator(SSG) + 静的ウェブサイトホスティングサービス
の組み合わせが最も良いと判断しました。長くなりましたので、続きはmasyus.workをWordPressからNuxt3 + Nuxt Content v2へ移行しました 後編にて掲載します。