WordPressを劇的に高速化、1秒以内に表示されるフロントエンドの構築方法 -Zero-latency WordPress Front-end

サーバーサイドのレンダリング(SSR)を使用して、数分の1秒以内にページが高速に表示されるWordPressのフロントエンドを構築するテクニックを紹介します。

バックエンドのキャッシュと組み合わせることで、非常に高速になり、しかも安価にWordPressサイトを構築できます。

待ち時間ゼロ!高速に表示されるWordPressを構築する方法

Zero-latency WordPress Front-end -GitHub

下記は各ポイントを意訳したものです。
※当ブログでの翻訳記事は、元サイト様のライセンスを元に翻訳しています。

デモページ

サンプルのコードで何ができるのかを示すために、3つのデモページを用意しました。

2つのデモページは、Amazon EC2 A1 インスタンスにホストされています。Graviton CPUのシングルコアと2GのRAMです。十分すぎるほどのスペックと言えるでしょう。

pfj.trambar.ioは同じサーバー上で実行されているテスト用のWordPressからデータを取得しており、ダミーテキストを使用しています。管理画面には、アカウント(bdickus)、パスワード(incontinentia)でログインできます。新しい記事を公開すると、キャッシュが削除されます。記事は約30秒後に自動的にフロントページに表示されます(更新ボタンを押す必要はありません)。

Nginxのキャッシュをここで見ることができます。

et.trambar.ioとrwt.trambar.ioは、それぞれExtremeTechReal World Techからデータを取得しています。これらは、サンプルコードが実際のコンテンツとどのように一致しているかを理解しやすくするためのものです。WordPressインスタンスからキャッシュパージコマンドを受け取らないので内容が古くなっている可能性があります。

サーバーサイドのレンダリング(SSR)

Isomorphic ReactコンポーネントはWebブラウザ上だけでなく、Webサーバー上でもレンダリングすることができます。サーバーサイドのレンダリング(SSR)の主な目的の1つは、検索エンジン最適化です。もう1つは、JavaScriptのローディング時間を隠すことです。ローディング時にスピナーやプログレスバーを表示するのではなく、フロントエンドをサーバーにレンダリングしてHTMLをブラウザに送信します。実質的には、ローディング画面としてフロントエンド自身の外観を使用しています。

下記のgifアニメは、SSRによってページがどのように機能するかを示したものです。

SSRでページがどのように表示されるか

SSRでページがどのように表示されるか

SSRのHTMLはJavaScriptにサポートされていませんが、機能的なハイパーリンクを持っています。JavaScriptの読み込みが完了する前にビジターがリンクをクリックすると、別のSSRページに移動します。サーバーはコードとデータの両方に即座にアクセスできるため、このページを非常に迅速に生成できます。ページがすでにサーバー側のキャッシュに存在している可能性もありますが、その場合はさらに早く表示されます。

バックエンドのサービス

バックエンドはWordPress自身と、Nginx、Node.jsの3つのサービスから成り立っています。下記の図では、さまざまなタイプのデータがどのように移動するかを示しています。

バックエンドの構成

バックエンドの構成

NginxがWordPressから直接JSONデータを取得しないことに注意してください。代わりに、データは最初にNodeを通過します。迂回しているのは、主にWordPressがJSONレスポンスに電子タグを付けないためです。電子タグがないと、ブラウザはキャッシュの検証を実行できません(つまり、条件付きリクエスト→304 not modified)。Nodeを介してデータを渡すと、不要なフィールドを削除することもできます。最終的に、Nginxに送信する前にデータを圧縮できます。サイズを小さくすると、より多くのコンテンツがキャッシュに収まります。また、Nginxが同じデータを何度もgzipする必要もなくなります。

フロントエンドのコードを実行すると、NodeはNginxにJSONデータをリクエストします。もしそのデータがキャッシュに見つからない場合、Nodeはそれ自身のリクエストを処理することになります。この往復により、NginxはJSONデータをキャッシュします。ブラウザはすぐに同じデータをリクエストするようになるので(同じフロントエンドのコードが実行されるので)、それが起こることをわたし達は望みます。

非キャッシュページのアクセス

下記のgifアニメは、ブラウザがページをリクエストし、Nginxのキャッシュが空の場合に何が起こるかを示しています。

キャッシュされていないページの場合

キャッシュされていないページの場合

キャッシュページのアクセス

下記のgifアニメは、コンテンツ(HTMLとJSONの両方)がキャッシュされた後のリクエストの処理方法を示しています。

キャッシュされているページの場合

キャッシュされているページの場合

キャッシュのパージ

