洗練されたフロントエンド。高速サイトに適したアーキテクチャ

こんにちは、Habr！



私たちは長い間、ブラウザ、CSS、およびアクセシビリティのトピックを無視してきましたが、今日の概要資料（オリジナル-2020年2月）の翻訳でそれに戻ることにしました。ここで述べたサーバーレンダリングテクノロジーについてのあなたの意見と、HTTP / 2に関する本格的な本の必要性がどれほど緊急であるかについて、私は特に興味があります-しかし、すべてを順番に話しましょう。



この投稿では、フロントエンドアプリケーションの読み込みを高速化し、使いやすさを向上させるためのいくつかの手法について説明します。



フロントエンドの一般的なアーキテクチャを見てみましょう。重要な資産が最初に読み込まれるようにし、それらの資産がすでにキャッシュに格納される可能性を最大化するにはどうすればよいですか？



バックエンドがリソースをどのように提供するか、ページをクライアントアプリケーションの形式にする必要があるかどうか、またはアプリケーションのレンダリング時間を最適化する方法については詳しく説明しません。

概要概要

アプリのダウンロードプロセスを3つの別々のステップに分けてみましょう。

1. 一次レンダリング-ユーザーが何かを見るまでにどのくらい時間がかかりますか？
2. アプリのダウンロード-ユーザーがアプリを見るまでにどのくらい時間がかかりますか？
3. – ?

一次レンダリング（レンダリング）の段階まで、ユーザーは何も見ることができません。ページをレンダリングするには、少なくともHTMLドキュメントが必要ですが、ほとんどの場合、CSSファイルやJavaScriptファイルなどの追加のリソースもロードする必要があります。利用可能な場合、ブラウザは画面へのレンダリングを開始できます。



この投稿では、WebPageTestウォーターフォール図を使用します。サイトへのリクエストのカスケードは次のようになります。







他のファイルのセットがHTMLドキュメントと一緒にロードされ、ページはすべてメモリに格納された後にレンダリングされます。CSSファイルは並行してロードされるため、後続の各要求によって遅延が大幅に増加することはないことに注意してください。

レンダリングブロックリクエストの数を減らす

スタイルシートと（デフォルトで）スクリプト要素では、その下のコンテンツを表示できません。



これを修正する方法はいくつかあります。

• タグの一番下にスクリプトタグを配置します body
• を使用してスクリプトを非同期でロードする async
• 同期的にロードする場合は、JSまたはCSSの小片をインラインで記述します

ブロッキングクエリチェーンのレンダリングを回避する

サイトの速度を低下させる可能性があるのは、レンダリングをブロックするリクエストの数だけではありません。さらに重要なのは、ダウンロードする必要のある各リソースのサイズと、リソースをダウンロードする必要があることをブラウザーが正確に検出したときです。



別のリクエストが完了した後でのみファイルをダウンロードする必要があることにブラウザが気付いた場合、同期リクエストのチェーンが発生する可能性があります。これはいくつかの理由で発生する可能性があります。

• @importCSSにルールがある
• CSSファイルで参照されているWebフォントの使用
• JavaScriptインジェクションリンクまたはスクリプトタグ

この例を考えてみましょう。この







サイトのCSSファイルの1つに、@importGoogleフォントをロードするためのルールが含まれています。したがって、ブラウザは次の要求を1つずつこの順序で実行する必要があります。

1. ドキュメントHTML
2. アプリケーションCSS
3. Google Fonts CSS
4. Google Font Woffファイル（カスケードには表示されていません）

これを修正するには、最初にGoogle FontsCSSのリクエストをから@importHTMLドキュメントのlinkタグに移動します。これにより、チェーンが1リンク短くなります。



さらに高速化するには、Google FontsCSSファイルをHTMLまたはCSSファイルに直接埋め込みます。



（Google FontsからのCSS応答は、ユーザーエージェントによって異なることに注意してください。IE8を使用してリクエストを行うと、CSSはEOTファイル（OpenTypeに埋め込まれている）を参照し、IE11はwoffファイルを受け取り、最新のブラウザーはwoff2を受け取ります。ただし、問題がなければシステムフォントを使用する比較的古いブラウザと同じように機能し、CSSファイルの内容をコピーして貼り付けるだけです。）



