ヘッドレス WordPress: 概要と必要性

公開: 2022-09-22

Servebolt では、WordPress とそのエコシステムの大きな支持者です。統計が毎年示し続けているように、私たちはそれが最高のコンテンツ管理システムであると本当に思っているので、私たちは自分のサイトにもそれを使用しています. オープンソースで汎用性が高く、簡単に言えば、インターネット上のすべての Web サイトの 40% 以上で使用されている理由が非常に簡単にわかります。

WordPress を取り巻くエコシステムと開発者コミュニティがいかに大きいかを考えると、人々がさまざまな方法で WordPress を使用することは当然のことです。そのようなアプローチの 1 つは、WordPress をヘッドレス CMS として使用することです。要するに、人気が高まっているヘッドレス WordPressと呼ばれます。

このガイドでは、ヘッドレス WordPress について知っておく必要があるすべてのこと、その利点、欠点などをチームの直接の経験から分析します.

ヘッドレスWordPressとは？

ヘッドレス WordPress を理解するには、モノリシック WordPress とは何かを知る必要があります。 モノリシック、または従来の形式の WordPress は、ご存じのとおり WordPress です。これは、サイト上のすべてのコンテンツを管理するために使用できるコンテンツ管理システムです。

通常、WordPress にはバックエンド (コンテンツ管理システム) と Web サイトをデザインできるプレゼンテーション層があります。ただし、ヘッドレス WordPress サイトは、単にコンテンツ管理システムとして WordPress に依存し、別のフロントエンドスタックを使用してコンテンツを表示するサイトです。

これにより、開発の柔軟性が向上します。基本的に、REST API の助けを借りて、 Vue.jsやReactなどのフレームワークで個別に構築されたフロントエンドとペアリングしながら、コンテンツ管理機能に WordPress を使用できます(ほんの数例を挙げると、他にもさまざまな機能があります)。フレームワークとフロントエンドツールが利用可能)。

ヘッドレス WordPress の説明

WordPress は、すべてのフロントエンド編集ツールとバックエンドコンテンツ管理 (編集) 機能が結合されているため、結合 CMS アーキテクチャと見なされます。これにより、開発者、編集者、コピーライターなどのチームがプレゼンテーション層とコンテンツの両方を管理できます。名前が示すように、プレゼンテーション層とコンテンツが分離された分離アーキテクチャに従うヘッドレス WordPress Web サイトとは対照的です。

REST、GraphQL、およびフラットファイルの統合

ヘッドレス CMS セットアップでは、API と CDN を使用してコンテンツをレンダリングします。現時点では、REST API、フラットファイル統合、GraphQL の 3 つのオプションが利用可能です。

WordPress は REST API を使用して、フロントエンドを CMS に接続できるようにします。 REST API は、REST アーキテクチャの制約に従う単なるアプリケーションプログラミングインターフェースであり、サーバーとクライアントが相互にデータを転送できるようにする統一されたインターフェースを提供します。 REST を使用すると、開発者は特定のデータを公開して使用できます。REST エンドポイントでデータを直接利用できない場合は、追加の開発が必要になります。

もう 1 つの代替手段は GraphQL です (QL は Query Language の略です)。 GraphQL を使用すると、データベースの場合と同じように、特定のフィールドと関係を使用して API を簡単にクエリできます。これは大幅な改善であり、WordPress で GraphQL API を利用できるようにするプラグインがあります。これは、GraphQL が既に CMS のコンテンツにアクセスしているため、CMS のコンテンツを悪用するために追加の開発が必要ないことを意味します。より複雑な部分は、それを取得するための適切で効率的なクエリを要求することです。

もう 1 つのオプションは、フラットファイル統合です。フラットファイル統合により、通常は REST または GraphQL を介して提供されるデータを .JSON ファイルとしてエクスポートできるため、サーバーはデータをキャッシュでき、リクエストごとに生成する必要がなくなり、はるかに高速になります。このメソッドを使用すると、データベースが変更されるたびに新しい .JSON ファイルのセットが自動的に生成されます。これは通常、単なるプラグインではなく、特注の実装です。したがって、それを設定するには開発者が必要です。

ヘッドレス WordPress の長所と短所

ヘッドレス WordPress とは何か、従来のWordPress セットアップとどのように異なるのかがわかったので、決定を下す前に知っておくべき長所と短所を次に示します。

ゼロからの柔軟な開発。

