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

TwitterFacebookHatena

TL;DR

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

本来、WordPress は基本的にはヘッドレス CMS と比較されるべきですが、今回は Jamstack や Vercel なども絡めて書きました。私自身も、これらのアーキテクチャまたは哲学がまだよく分かってない部分もあります。

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

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

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

と偉そうなことを言っておりますが、WordPress の粗探し（あらさがし）をしていくので、WordPress に対する偏見があることをご了承ください。

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

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

性能比較表

これは、WordPress と Jamstack による静的サイトの性能比較表です。ただし、具体的な数値はあくまで一般的な目安であり、サイトの設計や最適化の度合いによって大きく変動する可能性があることをご了承ください。

項目 WordPress Jamstack
ページロード時間 平均 2~5 秒（高速化の施策次第） ほぼ即時（CDN でホストされた静的ファイル）
セキュリティ脆弱性 高い（プラグインやテーマによる脆弱性、不適切なコード） 低い（静的コンテンツとセキュアな API）
データベースの依存度 高い（MySQL 等） 低い（API からのデータフェッチが主）
スケーラビリティ 制約あり（サーバーレスポンス時間、データベースクエリ数） 高い（静的ファイルの配信）
ホスティングコスト 高い（データベース、サーバーメンテナンス必要） 低い（静的ホスティング）
技術スタック PHP 主体 JavaScript, TypeScript, React, APIs
カスタマイズの自由度 制約あり（テーマやプラグイン） 高い（JavaScript ライブラリやフレームワークの利用）
更新の手間 高い（コア、テーマ、プラグインの更新） 低い（個別の依存関係の更新）

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

それでは、具体的に WordPress がどのようなリスクを抱えているのか、Jamstack との比較コードを交えて解説していきます。

WordPress のパフォーマンス問題

WordPress は動的なコンテンツを生成するため、サイトが大きくなるとパフォーマンスが低下する可能性があります。一方、Jamstack は静的サイトジェネレータを使用しているため、ページのロード時間は短く、大量のトラフィックにも対応できます。

WordPress

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

Jamstack

// Jamstackの静的コンテンツ生成
type MarkdownRemark = {
  html: string
}

type Data = {
  markdownRemark: MarkdownRemark
}

type PageProps = {
  data: Data
}

const Page = ({ data }: PageProps) => {
  const { markdownRemark } = data
  return <div dangerouslySetInnerHTML={{ __html: markdownRemark.html }} />
}

export default Page

WordPress のセキュリティ問題

WordPress は、脆弱なプラグインや古いコードを利用することで、ハッキングのリスクが高まります。Jamstack は API ベースの設計と静的サイト生成により、このようなセキュリティリスクを大幅に減らすことができます。

WordPress

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

Jamstack

// Jamstackの安全なAPI呼び出し
// 型定義はAPIから取得するデータの形状に依存します
type ResponseData = unknown

const fetchData = async () => {
  const response = await fetch('/api/secure-endpoint')
  const data: ResponseData = await response.json()
  console.log(data)
}

fetchData()

サーバーのリスク

WordPress をレンタルサーバー上で稼働させているサイトを見かけることがあります。別段、これは悪いことではありません。私も、Next.js と Vercel でサイトを運用する前は、WordPress を VPS サーバー上で運用していました（今は、全て解約しています）。

