フロントエンドのパフォーマンス最適化 - フロントエンドエンジニアが話し合うべき問題点

はじめに<br />前回の記事「私の CSS アーキテクチャコンセプト」では、公園で友人たちの親切のおかげでずっと勧められ、小さなフロントエンドエンジニアの私は驚き、興奮し、そしてパニックになりました。私が心配しているのは、私の資格が限られており、知識が不足しており、若者を誤解させてしまうのではないかと非常に恐れていることです。これが真実だ！しかし、時間があるときは記事を書き続けるつもりです。要約できるだけでなく、新しい知識を学んで皆さんと共有することもできます。共有することは価値のあることだと私は信じています。インターネットがカラフルであるのは、そのためではないでしょうか。

前の記事のコメントで、多くの友人が HTTP リクエストに関する私の CSS アーキテクチャについて質問しました。私はそれに答えたいと思っていましたが、どこから始めればよいかわかりませんでした。私はフロントエンドのパフォーマンスについて深く理解していません。リファクタリングに関する本を1、2冊ざっと読み、情報を調べ、専門家が書いた記事を読みました。彼らのやり方は理にかなっていると思ったので、彼らが学んだことをコピーして使用し、要約をいくつか作成して、この記事が生まれました。これらはどれも新しいものではありませんが、たくさんの小さな知識が含まれているため、そこに書かれていることが皆さんが探している答えを与えてくれることを願っています。

フロントエンドのパフォーマンス最適化 - フロントエンドエンジニアが語らなければならない悩み
1.html、css、jsが分離されます。しっかり分離してください！なぜこの3つを分離する必要があるのかは皆さんも理解されていると思いますので、詳しく説明はしません。
2. CSS をインポートする方法。 CSS では @import ではなく link が使用されます。これは、IE では @import ディレクティブが HTML の下部に link タグを記述することと同等であり、CSS の読み込み時間が長くなり、ファイルのダウンロード順序も変更される可能性があるためです。
3. jQuery を合理的に扱う。 jQuery を使用すると、「より少ない記述で、より多くのことを実現」できます。強力なセレクター、DOM 操作の完全なカプセル化、完全な Ajax、優れた互換性処理など、多くの利点があります。しかし、私たちは本当にそれから切り離せないのでしょうか?それは需要とビジネスロジックに基づくべきだと思います。わずか数行または数十行の js コードでページを実現できる場合、なぜ jQuery を使用するのでしょうか?最初にページに jquery.js をロードさせてから、独自のコードを記述しますか?それは必要ありません。
4. ページのコンテンツを適切にレイアウトします。 DOM の読み込み順序は上から下です。CSS に遭遇したら CSS を読み込み、JS に遭遇したら停止し、JS を読み込んで解析します。ページをレイアウトするときは、最初にメインコンテンツを表示し、重要なコンテンツを上部に配置して、ブラウザで最初に解析させる方がよい解決策です。
5. js をインポートする方法。「JavaScript キングの帰還」では、js インポート方法の長所と短所を比較します。個人的には、JS コードの再利用とメンテナンスを考慮せずに (ただし、これが最も重要な指標になることが多い)、重要なビジネスモジュールを含む JS コードはタイトルに配置し、操作効果のある二次的な JS コードは DOM 内の対応するオブジェクトの後に配置するべきだと考えています。これを行うための理論的根拠は、DOM の読み込み順序です。上記の記述は理解しにくいです。例えば、

上の写真は、QQ Music のホームページのナビゲーションを示しています。メインナビゲーションの重要性は明らかです。以下は対応する 2 つのコードです。

コードをコピー

コードは次のとおりです。

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<ヘッド>
<meta http-equiv="コンテンツタイプ" コンテンツ="text/html; charset=utf-8" />
<title>test--js インポート方法 1</title>
<script type="text/javascript">
</スクリプト>
</head>
<本文>
<ul>
<li><a href="">ホーム</a></li>
<li><a href="">ミュージックライブラリ</a></li>
<li>
<a href="" id="mv">MV</a>
<divクラス="">
<a href="">MV の推奨事項</a>
<a href="">MV ライブラリ</a>
<a href="">音楽シーン</a>
<a href="">MVスペシャル</a>
</div>
</li>
<li><a href="">私の音楽</a></li>
<li><a href="">クライアントをダウンロードする</a></li>
</ul>
</本文>
</html>