コンテンツ管理システムとして引き続き WordPress を使用している場合でも、WordPress を切り離すことで、開発者は選択したフロントエンドテクノロジ (つまり、 Next.jsなどのフレームワーク) を使用して構築する柔軟性が得られます。表面的なレベルでは、これは構築の自由度が大幅に高まることを意味します。

表面的には、これは素晴らしいことです。しかし、それはまた、サイトマップやパーマリンクなどの基本的な機能のホイールを再発明して、投稿やページコンテンツのライブプレビューが確実に機能するようにすることも意味します。

そして、WordPress で知られている編集ワークフローの大部分が失われます。多くの場合、新しいページの設定は非常に複雑になり、問題が発生したときに開発者が待機してデバッグする必要があります。

WordPress バックエンドでモバイルアプリを構築する

見落とされがちなユースケースの 1 つは、WordPress を切り離すと、バックエンドのみに使用してモバイルアプリを構築できるということです。

アプリは複雑であり、ウェブサイトをゼロから構築する場合 (つまり、WordPress の有無にかかわらず) よりもはるかに複雑です。つまり、最終的にこのルートに進むと、コンテンツは API 駆動になりますが、残りの多くはネイティブデバイスの機能に依存します。 React Native のようなフレームワークの助けを借りて。 AppPresser の Scott Bollinger によるモバイルアプリのさまざまな作成方法の優れた比較を次に示します。そのうちの 1 つは、ご想像のとおり、AppPresser です。これは、箱から出してすぐに使い始めたい人のための優れた実装です。もちろん、WordPress プラグイン、テーマ、および REST API を使用して、ネイティブ/ハイブリッド iOS および Android モバイルアプリケーションを強化します。

このようなソリューションから始めると、数か月ではないにしても数週間の開発時間を節約できます。最終的には、何年にもわたってクライアントプロジェクトに取り組み、本番環境でプラットフォームをテストして改良してきたチームの社内での長年の経験に基づいています。

パフォーマンスの向上とトレードオフ。

ヘッドレスを開発する主な方法は 3 つあります。

クライアント側: すべてが JavaScript を使用してブラウザ上に構築され、アクセス時にサーバーからコンテンツがロードされます。 たとえば、React をエンジンとして使用すると、REST API などを介してデータを取得します。ページが変更されると、API に対して追加のデータが要求され、新しいページがクライアント上に構築されます。ほとんどの場合、シングルページアプリケーション (SPA) で使用されます。
静的公開: すべてがサーバー上で HTML、CSS、および JS として既にビルドおよびエクスポートされています。 ページを動的に生成するのではなく、静的ファイルのみを提供するため、これは非常に低電力のサーバーまたは CDN に保存できます。この方法は超高速です。これは、多くの場合、Next.js などで行われます。ページが変更されると、新しい HTML ページがサーバーからダウンロードされて表示されます。パンフレットサイトやドキュメントなど、あまり変更されないサイトで最も頻繁に使用されます。
アイソモーフィックページ: アクセスされる最初の Web ページは HTML としてサーバーサイドレンダリング (SSR) されますが、それ以降の他のすべてのページは、クライアント側で生成できる場合はクライアント側で生成されます。クライアントがページを生成できない場合、サーバーに要求します。ほとんどの場合、プログレッシブ Web アプリ (PWA)、非常に動的なサイト、または古い Web ブラウザーに対応する必要があるサイトで使用されます。多くの場合、これにはSvelte.kitなどのフレームワークが使用されます。

方法 1 と 3 は、フラットなデータファイルを使用して HTML を生成し、静的な公開サイトと同等にすることができますが、REST または GraphQL を使用すると、リクエストごとに JSON コンテンツを生成する必要がある場合があるため、処理が少し遅くなります。

ユーザー生成コンテンツ (フォームやコメント) が必要な場合、これら 3 つの作業方法は標準の WordPress よりもはるかに複雑になります。

連絡先フォームを例に取りましょう。フォームはクライアント側で動作するように構築する必要があり、その情報を Javascript/AJAX 経由でサーバーに送り返す必要があります。サーバーでは、チェック、サニタイズ、および連絡先への挿入が行われます。フォームプラグイン管理システム。これはまったく異なる作業方法であるため、コンタクトフォームプラグインメーカーにこれを提供することや、ハニーポットやその他のスパム保護などの機能が引き続き機能することに依存することはできません。 REST エンドポイントを作成し、必要に応じてすべてを機能させるには、開発者が必要になる場合があります。はるかに複雑です。