しかし、これらのサーバーは、初心者にとっては手軽に利用できる反面、いくつかのデメリットが存在します。ここでは、Vercel というモダンなサーバーレスプラットフォームとの比較を通じて、それらの問題点を深堀りしていきましょう。

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

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

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

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

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

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

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

  1. パフォーマンス: レンタルサーバーは共有サーバーであることが多く、他のユーザーとリソースを共有します。これにより、他のユーザーのトラフィックが多い場合、あなたのウェブサイトのパフォーマンスに影響を与える可能性があります。一方で、Vercel のようなサーバーレスプラットフォームでは、リクエストごとに個別の環境が立ち上がるため、他のユーザーの影響を受けずに一貫したパフォーマンスを保つことができます。

  2. スケーラビリティ: レンタルサーバーは固定のリソースを持っています。トラフィックが急増した場合、サーバーがその負荷に耐えられない可能性があります。この問題を解決するためには、より高いリソースを持つサーバーに移行する必要がありますが、これは時間とコストがかかります。対照的に、Vercel のようなサーバーレスプラットフォームは、需要に応じて自動的にスケーリングします。そのため、トラフィックの増減に応じてリソースを自動的に調整し、必要な時に必要なだけのリソースを利用することができます。

  3. セキュリティ: レンタルサーバーでは、サーバーのセキュリティを保つ責任がユーザーにあります。WordPress はその人気からくる標的であり、常に最新のセキュリティパッチを適用していることが求められます。しかし、これは技術的な知識と時間を必要とします。それに対して、Vercel のようなプラットフォームでは、サーバーの管理とセキュリティはプラットフォーム側が担当します。これにより、ユーザーはアプリケーションの開発に集中することができます。

  4. 開発とデプロイの便利さ: 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)
}

Jamstack

// Jamstack TypeScript code
import { NextPage } from 'next'

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

export default CustomPage

なぜ、PHP ？

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

  1. 型安全性の欠如: PHP は動的型付け言語であるため、開発の初期段階で型エラーを発見するのは困難です。これに対して、TypeScript は静的型付け言語であり、コンパイル時に型エラーを検出することができます。これは、バグの早期発見と修正に役立ち、結果としてコードの品質と信頼性を向上させます。

  2. モダンな機能の欠如: PHP は長い歴史を持つ言語であるため、その設計は現代のプログラミングパラダイムや機能に必ずしも対応していません。特に非同期処理、高度な型システム、パッケージ管理などの領域では、TypeScript やその他の新しい言語に比べて不十分であると感じられます。

  3. コードの保守性と可読性: PHP の柔軟性はコードの可読性と保守性に影響を与える可能性があります。例えば、PHP では変数の型が動的に変わることが許されているため、コードの挙動を予測するのが難しくなることがあります。これに対して、TypeScript は静的型付けを導入することで、コードの意図を明確にし、他の開発者が理解しやすいコードを書くことを促進します。

  4. ツールとエコシステム: 最近のフロントエンド開発では、ビルドツール、リントツール、テストフレームワークなど、開発を助ける多くのツールが存在します。これらのツールは JavaScript や TypeScript と密接に統合されており、そのエコシステム内での利用が前提となっています。これに対して、PHP のツールは比較的分断されており、JavaScript や TypeScript のエコシステムほど統一性や進化の速さを持っていません。

以上のように、TypeScript と比較した場合、PHP は型安全性の欠如、モダンな機能の不足、コードの保守性と可読性の問題、ツールとエコシステムの差異という面でいくつかの弱点（個人的な不満かもしれませんが…）が見られます。これらの観点から見ると「TypeScript を使用した開発のほうが、より信頼性が高く、効率的な解決策となるんじゃないかな」と思ったわけです。

WordPress のホスティングコスト

WordPress サイトはデータベースと連携する必要があり、これがホスティングコストを高くします。一方、Jamstack サイトは静的ファイルで構成され、低コストでホスティングできます。

WordPress

// WordPressデータベースの接続
define('DB_NAME', 'database_name')
define('DB_USER', 'database_username')
define('DB_PASSWORD', 'database_password')
define('DB_HOST', 'localhost')

Jamstack

// Jamstack静的ファイル
// データベース接続は不要

WordPress のカスタマイズの非効率さ

WordPress は既存のテーマやプラグインに依存しており、特定のカスタマイズを行うには時間とエネルギーを必要とします。しかし、Jamstack は柔軟性とカスタマイズの自由度が高いです。

WordPress

// WordPressテーマカスタマイズ
add_action('wp_enqueue_scripts', 'my_theme_enqueue_styles');
function my_theme_enqueue_styles() {
    wp_enqueue_style('child-style', get_stylesheet_uri(),
        array('parenthandle'),
        wp_get_theme()->get('Version')
    );
}