コードをコピー

コードは次のとおりです。

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<ヘッド>
<meta http-equiv="コンテンツタイプ" コンテンツ="text/html; charset=utf-8" />
<title>test--js インポート方法 1</title>
</head>
<本文>
<ul>
<li><a href="">ホーム</a></li>
<li><a href="">ミュージックライブラリ</a></li>
<li>
<a href="" id="mv">MV</a>
<divクラス="">
<a href="">MV の推奨事項</a>
<a href="">MV ライブラリ</a>
<a href="">音楽シーン</a>
<a href="">MVスペシャル</a>
</div>
</li>
<li><a href="">私の音楽</a></li>
<li><a href="">クライアントをダウンロードする</a></li>
</ul>
<script type="text/javascript">
</スクリプト>
</本文>
</html>

2 つのコードの js 効果は、マウスが MV メニュー項目に移動したときにサブメニューオプションを表示することです。最初のコードセグメントでは、ブラウザーが <script> タグを解析すると、解析が完了するまで停止し、その後、続行されます。MV が表示されたら、マウスをその上に移動するとすぐにサブメニューが表示されます。2 番目のコードセグメントでは、ブラウザーが MV を解析し、次に <script> を解析するときに、最初に js を読み込む必要があり、それが完了するまでサブメニューは表示されません。明らかに、このような重要な機能モジュールの場合、最初のコードの方が適しています。この原則に関して、私の理解に逸脱や誤りがあるかどうかはわかりません。これについて詳細な研究を行った庭の友人は、私を訂正してください。

6.画像ファイルの形式を選択します。この点に関しては、Taobao UEDの画像フォーマットとデザインについて非常に詳細な議論があります。個人的には多くの恩恵を受けたと感じていますが、記事が長すぎて詳細すぎて、本当に忍耐強くなければ読めないので、後で自分で要約しました。画像ファイル形式の次の3つの選択肢を参考にしてください。この記事を要約した後、私は仕事の際にはそれを厳守しました。

7.スプライトマッピング技術。これは登場以来議論を呼んでいる技術です。まず、PSを開いて、たくさんの小さなアイコンを整然と並べる必要があります。次に、PSを開いて、5倍に拡大してから、2本の参照線を水平と垂直に引き下げ、定規に合わせ、左/上の値を書き留めて、CSSファイルに書き込むのが最適です。3番目に、スプライトマッピング技術は、高さと行の高さに密接に関係しています。それらのため、2番目のポイントに配置された左/上は不正確になります。このとき、アイコンの間に一定の隙間を残す必要があります。そうしないと、アイコンの半分しか表示されないことに注意してください。自分が正しいことを証明するためにスクリーンショットを撮ったりコードを書いたりする気力は本当にありませんが、自分でやることはできます。私はこの技術を軽視していたようで、デイブ・シーは恥ずかしい思いをしているようです。テクスチャ技術が今でも広く使われている主な理由は、リクエスト数を大幅に削減し、画像の合計サイズをある程度まで削減できることだと思います。これら 2 つの点と比較すると、先ほど述べた欠点は取るに足らないものに思えます。

8. ページを段階的に強化します。プロジェクトの解像度、オペレーティングシステム、ブラウザー、および対象ユーザーグループを組み合わせ、ページ作成プロセスでプログレッシブエンハンスメントの原則を採用します。プロジェクトの対象ユーザーグループが一般的に 1024*768、Mac OS X、IE7+ ブラウザを使用している場合、ページを設計するときには、それに応じて幅を制限し、水平スクロールバーがないのが最適です。フォントは Songti ではなく、他の Web セーフフォントを使用する必要があります。そうすれば、IE6 を考慮する必要がなくなるので、私たちは幸せです。仕事が突然とても楽しくなったと感じませんか?プログレッシブエンハンスメントは、全体像だけでなく、単一ページモジュールにも適用できます。

（図1）

