あなたの知らない WordPress のデメリットとリスク

公開：2023-07-03
更新：2023-10-26
文章量：16982
Jamstack WordPress

TL;DR

2023/10/20：SNS などで色々とご指摘がありました。記事全体を見直し、公平さと正確性に欠ける部分について、加筆・修正いたしました。

最近、WordPress を中心に扱う Web 制作業者の方々から Next.js + ヘッドレス CMS を使った開発を依頼されることが急激に増えてきました。その際に、WordPress やヘッドレス CMS について長々と説明することが多くなり、それなら事前に記事にしておけばと思い、本記事を執筆しました。

よく「どのように違うのか？」と聞かれるので執筆しましたが、比較することは困難ですし、どちらが優れているというわけではありません。

WordPress と、ヘッドレス CMS

本来、WordPress はヘッドレス CMS と比較されるべきですが、思うところがあって今回は Jamstack や Vercel など色々絡めて書きました。私自身も、これらのアーキテクチャまたは哲学がまだよく分かってない部分あり、勉強中です。仕組みを整理するために、本記事を執筆しました。

タイトルは少々あおり気味ではございますが、本記事は、特定の技術選択について、深く掘り下げて考察することで、読者がより知識を深める一助になることを目指しています。強調したいのは「これらの観察や結論が絶対的な真実を主張するものではなく、あくまで一つの視点から見た解析に過ぎない」ということです。

また、本記事は未熟ながらも技術的な観点から見た評価であり、WordPress あるいは Conteful などのヘッドレス CMS を採用するか否かは、プロジェクトの具体的なニーズ、チームの技術スキル、そして開発期間等、様々な要素によって左右されます。

なお、本記事が「ヘッドレス CMS は悪」とか「WordPress がイケてる」といった単純な二項対立をわめき散らすものではありません。むしろ、それぞれの技術が得意とする領域とそうでない領域を理解することで、読者が最適な技術選択を行う助けになればと思います。

どちらかが優れているというわけでもなく、本来比較できるものでもありません。 どちらも進化し続けていますし、素晴らしい CMS です。使いやすいほうを使えばよいのではないかと思います。

ただ私自身、長年 WordPress を使っていて非常にお世話になっておりましたが、Next.js を使ったヘッドレス CMS の開発体験のよさやメリットに触れ、今ではどっぷり浸かっています。ということもあるので、WordPress に対する偏見があることをご了承ください。

オープンで建設的な議論を歓迎しますので、異なる視点や意見をお持ちの方は、ぜひシェアしていただければと思います。

サイトに、どのような技術やサービスが使われているか判別するには、Wappalyzerという Chrome 拡張機能をインストールすることで、簡単に確認できます。Web 制作業の方は必ずインストールしておきたいツールです。

性能

これを比較するのもどうかな？と思ったのですが、分かりやすいというか、一番多そうなパターンかなと思って。次は、WordPress をレンタルサーバーで動かしているケースと Next.js + ヘッドレス CMS + Vercel による静的サイトの性能比較表です。ただし、具体的な数値はあくまで私が思う目安であり、サイトの設計や最適化の度合いによって大きく変動する可能性があることをご了承ください。

項目	WordPress + レンタルサーバー	Next.js + ヘッドレス CMS + Vercel
ページロード時間	高速化の施策次第	ほぼ即時（CDN でホストされた静的ファイル）
セキュリティ脆弱性	プラグインやテーマの脆弱性対策が必要	静的コンテンツとセキュアな API
データベースの依存度	高い（MySQL 等）	低い（API からのデータフェッチが主）
スケーラビリティ	サーバーによる（サーバーレスポンス時間、データベースクエリ数）	高い（静的ファイルの配信）
ホスティングコスト	普通（データベース、サーバーメンテナンス必要）	普通（静的ホスティング）
技術スタック	PHP 主体	JavaScript, TypeScript, React, APIs
カスタマイズの自由度	テーマやプラグインをカスタマイズ可能	JavaScript ライブラリやフレームワークを使える
更新の手間	コア、テーマ、プラグインの更新が必要	個別の依存関係の更新が必要