ページがレンダリングを開始した後でも、フォントが完全に読み込まれるまでテキストが表示されないため、ユーザーはページを使用して何もできない場合があります。これは、現在GoogleFontsのデフォルトであるfont-displayswapプロパティを使用することで回避できます。



リクエストのチェーンを完全に取り除くことができない場合があります。このような場合は、preloadまたはタグを使用してみてくださいpreconnect。たとえば、上記のサイトfonts.googleapis.comは、実際のCSS要求が行われる前に接続する場合があります。

サーバー接続を再利用してリクエストを高速化

通常、新しいサーバー接続を確立するには、ブラウザーとサーバー間で3回のラウンドトリップパスが必要です。

1. DNSルックアップ
2. TCP接続の確立
3. SSL接続の確立

接続が確立されたら、少なくとももう1回のラウンドトリップが必要です。リクエストを送信し、レスポンスをダウンロードします。



以下のカスケードに示すように、接続は、hostgator.com、optimizely.com、googletagmanager.com、およびgoogelapis.comの4つの異なるサーバーに対して開始されます。



ただし、影響を受けるサーバーへの後続の要求は、既存の接続を再利用できます。したがって、base.cssまたはindex1.cssそれらはまたhostgator.comに位置しているので、すぐにロードされます。

ファイルサイズの縮小とコンテンツ配信ネットワーク（CDN）の使用

制御する他の2つの要素は、ファイルサイズとともに、リクエストの期間に影響します。リソースのサイズとサーバーの場所です。



さらに、必要最小限のデータをユーザーに送信し、圧縮に注意します（たとえば、brotliまたはgzipを使用します）。



コンテンツ配信ネットワーク（CDN）はさまざまな場所にサーバーを提供するため、そのうちの1つがユーザーの近くに配置される可能性が高くなります。それらを中央のアプリケーションサーバーではなく、CDN上の最も近いサーバーに接続できます。したがって、サーバーとの間のデータパスが大幅に削減されます。これは、CSS、JavaScript、画像などの静的リソースを簡単に配布できるため、それらを操作する場合に特に便利です。

サービスワーカーによるネットワークのバイパス

Service Workerを使用すると、リクエストがネットワークに入る前にインターセプトできます。したがって、最初のレンダリングはほぼ瞬時に発生する可能性があります。







もちろん、これは、ネットワークに単に応答を送信させたい場合にのみ機能します。この応答はすでにキャッシュされているはずなので、ユーザーがアプリケーションを再ダウンロードするときの作業が楽になります。



以下に示すServiceWorkerは、ページのレンダリングに必要なHTMLとCSSをキャッシュします。再ロードされると、アプリケーションはキャッシュされたリソースを発行しようとし、それらが利用できない場合は、フォールバックとしてネットワークに切り替えます。

self.addEventListener("install", async e => {
 caches.open("v1").then(function (cache) {
   return cache.addAll(["/app", "/app.css"]);
 });
});

self.addEventListener("fetch", event => {
 event.respondWith(
   caches.match(event.request).then(cachedResponse => {
     return cachedResponse || fetch(event.request);
   })
 );
});

Service Workerを使用したリソースのプリロードとキャッシュの詳細については、このチュートリアルを参照してください。

アプリケーションのダウンロード

さて、私たちのユーザーはすでに何かを見ています。彼が私たちのアプリケーションを使用できるようにするために他に何が必要ですか？

1. アプリの読み込み（JSおよびCSS）
2. ページの最も重要なデータの読み込み
3. 追加のデータと画像をダウンロードする

ネットワーク経由でデータをロードするだけでなく、レンダリングが遅くなる可能性があることに注意してください。コードがロードされると、ブラウザはコードを解析、コンパイル、および実行する必要があります。



バンドルの分割：必要なコードのみをロードし、キャッシュヒットを最大化します。



バンドルを分割することで、このページにのみ必要なコードのみをダウンロードでき、アプリケーション全体をダウンロードすることはできません。バンドルを分割すると、コードの他の部分が変更されて再ロードする必要がある場合でも、バンドルを部分的にキャッシュできます。