Jamstack

// Jamstackカスタマイズ
// CSS-in-JSを使ってスタイルを直接コンポーネントに適用
import styled from 'styled-components'
const CustomStyledComponent = styled.div`
  color: blue;
`

CSS-in-JS と CSS の比較

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

命名の衝突

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

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

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

// Jamstack 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 を使ってスタイルを動的に変更することができます。

// Jamstack 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 は自動的にスコープを提供します。これにより、コンポーネントは他のスタイルに影響を与えることなく、それ自体のスタイルを持つことができます。

// Jamstack CSS-in-JS
import styled from 'styled-components'

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

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

Tailwind CSS との相性の悪さ

Tailwind は、モダンフロントエンドであって、そもそも Web 開発での使用が想定されているので、Web 制作になる WordPress との相性は悪いです。

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

  1. 開発環境のセットアップ: Tailwind CSS を効果的に使用するには、PostCSS という CSS のトランスパイラの設定や、PurgeCSS という未使用 CSS の削除ツールの設定が必要です。これらのツールは Node.js 上で動作するため、WordPress の PHP ベースの環境とは異なる開発環境を整備する必要があります。

  2. テーマとの互換性: WordPress はテーマを使用してサイトの見た目を管理しますが、既存のテーマは大抵の場合、プレーンな CSS や Sass を前提にして作られています。Tailwind CSS を適用するには、テーマのスタイルを一から書き直すか、新たに Tailwind CSS を前提にしたテーマを作成する必要があります。

  3. プラグインとの互換性: WordPress の強力な点の一つは、豊富なプラグインエコシステムです。しかし、これらのプラグインの多くは既存の CSS 規則に依存しています。Tailwind CSS のユーティリティファーストのアプローチを採用すると、プラグインのスタイルが予期せぬ形で崩れる可能性があります。

以上のような理由から、WordPress で Tailwind CSS を適用するのは難しく、一般的には Jamstack などのモダンなフロントエンドスタックで使用されることが多いです。

リダイレクト処理の問題

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

以下はその危険性についていくつか挙げてみます。

  1. セキュリティリスク: wp-config.phpファイルが不適切に扱われると、外部の不正アクセスやハッキングのリスクが高まります。データベース接続情報が漏洩すれば、それだけでサイト全体の情報が危険に晒されることになります。

  2. ヒューマンエラー: wp-config.phpは手動で編集することが多く、それによる誤操作により、サイトの機能が停止する可能性があります。また、誤った設定をすると、パフォーマンスに影響を及ぼすこともあります。

  3. バージョン管理: wp-config.phpはセンシティブな情報を含むため、通常、バージョン管理システムに含めることは推奨されません。しかし、これにより設定情報の一貫性を保つことが難しくなる場合があります。

  4. 柔軟性の欠如: wp-config.phpは、静的な設定ファイルであるため、動的な設定や環境に依存した設定が難しいです。これにより、開発、ステージング、本番など異なる環境での管理が困難になる場合があります。

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

WordPress の管理画面への不正ログイン

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

以下のような攻撃が一般的に見られます。

  1. ブルートフォース攻撃: 攻撃者が大量のパスワードの組み合わせを試す攻撃です。弱いパスワードを設定していると、この攻撃によって簡単にアクセスを許してしまう可能性があります。

  2. パスワードリスト攻撃: パスワードが漏洩したリストをもとにログインを試みる攻撃です。これらのリストはダークウェブなどで取引されており、個々のユーザーのパスワードが含まれている場合もあります。

こうした攻撃を防ぐためには、強固なパスワードを設定し、定期的にパスワードを変更することが基本的な対策となります。また、二段階認証（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 を最新の状態に保つには、定期的にコア、テーマ、プラグインのアップデートが必要です。これらのアップデートは、新たな問題を引き起こす可能性があります。一方、Jamstack では依存関係を個別に管理し、それぞれを独立してアップデートできます。