この表は、あくまで一般的な比較の一例であり、各々のサイトの設計、最適化の度合い、具体的なニーズにより異なる結果となる可能性があります。また、WordPress は十分に最適化され、高速化プラグインや CDN を用いることでパフォーマンスを向上させることも可能です。

ですので、どちらも使い方次第でパフォーマンスは改善できる、ということになります。

WordPress のパフォーマンス

WordPress は動的なコンテンツを生成するため、サイトが大きくなるとパフォーマンスに影響が及ぶ可能性があります。

// WordPressの動的コンテンツ生成
$page = get_page_by_path($path);
$content = apply_filters('the_content', $page->post_content);

WordPress のセキュリティ

WordPress は、脆弱なプラグインや古いコードを利用することで、ハッキングのリスクが高まる可能性がありますので更新を怠らないようにする必要があります。

WordPress

// WordPressの脆弱なプラグイン
add_action( 'wp_footer', 'my_custom_footer' );
function my_custom_footer() {
  echo '<script src="yabai-plugin.js"></script>';
}

サーバー

少し、サーバーに関しても触れておきたいと思います。私も、Next.js と Vercel でサイトを運用する前は、WordPress を VPS サーバー上で運用していました。

以下は、Vercel と一般的なレンタルサーバーの性能とコストの比較表です。この表は、一般的な平均値を基にしていますので、具体的な値は提供されているサービスやプランにより異なる場合があります。

Vercel と、レンタルサーバーの比較表

	Vercel	レンタルサーバー
パフォーマンス	高	低
スケーラビリティ	高	低
セキュリティ	高	中
開発・デプロイの便利さ	高	中
初期費用	低	中
維持費	中	低
カスタマイズの自由度	高	中

仕方のないことですが、性能面では、Vercel が明らかに優れています。コスト面では、初期費用は Vercel が低く抑えられますが、維持費についてはサイトの規模やトラフィックによります。

小規模なサイトや低トラフィックのサイトでは Vercel がコスト効率が良い一方で、大規模なサイトや高トラフィックのサイトではレンタルサーバーの方がコストパフォーマンスが良い場合もあります。ひょっとしたら将来、私達の想像を遥かに超えるレンタルサーバーが登場するかもしれません。

ですので、今どちらが良いとか悪いとかを議論する気はありません。

ただし、これらは一般的な評価であり、具体的な評価は使用するサービスやプラン、そして具体的なニーズによります。必要に応じて、Vercel やレンタルサーバー各社のプラン詳細を確認し、自分のニーズに最適な選択をすることが重要です。

パフォーマンス: レンタルサーバーは共有サーバーであることが多く、他のユーザーとリソースを共有します。これにより、他のユーザーのトラフィックが多い場合、あなたのウェブサイトのパフォーマンスに影響を与える可能性があります。一方で、Vercel のようなサーバーレスプラットフォームでは、リクエストごとに個別の環境が立ち上がるため、他のユーザーの影響を受けずに一貫したパフォーマンスを保つことができます。
スケーラビリティ: レンタルサーバーは固定のリソースを持っています。トラフィックが急増した場合、サーバーがその負荷に耐えられない可能性があります。この問題を解決するためには、より高いリソースを持つサーバーに移行する必要がありますが、これは時間とコストがかかります。対照的に、Vercel のようなサーバーレスプラットフォームは、需要に応じて自動的にスケーリングします。そのため、トラフィックの増減に応じてリソースを自動的に調整し、必要な時に必要なだけのリソースを利用することができます。
セキュリティ: レンタルサーバーでは、サーバーのセキュリティを保つ責任がユーザーにあります。WordPress はその人気からくる標的であり、常に最新のセキュリティパッチを適用していることが求められます。しかし、これは技術的な知識と時間を必要とします。それに対して、Vercel のようなプラットフォームでは、サーバーの管理とセキュリティはプラットフォーム側が担当します。これにより、ユーザーはアプリケーションの開発に集中することができます。
開発とデプロイの便利さ: WordPress のサイトをレンタルサーバーにデプロイするには、FTP を用いた手動のアップロードや、cPanel などのインターフェースを使用することが一般的です。これに対して、Vercel では Git ベースのデプロイが可能であり、開発からデプロイまでのフローがスムーズになります。

