CMS Hubで構築したウェブサイトのパフォーマンス最適化

APPLICABLE PRODUCTS
  • Marketing Hub
    • Professional or Enterprise
  • Content Hub
    • Starter, Professional, or Enterprise

ユーザーエクスペリエンスは、コンテンツの品質、表示速度、セキュリティー、アクセシビリティーを支える要素の1つです。これらを最適化することは、通常、検索エンジン最適化（SEO）対策としても効果的です。

優れたパフォーマンスとは、エンドユーザーの利便性を高めることに他なりません。パフォーマンスを向上するには、ウェブサイト上のさまざまな課題を解消する必要があります。

優れた基盤を出発点にする

後からパフォーマンス上の問題を修正するよりも、パフォーマンスを念頭に置いた優れた基盤を出発点としてサイトを構築するほうが簡単です。例えば、速度の遅い自動車を買ってスピードを速めるよりも、速い自動車をゼロから組み立てるほうが簡単です。

HubSpot CMSボイラープレートは、ベストプラクティスを採り入れてサイトを迅速に構築できるようにするために作成されています。ウェブサイトの評価での現在のスコアについて、GitHub READMEをご覧ください。

コードを一切追加していない状態のボイラープレートから作成したウェブサイトでも、これだけのスコアを達成できます。つまり、ボイラープレートをベースに追加するコードだけに専念できるということです。 

Build a site based on the boilerplate

ウェブサイトのパフォーマンスにおける一般的なボトルネック

ほとんどのウェブパフォーマンスの最適化手法とベストプラクティスは、HubSpotに固有のものではありません。ほとんどのウェブサイトのパフォーマンスのボトルネックはHubSpotに固有のものではないためです。 

パフォーマンスの問題の大半は、レンダリングと読み込みの2つに分類されます。

  • 読み込みのパフォーマンスは、ウェブページに必要な全てのファイルをユーザーのブラウザーに転送する際の効率性を意味します。
  • レンダリングのパフォーマンスは、ブラウザーがダウンロードした全てのものを最終結果としてユーザーに表示する際の効率性を意味します。

読み込みのパフォーマンスを理解することはそれほど難しくありません。読み込みのパフォーマンスはファイルの数、ファイルのサイズ、ファイルの配信速度によって決まります。レンダリングのパフォーマンスは複雑です。カスケーディング スタイル シート（CSS）、JavaScript（JS）、画像、動画、訪問者が使用しているデバイス、使用されているウェブブラウザーのそれぞれが、重要な要素です。CSSはレンダリングの妨げとなります。CSSの不適切な記述が原因で、ページのレンダリング中に累積レイアウト変更（CLS）が発生することがあります。画像が原因でCLSが発生し、RAMを消費する可能性があります。動画プレイヤーが原因でCLSが発生し、一部のファイル形式は多くの処理を必要とすることがあります。JSではページのDocument Object Model（DOM）とCSSオブジェクトモデル（CSSOM）を操作できますが、これによって前述の問題が発生します。また、JSによってリソースが大量に消費される可能性もあります。全ての訪問者に対して高速な操作性を提供するには、全ての要素のバランスを取り、ベストプラクティスに従う必要があります。

画像

ウェブ上のほぼ全てのページでは、画像が至るところで使われています。通常、画像はページ上で最もサイズが大きいファイルです。画像の数が多かったり、画像のサイズが大きかったりすると、それだけページの読み込み時間が長くなります。GIFやwebpのアニメーションも、同じサイズのアニメーション化されていない画像と比べると、読み込み時間が長くなります。一部の画像形式は他の形式よりもパフォーマンスに優れています。また、状況によっても最適な画像形式は異なります。

可能な対策

  1. パフォーマンス向上のためにできることのうち、最も重要なのは、ウェブ用として画像を最適化することです。画像の最適化は、制作担当者と開発者の双方が共同で取り組むことが求められます。
  2. ページあたりの画像数を減らします。
  3. それぞれの用途に応じた適切な画像形式を使用します。
  4. 可能な場合は常にSVG（Scalable Vector Graphics）を使用します。SVGは品質を落とすことなく無制限に拡大できます。アニメーションを作成するときは、SVGをインライン化するのが有効です。静止画では、SVMスプライトシートを作成するか、SVGをそのまま通常のimg要素または背景画像として扱うほうが、通常は良好なパフォーマンスが得られます。
  5. 画像の遅延読み込みを適切に制御します。
  6. img要素に高さと幅のHTML属性を含めるようにします。こうすると、ブラウザーでレンダリングしやすくなり、HubSpotが自動的にsrcsetを追加することもできます。幅と高さを指定すると、HubSpotで最適化をサポートできるだけでなく、ブラウザーも累積レイアウトシフト（CLS）に応じて自動的に最適化できます。 
  7. CSS aspect-ratioプロパティーを使用して、imgのサイズが変更される際のスペースを確保します。
  8. resize_image_urlを使用して、画像が特定の解像度になるようにサイズ変更します。
  9. 背景画像の場合は、メディアクエリーとresize_image_urlを組み合わせて、デバイスに最適なサイズで画像を配信します。
  10. 大きなヒーローイメージを使用する場合は、require_headタグの中で<link rel="preload" as="image" href="http://example.com/img_url.jpg">を使用して、ヒーローイメージを事前に読み込むことができます。この方法は最小限に控えてください。多用すると、パフォーマンスが低下するためです。

