こんにちは、私の名前はアレクサンダー・ゼレニンで、私はウェブ開発者です。 サイトをすばやく開く方法を説明します。 とても速い。

エントリー

「A」を作成してスーパーウィンを獲得するアドバイスはありません。 これは起こりません。 この記事では、加速できる要因とその原因を検討します。 他の要因はありません。 次回、あなたのサイトをより速くするとき、あなたがどのように勝つかを理解するでしょう。

この記事は上級開発者を対象としています！

説明されている各トピックは、個別の投稿、または複数の投稿に値します。 おもしろい場合は、もっと詳しく説明します。

ユーザーにとって本当に重要なことから始めましょう：

1. HTMLの読み込みが開始されます（ TTFB ）
2. ページ上部のHTML、CSS、およびスクリプトが読み込まれます。 レンダリングされたページ（ TTI ）
3. 完全な機能：追加コンテンツが利用可能、コントロールボタンが機能（ TTLB ）*

* TTLBと呼ぶのは完全に正しいわけではありません。 いくつかの個別のファイルをロードしましたが、最後の必要なバイトがロードされていると想定できます。

ユーザーがサイトがすぐに機能していると考えるように、 1秒以内にメインコンテンツを表示するだけで十分です。 これは思ったよりもずっと簡単です。

最初に最適化するものは何ですか？

記載されているサイトメトリックを測定し、最大のメトリックをこの順序で選択して最適化する必要があります。 これで、これまで以上に簡単になりました。たとえば、ウェブ開発者ツールのChromeパネルネットワークで開くだけです。

最適化を開始する前に知っておく必要があります

1. ターゲットオーディエンスの地理的位置（都市、国。地域によっても違いが生じる場合があります。）
2. ユーザー通信チャネルのパラメーター（特定の地理的位置で一般的な関税はどれですか？モバイルインターネットについてはどうですか？）
3. アクセスデバイスの種類（PC、電話、タブレット）

すべての推奨事項は、50ミリ秒を超えない資本へのpingで、毎秒8メガビットの接続と最新のPCマシンに対して提供されます。 あなたの場合、希望する条件に応じて数値を調整する必要があります。

ページを開くことは何から成っていますか？

1. 待ってる
   
   1. 待ち行列
   2. プロキシウォークスルー
   3. DNSを解決する
   4. 接続の確立（TCPハンドシェイク）
   5. SSLハンドシェイク
   6. 提出依頼
   7. 応答の待機（最初のバイトが受信されるまでの時間）
   
   
2. データの読み込み
3. スクリプト実行
4. レンダリング
5. 描画

待ってる

待機は、最初のバイトが受信されるまでのすべてです。

待ち行列

影響 ：制限を超えた場合、すべてのリクエスト
要因 ：1つのドメインから同時に要求されたファイルの数
適切な値 ：意味のあるコンテンツの場合は 0
意味のあるコンテンツの値がゼロより大きい場合は注意してください 。

ブラウザーは、同じドメインとの同時接続（同時ダウンロード）の数に制限があります。 平均で4〜8ですが、デバイス、ブラウザ、およびそのバージョンによって異なる場合があります。 さらに、この制限はすべてのタブに同時に適用されます。

ブラウザが制限より多くのリソースをダウンロードする必要がある場合、ブラウザは最初のダウンロードを開始し、残りをキューに入れます。

必要な手順：

1. 意味のあるコンテンツの読み込みをキューの先頭に移動します
2. 意味のあるコンテンツがまだキューを作成している場合は、関連するリソースを組み合わせてください*。 1つのCSSファイル、1つのJSファイル、アイコンを組み合わせてスプライトにするか、CSSに直接配置します（通常、コストは10〜20％を超えず、価値があります）。
3. オプションのコンテンツのダウンロードをキューの最後に移動する
4. オプションのリソースをグループにまとめます。 すべてを結合するべきではありません。スクリプト、スタイル、グラフィックスをブロックで結合するのが最善です。 場合によっては独立しており、非同期に表示できます。

*そして、あなたはこのようにそれを行うことができます