（図2）
図 1 と図 2 は、リスト内の li のスクリーンショットです。図 2 は、マウスを li の上に移動したときの効果を示しています。「フォロー解除」と表示されます。このモジュールでは、プログレッシブエンハンスメントの原則を適用します。まず、IE6を考慮する必要があります。IE6はaタグ以外のタグのホバー効果をサポートしておらず、「unfollow」は重要な機能であるため、これなしでは実行できないため、マウスインとマウスアウト効果を実現するにはjsコードを使用するしかありません。2番目に、IE6を考慮しない場合、「unfollow」のタグがspanであると仮定すると、CSSスタイルシートに次のように記述できます。li:hover span{display:block;};3番目に、「unfollow」機能を時間表示などの無関係なテキスト表示に置き換えると、2番目の記述方法も使用できます。これにより、他のブラウザーで表示でき、IE6で表示されなくても大きな影響はありません。

9. フィルター、表現、ハックの使用を減らします。これは多くのリファクタリングの本で言及されています。プロジェクトではフィルターがテストされています。フィルターが適用された写真の壁がある場合、ブラウザはページの読み込みが非常に遅くなります。私は自分の目でそれを見ました!表現は不明です。私は最初からハッキングを避けており、ほとんど使用したことがないので、コメントはありません。

10. 外部アプリケーションを使用して、CSS および JS ファイルへのリクエストの数を減らします。 PHP プログラマーは、minify を使用して各ページの CSS と JS を統合し、ページ内で呼び出すことを検討できます。この方法では、ページは CSS と JS を 1 回だけ要求し、パフォーマンスが大幅に最適化されます。
今のところ私が思いつくのはこれだけです。フロントエンドのパフォーマンスを最適化するには、他にも多くの方法があります。これらは基本的なものにすぎません。これからゆっくりと詳しく説明していきます。さて、別の話をしましょう！

フロントエンドおよびアートスタッフ<br />フロントエンドエンジニアは、上位のアートデザイナーに報告し、下位のバックエンドエンジニアと連携し、製品によってサポートされるため、いずれも欠かすことはできません。責任分担は明確でなければなりません。フロントエンドデザイナーは、アーティストに対して、使用する画像をできるだけ少なくすること、画像のファイル形式を合理的に選択すること、Web サイトのページのスタイルをできるだけ一貫して維持すること、Web サイトにメインのビジネスリンクの色、セカンダリリンクの色、メインテキストの色、その他のテキストの色などを指定することなどを指示する必要があります。アートワークは1ページ分だけ行うため、ウェブサイト全体の最終的な効果を考慮することは不可能な場合が多いです。このとき、フロントエンドは促す役割を果たす必要があります。このリンクで何を決定する必要があるかが決定されないと、バージョンを修正するのは非常に苦痛になります。

フロントエンドおよびバックエンド担当者<br />命名方法を明確に伝え、フロントエンドの CSS、JS、およびイメージのディレクトリ構造定義の考え方をバックエンド担当者に説明し、バックエンドの動作原理を理解します。

フロントエンドとプロダクトマネージャー<br />どのような立場の人にとっても簡単なことではありませんが、プロダクトマネージャーにとってはなおさらです。最終的に、プロダクトマネージャーが製品の責任者となります。そのためかどうかは分かりませんが、私が会ったプロダクトマネージャーは皆、非常に細心の注意を払っています。中には、プロトタイプのレンダリングが 2 ピクセルか 3 ピクセル違うかどうかがわかるほど細心の注意を払っている人もいます。プロダクトマネージャーが細部にこだわりすぎると、フロントエンドは惨めなものになります。このような状況にどう対処すればいいのでしょうか?プロダクトマネージャーのように、製品とユーザーの観点から問題を考えます。決して個人的な立場から問題を考えてはいけません。そうしないと、彼を説得することは決してできません。もちろん、これは少し難しいですが...
ようやく話が終わりましたので、プログラム設計に関するいくつかの考えをまとめます。プログラムは人生のようなもので、時には妥協が必要です。リクエスト数を減らすためだけにコードのメンテナンスを無視することはできません。2M を使用するユーザーと 10M を使用するユーザーに同じ処理方法を使用することはできません。Web サイトの訪問数も考慮する必要があります。最適なソリューションを見つけるには、複数の側面を検討して比較検討する必要があります。これが最も合理的なことだと思います。

<<: MySQL はどのようにしてマルチバージョンの同時実行性を実現するのでしょうか?

>>: CSSのclip-pathプロパティを使用して不規則なグラフィックを表示する