以上のように、レンタルサーバーのメリットは手軽に扱えて管理しやすいということです。パフォーマンス、スケーラビリティ、セキュリティ、開発とデプロイの便利さという面では、Vercel のようなサーバーレスプラットフォームをおしたいところです。

WordPress と PHP

WordPress は PHP に依存しています。PHP は歴史的に使われている言語です。個人的見解ですが、新しい開発者がスキルセットを更新し、最新の開発技術に追いつくためには、Jamstack のような JavaScript ベースのスタックを学ぶことも有用だと思います。

WordPress

// WordPress PHPコード
function add_my_custom_page() {
  add_menu_page(__('Custom Page', 'textdomain'), 'custompage', 'manage_options', 'custompage_slug', 'my_custom_page_html', plugins_url('myplugin/images/icon.png'), 6)
}

ヘッドレス CMS + Next.js

// TypeScript code
import { NextPage } from "next";

const CustomPage: NextPage = () => {
  return <h1>Welcome to my custom page!</h1>;
};

export default CustomPage;

PHP

PHP は Web 開発の初期から存在する言語であり、その利便性と学習コストから、多くのウェブサイトやアプリケーションで使用されている歴史のある素晴らしい言語です。しかし、私には PHP が少し受け入れがたいところがありました。

型安全性: PHP は動的型付け言語であるため、開発の初期段階で型エラーを発見するのは困難です。これに対して、TypeScript は静的型付け言語であり、コンパイル時に型エラーを検出することができます。これは、バグの早期発見と修正に役立ち、結果としてコードの品質と信頼性を向上させます。
コードの保守性と可読性: PHP の柔軟性はコードの可読性と保守性に影響を与える可能性があります。例えば、PHP では変数の型が動的に変わることが許されているため、コードの挙動を予測するのが難しくなることがあります。これに対して、TypeScript は静的型付けを導入することで、コードの意図を明確にし、他の開発者が理解しやすいコードを書くことを促進します。
ツールとエコシステム: 最近のフロントエンド開発では、ビルドツール、リントツール、テストフレームワークなど、開発を助ける多くのツールが存在します。これらのツールは JavaScript や TypeScript と密接に統合されており、そのエコシステム内での利用が前提となっています。これに対して、PHP のツールは比較的分断されているのではないかと思います。

しかし、これはあくまでも個人的見解なので、愛着のある好きな言語を使えばよいと思います。

CSS-in-JS と CSS の比較

ついでに、CSS-in-JS についても触れておきます。

一般的な WordPress のテーマやプラグインの開発には、伝統的な CSS（もしくは、SCSS）が使われます。これは、開発者にとって理解しやすく、学習コストもかかりません。しかし、このアプローチに私は少し抵抗があります。

命名の衝突

CSS のセレクターはグローバルな名前空間に存在します。記述内容によっては、大規模なプロジェクトや多くの開発者が関与するプロジェクトで命名の衝突を引き起こす可能性があります。

/* WordPress CSS */
.button {
  background: blue;
  color: white;
}

一方で、CSS-in-JS のライブラリ（例えば、styled-components や Emotion）は、自動的に一意のクラス名を生成します。これにより、命名の衝突を心配することなくスタイルを適用することができます。

// CSS-in-JS
import styled from "styled-components";

const Button = styled.button`
  background: blue;
  color: white;
`;

動的なスタイル

WordPress と CSS では、動的なスタイルの適用は、私は困難であると思います。一般的には、JavaScript を使用して DOM を直接操作するか、クラスを切り替える必要があります。

// WordPress CSS + JavaScript
const button = document.querySelector(".button");
button.style.backgroundColor = "blue";
button.style.color = "white";

