ウェブサイトの読み込み時間を短縮する 5 つの最も効果的な方法

Web サイトやアプリの最初の読み込み速度がユーザーに与える第一印象となります。このガイドでは、最初のページ読み込みから貴重な数秒を短縮する実証済みのテクニックをリストします。

初期ロード時間

ユーザーまたは顧客が Web サイトのドメイン名を入力してからコンテンツが表示されるまでにかかる時間は、良い第一印象を与えるために必要な最も重要な数秒です。

Amazon は、遅延が 100 ミリ秒ごとに売上の 1% が犠牲になることを発見しました。

それにも関わらず、多くの Web 開発者はこれを結果論として扱っています。より多くの機能を提供するために、より多くのライブラリが追加され、時間の経過とともに徐々に変換が減少し始めます。さらに悪いことに、こうしたコンバージョン損失は、指標を送信する前に読み込みの遅いページを放棄するため、検出するのが困難です。

これらの手法の中には、フロントエンドで実装できるものと、バックエンドで実装できるものがあります。いずれにせよ、Web アプリは迅速に読み込まれる必要があります。

適切な測定値を追加する

最初に行う必要があるのは、測定値を追加することです。読み込みプロセスには多くの段階があり、適切なセグメントを測定しないとボトルネックがどこにあるのかわかりません。

読み込みプロセスの最も重要なマイルストーンは次のとおりです。

これが意味するのは、この図の すべてのセグメント のメトリクスを追跡する必要があるということです。

それを行う方法を見てみましょう。

ブラウザーのリクエストからレスポンスまでの処理:

これをサーバー上で測定してください。 API がリクエストを取得してレスポンスを返す瞬間を取得したいと考えています。たとえばデータベースへの外部呼び出しが行われるかどうかに応じて、これは非常に短い場合もあれば、重大なボトルネックになる場合もあります。

受信した応答に対して配信された応答:

これを測定するのはさらに困難ですが、そのための 1 つの方法は、応答がサーバーから送信されたときにタイムスタンプを追加し、可能な限り最初の時点でユーザー側の現在時刻 (HTML の先頭にあるスクリプト タグ) でそれを測定することです。ページ）。

最初のコンテンツフルペイントに対して受け取った応答:

最初のコンテンツ ペイントは、最初の要素が DOM 上にレンダリングされるときです。それは、テキスト、背景、読み込みスピナーなどの単純なものにすることができます。これは、Chrome 開発ツールで Lighthouse を実行することで測定できます。

最初のコンテンツフル ペイントから最大のコンテンツフル ペイントまで:

最大のコンテンツを含むペイントは、最大の要素がユーザーのブラウザ ビューポートにレンダリングされるときです。これは通常、ページ読み込みの「レンダリング」部分の終了を通知し、ユーザーにはデータが入力された画面が表示されます。これも Lighthouse を実行することで測定されます。

インタラクティブ化までの最大の内容豊富なペイント:

最後に、対話時間とは、ユーザーがスクロール、クリック、入力などのアクションを実行できる時間を指します。この期間が長い場合、目の前にレンダリングされた画面が表示されているにもかかわらず、何もできるはずなのに何もできないため、特にイライラする可能性があります。これは、Lighthouse が測定に役立つもう 1 つの指標です。

コードを減らす

測定が完了したので、最適化を開始できます。最適化にはトレードオフがあり、どちらが価値があるかは測定によってわかります。

最も速く読み込まれるページは空のページですが、空のページとの読み込み速度の違いに気づく前に、多くのコードをアプリに追加することができます。よく発生するのは、増分が非常に細かいため、ある日までビルドごとの違いに気づかず、速度が遅く感じられるようになるということです。アプリが肥大化していることに気づき、この時点でコードを減らすことが効果をもたらすことになります。

コードを減らすと、速度が 2 つ向上します。

• アプリはネットワーク経由でより速く転送されます。
• ユーザーのブラウザはコードの解析をより速く完了します。

最初の高速化はわずかです。リクエストはネットワーク上で圧縮されるため、1 MB のソース コードを削減したとしても、帯域幅の節約は 10 KB にすぎない可能性があります。ただし、解析による速度向上は 大幅 です。おそらくユーザーは、さまざまなブラウザーやコンピューター上でアプリを実行していると思われますが、その多くは、自分で実行するほど迅速にコードを解析できるほどの計算能力を持っていません。

あるいは、コンピューティング能力がさらに低いモバイル デバイス上で実行されている可能性もあります。違いは秒単位になる場合があります。

したがって、コードが少ないほど、ブラウザーはより早く解析を完了してアプリを実行できるようになります。 JavaScript が制御するロード画面を表示したい場合でも、そのコードの解析が先に行われます。

ただし、機能を削減したり、実際にコードを削除したりする必要はありません。幸いなことに、それを行わずにコードを削減するための標準的な方法がいくつかあります。