下記のgifアニメは、新しい記事がWordPressで公開されるとどうなるかを示しています。

新しい記事が公開された場合

新しい記事が公開された場合

始めてみよう

このデモはDockerアプリとして提供されています。DockerとDocker Composeがコンピュータにインストールされていない場合はインストールしてください。WindowsとmacOSでは、ポート8000​​を有効にする必要があります。

コマンドプロンプトで、npm installまたはnpm ciを実行します。すべてのライブラリがダウンロードされたら、npm run start-serverを実行します。DockerはDocker Hubから4つの公式イメージ(WordPressMariaDBNginxNode.js)をダウンロードします。

サービスが起動して実行されたら、http://localhost:8000/wp-admin/にアクセスします。すると、WordPressのインストールページが表示されます。テストサイトに関する情報を入力して、管理者用のアカウントを作成します。その後ログインして、設定のパーマリンク設定に移動します。共通設定からURLスキーマをどれか1つ選択してください。

次に、プラグインの新規追加に移動します。Proxy Cache Purgeをインストールし、有効化します。サイドバーに表示されるので、クリックした後、下部のカスタムIPを172.129.0.3に設定します。これはわたし達のNode.jsサービスのアドレスです。

ブラウザの別タブを開き、http://localhost:8000/にアクセスすると、テストサイトが表示されます。

テストサイトの表示

テストサイトの表示

テストサイトが無事表示されているのを確認した後、管理画面に戻り、記事を新規に追加します。約30秒後にその記事は自動的にトップページに表示されます。

記事を新規に追加

記事を新規に追加

コードがデバッグモードで実行されていることを確認するには、npm run watchを実行します。クライアント側のコードは変更があるたびに再構築されます。

テストサイトにダミーデータを入力するには、FakerPressプラグインをインストールしてください。

テストサーバーをシャットダウンするには、npm run stop-serverを実行します。Dockerボリュームを削除するには、npm run remove-serverを実行します。

WordPressを実行している本番用サイトがある場合は、フロントエンドのデモでその内容がどのように見えるかを確認できます(ただし、RESTインターフェースが公開され、パーマリンクが有効になっている場合)。docker-compose-remote.ymlを開き、環境変数WORDPRESS_HOSTをサイトのアドレスに変更します。そして、npm run start-server-remoteを実行します。

Nginxの設定

Nginxの設定ファイルを確認してみましょう。最初の2行は、キャッシュのパス、キャッシュの最大値(1GB)、非アクティブのエントリの保持期間(7日)を設定しています。

proxy_cache_pathはレベルなしで指定されるので、ファイルはフラットなディレクトリ構造に格納されます。これにより、キャッシュをスキャンしやすくなります。 proxy_temp_pathはキャッシュと同じボリューム上の場所に設定されているため、Nginxは名前の変更操作でファイルをそこに移動できます。

次のセクションでは、WordPress管理者ページのプロキシを設定します

次のセクションでは、NginxとNodeとのやりとりを制御します。

先ほどproxy_cacheディレクティブで定義したキャッシュのゾーンを選択します。proxy_cache_keyを使って、キャッシュのキーを設定します。パスとクエリ文字列のMD5ハッシュは、キャッシュされた各サーバー応答を保存するために使用される名前になります。proxy_cache_min_usesディレクティブを使用して、Nginxに最初のリクエストでキャッシュを開始するように指示します。proxy_cache_validディレクティブを使用して、Nginxに1分間エラー応答をキャッシュするように依頼します。

proxy_ignore_headersディレクティブは、同じURLへのリクエストが異なるAccept-Encodingヘッダを持っている場合にNginxが別々のキャッシュエントリを作成しないようにするためのものです(例えば、追加の圧縮方法)。

add_headerを使用して追加された最初の2つのヘッダは、CORSを有効にするためのものです。最後の2つのX-Cache-*ヘッダはデバッグ用です。ブラウザのデベロッパーツールを使用してリクエストを調べると、リクエストによってキャッシュヒットが発生したかどうかを確認できます。

デベロッパーツールで確認

デベロッパーツールで確認

バックエンドのJavaScript

HTMLページの生成

Expressハンドラ(index.js)は、NginxがHTMLページを要求したときに呼び出されます。ページのナビゲーションはクライアントサイドで処理されるので、これはめったに起こらないはずです。ビジタ-のほとんどはルートページからサイトに入るでしょう、そして必然的にキャッシュされます。

ハンドラは、リモートエージェントが検索エンジンのスパイダーであるか検出し、それに応じてリクエストを処理します。

