高速 Web サイトと低速 Web サイトの違いは何ですか?
正解は 1 つありますか?
いいえ、残念ながらまだです。その理由は、Web サイトには多くの要因があり、それぞれが Web サイトの速度を低下させる可能性があるためです。したがって、この記事は完了する必要があるチェックリストを提供するものではなく、特定の要因によって Web サイトの速度がどのように低下するのか、そしてそれに応じて何ができるのかを説明することを目的としています。
ことわざにあるように:
人に魚の釣り方を教えるよりも、人に魚の釣り方を教える方が良い。魚を釣ることで一生の必需品が救われます。
スクリプトに「async」タグを追加したり、ページを特定の順序でレイアウトしたりできるようにすることに加えて、これらの変更によって生じる違いについても説明します。このようにして、アプリケーションを試して、どの変更が役立つかを確認できます。
ところで、これらのヒントは、Ilya Grigorik との素晴らしい会話から得たものです。
W3C Web パフォーマンス ワーキング グループの共同議長であり、Google の Web パフォーマンス エンジニアである Ilya Grigorik を紹介します。まあ、彼はパフォーマンスに関する知識が豊富です。
先ほども述べたように、そのようなことはありません。ウェブは驚くほど複雑です。ページの読み込みが遅くなるという現象は、あなたにとって集中力の正しい基準ではない可能性があります。 (これについては後で詳しく説明します)
ただし、多くの場合、顕著な違いを生み出す非常に重要な要素がいくつかあります。あなたも以前にそれらに遭遇したことがあるかもしれませんが、それらがなぜ重要なのか理解していないかもしれません。
gzip 圧縮を使用して HTML、CSS、JavaScript を送信し、ネットワークを流れる必要のあるバイト数を削減します。これにより、リソースのダウンロードにかかる時間を大幅に短縮できます。ブラウザは HTML と CSS がないとページをレンダリングできないため、これらのリソースをできるだけ早くダウンロードしたいと考えています。
クライアント向けに WordPress の Web サイトを構築している友人がいます。最近、彼と話をしました。彼は、顧客がカメラからの画像を Web サイトに直接アップロードしているという問題に遭遇しました。
携帯電話で撮影した写真は1MBを超えています。 CSS でサイズを変更したとしても、この非常に大きな画像をケーブル経由でダウンロードする必要があります。インターネット速度が遅いユーザーは、開くまでに長時間待つ必要があります。
幸いなことに、それに対処する方法があります。 画像の最適化に関連するプログラムがあります。まだ見ていない場合は、ぜひお勧めします。
さまざまなページのスクリプトと CSS ファイルを見て、これらのファイルがそのページに本当に必要かどうかを自問してください。おそらく、追加されたものの削除されなかったファイルがいくつか見つかるでしょう。
この点でのプラグインのパフォーマンスは非常に悪いです。私が接触するかなりの数の ebordPress Web サイトでは、大量の CSS ファイルがロードされており、その半分は一部のページではまったく使用されていません。同様の現象は、WordPress 以外の多くの Web サイトでも発生します。以前、scaleyourcode.com のいくつかのページを確認したところ、不要なスクリプトが読み込まれていることがわかりました。
スクリプトやスタイルシートをクリアするのは恐ろしい場合があります。そのページにとってそれが本当に必要であるのに、単に覚えていない場合はどうすればよいでしょうか?これを確認するのに役立つツールがいくつかあります。DevTools (監査の下) をお勧めします。
これらの最適化の共通点がわかりますか?どちらも、転送する必要があるバイト数を減らします。
できるだけ早く HTML バイトをブラウザーに与える必要があります。
例: リクエストが受信され、サーバーが迅速に取得できるように (理想的には) データがキャッシュされます。次に、ブラウザはデータの解析を開始し、画面上にレンダリングします。
プログレッシブ レンダリングのおかげで、ページの読み込み時間は重視する必要のあるパフォーマンス基準ではない可能性があると先ほど述べました。
プログレッシブ レンダリング (ソース)
ただし、ユーザーにコンテンツを短期間 (できれば 1 時間未満) で提示する限り、ページは巨大になる可能性があります。 1 秒)、それでも読み込みが速いように感じます。
Amazon はこの点で良い仕事をしました。
Amazon のプログレッシブ レンダリング
この WebPageTest では、最初の結果は 1.5 秒で取得されました。 1 つの画面ですが、ご覧のとおり、すべてが含まれているわけではありません。ページの閲覧を開始したり、ホリデー セールをチェックしたりするのに十分なコンテンツが含まれています。
その後、3.5 秒までに、別のセクションに追加のトランザクションがロードされます。 6.5 秒の時点で、まだ何かが読み込まれています。実際、ページ全体のロードが完了するまでに 18 秒かかりました。そんなに待っていられますか？私はそれを疑う！
Amazon がページの読み込みが最も遅いことに焦点を当てたら、誰かが怒るでしょう。これらは、最も重要なバイトを最も早いパケットで送信することに重点を置いています。さらに一歩進んで、最初のパケットに最上位バイトを詰め込む可能性があります。彼らはバイトをできるだけ早くあなたに届けることにも重点を置いているに違いありません。
これは、TTFB (Time To First Byte) 注 1 の起源です。
ブラウザがページリクエストを開始すると、応答を待っている状態になります。 TTFB は、応答の最初のバイトを受信するまでにかかる時間を表します。この時間は、サーバーが応答を生成するのにかかる時間だけでなく、ケーブルを介して応答を送信するのにかかる時間も表します。
この画像には非常に高速な TTFB が含まれています。オンライン ショッピングに行くと、次のようなさまざまな TTFB が表示されます。
なぜそうなるのか、どうすれば時間を最小限に抑えることができるでしょうか?最適化に重点を置くべきでしょうか?良い質問ですね。これについてさらに詳しい情報を用意しました。
さらに詳しく知りたい場合は、パフォーマンスの測定基準についての Steve Souders の優れた講演をご覧ください。ページの読み込み時間は常に最良の基準であるとは限りません。
TTFB が高速になったので、すべてのレンダリングが非常に高速になるでしょうか?必ずしもそうではありませんが、クリティカル レンダリング パスを見てみましょう。
クリティカル レンダリング パスは、HTML の取得、DOM の構築、スタイル情報の取得、重要な JavaScript の実行、およびコンテンツの描画のためにブラウザが実行する必要がある一連の手順です。
なんと、やるべきことがたくさんあります。
だからこそ、慎重に扱う必要があります。 HTML、CSS、JavaScript の量が増えるほど、時間がかかります。このため、JavaScript ファイルを読み込むときは、async タグを追加します。
ブラウザが JavaScript に遭遇したとき、ここの JS が DOM を変更しようとしているかどうかがわからない可能性があります。したがって、変更されることを想定し、JavaScript の実行が終了するまでレンダリングをブロックする必要があります。 async タグを追加すると、JS がページにとって重要ではないことをブラウザーに保証することと同じになり、ブラウザーは JS の実行が完了するのを待たずにレンダリングを続行できます。
ページを変更するスクリプトが見つかった場合、それは非同期であってはいけないということですか?可能。ただし、ページ上のスクリプトを非同期的に変更したとしても、ユーザーの観点からは意味があります。ユーザーはコンテンツを表示して、コンテンツとの対話を開始できます。実際、場所によってはご利用いただけない場合があり、少々お待ちいただく場合がございます。もちろん、これはすべてアプリケーションに依存するため、試してニーズを満たしているかどうかを確認してください。
バイトをできるだけ早く取り込むためにクリティカル パスが非常に重要である理由は、プロセス全体の処理を早く開始できれば、より早く完了できるからです。クリティカル レンダリング パスの最適化については、こちらを参照してください。
WebPageTest という優れた測定ツールがあります。スライドショー表示など、さまざまな役立つ情報が得られます。スライド ビューは、Amazon ページを表示するために使用したビジュアライゼーションです。これを Web サイトで使用して、非同期の有無の違いを並べて比較できます。
最近まで、DevTools は独自のスライドショー ビューを実装していました。
Chrome DevTools を開き、[タイムライン] -> [スクリーンショットをオンにする] -> ページをリロードします。
ページの読み込みプロセスのスクリーンショットが表示されます。悪くないですよね？
これで次のことができます:
DevTools のインターネット速度で調整できます
もう 1 つのツールは、最近偶然見つけた SpeedCurve です。これは Mark Zeman と Steve Souders という 2 人の賢い人によって開発されたもので、役に立ちそうです。
問題は、追加する機能が多すぎることによる残念な副作用にあります。
上記の例を見る以外に、学習と練習を始めるのにこれより良い方法はあるでしょうか? Paul Lewis らは、実際の Web サイトで DevTools を使用する方法を経験しました。これは、スクロールのパフォーマンスの問題を解決する優れた例です。
この記事はインタビュー全体の簡単な要約であり、詳細を詳しく説明し、より重要なトピック (HTTP/2 がどのように異なるのか、HTTP/2 がどのように異なるのかなど) を取り上げています。最小化と連結は依然として必要です)。
ここで概要全文を読むか、インタビューを聞くことができます。必要な場合は、以下のビデオを参照してください: https://youtu.be/Aayh2FAYGqc
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
