DE{CODE}: クライアントにヘッドレスを選択する場合

公開: 2023-02-12

クライアントにパフォーマンスとセキュリティの要件がある場合、エージェンシーはどのような場合に従来の WordPress またはヘッドレス WordPress を選択する必要がありますか? この DE{CODE} セッションでは、ヘッドレス化の利点、制約、機会、およびトレードオフについて議論する代理店の専門家のパネルを特集しています。

ビデオ: クライアントにヘッドレスを選択する場合

セッションスライド

WP EngineからClients.pdf のヘッドレスを選択する場合

全文トランスクリプト

HASHIM WARREN:こんにちは、私たちのパネルへようこそ、クライアント向けにヘッドレス WordPress を選ぶとき。私の名前は Hashim Warren です。ヘッドレス WordPress のソリューションである Atlas のプロダクトマーケティングマネージャーです。そして、ヘッドレス WordPress を採用している、または採用したいと考えている人々から私が最初に受け取った質問の 1 つは、いつ従来の WordPress をオールインワン WordPress で使用すべきか、いつヘッドレス WordPress を使用すべきかということです。

したがって、ヘッドレスまたは従来の WordPress の採用または選択に関して、パフォーマンスとセキュリティの要件があるクライアントがいる場合、何を考えるべきでしょうか。また、ヘッドレス WordPress を選択した場合、何を期待すればよいのでしょうか。今日は、従来の WordPress プロジェクトとヘッドレス WordPress プロジェクトの両方の経験を持つ優れたパネルがあり、皆さんの多くが抱えている大きな質問のいくつかに答えることができます.

今日は、Click Here Labs のテクニカルプロダクションディレクターである Jonathan Jeter と一緒にいます。また、Springbox のテクノロジディレクターである Stephen Brooks もいます。また、スペース 150 の最高技術責任者である James Squires もいます。drawl のマネージングディレクターである Tayo Onabule もいます。

ですから、今すぐパネルを持ってきて、この会話を始めたいと思います。それでは、このような形で会話を始めましょう。そもそも、個人的に、またはあなたの代理店がヘッドレス WordPress に興味を持った理由を教えてください。ジョナサン、私たちを始めてもらえますか?

JONATHAN JETER : もちろんです。そのため、私たちはしばらくの間、ヘッドレススペースでの作業に関心を持っていました。私たちがこれに関心を持った主な理由は、複数のソースからのデータを統合する大規模なプロジェクトを作成したかったからです。そして、WordPress API はまだ完成していませんでした。そのため、WordPress のコンテンツを引き続き使用しながら、フロントエンドレイヤーを表示するさまざまな方法に取り組んでいました。そして、それは基本的に私たちが約5年から7年にわたって行ってきたことであり、それを行うための最良の方法は何かを理解しようとしていました.

そして今では、以前よりもはるかに簡単になりました. そして、私たちはスペースが成長するのを見てきました. それ

ハシム・ウォーレン: 素晴らしい。スティーブン、似たような話はありますか? あなたやあなたの代理店がヘッドレス WordPress に興味を持ったきっかけは何ですか?

STEPHEN BROOKS : ええ、2015 年頃からヘッドレスの分野に携わっており、伝統的にジャムベースの CMS プラットフォームを扱ってきました。過去数年間、投稿やページタイプのアプローチとは対照的に、コンテンツエントリのパラダイムシフトが原因で、Jam システム内で作業している一部のマーケティングチームに対応することが困難になってきました。

また、Jonathan と同様に、WordPress API を活用することも試みました。これは少し面倒です。常に必要なものを正確に取得できるわけではありません。 WP Engine が Atlas に言及し、その基盤となるテクノロジーについて話すときはいつでも、ジャムスペースで伝統的に行ってきたことに対するシェフのキスでした。

ほとんどすべてのマーケティング担当者が WordPress 内で作業した経験があるため、クライアントとの会話は非常に簡単になりましたが、開発者はヘッドレスソリューションの追加の利点を得ることができます。そのため、React ベースのプレゼンテーションレイヤーとの最上位のやり取りだけでなく、セキュリティリスクを軽減することもできます。それが最近の私たちの本当の推進力です。

