パフォーマンスの最適化に関する簡単な説明_html/css_WEB-ITnose

知らないうちに、私は正式にブログを始めて半年以上経ちましたが、私と一緒に成長していけたらと思っています。半年以上勉強と仕事をしてきた中で、自分の才能や知識が浅いのと同時に、フロントエンドの知識が広く深いと感じることが増えてきました。

この概要は主にパフォーマンス最適化の探索体験についてです。レベルは非常に浅いので、学んだことについてだけ話します。

************ここから始まります*******************

すべてのフロントエンド私が読んだ開発書にはこう書かれていました。パフォーマンスの最適化を 4 つの単語で文字通り説明すると、システムの正確さに影響を与えることなく、システムの実行を高速化し、特定の機能をより短時間で完了することです。この文から、パフォーマンスの最適化の目的、つまり高速化、時間短縮がわかります。

1) パフォーマンスの最適化の重要性は何ですか?

Google のデータによると、10 個のデータを含むページは 0.4 秒で読み込まれるが、30 個のデータの読み込み時間が 0.9 秒になると、トラフィックと広告収入が 20% 減少します。 Google マップのホームページのファイル サイズを 100 kb から 70 ～ 80 kb に削減したところ、トラフィックは最初の 1 週間で 10%、次の 3 週間で 25% 増加しました。 Tencent のフロントエンド エンジニアは、長期的なデータ監視に基づいて、ページが 1 秒遅れると PV が 9.4% 低下し、直帰率が 8.3% 増加し、コンバージョン率が 3.5% 低下することも発見しました。両社は業界のリーダーであり、非常に大規模なユーザー ベースを抱えており、パフォーマンスの最適化に注意を払うにはこれらのデータが十分です。ほぼ 80% のユーザーが許容できる応答時間は、500PC のメイン サイトを開いてリソースを読み込むのにかかる時間は 5.67 秒、QQ 宝くじは 12.75 秒、NetEase 宝くじは 16.79 秒です。これを見ることができてとても光栄です *_*。

2) 最適化するにはどうすればよいですか?

データ表示とブラウザーのデバッグ分析により、ページを開く速度がブロードバンド速度 (一般にネットワーク速度として知られる)、Web サーバー、ページ構造の 3 つの理由と密接に関係していることがわかりました。表 1 に参加できます:

表 1. 開く速度に主に影響を与える 4 つの要因の分析

ユーザーエクスペリエンス

主要影响因素	作用原理	影响
宽带速率	接收响应、连接速度减慢	连接变慢
服务器	宽带限制或者服务器请求响应最大限制、硬盘故障、网卡故障	等待时间延长
页面结构	导致重绘和白板屏	用户体验

主な影響要因

行動原則

影響

ブロードバンドrate

応答を受信中、接続が遅くなります

接続が遅くなります

サーバー

帯域幅制限またはサーバー要求応答の最大制限、ハードディスク障害、ネットワークカード障害

拡張待機時間

ページ構造

再描画とホワイトボード画面の原因

-----サーバー-----

ページが開かれると、ブラウザーとサーバー (Web のみを指します) が山に向かって叫び、自分の応答を待つようなものです。サーバー) http プロトコル プロセスを通じて通信します。サーバーへの影響は、サーバーのパフォーマンスとハードウェア構成にも分けられます。ここでは、ブラウザが Web ページをロードしてレンダリングするプロセスを簡単に見ることができます。図 1 を参照してください。

図 1. ブラウザの動作原理

図からわかるように、要求されたリンク www.500.com があり、DNS 分析によりマッピングされた IP アドレス (A として記録) 192.168.18.58 が見つかり、接続後、ブラウザはこの IP アドレスに接続します。成功すると、HTTP プロトコルを通じてリクエスト ヘッダー情報が A が存在するサーバーに送信され、Web サーバーはリクエストを受信して​​処理を待機し、処理後にブラウザに応答します。このとき、ブラウザは HTML コードの表示を開始し、css/image/js のアドレスを取得し、再度 DNS にリクエストを行ってそれを取得し、ページのレンダリングを開始します (スタイル、アニメーションの実装はよく知っています)。 、など）。これは論理的であり、実際の状況は、一般に Web インスペクタとして知られるブラウザのデバッガで確認できます (現在は、Safari の Web インスペクタ、IE の開発者ツール、Firefox の FireBug、および Opera の Dragonfly のみです)。ここでは Firefox の Firebug を使用します。検索バーに www.500.com と入力すると、傍受されたリクエストの 1 つの期間の詳細が図 2 に表示されます。 500 宝くじメイン サイトの特定の時間 リクエスト時間の詳細

写真からわかるように、ドメイン名解決は 16 ミリ秒で開始され、0 ミリ秒続きました。IP への接続は 16 ミリ秒で開始され、31 ミリ秒続きました。 IP が位置するサーバーに送信し、サーバーを待機するのに 0 ミリ秒かかりました (なぜ待たなければならないのか知りたいですか? 最後の追記を参照してください)。応答に 47 ミリ秒、受信したデータを送り返すのに 0 ミリ秒かかりました。サーバーの影響でフロントエンドの読み込み時間がかなりかかりますが、これも客観的にはサーバーとバックエンドのDB設計に依存しているようです。ただし、http リクエストの数に関しては、フロントエンドは確かにそれを行うことができます。