理論的には、REST エンドポイントが既に存在するため、コメントははるかに簡単ですが、開発者は、承認されたコメントを取得してスレッド化されたレイアウトで表示し、新しいコメントを承認プロセスにアップロードできるようにする必要があります。、そしてもちろんスパムに対処します。

ヘッドレスの方法で開発する場合、WordPress ですぐに使用できる、またはいくつかのプラグインで可能になるのと同じ目標を達成するために、さらに多くのことを行う必要があります。

改善されたセキュリティの認識?

ヘッドレス WordPress のセキュリティに関しては、多くの誤った情報があります。 CDN を使用して静的サイトのセットアップを実行することは、DDoS 攻撃に対する優れた予防策です。しかし、最終的には、必要なシステム (Cloudflare など) を配置しないと、どのサーバーも DDoS 攻撃の犠牲になる可能性があります。分離された WordPress セットアップは、別のドメインまたはサブドメインにインストールされた WordPress で動作し、フロントエンドは標準ドメインにあります。

たとえば、この Web サイトを使用する場合、wp.servebolt.com をチームがブログ投稿を公開し、サイトの一部を管理するための領域として設定しながら、一般にアクセス可能なサイトとして引き続きservebolt.comを使用しますたとえば、Next.js フロントエンドを例として使用すると、リクエストごとにページ HTML が生成されるSSR (サーバー側レンダリング) またはページ HTML が生成されるSSG (静的生成) のいずれかを使用する選択肢があることを意味します。ビルド時に生成されます。静的な生成により、HTML をリクエストごとに再利用して、CDN によってキャッシュできるようになります。

どちらの場合でも、プレゼンテーションレイヤーは引き続き、WordPress を実行するコンテンツレイヤーと通信し、そこからコンテンツを要求します。これは、ヘッドレス WordPress セットアップのコンテンツ管理レイヤーをホストする領域で引き続き WordPress が実行されることを意味します。

これをまとめると、ヘッドレス WordPress Web サイトと従来のセットアップで実行されるサイトのセキュリティが優れているかどうかの答えは、そうなる可能性があるということです。 簡単に言えば、あまり一般的ではない設定だからです。これが意味することは、WordPress を実行しているサイトにセキュリティ上の問題があるという認識を一部の人が描き出そうとする本当の理由は、非常に多くのサイトが WordPress を実行しており、物事は完全に柔軟であるため、もちろん、何かを構築またはインストールできるということです。ヘッドレスおよび事実上他のスタックでビルドする場合も同様です。

私たちがServeboltで行っているように、セキュリティ、スケーリング、およびパフォーマンスの能力をもたらすWordPressホスティングプロバイダーと協力する場合、WordPressでできることすべてを犠牲にすることなく、サイトを安全に保つことが非常に可能です – 高価な開発に耐える必要がありますゼロから再構築するためのコスト。

ヘッドレスで遭遇する可能性が高いその他の欠点

ヘッドレス WordPress のコスト

これについてはすでに簡単に触れましたが、要するに、ヘッドレス WordPress は非常に高価になる可能性があります。開発コストだけでなく、おそらくもっと重要なのは時間です。

あなたのチームは、社内 (または代理店) のエンジニアに頼らなくても、迅速に行動して反復する能力を失います。

サイトを静的なものと見なさないペースの速いチームにとって、これは最終的に価値のないトレードオフです。社内でヘッドレス WordPress を管理するためのリソースを明らかに持っている 8 桁の企業が、ヘッドレスのセットアップに移行し、最終的に戻るという選択をする方法を直接見てきました。時間の損失、迅速に動く柔軟性、そして最終的にはチームのほんの一握りの人々がサイトで作業するためのコントロールを提供します。

自分が何をしているかを知っている優れた開発者を見つけるのは難しい場合があります

ヘッドレス WordPress はまだ比較的新しい設定です。したがって、JavaScript (および React、Vue、Svelte、Gatsby などのフレームワーク) に精通している JavaScript 開発者を見つけることは決して特に難しいことではありません。おそらく、優れた WordPress 開発者を見つけるよりも簡単です。すべてのベストプラクティスに準拠した従来の方法での WordPress は、入手がより困難になる傾向があります。

フルページエッジキャッシュより常に高速であるとは限らない