ハシム・ウォーレン: すごいですね。 Tayo さん、あなたのストーリーを教えていただけますか。それをフォローアップするために、パブリッシャーにヘッドレス WordPress を採用するよう説得したことについて教えていただけますか?

TAYO ONABULE : ええ。つまり、私たちの場合、ヘッドレスWordPressスペースへの参入は少し最近で少し異なっていると思います. 私たちの中心的な推進力の 1 つは、クライアントの 1 つである Android Authority で、かなり広い範囲をカバーしています。現時点では、月間訪問者数が 2,000 万人を超えていることを暗示しているようなものです。

そして、彼らのニーズはある意味で非常に単純です。トップティアのような本当に優れたSEOが必要です。そして、彼らの周りには非常に有能な競争相手がたくさんいます。ええ、本当に素晴らしいSEO、本当に素晴らしいパフォーマンス、そして彼らが公開するすべての記事の本当に素晴らしい読書体験.

つまり、ヘッドレスは本当に、会話の一部として、既存の WordPress サイトでこれらすべてのニーズを満たせるようにする方法を見つけるためにできる限りのことをしようとしていたときに、私たちにとって本当に思いつきました。基本的に、本当に最大限に。そして、ヘッドレスについては、まず、私がいくつかの調査を行って、ああ、もしかしたらできるかもしれない、これをやってみるかもしれないというようなものでした。

そしてどんどん突っ込んで、チームを説得するプロセスを経ていきました。しかし、開発全体を進めていくと、SEO のパフォーマンスやエクスペリエンスなどの主要な質問のすべてに答えていることに気付き始めましたが、年月が経つにつれて完全な柔軟性も得られました。の上。

ローンチしたのは昨年の 5 月だったと思いますが、実際にはその記念日に近づいています。、しかし、ええ、その立ち上げ以来、私たちはサイトに膨大な数の統合を構築することに成功しました. モノリシックまたはオールインワンの WordPress を使用していた場合、これらすべてがかなり困難だったでしょう。それが提供するその柔軟性は、私が Android Authority に伝えていたことの 1 つです。

ハシム・ウォーレン: すごいですね。これまでのところ、SEO のパフォーマンス、開発者にとっての柔軟性、プロジェクトの種類に関する柔軟性、パブリッシャーが知っている CMS を使い続けることができることについて聞いてきました。ジミー、あなたの経験はそれと一致しますか? それとも、あなたやあなたの代理店がヘッドレス WordPress に惹かれた理由について何か付け加えることはありますか?

JAMES SQUIRES: ええ、共通点もたくさんあると思います。私がおそらく付け加えたいことの1つは、最初は少し利己的であるかもしれないということですが、私はそこにたどり着き、なぜそれが良いことなのか. しかし、私たちにとっては、開発者の満足度が重要でした。

私たちは主に React と React ベースのフレームワークのバックグラウンドから来ており、WordPress を始めたようなものです。そして、クライアントは WordPress をますます要求していましたが、エンジニアは、ほとんどの部分でテーマベースの開発を行うことに満足していません. それが非常に理にかなっているアプリケーションがまだある場合は、私たちはまだそれを行っていますが、開発者が製品と彼らが構築しているものに満足している場合、その結果はしばしば優れたエクスペリエンスを得ることがわかります。これは、エンジニアがやりたいことを中心としたものでしたが、クライアントにとっては本当にメリットがあります。

ハシム・ウォーレン: すごいですね。これを見ている多くの人が会議で耳にしたことの 1 つは、WordPress のテーマベースの開発とコンポーネントベースの開発の違いです。誰もそれについて話すことができますか？ Web サイトを構築する際にコンポーネントベースのアプローチを採用する利点は?

TAYO ONABULE: ええ、実際に飛び込みたいです。同様に、私たち全員がこの例を持っていると確信していますが、とにかく私たちの経験では、React のような JavaScript ライブラリを使用するときに起こる最も満足のいくことの 1 つは、あなたが言うように、そうです。この種のコンポーネントベースの建物スタイルへのアクセス。