PageRenderer.generate()(page-renderer.js)は、Isomorphic Reactコードを使用してページを生成します。Fetch APIはNode.jsには存在しないため、データソースに互換性のある機能を提供する必要があります。これを利用して、フロントエンドがアクセスするURLのリストを取得します。後で、このリストを使用して、キャッシュされたページが古くなったかどうかを判断します。

FrontEnd.render()は、プレーンなHTMLの子要素を含むReactElementを返します。React DOMサーバーを使って、それを実際のHTMLテキストに変換します。そして、HTMLテンプレートに貼り付けます。そこでは、ルートReactコンポーネントをホストする要素の中にHTMLのコメントがあります。

FrontEnd.render()は、フロントエンドのBootstrapのコードによってエクスポートされた関数です。

コードはデータソースとルートマネージャを起動します。これらを使用して、ルートのReact要素<FrontEnd />を作成します。関数harvest()は、プレーンなHTML要素になるまでコンポーネントツリーを再帰的にレンダリングします。

コンポーネントツリーを再帰的にレンダリング

コンポーネントツリーを再帰的にレンダリング

フロントエンドはRelaksの助けを借りて構築されています。RelaksはReactコンポーネントのrenderメソッド内で非同期呼び出しを可能にするライブラリです。データの取得はレンダリングサイクルの一部として行われます。このモデルはSSRを非常に簡単にします。ページをレンダリングするには、そのすべてのコンポーネントのrenderメソッドを呼び出して、それらが終了するのを待ちます。

JSONデータの検索

下記のハンドラは、NginxがJSONファイルをリクエストした時(キャッシュミスが発生した時)に呼び出されます。非常にシンプルで、URLのプレフィックスを/json/から/wp-json/に変更し、HTTPヘッダをいくつか設定するだけです。

JSONRetriever.fetch()json-retrievever.js)は、WordPressからJSONデータをダウンロードし、不正なプラグインを処理するためにエラー訂正を実行します。

不要なフィールドは、JSONオブジェクトが再度文字列化される前に取り除かれます。

パージリクエスト処理

新しい記事がWordPressで公開されると、Proxy Cache PurgeはPURGEリクエストを送信します。Nodeがこれらのリクエストを受け取るようにシステムを構成しました。パージを実行する前に、リクエストが本当にWordPressからのものかどうかを確認します。それはURLかワイルドカード表現を与えるかもしれません。

プラグインがキャッシュ全体を消去したい場合と、単一のJSONオブジェクトを消去したい場合の2つのシナリオについて説明します。後者の場合は、影響を受ける可能性のあるすべてのクエリを削除します

例えば、PURGE /wp-json/wp/v2/posts/100/を受け取ったときは、/json/wp/v2/posts.*のパージを実行します。このアプローチはかなり保守的です。必要がない時は、エントリーはパージされます。データはかなり速くリロードされるので、それほどひどくありません。電子タグはコンテンツに基づいているため、実際には変更が行われていない場合は同じ電子タグになります。バックエンドのキャッシュミスがあっても、Nginxはブラウザに304 not modifiedを送ります。

JSONデータを消去した後、/.mtimeタイムスタンプのファイルを消去します。これは、データクエリを再実行する時が来たというブラウザへの合図として機能します。

それから、パージされたデータを利用し、以前に生成されたHTMLファイルをパージします。handlePageRequest()でソースURLのリストを保存した方法を思い出してください。

キャッシュのパージをサポートしているのは、Nginx Plus(Nginxの有料版)だけです。NginxCache.purge()(nginx-cache.js)は基本的にそのための回避策です。コードはそれほど効率的ではありませんが、機能は果たします。うまくいけば将来、キャッシュのパージはNginxの無料版で利用可能になるかもしれません。

タイムスタンプ処理

タイムスタンプのリクエスト処理は非常に簡単です。

フロントエンドのJavaScript

DOM hydration

下記の関数(main.js)はフロントエンドのブートストラップを担当します。

このコードはデータソースとルートマネージャを作成します。SSRが採用されている場合は、すでにページ内にあるDOM要素を「hydrate」します。最初に、サーバーで行われたのと同じ一連のアクションを実行します。そうすることで、ビジターがSSR HTMLを見ている間に、後でCSRに必要となるデータが取り込まれます。harvest()に{seeds:true}を渡すと、リスト内の非同期のRelaksコンポーネントのコンテンツを返すようになります。「seeds」がRelaksに置かれ、非同期コンポーネントがその初期の外観を同期的に返すことができます。このステップがないと、非同期レンダリングに必要なわずかな遅延によって、hydrationプロセス中にミスマッチが発生します。

