Clever Geek Handbook

JSファイル2.0の結合（2/2）

パート1



そのため、最後の部分の最後で、新しいユーザーを放っておきました

特別なものを一切含まない単一のJSファイルを使用します。 なりましたか

ユーザーは幸せですか？ まったくありません。 それどころか、 平均して

ユーザー1は以前より悲惨になり、その理由は

ページの読み込み時間が増加しました。







素敵な理論



... あなたは風船の中にいます！ ...





HTTPを介したリソースの読み込み時間は、次の主要な要素で構成されています。

  1. T1サーバーにリクエストを送信する時間-ほとんどの2つのリクエストでは、値はほぼ一定です。

    サーバー応答生成時間-現在検討中の静的リソースの場合、

    無視できる;

    T2サーバーの応答時間。サーバーの一定のネットワーク遅延Lと、

    応答時間R。これはリソースのサイズに正比例します。





    次に、ページの読み込み時間は、HTMLコードのダウンロード時間とすべての

    外部リソース：画像、CSSおよびJSファイル。 主な問題は

    CSSおよびJSファイルは順次ロードされます3 。 この場合、サーバーとの通信は次のようになります。 

     -要求されたページ
 -HTMLを取得 
 -要求されたリソースA：T1
 -受信したリソースA：L + R（A）
 -要求されたリソースB：T1
 -受信したリソースB：L + R（B）
 -要求されたリソースC：T1
 -受信したリソースC：L + R（C）


    この場合に費やす合計時間は3（T1 + L）+ R（A + B + C）になります



    ファイルを結合することにより、サーバーへのリクエストの数を減らします。 

     -要求されたページ
 -HTMLを取得 
 -要求されたリソースA + B + C：T1
 -リソースA + B + Cを受信しました：L + R（A + B + C）


    明らかな節約は2（T1 + L）です。

    20のリソースの場合、この節約はすでに19（T1 + L）です。 あなたが今の標準を取るのに十分なら

    自宅/オフィスのインターネット速度は256 kbps、pingは20〜30ミリ秒、節約できます

    950ミリ秒-ページ読み込みの1秒 。 モバイルを使用している人や

    pingが300ミリ秒を超える衛星インターネットでは、ページの読み込み時間の差は

    6〜7秒。



    一見したところ、ページの読み込みはもっと速くなるはずだという説があります。 彼女は何に分かれましたか

    練習で？



    厳しい現実



    彼らは最高のものを望んでいましたが、いつものように判明しました。




    私たちのサイトに3つのページP1、P2、P3があり、それらは新しいユーザーによって順番に要求されます。

    P1はリソースA、B、およびCを使用し、P2はA、C、およびDを使用し、P3はA、C、E、およびFを使用します。

    リソースが結合されていない場合、次の結果が得られます。

    • P1-A、B、Cのロードに時間を費やす
    • P2-D のみのダウンロードに時間を費やす
    • P3-EおよびFのロードに時間を費やす




    すべてを完全にマージした場合

    サイトのJSモジュールは次のようになります。

    • P1-ダウンロードに時間を費やす（A + B + C + D + E + F）
    • P2-外部リソースは不要
    • P3-外部リソースは不要


    その結果、最初のページの読み込み時間が長くなり、

    ユーザーが上陸します。 スピード/キックの典型的な値では、すでに浸透し始めています

    2〜3キロバイトの負荷が追加されます。



    現在のページに必要なモジュールのみを組み合わせると、次のようになります。

    • P1-ダウンロードに時間を費やす（A + B + C）
    • P2-ダウンロードに時間を費やす（A + C + D）
    • P3-ダウンロードに時間を費やす（A + C + E + F）


    空のキャッシュを持つ個々のページはより高速にロードされますが、それらはすべて一緒に-

    元の場合よりも遅い。



    現在流行しているリソースのプールのブラインド使用は、しばしば悪化するだけです。

    ユーザーライフ 。



    解決策



    -ビリヤードボールを飲み込むことは可能ですか？

    -可能ですが、原則として必要ありません。





    もちろん、この状況から抜け出すには4つの方法があります。 ほとんどの場合

    本当の勝利を得るには、「コア」を選択するだけで十分です-すべてで使用されるモジュールのセット

    （または少なくとも頻繁にダウンロードされる）サイトページ。 たとえば、この例では、強調するだけで十分です

    コアリソースAおよびBで、利点を得るには：

    • P1-読み込みに時間を費やす（A + B）およびC
    • P2-Dのダウンロードに時間を費やす
    • P3-ダウンロードに時間を費やす（E + F）


    思慮深い読者は今nowして、尋ねます：「しかし、コアがなければどうですか？ または、カーネルも判明

    少し？」 私はあなたを保証するために急いで-これは2-3独立を選択することにより、手動で簡単に解決されます

    独自のカーネルを持つグループ。 必要に応じて、パーティションの問題を定式化して、

    正確な機械ソリューションを得るために-しかし、これは通常必要ありません。 最も単純なルールによって導かれる-より

    コアが大きいほど、非常に適切な結果を得ることができます。



    Habréで彼らが言うように、「この記事のメッセージは何ですか？」私たちは悲惨な3つのポイントに限定しています。

    • ファッションのトレンドを軽率に守ることは無駄な仕事につながります。
    • ファッショントレンドは、しばしば良いアイデアをもたらします。
    • ユーザーを愛しているなら-リソースを賢く組み合わせてください。




    もちろん、キャッシュが空の1です。

    2は 、ほとんどの要求が妥当なURL長のGET要求であることを意味します。

    このような要求の長さはほぼ一定で、最大450〜600バイトです。

    3少なくとも同じホスト上にある限り。

    4 、およびコメントから見ると良いが使用されます。

    5 「このようなデバイスはありますが、それらについては説明しません。」 一言言わなければならない。


More articles:


All Articles