そして、それは、サイトのデザイン全体を、はるかに柔軟なこれらのコンポーネントパーツに分割できることを意味します。例として、ページに 2 つの異なるスタイルを持つブロックがあるとします。 1つは、画像が左側にあり、テキストが右側にあるとしましょう。単純な例のようなものです。そして React は、モディファイア付きの 1 つのブロックを持っている場合です。基本的には、テキストと画像の順序を反転させます。

私たちがモノリシックについて話しているとき、あなたは基本的に、そうです、おそらく同じベースで始めますが、すぐに2つを分割する必要があり、2つの別々のものを手に入れます. そして、変更はある程度、2 つの別々のものに分散する必要があります。そして、ヘッドレスフロントエンドの使用がますます大規模になるにつれて、サイト全体、特定のコンポーネントのすべての使用にわたって実行できる柔軟性と一貫性が開発を意味するのは、そのような概念です。、ジェームズが以前に言ったように、開発者にとって非常に満足のいくものです.

それはかなり良い経験です。 React は、開発者のアウトプットを最大化するように設計されていることがわかります。James が言うように、そのすべてがクライアントに渡されます。愛情を込めて作ったものの方が良いアウトプットにつながると思うので。

スティーブン・ブルックス: うん、それだけじゃないよ、タヨ。しかし、それには他にもいくつかの大きな利点があります。開発者の満足度という点では本当に頭を悩ませているということですが、コンポーネントベースの開発ではなく、従来のテンプレートベースの開発を見てみると、ユニットテストですよね。テーマベースのアプローチ内であらゆる種類の単体テストを実装するのは非常に困難です。コンポーネント、ブームがあれば、すぐそこにあります。

1 つ付け加えておきたいのは、必ずしも開発者向けというわけではなく、ビジネスオーナー向けということです。通常、コンポーネントベースのアプローチでは、特定のテーマページに対する労力のレベルが大幅に低下します。これは、コンポーネントをあらゆる場所で再利用することになるからです。また、他の場所に移動してその追加のブロックを追加するために、追加のキーボード入力時間、タイピングを必要としません。一度ビルドするだけです。それを消費するたびに、ビルドを水和します。ブーム、あなたは終わった。とても美しく、とても速いです。素晴らしいです。

JONATHAN JETER: そして、クリエイティブスタッフをトレーニングする必要がありました。私たちは、いや、それから逃げませんよね。そして、私たちはそれを呼び出すことになりました。キッチンシンクのページをデザインするだけです。1 つのページにすべてが含まれています。そうです。そこから作成します。ええ、開発はずっと簡単になりましたが、私たちが何をしているのか、どのように構築しているのかをスタッフが確実に理解できるように、全面的にスタッフをトレーニングする必要がありました。

JAMES SQUIRES: ええ、作戦にも。つまり、これを行っているときに、クライアントへの提案がどのように形作られるかが変わりました。テンプレートとは対照的に、ブロックの量と、それらをどのように構築しているかについて話します。これはまさにパラダイムシフトだと思います。特にマーケティング側の一部の人にとっては、さまざまなブロックタイプの無限のページがあることを考える必要があると思います。それは実際には、これらのコアブロックとコンポーネントであり、私たちが構築してスコープを設定しているものです。

TAYO ONABULE: 最後に 1 つだけ。また、提案について言及することは非常に良い点だと思います。なぜなら、ヘッドレスプロセスは、機能や新しいページレイアウトに必要な予測を大幅に変更するからです。事実、時間の経過とともに非常に一貫して減少しています。コンポーネントライブラリが広ければ広いほど、スタイルや何かを追加したり、サイト全体でスタイルを微調整したり、新しいページレイアウトを追加したりするのにかかる時間が少なくなります。これらはすべて、ますます簡単になります。

正直なところ、それは誰にとっても嬉しいことだと思います。