すべてを一度に整理する方法は？

CSSインラインフォントとアイコン。 レンダリングにCSSを必要とし、依存関係マネージャーを使用して残りを1つずつ読み込みます。 必要なCSSはページヘッダーから読み込まれ、残りはjsを介して読み込まれます。 JSはまったく同じです。 CDNに静的データを配置します。

プロキシウォークスルー

プロキシ接続を介して作業が発生すると、制限が課され、応答と最終ダウンロードの遅延が増加します。 このパラメーターに影響を与えることはできません。そのため、このパラメーターを考慮しても意味がありません。

DNS認識

影響 ： TTLごとに1回
要因 ：使用されるドメインの数、レ​​ジストラネームサーバーの場所
良い値 ：20-50ms
ターゲットオーディエンスの値が80msを超える場合は注意してください

ページで使用される各ドメイン（最初のドキュメントを含む）には、ドメイン認識サイクル全体が必要です。通常、10〜120ミリ秒かかります。 多くのDNSサーバーには、世界中にミラーがあります。

必要な手順：

1. ターゲットオーディエンスの地理的な場所を特定し、ネームサーバーの場所が適切なレジストラを選択します。
2. サーバーの移行が計画されていない場合は、ドメインTTLを1日または1週間という大きな値に増やすことができます。
3. スクリプトまたは他の保留中のソースからのサブドメインまたは他のドメインのリクエストを計画している場合は、指定する必要があります

   <link rel="dns-prefetch" href="//example.com"> 

   メインドキュメントで。

接続を確立する

影響 ：ダウンタイム後のすべてのリクエスト
要因 ：データがあるサーバーまでの距離
良い値 ：50-80ms
値が150ms以上の場合は注意してください

データの送受信を開始する前に、ブラウザはサーバーとの接続を確立します。 3つのパケット転送で構成され、1.5 RTT （サーバーへのping x 1.5）で実行されます。 使用可能な接続がない場合、データがロードされるたびに接続が確立されます。 覚えているように、ブラウザは一定数の接続しか開きません。 データがダウンロードのためにキューに入れられていて、アクティブな接続がある場合、それらは解放されるとすぐに使用されます。 追加の遅延はありません。 すべての関連情報がすぐに最初のhtmlドキュメントに含まれる場合、1.5 pingの遅延が発生し、少なくとも何か他のものがロードされると、3 pingの遅延が発生します。 pingが100ミリ秒の場合、合計損失は300ミリ秒になります。

手順：

1. 最初のリクエストで意味のある情報を返します（この要因の影響をすぐに半分に減らします）。
2. ターゲットオーディエンスの領土の場所を決定し、サーバーを可能な限り近くに配置します

SSL

影響、オーバークロック機能、要因 ：接続時と同じ
良い値 ：100-150ms
値が250ms以上の場合は注意してください

SSLを使用すると、接続セットアップ時間が数倍長くなります。

接続を確立するために送信されるパケットの数は、3から12および3 RTTに増加します。 これは、元のドキュメントにデータが含まれていない場合、100msの遅延で、最低600msの遅延が発生することを意味します。 サーバーのアップタイムは、次のように無視できます。 この場合、それは小さくなります。

手順：

1. SSLが本当に必要であることを理解し、それが不要な場所を拒否する
2. 接続設定を高速化するアクションは、SSLダウンロードも高速化します。

提出依頼

通常は1ms未満です 。 正直なところ、練習から、私はもっと多くの状況があったときに覚えていません。

私が注意したいかなり重要な点は、すべてのリクエストで多くのヘッダーが送信されることです。 Cookieもヘッダーです。 Cookieに大量のデータを入れると、そのたびにサーバーに送信されます。 大量の重いCookieを本当に使用する必要がある場合（理由はわかりませんが、言いましょう）-正しいパスを指定して、必要な場所にのみ移動するようにします。

応答待ち

影響 ：すべてのリクエスト
要因 ：サーバーの稼働時間
良い値 ：10-50ms
値が100ミリ秒を超える場合は注意してください