対照的に、CSS-in-JS は JavaScript の力を借りて、動的なスタイルの適用を容易にします。例えば、props を使ってスタイルを動的に変更することができて簡単。

// CSS-in-JS
import styled from "styled-components";

const Button = styled.button`
  background: ${(props) => (props.primary ? "blue" : "white")};
  color: ${(props) => (props.primary ? "white" : "blue")};
`;

スコープの問題

伝統的な CSS はグローバルスコープに存在し、他の CSS ルールに影響を与える可能性があります。WordPress の開発では、この問題を解決するために BEM や OOCSS などの命名規則がよく用いられます。

/* WordPress CSS */
.button--primary {
  background: blue;
  color: white;
}

しかし、CSS-in-JS は自動的にスコープを提供します。これにより、コンポーネントは他のスタイルに影響を与えることなく、それ自体のスタイルを持つことができます。

// CSS-in-JS
import styled from "styled-components";

const PrimaryButton = styled.button`
  background: blue;
  color: white;
`;

これらの点から、CSS-in-JS は伝統的な CSS よりも高度なスタイリングが可能です。とはいっても、新たなスキルセットの習得と学習コストが必要となります。

Tailwind CSS との相性

Tailwind は、モダンフロントエンドであって、そもそも Web アプリケーション開発での使用が想定されているので、Web 制作になる WordPress との相性はあまり良くないのではないかと思います。

WordPress で Tailwind CSS を扱うこと自体は可能です。しかし、その適用には以下のようないくつかの困難があります。

開発環境のセットアップ: Tailwind CSS を効果的に使用するには、PostCSS という CSS のトランスパイラの設定や、PurgeCSS という未使用 CSS の削除ツールの設定が必要です。これらのツールは Node.js 上で動作するため、WordPress の PHP ベースの環境とは異なる開発環境を整備する必要があります。
テーマとの互換性: WordPress はテーマを使用してサイトの見た目を管理しますが、既存のテーマは大抵の場合、プレーンな CSS や Sass を前提にして作られています。Tailwind CSS を適用するには、テーマのスタイルを一から書き直すか、新たに Tailwind CSS を前提にしたテーマを作成する必要があります。
プラグインとの互換性: WordPress の強力な点の一つは、豊富なプラグインエコシステムです。しかし、これらのプラグインの多くは既存の CSS 規則に依存しています。Tailwind CSS のユーティリティファーストのアプローチを採用すると、プラグインのスタイルが予期せぬ形で崩れる可能性があります。

とはいえ、Tailwind CSS も扱いにくいところがあるので、このあたりも好みになります。

リダイレクト処理

WordPress と Next.js では、リダイレクトの実装方法が大きく異なります。結論から言うと、Next.js でのリダイレクトは「シンプル」です。

WordPress のリダイレクト

WordPress では、リダイレクトは主に 2 つの方法で実現されます。一つは.htaccessファイルを編集する方法、もう一つはプラグインを利用する方法です。

.htaccessを使用する場合、リダイレクトルールを直接記述するため、高度なカスタマイズが可能です。しかし、この方法は Apache サーバー上でのみ機能し、また、.htaccessファイルの書式は独自のものであり、間違った編集を行うとサイト全体が機能しなくなる危険性があります。

一方、リダイレクトプラグインを使用すると、コードを書かずにリダイレクトを設定することができます。しかし、この場合、プラグインの提供する機能に依存するため、特殊なケースでの対応が困難になることもあります。

Next.js のリダイレクト

Next.js では、next.config.jsファイルの中にリダイレクトを定義することで、簡単にサーバーサイドやクライアントサイドでのリダイレクトを実装することができます。

module.exports = {
  async redirects() {
    return [
      {
        source: "/old-route",
        destination: "/new-route",
        permanent: true,
      },
    ];
  },
};

これにより、JavaScript の知識を活かして簡潔かつ明瞭なリダイレクトルールを記述することができます。また、この方法はホスティングプロバイダーに依存しないため、どのサーバー環境でも問題なく動作します。