ハシム・ウォーレン: とても興味深いですね。ヘッドレス対オールインワンサイトというだけではなく、テンプレートベースの開発とコンポーネントベースの開発です。そして、見積もり、クライアント作業とクライアント承認、テスト、および QA 作業、開発作業、および設計作業に触れているようです。そして、シフトがあるようです。そして、ポジティブな変化があるように聞こえます。何かありますか-

したがって、クライアントが来て、xyz 要件があると彼らが言うとします。これがヘッドレスプロジェクトに最適であると思わせる要件のセットは何ですか? そしてスティーブン、私たちを始めてもらえますか?

スティーブン・ブルックス: そうですね。したがって、私が個人的に最初に注目するのは、組織が必要とするセキュリティフットプリントです。これは内部向けの Web サイトですか、それとも外部向けの Web サイトですか? その後、この CMS が複数のアイテム、オムニチャネル配信を強化するかどうかについて検討を始めます。これらの最初の 2 つのボックスがオフになっている場合、ブーム、それは自動ヘッドレスビルドです。

そのうちの 1 つだけがチェックされている場合は、クライアントともう少し深く話し合って、それが運用フットプリントに沿っていることを確認する必要があります. そして、過去 8 か月間に交わした会話の 95% はすべてクールなものでした。誰もがそれを好きです。これは、他のすべてのものからの真のパラダイムシフトです。それで、ええ。

ハシム・ウォーレン: いいえ、それは素晴らしいことです。ジョナサン、それについて少し話してもらえますか? 「これはヘッドレスプロジェクトにすべきだ」と感じさせる要件は何ですか? また、ヘッドレスの採用についてクライアントにどのようなトレードオフを説明しますか?

JONATHAN JETER: わかりました。それで、主なものの 1 つは、サイトのコンテンツを集約するためにいくつのデータソースを使用しているかということです。そして、クライアントは、モバイルアプリやメディア、またはその他のもののために、これと他の 8 つのソースとは対照的に、これを中央のコンテンツリポジトリとして使用したいと考えていますか?

だから私たちはその会話をしています。彼らがそうなら、私たちはすべて参加しています。そして、それは当然の選択です。また、広告代理店として、常にこれらの非常にクレイジーなものをデザインしているこれらのクリエイティブなタイプがいます。そのため、クリエイティブが誰であるかを事前に知っていれば、そのテーマをカスタマイズするよりも、React アプリとして開発する方が簡単であることがわかります。ワードプレスで。

しかし、トレードオフ。 1つは価格です。それはより高価です、それはメンテナンスですよね。つまり、WordPress を維持しているだけでなく、2 つの異なるスタック、2 つの異なるアプリケーションを維持しているのです。これが、私たちがその道を進んだ理由であり、すべての AWS と Gatsby を使用して、事前にそれを行っていました。それで、アトラスが現れたとき、私たちは全員参加していました. 私たちは、そうそう、これらすべてを 1 か所で行うことができればのようでした。

何年もの間、私たちはWPエンジンと話をしてきましたが、私はそうでした。それでは、まとめてみましょう。だから私たちはそれについて興奮していました。 Atlas でサイトを構築するプロセスには本当に満足しています。しかし、トレードオフは基本的にメンテナンスであり、これは Atlas ではなくなります。標準の WordPress サイトとは対照的に、ホスティングに関する限り、クライアントのコスト。

しかし、前に言ったように、サイトの開発コストが下がり、サイトを維持するコストが下がることもあります。だからそれはトレードオフです。

JAMES SQUIRES: テーマベースのアプローチやヘッドレスに適しているかどうかを議論する際に考慮すべきもう 1 つの非常に重要なことは、サイト構築後のハンドオフはどのようになるかということです。クライアントは、これを引き受ける内部リソースがあることを期待していますか? それとも、信頼できる長期的なエージェンシーパートナーを探しているのでしょうか。

これは非常に重要な決定です。たとえば、React、Gatsby、Next など、ヘッドレススタックが最終的にどのようなものになるかに慣れていないチームがいる場合、彼らがヘッドレスアーキテクチャ、およびそれを維持する方法。これは非常に重要なことで、当たり前のように思えるかもしれませんが、明確に言うと、これがローンチされてメンテナンスモードになり、引き継ぎが行われたら、どのような計画があるのでしょうか?