通常、このステップでは速度が最大に向上します。 サーバーキャッシュは別の記事に値するものであり、おそらく私はそれを書くために何らかの形で成熟するでしょう。 応答の待機に対する主な影響は、サーバーでのスクリプトの実行時間（要求処理、データベースクエリ、応答生成など）によって再生されます。 この段階の速度の主な秘密は、彼らが要求したいものに対して既製の答えを持っていることです。 簡単に言えば、キャッシュです。

手順：

1. どのデータとキャッシュ方法を決定する
2. キャッシュからすべてのデータを返します

データの読み込み

影響 ：すべてのリクエスト
要因 ：データサイズ、（ユーザーチャネル）
価値：前の手順を考慮に入れて、地理のプロバイダーに応じて、最大1秒
2秒を超える場合は注意してください

最後に、サーバーはデータを返し始めました。 それらをダウンロードする主な基準は、サイズです。
少量のデータの高速性は考慮しません。なぜなら、 ただし、通常のサイトは500kbから取得します。

重要 ：ユーザーチャネルの帯域幅が増加すると、この要因の影響は減少します。 メインのターゲットオーディエンスが首都にあり、100 mb / s（標準として8 ms / sに対して）を持っている場合、1メガバイトは1桁速くロードされ、最長の要因から、重要でないものの1つになる可能性があります。

「TCPスロースタート」について言及する価値はありますが、これは別の投稿のトピックです（ハブのどこかにいたのですが、見つかりませんでした）。

手順：

1. サーバーでデータ圧縮を有効にします。 ただし、データの解凍にも時間がかかり（エンドデバイスによって異なります）、場合によっては、非圧縮データの送信が正当化されることに注意してください。
2. ダウンロードから未使用のデータを削除します。 多くの場合、多くのライブラリが接続されており、しばらくすると、それらの一部は無関係になりますが、削除するのを忘れています。
3. データを必要なものと二次的なものに分け、その順序でロードします。 場合によっては、桁違いのゲインを得ることができます。

スクリプト実行

影響 ：常に
要因 ：スクリプトの量、使用されるアルゴリズム
適切な値 ：意味のあるコンテンツが表示される0〜50ミリ秒前、その後は重要ではない
200ms以上のデータをダウンロードした後、「どこにも行かない」 場合は注意してください

スクリプトをダウンロードした後、ブラウザはそれらを解析して実行するのに時間がかかります。

レンダリング

影響 ：常に
要因 ：スタイルのボリュームと品質、およびサイトブロックのネスト
適切な値 ：最大50ミリ秒
レンダリングに200ms以上かかる場合は注意してください

すべてのスタイルを読み込んだ後、ブラウザは、配置するブロック、行を転送する場所などの計算を開始します。
サイトの速度に非常に大きなHTMLネスティングが20％の影響を与えたことがわかりました。 真剣に-HTMLネストだけを最適化すると、20％応答性の高いサイトができました。

手順：

1. スタイルの数を減らす
2. 可能な場合はいつでもリマップスタイルを削除します（1つのプロパティに多数のルールが重複しており、1つのプロパティのみが実行される場合。OOCSSに向かって

描画

影響 ：常に
要因 ：影などの後処理を伴う「重い」要素の量。 グラフィックの数。
適切な値 ：最大50ミリ秒
描画に200ms以上かかる場合は注意してください

レンダリング時間への主な影響は、ページ上の変化する部分によって演じられます。 1つのgif'kaは、他の何よりも増加します。

手順：

1. ページ上のグラフィックと動的要素の数を減らす

CDN

CDNを適切に使用すると、多くの問題が解決され、サイトの読み込みが大幅に高速化されます。
接続の作成の遅延が20ミリ秒以内になるという事実から始めて、プロバイダーのサーバー上の場所が原因で、CDNがユーザーの関税率を超えるダウンロード速度を提供する場合があります（たとえば、Googleはこれを行います）。

ブラウザキャッシュ

