あなたはいつもあなたのウェブサイトのサイズを気にする必要がありますか?

TLDR:あなたが90から60 KBまであなたのクリティカルパスサイズを減らすならば、それは良いです、しかし、すべてがネットワーク展望から大きくないというわけではありません.しかし、42から40(特に遅い接続で)に行くことは、より顕著であるかもしれません.常にカンニングペーパーを見て、小さい往復のサイズに到達しようとします.閉じるこの動画はお気に入りから削除されています.
往復のサイズのシート( KBで)
往復
ウィンドウサイズ( kb )
合計サイズ
1
14
14
2
28
42
3
56
98
4
112
210
5
224
434年
あなたがあなたのクリティカルパスのためにより多くを必要としないことを願っています.いくつかのヒントについては、この記事の記事といくつかの他の記事をチェックしてください.

往復旅行規則

最近では、TCPの動作方法、特に小さなパッケージでの雪だるま(またはスロースタート)の接続についてのいくつかの有用な記事を読みました.あなたのウェブページクリティカルパス(基本的にHTML + CSS)がTCP接続の範囲内で最初の往復旅行に適合することができるならば、ブラウザが何のためにでも再びサーバーを尋ねないので、それは最も良いケースシナリオです.
これはウェブページがCSSフレームワークを使用したり、JavaScriptをインライン化したり、テキストをたくさん持っているので、めったに起こりません.しかし、2番目の最高のものもあります.つの往復または3つの内であなたのウェブページを返してください.
最初の往復は14 KBの大きさです.
つ目はその2倍です.は28です.それで、2回目の往復旅行の終わりに、それが28 + 14 = 42 Kb未満であるならば、あなたのウェブページはロードされます
再び、3回目の往復は2 * 28 = 56です.56 + 42 = 98.記事の上部にあるカンニングペーパーを見てください.

我々のケース

我々は、最初の往復で合うように、我々のドキュメンテーションウェブサイトのホームページを調整しました.それは18 Kbsの周りでしたが、多くのインラインのものを持って、かなりよく(すでに灯台で100を持ちました)最適化されました.
14 KBを下回るために、私たちはいくつかのもの(主にSVG画像、Favicon、別の実験では別の実験だった)をいくつかの未使用のSVGシンボルをきれいにしてインラインにしなければならなかった.CSSのためのHTMLと6.88 KB用の5.29 KB.

うまくいきましたか。

よく、それは言うのは難しい.SSLの握手は、重要なデータの実際の転送よりも多くの時間を取るので、フロントエンドの観点から悪いことではない.
これはなんとか14 KB以下になる前の滝です

そして、これは14 KB以下になってからです( HTTPヘッダのプリコネクトの追加は、CDNへの接続の初期化をうまく期待します).

注:テストは、WebPageTestの1.5 Mbpsの設定で行われた.
テストの後、我々はSSLの握手を最適化することができますので、これは非常にすぐに世界的な改善を行う私たちの目標になることを発見.SSLハンドシェイクデータは約6 KBの重さが検出され、14 KBのTCPパケットが発生する可能性がある.その地域にはもっと多くの調査が必要だ.
実際のデバイスとライブのウェブサイト上でテストの性質は、本当に正確な数字を予測することはできません.両側の変化に関するネットワーク条件.デバイス負荷問題.多くのことは変化することができます、そして、私は私のポイントを証明するために数回テストを走らせることができました、しかし、私は異なる点を証明するのを好みます:何かがより良いので、それはあなたが毎回、チャートでそれを示すことができるというわけではありません.これは実際の生活ではなく、実験室です.

CSSのインラインライニング実験

ちょうどテストのために、私は、これがどんな種類の結果を与えるかについて見るために、主なCSSをホームページに提出しました.クリティカルパスでは、1つのSSL握手を削除したので、理論上、それはすべての滝のグラフに残って移動する必要があります.
私は、資産が造られたあと、CSSで液体部分を占めることによってそれをしました.JavaScriptのいくつかの行がトリックをしました:

const { writeFileSync, readFileSync } = require('fs');

const css = readFileSync('../app/assets/app.css').toString();
const fileContent = css.replace('./fonts/Gotham', '/assets/fonts/Gotham');
writeFileSync('../app/views/partials/layouts/head/inline-css.liquid', fileContent); 

インライニング結果


それは非常によくやった- HTMLとCSSは、722 msの直後に、最初のリクエストの中で1往復でロードされました.当分の間、我々は開発プロセスで複雑さのためにこの技術を生産に使用するつもりはない.ある日、私たちはこのプロセスを自動化するより良い方法を見つけるでしょう.

結論

タイトルから質問に答える:あなたはいつもあなたのウェブサイトのサイズを気にする必要がありますか?
はい.より大きなウェブサイトより大きいウェブサイトを持つことは、常によりよいです.今日の素晴らしい結果を得ることができない場合でも、良い結果は、小さな変更の多くから来て覚えておいてください.だからそれを一度に一歩.
あなたの2 MBの反応アプリから100 KBを削減している場合は、それについて強調しないでください.あなたの時間を過ごすより効果的な方法があります

怠惰な荷、

コード分割と非同期ローディング、

の木の揺れ、

重い枠組み、へのより良い選択肢

Cookoutを使用するCSSの移動

フォントを最小限に抑え、ローディング

を最適化する
それらのすべては、一度に1つのステップを実装するために比較的高速である間、ユーザーエクスペリエンスを改善するのに非常に効果的であると証明されました.

続きを読む

あなたがより多くのパフォーマンス指向のコンテンツに興味を持っている場合は、私に従って、私はあなたのウェブサイトを改善するためのオリジナル、または少なくとも効果的な方法を提供することを約束します.

既存のWebページでのWebPの使用

パウサウカワラルスキー・ Nov 17・ 4分読む

#webperf #design

Webのための画像の最適化

パウサウカワラルスキー・ 4月24日・ 8分読

#beginners #node

ウェブサイトの速度を維持する3つのヒント

パウサウカワラルスキー・ ジュン24・ 6分読む

#webperf #webpack #javascript #css