さらに、Next.js では API ルートやgetServerSideProps関数内での動的なリダイレクトも可能であり、これによりデータの状態に基づくリダイレクトを実装することもできます。

全体的に見ると、Next.js は WordPress よりも柔軟かつシンプルなリダイレクトの実装を提供します。これにより、開発者は高度なリダイレクトロジックを手軽に実装でき、更なる UX の向上を図ることが可能になります。

wp-config.php

WordPress におけるwp-config.phpファイルは、サイトの重要な設定情報が含まれるため、非常に敏感な部分と言えます。ここにはデータベース接続の情報や暗号化キー、開発モードの設定などが格納されています。

以下、気をつけるべきポイントを挙げておきます。

セキュリティ: wp-config.phpファイルが不適切に扱われると、外部の不正アクセスやハッキングのリスクが高まります。データベース接続情報が漏洩すれば、それだけでサイト全体の情報が危険に晒されることになります。
ヒューマンエラー: wp-config.phpは手動で編集することが多く、それによる誤操作により、サイトの機能が停止する可能性があります。また、誤った設定をすると、パフォーマンスに影響を及ぼすこともあります。
バージョン管理: wp-config.phpはセンシティブな情報を含むため、通常、バージョン管理システムに含めることは推奨されません。しかし、これにより設定情報の一貫性を保つことが難しくなる場合があります。
柔軟性の欠如: wp-config.phpは、静的な設定ファイルであるため、動的な設定や環境に依存した設定が難しいです。これにより、開発、ステージング、本番など異なる環境での管理が困難になる場合があります。

これらの問題は、特に WordPress が大規模なプロジェクトや複雑なインフラストラクチャに使用される場合に顕著となります。セキュアな扱いと適切な管理が不可欠であり、しっかりとした知識と経験が求められます。

WordPress の管理画面

WordPress の管理画面（wp-admin）は、サイトの設定や内容を管理するための重要なエリアです。そのため、適切な処理を行わないとこのエリアへの不正なログインやアクセスは大きなセキュリティリスクとなります。

ブルートフォース攻撃: 攻撃者が大量のパスワードの組み合わせを試す攻撃です。弱いパスワードを設定していると、この攻撃によって簡単にアクセスを許してしまう可能性があります。
パスワードリスト攻撃: パスワードが漏洩したリストをもとにログインを試みる攻撃です。これらのリストはダークウェブなどで取引されており、個々のユーザーのパスワードが含まれている場合もあります。

こうした攻撃を防ぐためには、強固なパスワードを設定し、定期的にパスワードを変更することが基本的な対策となります。また、二段階認証（2FA）を導入することで、不正なログインを大幅に防ぐことができます。

WordPress では、例えば以下のように「wp-login.php」ファイルで認証処理が行われます。

// wp-login.php
function check_password($password, $hash, $user_id = '') {
  // password_verify()はPHPによって提供される関数で、
  // ハッシュ化されたパスワードと入力されたパスワードが一致するかどうかを検証します
  $check = password_verify($password, $hash);

  if ($check) {
    // パスワードが一致したら、ログイン成功として扱います
    return true;
  } else {
    // パスワードが一致しなかったら、ログイン失敗として扱います
    return false;
  }
}

しかし、これだけで不正ログインを完全に防ぐことはできません。セキュリティプラグインの導入や、IP 制限などの追加的なセキュリティ対策も必要となります。

WordPress のロード時間

WordPress のページロード時間は、サーバーからのレスポンス時間とその後のページレンダリング時間に大きく依存します。しかし、Next.js とヘッドレス CMS を使ったサイトは静的にプレレンダリングされるため、ロード時間を大幅に削減することが可能です。

WordPress

// WordPressのサーバーサイドレンダリング
function my_custom_template() {
    get_header();
    if ( have_posts() ) :
        while ( have_posts() ) : the_post();
            the_content();
        endwhile;
    endif;
    get_footer();
}

Markdown + Next.js

// 静的レンダリング
import { NextPage } from "next";