http リクエストを減らすにはどうすればよいですか?上記の分析に基づいて、画像、CSS、および JS リンクはすべて http リクエストを発行することがわかり、自然にリソースをマージすることを考えることになります。実際、私たちもこれを行います。画像は画像スプライトで処理でき、CSS は

図 3. 500 メイン サイトの結合画像

最初にスタイル ファイルのプロジェクトに取り組み始め、css をbase.css、public.css、style.css、header.css に分割しました...これはスタイルの構造を確認するのに非常に役立つことを認めなければなりませんが、後で気づきました。ユーザーにとって貴重なロード時間を犠牲にしてしまいました。今は 2 つの CSS リンク以下に保つように厳密に制御しています。追加の js リンクを避けるために、厳密なタイムフレーム要件がないアニメーションは CSS3 で記述されることになり、これも変更です。ここで、元の散乱した CSS リスト、悪用された JS リンク、および膨大な数の画像について考えてみましょう。これは悲惨です。

-----ブロードバンド速度-----

ブロードバンド速度とは、簡単に言えば、速度が大きいほど、アップロードとダウンロードの速度が速くなります。 2014 年の統計によると、中国の固定ブロードバンド ユーザーの平均インターネット速度は 199.3kb/s で、200kb/s に基づいて計算すると、2M ブロードバンドの理論上の速度は 256kb/s であることがわかります。中国のネットユーザーの速度は約 2M です。

ページの総リソースを約 500 kb に保つことができるようになりました。その場合、ユーザーはその使用時に平均 500/200=2.5 秒を費やすことになります。ネットワーク速度が遅い場合、影響はさらに大きくなります。 。

図 4. 世界インターネット会議

今年 12 月 16 日に江武鎮で開催された「第 2 回世界インターネット会議」で、習総書記は次のように述べた。 「ブロードバンド中国」戦略。2020 年までに完全にカバーされる予定です (美しい写真を添付し​​ます -_-)。ブロードバンド速度の将来は比較的楽観的ですが、現在のフロントエンドでできることは、Web ページの合計サイズである分母の値を減らすことです。

リソースの総量を減らすにはどうすればよいですか?頭に浮かぶのは「プレッシャー」の一言です。ページを書き込むときは、コードの数を減らし、冗長性をできるだけ少なくします。書き込み後、圧縮ソフトウェアを使用してコードを整形し、画像を圧縮して総リソース サイズを削減します。

そこで、非冗長コードの標準とは何なのかという疑問が生じます。一般的に、プログラムは与えられたタスクを実行できますが、最適化後は目的も達成でき、実行時間とコード数が減少します。これは、削除されたコードがプログラムの冗長コードであることを示します。実際のプロジェクトでは、スペースの占有を避けるために、複数のスタイル名で同じスタイルのほとんどを使用せず、重複したスタイルを共通のクラスにマージし、無駄なタグを削除してください。一般に、コードが繰り返されていないということは、冗長ではないことを意味します。以前のプロジェクトでは、2 つの DOM ノードを区別するために、ノードに空のラベルを付けていたことがありましたが、これによりリソースの総量も増加しました。

-----ページ構造-----

ページ構造とは、ページ上の要素の順序を指します。ページ構造が読み込み速度に与える影響は、ブラウザがページを読み取る順序によって決まります。図 1 からわかるように、ブラウザはまず HTML コード構造を解析し、次にページをレンダリングします。ブラウザが HTML をロードして表示するときは、上から下にロードされ、レンダリング シーケンスも上から下に行われます。ダウンロードとレンダリングは同時に行われます。意味的に解釈可能なタグ埋め込みファイル (JS スクリプト、CSS など) が見つかった場合、ダウンロード プロセスでは、ダウンロード用に別の接続が有効になります。ダウンロード後に解析し、解析中はすべての要素のダウンロードを停止します。解析が完了するとレンダリングが開始されます。 JS または CSS で再定義が行われた場合、後で定義された関数が以前に定義された関数を上書きします。 HTML ページのロードおよび解析プロセスの詳細を以下の図に示します。

図 5. HTML ページのロードおよび解析プロセス

図からわかるように、 html は上から下に続きます。ページの解析とレンダリングの順序。通常は解析 1 回 + レンダリング 1 回です。再描画を減らすために、一部のブラウザは CSS ファイルが読み込まれた後にページをレンダリングします。このとき、ユーザーは白い画面に直面して人生について考えるでしょう~_~。コンテンツが大きく、ネットワーク速度が遅いと、ホワイトボードの時間が長くなります。ページの読み込み時に少なくともユーザーに何かが表示されるようにするには、HTML の先頭に CSS を配置することがユーザーに配慮する方法です。 dom ノードでの操作性のため、js は html と並行してダウンロードして解析することができません。つまり、スクリプトがヘッド内にあると、ページのレンダリングが妨げられ、ユーザーは呆然とホワイトボードを見つめ始めることになります。現在、DEFER 属性を使用してブラウザに並列ダウンロードを通知できますが、一部のブラウザではこの属性が認識されない可能性があり、DEFER を使用すると document.white() を HTML の最後に配置することでスクリプト ブロックの問題を本質的に解決できます。ロード時間。

-----概要-----

1) http リクエストを削減します

2) リソース (css、js、画像) をマージします

3) 画像を圧縮し、コーディング

4) 再描画を減らす

5) CSS を先頭に配置し、JS をフッターに配置