動画の自動再生

動画の背景と動画の自動再生を使用すると、ウェブサイトを際立たせることができます。ただし、それには犠牲も伴います。動画の背景はウェブサイトのヘッダーに使用されることがよくあります。動画を自動再生することは、ブラウザーが直ちに動画の読み込みを開始しなければならないことを意味します。これは接続が遅いか、携帯回線でデータを受信しているユーザーにとっては特に問題になることがあります。

可能な対策

  1. 動画の自動再生は回避してください。背景にアニメーションを表示する場合は、CSSアニメーションまたはJavaScriptアニメーションの使用を検討してください。自動再生動画を表示する場合：
  2. ニーズに応じて動画の解像度を許容できる程度まで抑え、動画に効果を適用して低解像度であることが目立たないようにします。
  3. デバイスと接続に基づいて動画品質を調整します。YouTube、Vidyard、Vimeoなどの動画共有／ホスティングサービスを使用する方法が最適です。
  4. モバイル上での自動再生を無効にして、代わりの静止画を表示します。

JavaScript

操作可能な要素をウェブサイトに追加するには、JavaScript（JS）が役立ちます。ただし通常は、大量のJSコードを読み込むとJSファイルのサイズが大きくなり、操作可能な要素をブラウザーが読み込むまでの時間が長くなります。<head>にJSを読み込むことも問題になる可能性があります。既定では、JavaScriptはレンダリング ブロック リソースとして設定されているためです。また、JSは訪問者のデバイス上で実行されます。つまり、デバイスのリソースの制約を受けます。

可能な対策

  1. HubSpotのCMSが初めてリリースされた当時、既定で<head>にjQueryが読み込まれていました。［設定］＞［ウェブサイト］＞［ページ］の順に進んで完全に削除するか、最新バージョンのjQueryにアップグレードすることができます。このような設定を、構築に自身が関わっていなかった古いウェブサイト上で変更する際には、jQueryに依存して構築されていたり、ヘッダーでのjQueryの読み込みに基づいて構築されていたりすることがあるので注意が必要です。
  2. レンダリングの妨げにならないように、JavaScriptが</body>の直前に読み込まれるようにします。require_jsは、モジュールまたはテンプレート上で必要な場合に限ってJavaScriptを読み込むために、また、モジュールの複数のインスタンスによって誤ってJavaScriptが複数回読み込まれることをなくすために使用できます。
  3. JSをリファクタリングして効率化することを検討します。JSプラグインの数を減らして、セマンティックHTMLが役立つ場合はこれを使用します。例えばドロップダウンには、<details>および<summary>を使用します。モーダルには<dialog>を使用します。
  4. ごく一部の機能のために大規模なJSライブラリーを使用している場合は、簡素なJSで代用するか、可能な場合はライブラリーのサブセットを読み込むことを検討します。
  5. require_jsを使用して、必要な場合に限定してJSを読み込みます。この場合、ページごとに1度だけ読み込まれます。require_jsを使用する場合は、asyncまたはdefer属性を使用してページパフォーマンスを改善します。
  6. モジュールのJavaScriptが読み込まれる位置とタイミングを制御するには、モジュールのmeta.jsonファイル内でjs_render_optionsを使用します。
  7. 外部リソースを読み込む場合は、事前接続とDNSプリフェッチを適切に使用して読み込み時間を短縮します。
  8. 使用するトラッキングスクリプトの数を制限します。トラッキングスクリプトは、情報を収集するために、ページでのユーザーによるあらゆる行動の把握を試みる性質があります。こうしたユーザー操作の分析には大量のコードが使用されます。トラッキングスクリプトごとにこのコードの量が増大します。

推奨ツール

HubSpotの推奨ツールは、特定のウェブサイトのパフォーマンスとSEOに関するフィードバックを得るための有用なツールです。  

推奨ツールの詳細をご確認ください。

コードアラート

コードアラートは、HubSpotウェブサイト内で特定された問題を集約した概要としての役割を果たす、CMS Hub Enterpriseの機能です。コードアラートで特定された問題を修正すると、ウェブサイトのパフォーマンス最適化に役立ちます。HubLの制限からCSSの問題まで、さまざまな領域の問題が特定されます。