interface Data {
  markdownRemark: {
    html: string;
  };
}

const Post: NextPage<{ data: Data }> = ({ data }) => {
  const { markdownRemark } = data;
  return <div dangerouslySetInnerHTML={{ __html: markdownRemark.html }} />;
};

export default Post;

WordPress での TypeScript 活用の難しさ

全く得意ではないのですが、私は、TypeScript を使って開発したい人間です。

WordPress は基本的に PHP で書かれたシステムですが、その内部には JavaScript も多く含まれています。管理画面のインタラクティブな機能の多くは JavaScript で制御されており、最近では React を用いた新エディタ「Gutenberg」が導入されています。

そのため、理論的には WordPress の一部（特にフロントエンドに関わる部分）で TypeScript を使用することは可能です。例えば、独自の JavaScript プラグインやテーマを開発する際に TypeScript を使用し、その結果を JavaScript にトランスパイルして WordPress に組み込む、という方法が考えられます。

しかし、実際は WordPress 自体や多くのプラグイン・テーマが PHP ベースであり、WordPress コミュニティにおいても PHP の知識が主に求められるため、WordPress 開発で TypeScript を使う機会はあまり多くないのではないかと思います。

また、WordPress の PHP ベースのバックエンドと TypeScript（または JavaScript）を使ったフロントエンドとの間でのデータのやり取り（例えば、WordPress REST API を通じて）は、型安全性が保証されないため、TypeScript の型システムをフルに活用することは難しいです。

そのため、TypeScript を用いた開発を行いたい場合には、JavaScript や TypeScript を第一級の言語として採用している Jamstack のようなアーキテクチャを採用する方が適しているかもしれません。

WordPress はもともと PHP で書かれた CMS(Content Management System)で、PHP は弱い型付けを持つ言語です。このため、WordPress のコアやプラグインのコードには、型エラーによるバグに対応する必要があります。

一方で、TypeScript は JavaScript のスーパーセットで、強い型付けを持っています。これにより、型エラーによるバグをコンパイル時に検出し、修正することが可能になります。TypeScript は、開発効率を高め、品質の高いコードを作成するためのツールとして、近年非常に高い人気を得ています。

しかしながら、WordPress と TypeScript の相性はあまり良くないと言えます。WordPress は PHP ベースであり、JavaScript や TypeScript は主にフロントエンド開発で使用されます。WordPress における JavaScript や TypeScript の利用は主にテーマや特定のプラグインに限られ、その利用範囲も限定的なのではないかと思います。

さらに、WordPress のプラグインやテーマ開発では、TypeScript を直接利用することはほとんどないのではと思います。

なぜ、ヘッドレス CMS に移行しづらいのか？

ヘッドレス CMS を使った開発のデメリットもあるので、それをまとめておきます。

なぜ WordPress からヘッドレス CMS に移行しずらいのでしょうか？その理由としては以下のようなものが考えられます。

1. 学習コスト

例えば、Next.js や Astro などとヘッドレス CMS で開発する場合は、TypeScript、React、静的サイトジェネレータ、API、Markdown、Git、CDN など、新たな技術スタックを学ぶ必要があります。また、これらの技術を組み合わせて効果的にサイトを構築するための新たなパターンやベストプラクティスも学ぶ必要があります。さらに、アプリやライブラリの膨大なバージョンアップ情報をキャッチアップし続け、修正し続ける必要もあります。

GSAP や Three.js などのアニメーションも、TypeScript と React に書き直す必要があります。

React（または他のモダンな JavaScript フレームワーク）と組み合わせてこれらのライブラリを使う場合は、フレームワークのライフサイクルメソッドやフックを活用してアニメーションや 3D 描画のセットアップとクリーンアップを行います。

しかし、これらの変更は学習曲線を伴います。それらのライブラリを React や TypeScript の環境で使用するための新たなパターンや慣習を学ぶ必要があるためです。これは、特に React のライフサイクルやフックの概念、TypeScript の静的型付けなど、これらの技術の基本的な概念にまだ馴染みがない場合は、学習コストが増大する可能性があります。