ハシム・ウォーレン: 素晴らしい。

TAYO ONABULE: もう 1 つ、おそらくジョナサンが言及していたと思いますが、エージェンシーとして私たちが重点的に取り組んでいるのは、主にヘッドレスによって可能になるのはエクスペリエンスであるという事実です。もの。ユーザーがやり取りするものに関して。多くの場合、これはすべての企業にとって変化する会話です。一部の企業は、仕事を終わらせたいだけです。一部の企業は、それについて派手になりたいと考えています。

そして、クライアントにとって本当に画期的な体験をすることが重要である、またはパフォーマンスの面で本当に最先端のものを持っていることが重要である、または競争にかなり関与するものを必要とするすべての場合において、それらのすべてははるかに簡単です.ヘッドレスで行う。そして、私の頭の中の会話、または少なくとも私たちが始める傾向がある角度は、これは、あなたはそれを成し遂げる必要があるか、これは、あなたはそれを成し遂げ、人々に多くの印象を与える必要があるということです.

確かにWordPressは長い間それを成し遂げてきており、サイトを構築するのに堅実な場所ですが、基本的に、どのくらい「派手な派手さ」が必要ですか? そして、あなたがたくさん欲しいなら、ヘッドレスは本当に素晴らしい方法です

ハシム・ウォーレン: すごいですね。ジミー、エージェンシーの観点から人員配置についてお話したいと思います。ヘッドレスプロジェクトについて考えるとき、JavaScript や、たとえば React のようなものを採用した WordPress 開発者が必要ですか? それとも、WordPress を使用していない JavaScript 開発者がもっと欲しいですか? ヘッドレスWordPressプロジェクトに関しては、人員配置についてどのように考えていますか?

JAMES SQUIRES: ええ、それは良い質問です。私たちの代理店は、React をコアベースラインの一種として探しています。そのため、明らかに JavaScript と React フレームワークの経験が必要です。それは、すべてのレベルで、私たちの義務のようなものです。 WordPress は – 私たちはそれを「あればいい」ものとして扱います。これは、特にヘッドレススペースでは、比較的迅速にトレーニングできるものです。

つまり、一般的に言えば、ヘッドレスを使用すると、WordPress でカスタム投稿タイプの開発に時間を費やし、バックエンドの観点からコンポーネントフレームワークをレイアウトするだけですが、従来の種類のテーマベースの側面の多くには触れていません。通常のヘッドレスアーキテクチャで。そのため、本当にコアな WordPress エクスペリエンスは本当に必要ないことがわかりました。

もちろん、チームには特定の側面でそれを持っているプレーヤーが必要ですが、概して、これまで WordPress に触れたことのない React エンジニアを引き入れることに成功しています。フィールドに変更を加える方法を示し、彼らはすぐに実行に移します。彼らはすでにGraphQLを理解しています.GraphQLは、ヘッドレスアーキテクチャに慣れるために必要なコアコンピテンシーです.

しかし、それ以上に、WordPress の知識はかなり浅く、誰かをプロジェクトに参加させて非常に生産的にすることができます。 React コンポーネントの優れた点は、React 開発者がプロジェクトの途中に飛び込んでコンポーネントフォルダーを確認し、コンポーネントフォルダーを割り当てて、データ構造が既に設定されている限りレースに参加できることです。

HASHIM WARREN: 作業を分離できるという点では、それも非常に興味深いことです。このコンポーネントで作業し、プロジェクトとは別に作業することができます。それは本当に素晴らしい例です。

ジョナサン、ヘッドレス WordPress プロジェクトに関してはどう思いますか? React や JavaScript フレームワークを追加するスキルを持った WordPress 開発者が欲しいですか? または、WordPress でアップスケールする JavaScript 開発者は、それについてどう思いますか?

