プリレンダリング
プリレンダリング（事前レンダリング）とは、HubSpotのCMS上でウェブサイトページ、ランディングページ、ブログ記事、ナレッジベース記事の静的バージョンを作成する処理です。
このコンセプトは、Gatsby、WP Super Cacheなどの静的サイトジェネレーターに似ています。HubSpotは、ページがプリレンダリングに対応できるかどうかを自動的に判定します。対応している場合は、静的バージョンが生成されます。そうでない場合には、ページが引き続き動的に提供されます。
リクエストごとにページのデータとレイアウトを動的に取り込む代わりに、CMSによって1つのコピーがレンダリングされ、CDNにプッシュされます。これにより、世界中の訪問者に対してサイトの速度が向上します。HubSpotのCDNは、静的ファイルを処理する際に大量のトラフィックを処理できます。静的ページは、セキュリティーの面でも優れています。
いいえ、異なる概念です。プリレンダリングされた全てのページは、HubSpotのCDN上にキャッシュ処理可能です。プリレンダリングは、HubSpotのCMSがページの静的バージョンを生成するプロセスです。CDNのキャッシュにページがない場合でも、ページがすでに最終的なレンダリングの形になっているため、リクエストの処理にかかる時間が短くなります。
ページがプリレンダリングされているかどうかを確認する最も簡単な方法は、リクエストのHTTPレスポンスヘッダーを確認することです。X-HS-Prerenderedヘッダーが含まれている場合、ページはプリレンダリング済みです。このヘッダーの値は、ページが最後にプリレンダリングされた時刻です。
もう1つは、?hsDebugOnly=trueクエリーパラメーターを使用してページを読み込む方法です。この場合、ページがプリレンダリング可能かどうかも示されます。プリレンダリングできない場合には、妨げとなっている問題のリストが表示されます。デバッグ情報の形式が読みづらい場合は、代わりにパラメーター?hsDebug=trueを使用してページを調べることができます。同じデバッグ情報が、ページ下部に整形されたHTMLコメントとして表示されます。
ページに影響するデータをHubSpot上で変更すると、レンダラーが自動的にトリガーされます。例えば、ページまたはそのテンプレートを編集すると、ページが再レンダリングされます。その他の共有データ（CMS設定など）を変更すると、多数のページが再レンダリングされることがあります。
HubSpotではCSS、JavaScript、画像ファイルは常に静的に生成されるので、実質的には常にプリレンダリングされます。
つまり、JSまたはCSSファイルのHubLの評価は、「アセットが公開されるとき」に一度だけ行われます。
これらの機能を使用すると、全てのユーザーに対して同一のレスポンスを提供できません。このため、静的にプリレンダリングされたページが提供されなくなります。これらの機能を使用しているページを提供する際には、パーシャルプリレンダリングが使用される場合があります。
accountcompanycontactlocal_dtownerqueryrequest_contactrequest.cookiesrequest.full_urlrequest.geoip*（非推奨）request.headersrequest.path_and_queryrequest.queryrequest.query_dictrequest.referrerrequest.remote_ipyear
HubLのrequest変数には通常、対応するJavaScriptベースの代替手段があります。これらの変数を回避することも可能です。
|random|shuffle
ページごとに一連のデータをランダム化する必要がある場合は、代わりにJavaScriptを使用したランダム化を検討してください。
personalization_tokentodayunixtimestamp
- ページのパスワード保護
- ページのメンバーシップ制限
- スマートコンテンツを含むページ
- 適応型テストを使用しているページ（A/Bテストページはサポートされます）
- ナレッジベースのページ
?hsDebugOnly=trueクエリーパラメーターを使用してページを読み込むと、プリレンダリングの妨げとなる特定の機能を確認する上で役立つ出力が追加されます。この追加の出力には次の情報が含まれています。
- 問題の原因となる特定の機能のリスト
- 特定のファイルとキャッシュ不可能な変数を使用しているテンプレートの行番号
可能な場合、コンテンツに関する全ての動的レンダリングを、ユーザーのブラウザー側で実行されるJavaScriptに移動します。動的データの取り込みには、サーバーレス関数も使用できます。
パーシャルプリレンダリングでは、「ほぼ」プリレンダリングされたページを提供できます。例えば、ページに表示されるコンタクトの名前を除いて、ほぼ全体が静的なページがあるとします。このページの場合、コンタクト名以外の部分をプリレンダリングできます。ページをユーザーに戻す直前に、このような動的な値がHubSpotによって迅速にレンダリングされます。
パーシャルプリレンダリングを使用したページは、CDNまたはブラウザーにはキャッシュできませんが、パーシャルプリレンダリングできないページよりも迅速な配信が可能です。パーシャルプリレンダリングされたページは、停止や攻撃が発生した際にはパーソナライズなしの状態で提供することも可能です。
パーシャルプリレンダリングもサイトの速度と信頼性の向上に役立つ場合がありますが、ページのプリレンダリングの妨げになっているHubL機能を削除する方が、ページ全体のパフォーマンスが大きく向上します。
?hsPrcDebug=trueクエリーパラメーターを使用してページを読み込むと、ページ上のプリレンダリングされたコンテンツに関する出力が追加されます。ページがプリレンダリングされている場合、X-HS-Prerenderedヘッダーが存在し、ページのパーシャルプリレンダリング時刻の前にpartialが示されます。
パーシャルプリレンダリングで「現在サポートされている」機能を以下に示します。ページはパーシャルプリレンダリングされ、提供時には以下の機能を使用する式が評価されます。
accountcompanycontactlocal_dtownerqueryrequestyear
ページプリレンダリングの導入に伴い、ページでのCSS自動結合は段階的に廃止される予定です。次のような理由があるためです。
- CSS結合では1つのページビューを最適化できますが、ページごとにCSSを全て再ダウンロードする必要があるため、後続のページビューへの影響が望ましくありません。
- HTTP/2（SSL経由で配信される全てのHubSpotサイトではHTTP/2が使用されます）により、多数のCSSファイルに伴う多くの問題が解決されるため、CSS結合には従来ほどのメリットがありません。
- 結合されたCSSによってページが破損しないことを確認するために、HubSpotでは結合されたCSSがあるページに対して自動ビジュアルチェックを実行しています。ビジュアルチェッカーの効果は100％ではなく（スクロール時のみの表示要素やJavaScriptアニメーションなど）、問題を検出できない場合もあります。
- サイトの可用性と速度の観点から、ページのプリレンダリングはCSSの結合よりも重要です。レンダラーの後には結合されたCSSを常に検証する必要があるため、変更のたびにCSSを結合してビジュアルチェックを実行することは現実的ではありません。
これは、ページごとにモジュールとページスタイルを1つのファイルとして結合していた従来の機能を指しています。
これは、includeタグを使用して結合されたCSSファイルには影響しません。
- モジュールを活用しましょう。モジュールに固有のCSSの場合は、モジュールのCSS、またはrequire_cssでモジュールに関連付けるCSSファイルに配置します。つまり、このモジュールに固有の小さなcssファイルは、このモジュールが使用されるページでのみ読み込まれます。後続のページ読み込みでは、ユーザーに対してすでに表示されたモジュールのCSSはキャッシュ処理され、まだ表示されていないアセットのCSSのみがダウンロードされる必要があります。
- レイアウトクラスやユーティリティークラスなどのスタイルを複数のモジュールで共有する場合、またはモジュールの外観が類似していて多数のCSSを共有する場合には、CSSファイルを必要とする各モジュールについて、require_cssで関連付けるCSSファイルを作成することを検討してください。これにより、モジュールごとに同じCSSを繰り返すことを回避できるとともに、キャッシュ処理の面でもメリットがあります。
- サイト全体で使用するモジュールについてもこの点を考慮してください。例えばヘッダーモジュールとフッターモジュールがページごとに変化しない場合には、CSSスタイルにこの方法を採用することを検討してください。
貴重なご意見をありがとうございました。