// WordPressアップデート
wp core update
wp plugin update --all

// Jamstackアップデート
npm update

WordPress のロード時間問題

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

WordPress

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

Jamstack

// Jamstackの静的レンダリング
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 活用の難しさ

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 を直接利用することはほとんどありません。これは、WordPress が PHP ベースであり、JavaScript や TypeScript が完全には統合されていないからです。

これに対して、Jamstack のアーキテクチャでは、JavaScript とそのスーパーセットである TypeScript をフル活用することができます。フロントエンドからバックエンドまで、全てのコードベースで一貫した言語とツールを使用することが可能であり、開発効率を向上させるとともに、高品質なコードの開発を実現します。

したがって、TypeScript を使用した安全で効率的な開発を行いたいのであれば、WordPress よりも Jamstack の採用を検討することをお勧めします。

なぜ、Jamstack に移行しづらいのか？

それでは、なぜ WordPress から Jamstack に移行できないサイトが多いのでしょうか？

Jamstack に移行することは、一部の開発者や組織にとっては挑戦的なことかもしれません。その理由としては以下のようなものが考えられます。

1. 学習コスト

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

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

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

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

既に WordPress などの従来の CMS に慣れ親しんでいるデザイナーさんやディレクターさんにとっては、これらの学習コストは大きな障壁になっているように思われます。

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

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

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

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

つまり「Jamstack は WordPress よりも非常に学習コストが高い」ということです。

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

しかし、この容易さが、技術向上の喜びや、高度な開発スキルの習得を妨げることになっているのではないかと思うんですね。

私は常々思うのですが、「ある程度の難易度と学習コスト」があることで、愛着というかモチベーションが高まるのではないかと感じているんです。

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

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

まとめますと、学習コストの高さがある Jamstack 開発は、スキルの習得やトレンドに挑戦する喜びを実感することができる開発者にとっては、魅力的なものとなりますが、それ以外の方にとっては、学習コストが高すぎるため、敬遠されているんじゃないかな？と思うんですね。

2. 移行コスト

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

3. 機能の再現性

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

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

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

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

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

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

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

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

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

とはいえ、Jamstack はパフォーマンス、セキュリティ、スケーラビリティといった点で優れた可能性を持っています。たとえコストがかかったとしても、それを補うだけの価値はあると思います。

WordPress REST API はどうなのか？

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

  1. パフォーマンス: WordPress REST API を用いたデータの取得は、WordPress が通常行う全ての処理（テーマの関数、プラグイン、各種フック等）を経るため、大量のデータを取得しようとするとパフォーマンスが落ちる可能性があります。

  2. セキュリティ: 公開 API として WordPress REST API を利用すると、不適切なアクセスによる情報の漏洩を防ぐために適切なセキュリティ対策が必要です。また、認証の必要性や CORS の問題も生じる可能性があります。

  3. カスタマイズ: WordPress REST API は汎用的に設計されていますが、特定のアプリケーションに必要な特定のデータを取得するためには、エンドポイントのカスタマイズが必要となる場合があります。これは追加の開発コストを必要とします。

  4. バージョン管理: WordPress 自体やプラグインがアップデートされると、REST API の挙動に影響を及ぼす可能性があります。そのため、常に最新のバージョンに追従する必要があります。

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

結局、私の方針は「WordPress REST API は使わない」ということになります。

終わりに

本記事の目的は、WordPress と Jamstack の間に存在する一部の違いと特性を浮き彫りにすることで、開発者や組織が自身のニーズに最適な答えを選択できるようにすることです。

特に、Jamstack の新規導入を検討している方々に向けての情報提供が主な目的であって、導入にあたっての検討材料や学習コストについて、ある程度の見通しを持つことができればと思います。

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

私が書いた情報や見解は、あくまでも一つの視点であり、WordPress と Jamstack を一概に比較することは困難であることをご理解いただければ幸いです。

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

Jamstack での制作を依頼する

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