通常、コードは3つの異なるタイプのファイルで構成されます。

• このページに固有のコード
• 共有アプリケーションコード
• めったに変更されないサードパーティモジュール（キャッシングに最適！）

Webpackは、分割コードを自動的に分割して、ダウンロードの全体的な重みを減らすことができます。これは、optimization.splitChunksを使用して行われます。チャンクのハッシュが安定したままであり、長期キャッシングを有効に適用できるように、必ずランタイムチャンクを有効にしてください。 Ivan Akulovは、Webpackコードの共有とキャッシュに関する包括的なガイドを作成しました。



ページ固有のコードの分割は自動的に実行できないため、個別にロードできるスニペットを特定する必要があります。これは多くの場合、特定のルートまたはページのセットです。動的インポートを使用して、そのようなコードを遅延ロードします。



バンドルを分割すると、アプリケーションを完全にロードするためにより多くの要求が行われます。ただし、要求が並列化されている場合、特にHTTP / 2を使用しているサイトでは、この問題は大きくありません。このカスケードの最初の3つのクエリに注意してください。







ただし、このカスケードには、2つのクエリが順番に実行されていることも示されています。これらのフラグメントはこのページにのみ必要であり、呼び出しを使用して動的にロードされますimport()。これらのフラグメントが確実に必要になることがわかっている場合は



、タグを挿入することでこれを修正できますpreload link。







ただし、ご覧のとおり、この場合の速度の向上は、ページの合計読み込み時間に比べて小さい場合があります。



さらに、プリロードを使用すると逆効果になることがあり、他のより重要なファイルがロードされるときに遅延が発生する可能性があります。フォントのプリロードに関するAndyDavisの投稿と、最初にフォントをロードしてから、レンダリングを妨げるCSSをロードすることにより、プライマリレンダリングをブロックする方法を確認してください。

ページデータの読み込み

おそらく、アプリケーションはある種のデータを表示するように設計されています。事前にデータをロードし、レンダリングの遅延を回避するためのヒントをいくつか紹介します。



バンドルを待たずに、すぐにデータのロードを開始します。



順次リクエストが連鎖する特殊なケースがある場合があります。アプリケーションバンドルをロードすると、このコードはすでにページデータをリクエストしています。



これを回避する方法は2つあります。

1. ページデータをHTMLドキュメントに埋め込む
2. ドキュメント内のインラインスクリプトを介してデータの要求を開始します

HTMLにデータを埋め込むことで、アプリケーションはデータのロードを待つ必要がなくなります。また、ロード状態を処理する必要がないため、アプリケーションの全体的な複雑さが軽減されます。



ただし、データをフェッチするとドキュメントの応答が大幅に遅れる場合、このアイデアはあまり適切ではありません。最初のレンダリングも遅くなるためです。



この場合、またはService Workerを使用してキャッシュされたHTMLドキュメントを提供するときに、このデータをロードするインラインスクリプトをHTMLに埋め込むことができます。これは、次のようにグローバルな約束として提供できます。

window.userDataPromise = fetch("/me")

次に、データの準備ができている場合、アプリケーションはすぐにレンダリングを開始するか、準備ができるまで待つことができます。



これらの両方の方法を使用する場合、アプリケーションがレンダリングを開始する前であっても、ページに表示するデータを正確に知る必要があります。これは通常、ユーザー固有のデータ（名前、通知など）を提供するのは簡単ですが、ページ固有のコンテンツを処理する場合は簡単ではありません。最も重要なページを自分で強調表示し、それぞれに独自のロジックを記述してください。



無関係なデータを待っている間はレンダリングをブロックしないでください



ページデータを生成するには、バックエンドに実装された低速で複雑なロジックが必要になる場合があります。このような場合、アプリケーションを機能的かつインタラクティブにするのに十分であれば、最初にデータの簡略化されたバージョンをロードできると便利です。



たとえば、分析ツールは、最初にすべてのチャートをロードしてから、それらにデータを添付する場合があります。したがって、ユーザーは興味のある図をすぐに見ることができ、バックエンド要求をさまざまなサーバーに分散する時間があります。