JONATHAN JETER: Jimmy が言ったように、両方が必要ですが、これからは React、View、フロントエンドの JavaScript 開発者をもっと探すつもりです。さて、今では誰もが自分自身をフルスタックと呼んでいますが、JavaScript 開発者はすぐに参加できるようになります。そして、開発者がやって来て、「WordPress で働くつもりはない」と言いました。私はやってみたいです。そして、いったんそれに取り掛かると、私たちはヘッドレスプロジェクトを行っています。ああ、それほど悪くはありません。

彼らは、PHP などのすべての作業を扱っているわけではないからです。しかし同時に、DevOps 担当者の何人かをバックエンドの WordPress を扱うように実際に移動したので、バックエンドの開発者がそれを行う必要は必ずしもなく、非常にうまく機能しています。どうぞ。

JAMES SQUIRES: 少なくとも私たちの経験から言えば、ヘッドレスプロジェクトに参加して生産性を高めることができるエンジニアの数は、はるかに多くなる傾向があります。たとえば、先週、SvelteKit ベースの Headless をローンチしたばかりです。これは Atlas で最初のものだと思います。クライアントにはまだ SvelteKit をお勧めしませんが、かなり気に入っています。

しかし、8 人を超えるエンジニアが同時にコンポーネントに取り組んでおり、テーマベースの開発では、多くのエンジニアを獲得して生産性を上げるのに苦労する傾向があります。一度にいくつものものに触れることができるという点で、物事がもう少しモノリシックであるという理由だけで. それは可能であり、調整することもできますが、ヘッドレスアーキテクチャの方がはるかに簡単です。

ハシム・ウォーレン: ところで、それは美しい光景です。打ち上げを見ました。美しいサイトです。

JAMES SQUIRES: ありがとう。

JONATHAN JETER: もう 1 つ言いたいのは、WordPress のことだけを話していることはわかっていますが、WordPress 以外のプロジェクトも扱っているということです。したがって、これらの JavaScript 開発者は、複数のバックエンドシステムにまたがって作業できます。.net 開発者を雇った場合、彼らはほとんどの場合、.net でしか作業しないのとは対照的です。

つまり、API が機能することを確認し、データを集約し、それらすべてをまとめている人がいます。そして、特定の言語に特化するのではなく、これらのプロジェクトのいずれかに取り組むことができるフロントエンドがあります。

TAYO ONABULE: そして、私たちが言及しているいくつかのことがここにあると思います. Reactのように、それがどうだと思いますか? 私たちの場合、とにかくReactに固執する傾向があります。 View 開発者は数人いますが、React を使い続ける傾向があります。しかし、これらのフロントエンドフレームワークはすべて、開発者とプロセスを念頭に置いて特別に設計されています。それらは設計されています。Facebook 氏はある時点で、これが私たちのチームにとって可能な限り効率的であることを確認しようと考えていたと思います。

これが React の核心であり、View と Angular でほぼ同じです。 WordPress 側については、もう一度、そのままの形で呼んでください。基本的に、WordPress のバックエンドをナビゲートする方法と ACF を使用する方法を知っているだけで十分です。それ以外の場合は、WordPress の知識がなくても、WordPress ヘッドレスサイトを構築できます。

したがって、WordPress 側の要件は、複雑になり始めることをしようとしない限り、技術的には、関数 .php ファイルがどこにあるかを基本的に知っていれば、ヘッドレス WordPress サイトを構築できます。あなたは通り抜けることができます。これの素晴らしいところは、ジョナサンが言ったように、これらの JavaScript 開発者がすべてのプロジェクトで役立つことです。近い将来、Web は JavaScript に重点を置いたものになると言っても差し支えないと思います。それは非常に有用な才能です。

最後の切り替えがどれだけ先かというと、しばらく時間がかかる可能性があります。正直なところ、ある意味で大きなコミットメントではありません。ほとんどの場合を想像するのは理にかなっています。

HASHIM WARREN: 私はあなたの話をバックアップしたいだけです。前世では、新しい WordPress サイトで 2 人の React 開発者を訓練しなければならなかったからです。そして、それはヘッドレス WordPress サイトでした。そして、それはちょうど午後でした。私は彼らに ACF を見せました。彼らは本当に興奮していて、データモデルを作成し、準備を始めていました。そして、開発者の 1 人でさえ、実際に従来のエディターを接続して、フロントエンドのいくつかのコンポーネントを制御できるようにしました。