既に WordPress などの従来の CMS に慣れ親しんでいる方にとっては、これらの学習コストは大きな障壁になっているように思われます。

以下に、うんざりしてしまいそうな WordPress との学習コスト表を作りました。

この表は、それぞれのスタックが持つ主要な技術やツールの学習コストに基づいています。ただし、個々の開発者やチームの既存のスキルや経験により、実際の学習コストは異なる場合があります。

学習コスト	WordPress + レンタルサーバー	Next.js + ヘッドレス CMS
HTML/CSS	低	低
JSX	-	低
PHP	中	-
JavaScript	低	中
TypeScript	-	中
React	-	高
Next.js	-	高
CSS-in-JS	-	中
GSAP	低	中
3D アニメーション	低	高
デプロイ	-	低
ORM	-	中
Github	-	中
Github Actions	-	中
コマンドライン操作	-	中
API	低	中
ヘッドレス CMS	-	中
Node.js	-	中
静的サイト生成	低	中
サーバーレス関数	-	中
GraphQL	-	中
コンポーネントベースの開発	-	中
モジュラーシステム設計	-	高
パフォーマンスチューニング	中	高
マークダウン操作	-	中

この表を見ると、React ベースのフロントエンドフレームワークとヘッドレス CMS には WordPress では一般的でない、またはサポートされていないいくつかの技術や開発パラダイムが含まれていることがわかります。これらには、CSS-in-JS、サーバーレス関数、GraphQL、コンポーネントベースの開発、モジュラーシステム設計などが含まれます。これらの技術やパラダイムを習得することは、一般的には、それぞれに深い理解を得るための時間と労力が必要となります。

つまり「WordPress よりも非常に学習コストが高くなってしまう」というデメリットがあります。

WordPress は主に PHP と HTML/CSS に基づいており、その他の技術やツールの学習が必要な場面は比較的少ないです。WordPress 自体が提供する機能や、豊富なプラグインにより、比較的スムーズに多くの機能を実現できます。

一方、複数の新しい技術（React、Next.js、TypeScript など）とツール（Vercel、GitHub など）を組み合わせて使用するため、学習コストは WordPress よりも高くなります。これらの技術やツールを理解し、効果的に使用するためには、それぞれについての深い理解と実践的な経験が求められます。

例えば、WordPress で簡単に実装できていた、分割型のページネーション・関連記事・人気記事などの機能を、ヘッドレス CMS で実装するには、上述した表の技術知識がないと難しいかと思われます。

移り変わりの早いモダンなフレームワークを次々に理解していくキャッチアップも必要です。

ただ、最近は、WordPress の学習コストも上がりつつあるので一概にどちらが簡単かとは言えないかもしれません。

2. 移行コスト

既存の WordPress サイトをヘッドレス CMS に移行するには、記事の変換、ショートコードの置換、コンテンツのエクスポート、新しいテーマの作成または選択、新しいビルドとデプロイのプロセスの設定など、多くの作業が必要となります。大規模なサイトでは、これらの移行作業は大きな時間と労力を必要とします。

3. 機能の再現性

ヘッドレス CMS は基本的に静的なサイトを生成するため、WordPress で利用可能な動的な機能をそのまま再現することは困難な場合があります。サーバーサイドの処理などを実現するためには、API やサーバーレス関数などの追加的な技術を利用する必要があります。

4. ツールとエコシステムの違い

WordPress は長年にわたり成熟したエコシステムを築いており、多数のプラグイン、テーマ、コミュニティによるサポートが利用できます。一方、ヘッドレス CMS は比較的新しい技術であり、同じような豊富なリソースが利用できるわけではありません。

5. ヘッドレス CMS 料金が高い！

ヘッドレス CMS は伝統的な CMS（例えば WordPress）とは異なり、ヘッドレス CMS はフロントエンドとバックエンドが切り離されていて、API を介してコンテンツを提供します。このような設計は、開発者にとっては非常に柔軟性があるという利点がありますが、その一方で、利用料金は伝統的な CMS よりも高くなる傾向があります。