• ミニファイアーを通じてコードを実行します。 ミニファイアーは、短い長い名前を短い名前に変換したり (signUpDarkModeButton が ss になる)、空白文字を削除したりするなどの最適化を実行して、何も失わずにコードをできるだけコンパクトにします。
• 部分ファイルをインポートします。 ライブラリは、必要のないもので肥大化していることがよくありますが、包括的なパッケージの下にまとめてパッケージ化されています。ユーティリティ ライブラリの特定の関数だけが必要な場合は、ライブラリ全体をインポートする代わりに、必要なコードだけをインポートできます。
• ツリーシェイクのデッドコード。 デバッグ目的でコードを残したり、非推奨の機能を完全にクリーンアップしていない場合、その機能がソース コード内にあるにもかかわらず実行されない場合があります。 JavaScript ツールチェーンには、Webpack などのツールがあり、デッド コードや未使用の依存関係を検出し、実稼働ビルドから自動的に削除できます。

コードをチャンクに分割する

アプリ全体からできる限り多くのコードを削減した後、このアイデアをさらに絞って、初期読み込みに必要なコードを削減することを検討できます。

コードの 20% が、ユーザーが数回クリックしないとアクセスできないアプリの機能を強化しているとします。ブラウザーが読み込み画面を表示する前にそのコードを解析するのは時間の無駄です。コードをいくつかのチャンクに分割すると、対話時間を大幅に短縮できます。

すべての Javascript ファイルのインポートの絡み合った依存関係グラフを作成する代わりに、簡単にカットできる領域を特定します。たとえば、コンポーネントが重いライブラリをロードする可能性があります。そのコンポーネントを独自のファイルに分離し、ユーザーがそのコンポーネントを操作する準備ができたときにのみインポートできます。

使用しているフレームワークに応じて、読み込みを延期するライブラリがいくつかあります。これをやりすぎてすべてのコンポーネントを分割する必要はありません。分割すると、ユーザーは初期読み込みが速くなり、その後のすべての操作を待機する必要があるからです。セグメント化できる最大の部分を見つけて、そこでソース コードを分割します。

サーバーサイドレンダリング

ブラウザは集中的な解析とコンパイルをすべて行う必要があり、ユーザーは Chromebook やモバイル デバイスを使用する必要があるため、読み込み時間を短縮する一般的な手法の 1 つは、サーバーにその負荷の一部を引き受けさせることです。これが意味するのは、最近のほとんどの単一ページ アプリのように、空白のページを与えて Javascript を使用してすべてのコンテンツを入力する代わりに、サーバー (通常は Node.js) で Javascript エンジンを実行してコンテンツを入力できるということです。できる限り多くのデータとコンテンツを。

サーバーはユーザーのブラウザよりもはるかに高速で予測可能になります。必然的に、アプリをインタラクティブにするためには、JavaScript コードを解析する必要があります。それでも、サーバー側のレンダリングで初期コンテンツの多くを埋めることができるため、ユーザーがページを取得したときには、少なくとも読み込み画面または進行状況バーが表示されています。

また、初期ビューにデータが必要な場合、クライアントはそれを取得するために別のリクエストを行う必要はありません。クライアントが使用できるように、アプリ内ですでにハイドレートされています。

アセットを圧縮する

アセットによってページに命が吹き込まれますが、それらのアセットのレンダリングが完了するまでページは完全に読み込まれたように感じられません。これは、背景、ユーザー インターフェイス アイコン、ユーザー プロフィール写真、さらには読み込みスピナーである場合もあります。多くの場合、アセットによってレイアウトも変更される可能性があるため、ユーザーが何かを操作しようとすると、アセットが読み込まれている間、ページが飛び回り続ける可能性があります。場合によっては、これらのアセットが最大のコンテンツ ペイントとなることがあります。

しかし、アセットはアプリの中で最も重い部分の 1 つでもあります。画像は数メガバイトになる場合があり、多くのアイコンを読み込むとブラウザの最大同時ネットワーク要求制限を簡単に超えて、膨大な読み込みキューが発生する可能性があります。

インターネットから画像をダウンロードしてアプリ内で参照したいと思うことはほとんどありません。画像は、表示される最小の寸法にサイズ変更する必要があります。サイズを変更せずに 50 ピクセル x 50 ピクセルの小さな要素でユーザー プロフィールを表示している場合、アプリはデスクトップの壁紙として鮮明に見える完全な画像をダウンロードし、それから小さなサイズにサイズ変更するのに時間がかかります。

次に、画像はその形式に応じて圧縮できます。最近では、 webm が好まれる形式ですが、Web 上の圧縮分野は常に改良されており、多くの新しい形式が登場する予定です。形式の性質は変化しているため、一部のブラウザは新しい形式をサポートしていない可能性があります。幸いなことに、ブラウザ テクノロジーにより、ユーザーのブラウザはサポートされている形式を読み込むことができます。

したがって、最新かつ最高の形式に圧縮しますが、最新ではないバージョンも保持し、フォールバック形式をサポートする picture 要素と video 要素を使用します。

結論

これらは、ユーザーにアプリの初回読み込みを非常に高速にするための最も効果的な 5 つのテクニックです。 SEO では読み込み時間が短縮されるため、コンバージョン率、ユーザーの満足度、さらには検索ランキングが向上します。 Terrastruct では、ユーザーがこの記事にある図をできるだけ早く作成して表示できるように、これらのテクニックなどを採用しています。