これはグーテンベルクの前のことなので、リピーターフィールドと ACF を使用し、フロントエンドのコンポーネントの一部を制御していました。それは驚くべきものだった。しかし、2 人の React 開発者はすぐに理解しました。彼らはちょうど午後になり、レースに出かけました。

TAYO ONABULE: この種のフロントエンド開発者は、バックエンドにデータを接続し、データ構造に固執することに慣れています。これは彼らのワークフローの一般的な構成要素であるため、WordPress はそれほど有利ではありません。

JONATHAN JETER: 申し訳ありませんが、SaaS の普及により、アプリケーションがどこでも利用できるようになり、以前は WordPress で行っていたことが、e コマースであろうと、CRM との統合であろうと、あらゆる種類のものです。これはもう WordPress で行う必要はありません。 Marketo プラグインや Salesforce プラグイン、またはこれらを接続するための何かをインストールする必要はありません。

これらの接続を自分で行うことで、より優れたエクスペリエンス、カスタマイズされたエクスペリエンスが可能になります。 PHP 開発者をそこに招き入れて、WordPress 内でこれらを機能させる方法を見つけようとするのとは対照的に、これにより、速度、セキュリティ、およびこれらすべてが可能になります。

ハシム・ウォーレン: 素晴らしい。スティーブン、エコシステム、JavaScript エコシステムについてぜひお聞かせください。 WordPress 開発者は、プラグインやコミュニティの点で、非常に優れた堅牢なエコシステムに慣れていることを知っています。 JavaScript の世界のエコシステムとの比較について教えていただけますか? テクノロジーの面でも、コミュニティの面でも。

STEPHEN BROOKS: そうですね、WordPress では、従来のモノリスビルド用のプラグインの最大のマーケットプレイスを手に入れました。しかし、ほんの少し前の Jonathan のポイントに戻ると、フロントエンドから必要なすべての機能に NPM を活用することで、WordPress マーケットプレイスよりも優れているとまではいかなくても同等です。利用可能なすべての NPM パッケージがあるだけではないからです。必要なすべてのデータ統合を本当に迅速に作成するために、プルできる多数の STK もあります。

つまり、約 20% 大きいと言えます。そこに任意の数字を投げるだけですが、人々が動くのははるかに高速です。そして、NPM の多くは適切です。また、発生する可能性がある WP コアバージョンとプラグインバージョンの不一致についても心配する必要はありません。パッケージマニフェストにバージョンを固定したら、完了です。更新したくない場合でも、更新について心配する必要はありません。

繰り返しになりますが、誰もが言っていることに戻ります。従来のヘッドの WordPress アプローチとは対照的に、ヘッドレスソリューションを使用する場合は常に速度と柔軟性が最も重要です。

JAMES SQUIRES: WordPress プラグインで大金を稼いでいるビジネスに影を落としてはいけませんが、ヘッドレスアーキテクチャではライセンスコストが低くなる傾向があるため、これは別の領域です。いくつかの本当に素晴らしいプラグインがあり、購入して利用するための提案に常に取り組んでいます. ほとんどの場合、NPM のすべては無料のオープンソースソフトウェアです。

確かに、サービスモデルが関連付けられているものもあります。しかし、一般的に言えば、最も人気のあるソリューションを見つけることができ、それはオープンソースライセンスです。したがって、そのように迅速に移行するのは簡単であり、ライセンス費用などに関するクライアントの承認で速度を落とすことはありません。

ハシム・ウォーレン: ジミー、そのような別の例があります。それで、私はギャツビーのウェブサイトを構築していて、そこに Google アナリティクスを追加していました。 Gatsby にはプラグインエコシステムがあり、すべてのプラグインはオープンソースです。彼らのパッケージは NPM にあり、インストールするだけで簡単です。そこで、Google アナリティクスを追加しました。これらのオプションがすべてあり、WordPress 用の最も人気のある Google アナリティクスプラグインを使用すると、これらのオプションの一部がプレミアムバージョンに入ります。ですから、この WordPress プラグインに喜んでお金を払って、Gatsby プラグインでもあるこのパッケージと同じ機能を持たせることに、私は非常に興奮しました。これらのエコシステムがどのように一致するかについて、本当に興奮しています。