ヘッドレス CMS の料金はプロバイダーによって大きく異なります。無料で始められるものもありますが、多くの場合、無料プランでは提供される機能やデータの量が限られています。一方、プレミアムプランでは多くの高度な機能が提供されますが、その料金は月額数十ドルから数百ドルに及ぶことがあります。

また、一部のヘッドレス CMS はユーザー数や API のリクエスト数に基づいて課金されるため、サイトの規模やトラフィックが増えるにつれてコストも増えます。これは、伝統的な CMS（例えば自ホスト型の WordPress）では固定のホスティング料金しか発生しないため、運用コストの観点から見るとヘッドレス CMS のコストが高くなる可能性があります。

実際に「ヘッドレス CMS のランニングコストが高すぎる！何でそんなに高いの？それなら、WordPress で作ってください」と言われたこともあります。コストが高くなる理由を説明しても、なかなか理解してもらえないこともあります。

「どっかの企業さんが、格安で API 数無制限のヘッドレス CMS を出してくれないかなぁ」と妄想することも多いです。

WordPress REST API はどうなのか？

WordPress REST API は、WordPress のデータを操作したり取得したりするための強力なツールです。しかし、いくつか注意点も存在します。

パフォーマンス: WordPress REST API を用いたデータの取得は、WordPress が通常行う全ての処理（テーマの関数、プラグイン、各種フック等）を経るため、大量のデータを取得しようとするとパフォーマンスに影響が及ぶ可能性があります。
セキュリティ: 公開 API として WordPress REST API を利用すると、不適切なアクセスによる情報の漏洩を防ぐために適切なセキュリティ対策が必要です。また、認証の必要性や CORS の問題も生じる可能性があります。
カスタマイズ: WordPress REST API は汎用的に設計されていますが、特定のアプリケーションに必要な特定のデータを取得するためには、エンドポイントのカスタマイズが必要となる場合があります。これは追加の開発コストを必要とします。
バージョン管理: WordPress 自体やプラグインがアップデートされると、REST API の挙動に影響を及ぼす可能性があります。そのため、常に最新のバージョンに追従する必要があります。

これらの問題点は、Next.js のような静的サイトジェネレーターと組み合わせて使用する場合、特に顕著になる可能性があります。ビルド時に API からデータを取得し、静的サイトとして出力します。このため、ビルド時のパフォーマンスや、API のバージョン管理などについて特に注意が必要となります。

終わりに

React ベースのフロントエンドフレームワークとヘッドレス CMS の新規導入を検討している方々に向けての情報提供が主な目的であって、導入にあたっての検討材料や学習コストについて、ある程度の見通しを持つことができればと思います。

しかし、記事内の内容は一部辛辣な表現も含んでおりますが、これは WordPress を全否定するものではありません。WordPress は非常に優れた CMS であり、世界中の多くのウェブサイトで使用されている実績があります。おそらくこの先、シェア率が極端に減少することはないでしょう。

よく「どのように違うのか？」と聞かれるので執筆しましたが、私が書いた情報や見解は、あくまでも一つの視点であり、WordPress とヘッドレス CMS 等を一概に比較することは困難であることをご理解いただければ幸いです。

特に、テクノロジー選択はプロジェクトの特性、目的、リソース、チームのスキルセットなど、多くの要素が絡み合った上での決定なので、一概に優劣をつけることはできません。本記事が、その一部を補完する情報として役立てば幸いです。

Jamstack での制作を依頼する

MORE SKILL UP!

- 2023-07-19
- Next.js
- Jamstack
ヘッドレスCMSとは（学習コスト・種類・歴史・実装）
- 2023-05-25
- Next.js
- TypeScript
- WordPress
コムテブログを、WordPressからNext.jsへリニューアルしました
- 2020-12-22
- WordPress
WordPressプラグインの自動更新通知メールを停止させる

あなたの知らない WordPress のデメリットとリスク