シーケンシャルデータクエリの連鎖を回避する



このアドバイスは、無関係なデータのロードを2番目のリクエストに延期することについて話していた以前のポイントと矛盾しているように見えるかもしれません。ただし、チェーン内の後続のリクエストがユーザーに新しい情報を提供しない場合は、シーケンシャルリクエストをチェーンすることは避けてください。



最初にユーザーがログインしているものを尋ねてから、ユーザーが属するグループのリストを尋ねる代わりに、ユーザーに関する情報とともにグループのリストを返します。これにはGraphQLを使用できますが、カスタムエンドポイントでもuser?includeTeams=true問題ありません。



サーバー側のレンダリング



この場合、サーバー上でのアプリケーションの事前レンダリングを意味し、本格的なHTMLページがドキュメントからの要求への応答として提供されます。したがって、クライアントは、追加のコードまたはデータがロードされるのを待たずに、ページ全体を見ることができます。



サーバーは静的HTMLのみをクライアントに送信しているため、この段階ではアプリケーションにはまだ対話性がありません。アプリケーションをロードし、レンダリングロジックを再実行してから、必要なイベントリスナーをDOMに接続する必要があります。



非インタラクティブなコンテンツがそれ自体で価値があることがわかった場合は、サーバー側のレンダリングを使用します。また、このアプローチは、サーバーに表示されたHTMLをキャッシュし、ドキュメントが最初に要求されたときに遅滞なくすべてのユーザーに転送するのに役立ちます。たとえば、Reactを使用してブログを表示している場合、サーバー側のレンダリングは優れています。MichalJanaszekによる



この記事を読んでください。ServiceWorkerをサーバー側のレンダリングと組み合わせる方法について詳しく説明しています。

次のページ

ある時点で、アプリケーションを操作しているユーザーは次のページに移動する必要があります。最初のページが開いているときは、ブラウザで発生するすべてのことを制御できるため、次の操作の準備をすることができます。



リソースの



プリフェッチ次のページを表示するために必要なコードをプリフェッチすると、カスタムナビゲーションの遅延を回避できます。タグを使用するprefetch linkかwebpackPrefetch、動的インポートに使用します。

import(
    /* webpackPrefetch: true, webpackChunkName: "todo-list" */ "./TodoList"
)

特にモバイル接続に関しては、使用しているユーザーデータの量と帯域幅を考慮してください。プリロードに熱心になれなかったり、データ保存モードが有効になっている場合は、モバイル版のサイトにあります。



ユーザーが最も必要とするデータを戦略的に選択します。



すでにロードされているデータを再利用



するアプリケーションでAjaxデータをローカルにキャッシュして、後で不要な要求を回避します。ユーザーが[グループの編集]ページでグループのリストに移動した場合、以前に選択したデータを再利用することで、すぐに移行を行うことができます。



オブジェクトが他のユーザーによって頻繁に編集され、アップロードしたデータがすぐに古くなる可能性がある場合、これは機能しないことに注意してください。このような場合は、最初に既存のデータを読み取り専用モードで表示し、その間に更新されたデータを選択してみてください。

結論

この記事では、読み込みプロセスのさまざまな時点でページの速度を低下させる可能性のあるいくつかの要因について説明しました。などのツールを使用しクロームデベロッパーツール、WebPageTest、および灯台は、アプリケーションに関連するどのヒントを決定します。



実際には、包括的な最適化を実行することはめったに不可能です。ユーザーにとって何が最も重要かを判断し、それに焦点を合わせます。



この記事に取り組んでいると、複数のクエリはパフォーマンスの問題であるという深い信念を共有していることに気付きました。これは過去のケースであり、各リクエストには個別の接続が必要であり、ブラウザはドメインごとに数個の接続しか許可していませんでした。しかし、この問題はHTTP / 2と最新のブラウザーの出現で解消されました。



クエリを分割することには強い議論があります。これを行うことにより、変更されたファイルをリロードするだけでよいため、厳密に必要なリソースをロードし、キャッシュされたコンテンツをより有効に活用できます。