ユーザーが初めてサイトを開いたとき、キャッシュは役に立ちません（ライブラリでパブリックCDNを使用する場合を除き、これは別の記事のトピックであり、セキュリティ管理の問題です）。 しかし、繰り返しアクセスする場合、キャッシュには大きな利点があります。 不変のコンテンツはすべてブラウザのキャッシュに配置する必要があります。 グラフィック、スタイル、スクリプト。 APIへの応答をキャッシュに追加することもできますが、非常に慎重です。 適切なキャッシュ管理により、次のものが得られます。

1. 接続を確立するための75ミリ秒（追加の接続なし、キャッシュからのデータ）
2. サーバーの応答を待機する25ミリ秒
3. レンダリングあたり50ミリ秒
4. レンダリングに10ミリ秒
5. 100ミリ秒のデータロード（650ではなく）

つまり 四分の一秒以内にフルサイトロード！

ソケット

まず、ソケットを操作するには、スクリプトをロードして実行する必要があります。 その後、もちろん、接続とキューの制限を作成するコストを取り除きますが、キャッシュの管理で問題が発生します（手動で管理する必要があります）。

判定 ：ソケットは、動的で、キャッシュ不可能で、ボリュームのないコンテンツに使用する必要があります。

SPAがあります。

すべてのヒントはさらにSPAに適用されます。 通常、SPAは、コンテンツがレンダリングされるまで少なくとも1ステップ以上、つまり HTMLを取得->スクリプトを取得-> APIからコンテンツをロード。 ここから、少なくとも1つのRTTを取得し、スクリプトをロードした後。

アクション：

1. データを含むHTMLをすぐに返します。 最新のテンプレートエンジン（ハンドルバーなど）は言語に関連付けられておらず、サーバーとクライアントの両方で簡単に生成できます。 少なくとも許可されていないユーザーの場合。 認可されたものにはすでにキャッシュがあり、コストは最小限になります。
2. まず最初に、必要なコントローラー、モデル、ビュー、およびそこにある他のものだけをロードします。 依存関係を追加したり、 AMDを使用した場合、思ったより簡単です

主観的な最適化

実際には同じ場合でも、より速く動作するように見せることができます。 それを使うのは良いことです 例として、SPAのイベントのリッスンをクリックからマウスダウンに変換できます（クリックに加えて！）。 「試す」ことを可能にする小さなハック：

 document.onmousedown = function(e) { e.target.click(); } 

秘Theは、ユーザーの場合、クリックには最大50ミリ秒かかり、onmousedownイベントは中央で発生するということです。 したがって、処理を早く開始したので、結果をより早く生成できます。 私たちの処理がユーザーのクリック率を超えていない場合、後者はまだクリックさえしていないように感じますが、すべてがすでに見えた-すごい！ このようなトリックは、プロジェクトごとに個別に行う必要があります。

一般的に、これはもちろん特別な場合です。事前に何かを計算できれば、すぐに表示できます。

たとえば、0.1秒以上マウスオーバーをクリックすることもできます。

合計

ユーザー：プロキシなし、チャンネル幅8メガビット/秒、サーバーへのRTT 50ミリ秒：

1. DNS解決に50ミリ秒
2. 接続を確立するために75ミリ秒（SSLなし）（+ 75ミリ秒およびそれ以降の並列接続）
3. サーバーの応答を待機する25ミリ秒
4. スクリプトを実行するための0ms
5. レンダリングあたり50ミリ秒
6. レンダリングに10ミリ秒

285msのオーバーヘッド

コンテンツをダウンロードするのに700msのままです。これは、当社の条件下ではデータの約700kbに​​相当します。 圧縮を考慮すると、これは3.5MBのデータ領域にある可能性があり、ほとんどのサイトで十分です。

合計：1秒

再度開くと、DNSの遅延がなくなり、一部のデータがキャッシュからロードされます。

合計：〜0.4秒、キャッシュあり

高速サイトを作成すると、誰もが幸せになります。 このすべてのために、接続を切断するときにユーザー情報を表示する場合 、一般的には豪華になります。

ボーナスは高性能ブラウザネットワークで読むことができます

質問をする-答えます、記事を補足します。

仕事を探しています。