高速な Web サイトへのより簡単な (そしておそらくより良い) 方法があります。

ヘッドレスアーキテクチャを検討しているほとんどの企業は、非常に複雑な決定を下す前に、まずホスティングを修正する必要があります。これがはるかに簡単であるだけでなく、巨額の先行投資をしなくても、大幅な改善をすぐに確認できます。サイトの再構築に投資したり、WordPress インストールのすべての利点を現在の状態でトレードオフしたりする必要はありません。

ヘッドレスWordPressを避けるべきときは?

一般的な経験則として、ヘッドレス WordPress は、WordPress で構築するほとんどのビジネスには適していません。つまり、次のような人たちです。

2 つの別個のレイヤー (コンテンツレイヤーとプレゼンテーションレイヤー) を維持したくない。
WordPress で知られている編集とコンテンツ管理のワークフローをあきらめたくありません。
常に開発者に頼ることなく、彼らのチームが制御と柔軟性を持って作業できるようにします。
リソース（時間とお金）を節約したい。
システムの作成方法について正しい選択を行うために、経験豊富な開発者を用意しないでください。
一時的な労働者を雇うことを検討していますか、それとも将来の発展を見据えてエージェンシーにサイトを開発してもらいたいですか?

ヘッドレスWordPressは誰に適していますか?

ヘッドレス WordPress は、次の場合にチームに適した選択肢となります。

あなたの開発チームは JavaScript フレームワークを使った構築に熟練しており、WordPress 開発者を見つけることはできません (理由は何であれ)。しかし、WordPress をコンテンツ管理システムとして引き続き使用したい場合は、ヘッドレス WordPress が適切なオプションになる可能性があります。
あなたのチームは、すでに構築されている SaaS プラットフォームの設計間の継続性など、特定のことを達成したいと考えています。これにより、これらを再構築して WordPress で維持することがより多くの作業になります。この場合、コンテンツレイヤーとプレゼンテーションレイヤーを分離することをお勧めします。
あなたは、WordPress テーマの範囲内でビルドしないように設定されており、プラグインが提供する追加機能に特に依存していません。
雇用主として、技術スタッフに最新のスキルを継続的にトレーニングし、この知識を与えることで、彼らがより長くあなたと一緒にいる可能性が高いことを知りたいと考えています.
目標は、スタックのすべての部分でn次の最適化を実行することです。

ヘッドレス WordPress で構築された Web サイトの例

ヘルスライン

TechCrunch

フロンティティ

バックリンコ

ルディス

事後報告 – ソリューションとしてのヘッドレスの評価

ヘッドレスを探求したい人もいます。それは、他のほとんどの人が取り組んでいない輝かしい新しいものであるためです。それは、他の方法では達成できない特定の問題に対する真の最善の解決策だからではありません。副産物として、ヘッドレスアプローチを採用するほとんどのサイトは、必要のないオーバーエンジニアリングのカテゴリに分類されます。

言うまでもなく、ヘッドレス WordPress のエキサイティングな実装と、それが最適な選択肢となるシナリオもあります。チームが達成しようとしている結果を推進する素晴らしい Web サイトを構築できるのは、選択次第です。

ヘッドレス WordPress があなたのチームが求めているものと一致するかどうかまだ疑問に思っていますか? お気軽にお電話でご予約ください。お客様が経験していて、解決するためにヘッドレス WordPress の実装を検討している問題について、喜んでお話しさせていただきます。

または、このガイドがすでにすべての質問に答えており、Servebolt アプローチを試す準備ができている場合:

経験的に高速なマネージドホスティングに興味がありますか? WordPress ホスティングへのアプローチをお試しください:

スケーラビリティ:実際のユーザーワークロードテストでは、Servebolt は 65 ミリ秒の平均応答時間を実現し、2 番目に優れた製品よりも 4.9 倍高速でした。
最速のグローバル読み込み時間:平均ページ読み込み時間は 1.26 秒で、グローバルな WebPageTest の結果のリストのトップになりました。
最速のコンピューティング速度: Servebolt サーバーは、前代未聞のデータベース速度を提供し、1 秒あたりのクエリ処理速度は平均の 2.44 倍、PHP の実行速度は 2 番目に優れたサーバーの 2.6 倍です。
完璧なセキュリティとアップタイム:すべてのモニターで 100% のアップタイムがあり、SSL 実装の A+ 評価により、サイトがオンラインで安全であることを保証できます。