プログラム
プログラムは、 #5だが、実際には #6だった模様。このイベントは大半がビデオオンでの参加が印象的だった。
以下、発表を筆者が聞いて、筆者なりに理解した内容をネットで調べた情報などを加味した上で記載しています。そのため、必ずしも発表者の意図した内容になっていない場合もあります。
質問は、Twitter に #WPmeetupOsakaのハッシュタグを使って行うというのがベースとなっていた。
WordPress で Headless フロントエンド
Headlessを利用するにあたってのデータ取得は、
- WP API（WPコアが提供するREST API）を使う
- WP GraphQL（プラグイン）
- WordPress のデータを GraphQLで扱える
- 過去に破壊的変更があったので注意
Webサイトの表示方法は、SSR / SPA / SSGある
Client Side Rendering（SPA）・SSR・SSG を整理してみた（雑草魂エンジニアブログ）
- SPA = Single Page Application（描画：ブラウザ上）
- Ajax でデータを取得して表示というのが多い（Webアプリなど）
- WordPress だと Reast で REST API利用するような形態
- データ取得したときにサニタイズしておくのが無難（されているはずだが）
- SSR = Server Side Rendering（描画：サーバー上）
- すべて JavaScript でやるので、SEO / OGPで一手間必要
- JavaScript の読み込みサイズが肥大化しやすい
- SSG = Static Site Generator（描画：CI / ローカルなどサーバー上）
- React での SSGとして、Next.js（自前実装必要）, Gatsby (GraphQL 利用) などがある。
- サイトで表示するHTMLを事前に生成する（Movable TypeのGenerate のようなもの）# WordPressのHTML静的化プラグインのようなものか...
- HTML化することにあるので、表示速度がはやく、WordPressやDBに障害がおきてもウェブサイトはダウンしない。
- ビルド（HTML化）しないと公開できない（全ページをビルドし直す）。250ページぐらいだと2分ぐらい掛かった経験がある。
- ページ数に比類してビルド時間がかかる
- ビルドのデバッグが少し大変
SSR で Webサイトを作る
などもあるが、WordPress のテーマがやっていることを別のシステムでやっているだけなので、車輪の再発明ではないかという話はある。
JavaScript でフロントエンドをなぜ作るのか
Reactstrap / Material Design / Foundation 等を使ってマークアップの共有化ができる
筆者感想
筆者はデジタルキューブのAMIMOTOマネージドサーバーを利用して WordPressをいくつか管理運用している。そのうちの一つが、裏側で WordPress を動作しつつ StaticPress用な静的HTMLへビルドして、表のサイトを表示するということをやってもらっている。これがまさに SSG のような手法であり、今後はそちらのほうがいいのかもしれない。WordPressのStaticPressのようなプラグインは開発が停止してしまうこともあり、何度か変えた覚えもあるため。
以下、筆者が気になった質問を書き出してみた。
質問１（筆者）
https://twitter.com/kimipooh/status/1330390365359190017
WordPressの静的HTML化プラグインのようなものでウェブサイトを作っているものもあるのですが（そのサイト自体はもう更新しないのでいいのですが）、今後同じような運用形態が必要な場合、SSGを使うのがよいのかどう判断したらいいでしょうか。規模でしょうか。 #WPmeetupOsaka
回答
これも SSGといえる。１つや２つのサイトを作るぐらいで Next.js などを利用した SSGを使うのはコストパフォーマンスが悪いと思うので、 WordPress テーマを静的HTML化するのがよいとは思う。ただし、WordPress プラグインは内部PHPで静的HTML化処理をしており、大規模サイトなどではパフォーマンスが悪い場合が出てくる。そのため、デジタルキューブが提供を始めた Shifter のように外部から静的HTML化するという手もある。
質問２
どこから始めたらいい？
回答
とりあえずやってみたいというなら、Frontity がよい。
- Frontity -> Gatsby -> Next.js
らしい。
質問３
既存の WordPress で運用方法（SSR / SPA / SSG）を変更するときの気をつけることは？
回答
ウィジェットがうまく行かない可能性がある。プラグインやテーマが吐き出す CSS は Headless は自動取得できず、それぞれ調べて追加しないといけないので、既存テーマままで、移行するのはナンセンス。テーマ部分は作り直したほうがいい。
質問４
Headless を作ったサイトの管理運用は普通の人（WordPress でのサイト担当者）はできる？
回答
Headless をある程度理解している人に管理運用を担ってもらったほうがいい。
運用現場からお伝えします！ Headless CMS を使ったJamstack 構成の運用
- Jamstackって何なの？何がいいの？（Quiita）
- コンテンツ担当者にとっては、WordPress の画面なのでとっつきやすい
- マルチ管理しなくてよい
- １つ書いたら、複数サイトに同時更新できる
- 本番前には Staging でチェック
- マスターと Staging の２つのサイトが動いていて、Staging のほうでチェックしてから、マスターを更新するようにしている
- エラー時はログで判断する必要あり
- Headless CMS ==> Static Site Generator ==> CDN / Hosting という構成になると、どこの工程でどうなっているかはログをチェックし、それらのサーバーやシステムを管理するエンジニアとコンタクトする必要あり
- JAMStackとスタティックサイト サイトジェネレーターに酔いしれた一夜 JP_Getshifterミートアップレポート（デジタルキューブ）
- 成長を続けるJamstack WordPressコミュニティのシフターの最新ニュースと最新情報（デジタルキューブ）
以下、筆者が気になった質問を書き出してみた。
0 件のコメント:
コメントを投稿