TAYO ONABULE: NPM の話題全体についても非常に迅速だったと思います。それはほんの些細なことで、おそらく取るに足らないことだと思いますが、私にとっては私です。私は、React で何かを開発しているときに、何かが必要になり、CLI を介してダウンロードするという事実を非常に好みます。そして、WordPress やその他のグーイにアクセスする必要はありません。それはあなたのスペースにあるだけです。スタジオを出る必要はありません。すべてがそこにあります。また、調査を行ったり、プラグインを見つけたり、インストールしたりするよりも、はるかに面倒なプロセスではありません。私はそのファンではありませんでした。

ハシム・ウォーレン: 素晴らしい。ジョナサン、お聞きしたいのですが、これがヘッドレス WordPress に最適だと思わせる要件について話しました。どんな種類のプロジェクトがあなたに感じさせますか?OK、これは伝統的な WordPress プロジェクトであるべきです。

JONATHAN JETER: ですから、私たちもそれらの多くを行っています。場合によっては予算です。彼らは入ってきて、私たちはこれだけ持っていると言います。選択肢はありませんよね。これが私たちがしていることですよね。そして、私たちは使用するものを持っているからです。そのプロセスとシステムはすでに整っています。ジミーが言っていたように、私たちはプラグインをこれらの提案のすべてに組み込んでいます。非常に簡単だからです。

つまり、典型的な小さなブランドサイトです。典型的 – 先ほどタヨが言っていたように、派手である必要はありませんよね。このサイトにはとんでもなく創造的なものはありませんよね。そして、彼らはちょうど行きました、ねえ、私たちは以前にそれらを持っていました.私たちはウェブサイトが必要であることを知っているので、私たちを作ってください. 右。その場合は、予算と要件に基づいて、標準の WordPress サイトで十分です。

Genesis、Genesis Pro、Smart Plugin Manager などを使用して、開発者が触れないサイトを構築するまでになりました。プロセスを通過するだけで、クリエイティブなプロセスでは、スタジオがファイルを編集し、基本的にコンテンツを挿入します。それを校正し、コンテンツを挿入する編集者が何人かいます。サイトは、開発者が触れることなく完成します。それ。

そういうタイプの予算では、これらのサイトの 1 つのバックエンドで 20 時間の開発を行うことはできないからです。ですから、それが巨大なサイトでない限り、通常は私たちが決定する方法です。これを通常のサイトにしたいだけです。多くのコンテンツ、ブログ、そのようなことを行ってきました。

SEOに関しては、WordPressは依然として優れています。それが彼らが探しているものなら、それがどのように見えるかは気にしないようです. 機能が欲しいだけです。私たちはそれを速くしたいと思っています。コンテンツを充実させ、ランクを上げたいと考えています。従来の WordPress サイトはうまく機能します。

ハシム・ウォーレン: 素晴らしい。スティーブン、それについて話すことができますか? When would you say, OK, this needs to be a traditional site or traditional WordPress site?

STEPHEN BROOKS: It really follows along with Jonathan. Cost is going to be the first one, and then the second one after that is going to be time to market. If somebody needs something out pretty quick, even with the accelerator as John's talking about in terms of Genesis blocks, and just having a block catalog that you can do 0 dev from, it's still really incumbent on getting that stuff out as quickly as possible for those clients. Also to spin outs is a pretty big one for us. To where, hey, we need some sort of marketing presence for our investors. This is going live in two weeks. What could you do for me.

HASHIM WARREN: Awesome Thank you so much to our panel for your participation today. If you are interested in Headless WordPress, you can get a free Atlas Sandbox account at WPEngine.com/Atlas. And compare for yourself. You can use an all-in-one WordPress site, and compare it right against a Headless WordPress site, to compare everything that we talked about today. Thank you so much for joining us.