DOMがhydrateされると、2つ目の<FrontEnd />要素をレンダリングすることでCSRへの移行を完了します。今回はssrを使用しません。

その後、30秒ごとにコンテンツが更新するため、サーバーは無限ループに入ります。

ルーティング

フロントエンドでWordPressのパーマリンクを正しく処理することを望みます。単純なパターンマッチに頼ることはできないので、これはページのルーティングを少し複雑にします。/hello-world/のようなURLは、ページ、投稿、タグのリストを指す可能性があります。これはすべてスラッグの割り当てに依存します。正しいルートを見つけるためには、常にサーバーからの情報が必要となります。

relaks-route-managerはこのシナリオを考慮して設計されていません。ただし、ルート変更の前に非同期操作を実行することは意味があります。beforechangeイベントを発行する時、約束が満たされるまで(変更を許可しています)デフォルトのアクションを延期するためにevt.postponeDefault()を呼び出すことができます。

route.setParameters()(routing.js)は基本的にデフォルトのパラメータ抽出メカニズムを置き換えます。ルーティングのテーブルは下記のようになります。

これは、どのURLにも一致します。

route.setParameters()自体がroute.getParameters()を呼び出して、パラメータを取得します。

重要なパラメータはpageTypeです。これは、ページコンポーネントの1つをロードするために使用されます。

一見すると、route.getParameters()(routing.js)は非効率的に見えるかもしれません。URLがページを指しているかどうかを確認するには、すべてのページを取得し、そのうちの1つにそのURLがあるかどうかを確認します。

カテゴリでも同じチェックをします。

ほとんどの場合、問題のデータはすでにキャッシュされているでしょう。トップのナビはページをロードし、サイドのナビはカテゴリ(トップのタグも)をロードします。ルートを解決するために実際のデータ転送は必要ありません。コールドスタートでは、このプロセスはやや遅くなります。しかし、SSRのメカニズムはこの遅れを覆い隠します。ビジターは、気にならないと思います。もちろん、すべてのページが用意されているので、ビジターがナビゲーションバーをクリックするとすぐにページがポップアップします。

route.getObjectURL()(routing.js)は、オブジェクト(投稿、ページ、カテゴリなど)へのURLを取得するために使用されます。この方法は、オブジェクトのパーマリンクからサイトのURLを削除するだけです。

投稿にリンクするには、その投稿を事前にダウンロードする必要があります。記事をクリックすると、すぐに記事が表示されます。

カテゴリとタグへのリンクは、明示的な先読みを実行します。

最初の10件の投稿は常に取得されるため、ビジターはクリック後すぐに何かを見ることができます。

Welcomeページ

WelcomePage(welcome-page.jsx)は非同期コンポーネントです。renderAsync()メソッドは、投稿のリストを取得し、WelcomePageSyncに渡して、実際のユーザインタフェースをレンダリングします。

WelcomePageSyncは、投稿リストのレンダリングタスクをPostListに委任します。

投稿リスト

PostList(post-list.jsx)のレンダリング方法は、特別なことは何もしません。

コンポーネントに関して注目すべき唯一の点は、スクロール時にデータロードを実行するということです。

Cordova

これはボーナス セクションです。
あなたがCordovaで、cheapskateモバイルアプリを作成する方法を示します。

始めるには、Android StudioまたはXcodeをインストールしてください。その後、コマンドラインでnpm install -g cordova-cliを実行します。relaks-wordpress-example/cordova/sample-appに移動し、cordova prepare andoirdまたはcordova prepare iosを実行します。Android StudioまたはXcodeで新しく作成したプロジェクトを開きます。relaks-wordpress-example/cordova/sample-app/platform/[android | ios]にそれを見つけるでしょう。

リポジトリのCordovaコードはhttps://et.trambar.ioからデータを取得します。場所を変更するには、環境変数CORDOVA_DATA_HOSTを目的のアドレスに設定し、npm run buildを実行します。

終わりに

ここで紹介した方法が、あなたに新しいインスピレーションを与えることを願っています。WordPressは古いソフトウェアですが、コードに少し手を加えることで、エンドユーザーのエクスペリエンスを大幅に向上させることができます。

デモのシステムは、最初のロードが速く感じるでしょう。ページ間の遷移も速く感じます。さらに重要なことは、このシステムの運用コストが安いということです。

このコンセプトは、WordPress固有のものではありません。特にサーバーサイドレンダリング(SSR)は、単一ページのWebアプリケーションにとって非常に便利なテクニックです。ロード時間への悪影響を気にすることなく、JavaScriptライブラリを使用してプロジェクトを強化できます。

sponsors

top of page

©2019 coliss