コードアラートの詳細を参照してください。

HubSpotによる自動処理

パフォーマンスや速度に関するベストプラクティスのほとんどは、HubSpotに固有のものではありません。HubSpotのCMSでは、一般的なパフォーマンス問題が自動的に処理されます。次のような最適化があります。

カスタムモジュールにCSSが組み込まれていると、HubSpotでは、モジュールがページで使用されている場合にのみmodule.cssが効率的に読み込まれます。また、ページで使用されているモジュールのインスタンス数に関係なく、module.cssが1回だけ読み込まれます。既定では、module.cssの読み込みは非同期ではありませんが、この動作はモジュールのmeta.jsonファイルにcss_render_optionsを含めることで変更できます。

サイトの速度向上に関する追加資料

サイトの速度を最適化するにはさまざまな対処法があり、最適化手法の多くはさらに細分化できます。サイトの最適化に取り組むときは、HubSpotの充実した参考情報（英語）を参照してください。

パフォーマンスツール

パフォーマンスの向上やテストのためのツールは数多く提供されています。これらのツールを理解して活用するとパフォーマンスの最適化に役に立ちます。以下に、開発者コミュニティーで提供されている情報を参考として示します。

画像の最適化

画像を最適化してからウェブにアップロードして配信すると、画面に収まらないような大きい画像を配信しないように配慮できます。 

よく使われる画像最適化ツール：

パフォーマンステスト

どのようなウェブサイトを構築する場合も、パフォーマンスのテストと最適化はウェブサイトの構築プロセスの一環として行う必要があります。ウェブサイトの速度テストに利用できるツールは多数あります。パフォーマンスを情報に基づいて改善できるように、ツールとその仕組みを理解することが重要です。

測定に特化したツールもあれば、パフォーマンスに点数を付けるツールもあります。ツールが実際にどのように機能するかを理解することが重要です。

測定ツールは一般に、読み込み時間、スクリプトの実行時間、コンテンツの初回ペイントまでの時間、アセットをダウンロードするときのネットワーク時間をテストします。通常、これらのツールによる測定結果は、それぞれの指標に固有の時間を示します。ページは読み込みの度にがまったく同じとは限らないため、再テストすると、通常は測定値がわずかに異なります。 

評価ツールは速度を測定するだけでなく、多くの場合はパーセンテージや文字で表した点数で、パフォーマンスを示します。こうした点数は、開発者やマーケティング担当者がパフォーマンスを向上させる動機付けとなるよう意図されています。パフォーマンスには考慮に入れなければならないさまざまな指標や観点があります。1つの指標だけに基づいて全体的なパフォーマンスを評価することはできません。また、指標によっては、パフォーマンスに関する認識にもさまざまな影響を与えます。こうしたツールで全体的なパフォーマンスを計算する際には、各種の指標に異なる重みが付けられています。測定指標の重み付け方法について、業界全体で採用されている標準はありません。Google Page Speedのように、重み付けは時間の経過とともに変更される可能性があります。また、個々の指標で「良好」な状態を意味する最小値や最大値として業界全体で受け入れられている基準もありません。一部のツールは、テスト済みウェブサイトのパーセンタイルを基準にしています。つまり、ウェブサイトでのスコアは他のテスト済みウェブサイトでのスコアとの比較に基づいています。そのため、「良好／優秀」な速度の範囲に達することが次第に難しくなります。利用者にとっての利便性、訪問者の保持状況、およびROIに基づく調査などで良好なスコアのしきい値を決定するツールもあります。また、全てのツールにおいて後続のページの読み込みパフォーマンスが考慮されるとは限らないことを考慮してください。例えば、HubSpotモジュールシステムでは、各モジュールのCSSとJSが切り離されているため、このようなアセットはモジュールが実際にページに配置された場合にのみ読み込まれます。このため、複数の小さなCSSファイルが発生し、この状態がGoogle Page Speed Insightsによって警告されることがあります。実際には、次回のページ読み込みにおいて、次のページで繰り返されるモジュールのCSSまたはJSがキャッシュされていて、ダウンロードする必要がなくなっています。1つの大きなファイルをダウンロードするのではなく、これまでに表示されていないモジュールのファイル（数キロバイト程度）をダウンロードするだけで済みます。

点数を使用するツールに関しては、複数のツールを使用して、それぞれのツールで最高のスコアを獲得できるように努力する必要があります。ツールによって重み付けは異なるという点を理解してください。最適化の取り組みにより、あるツールではスコアが上がったとしても、別のツールではそうではないこともあります。

よく使われるパフォーマンス テスト ツール：

関連：

 

参考になりましたか？
こちらのフォームではドキュメントに関するご意見をご提供ください。HubSpotがご提供しているヘルプはこちらでご確認ください。