- ネットワーク読み込み
⑴DNSプリロード
dns-prefetch属性を使用すると、ブラウザはリソースまたはインターフェースに対応するサーバーのIPアドレスを事前に解決できるため、リクエスト内のDNS解決リクエストを回避し、リクエスト時間を節約できます。
ここで絵の説明挿入画像の説明を挿入し
、ここで
⑵CDNの加速
配信、帯域幅、サーバーのパフォーマンスに起因するアクセス遅延の問題を解決します。サイトの高速化、オンデマンド、ライブブロードキャストなどのシナリオに適しています。これにより、ユーザーは必要なコンテンツを近くで取得できるようになり、インターネットネットワークの混雑が解消され、Webサイトにアクセスするユーザーの応答速度と成功率が向上します。ここに
画像の説明を
挿入
CDNの利点を説明するためにここに画像を挿入：
ローカルキャッシュアクセラレーション、アクセスの高速化
ミラーサービス、オペレーター間の相互接続のボトルネックの影響を排除し、異なるネットワーク上のユーザーが優れたアクセス品質を確保できるようにする
リモートキャッシュサーバーの高速化、自動選択
帯域幅の最適化、ネットワークトラフィックの共有、プレッシャーの軽減、
クラスターの攻撃防止
costコストの節約
⑶リソースのプリロード
preload、prefetch、およびpreconnect属性を使用して、リソース取得リクエストを内部的に宣言的に書き込み、最初の画面ではないがより重要なリソースを事前にロードし、最初の画面が最初にロードされるときに他のそれほど重要でないリソースを無視しないようにすることができます。負荷;
http httpキャッシュヘッダーの設定
HTTPキャッシングには、強力なキャッシング（Cache-Control、Expire）とネゴシエーションキャッシング（最終更新、Etag）が含まれます。その中でも、プロトコルキャッシュリソースは毎回サーバーにリクエストを送信してリソースの有効期限が切れているかどうかを判断し、リソースの有効期限が切れていない場合は304を返します。ネットワークが非常にスタックしている場合、この304リクエストはページ全体のリソースの読み込みをブロックすることがあります。
Jモジュールと最初の画面の要件に従ってJSリソースのロードに優先順位を付け、必要に応じて不要なモジュールをロードします
モバイルネットワークのリソースは限られています。ユーザーが意味のある最初の画面をできるだけ早く表示できるようにするには、最初の画面にロードする必要のあるリソースをできるだけ小さくする必要があります。
the最初の画面のインラインキーCSS
最初の画面の主要なスタイルをページにインライン化して、基本的なスタイルの最初の画面ができるだけ早く表示されるようにし、ユーザー側で長時間の白い画面が表示されないようにします。
⑺インラインキーJSコード
インラインキーコードは、ページが初めて正常に読み込まれたことをユーザーに感じさせるためのものでもありますが、インラインコードはすべてのコードをHTMLにインライン化することはできません。これらのコードは毎回HTMLと共にダウンロードされ、HTMLファイルのサイズが大きくなるためです。また、コードは異なるWebページ間での多重化機能を提供できません。
serverサーバーが提供するリソースがGZIP圧縮を使用しているかどうかを確認します
GZIPはテキストリソース（JS、CSSファイル）の圧縮効率が高く、通常、ボリュームを70％削減できます。ただし、すべてのブラウザがgzipをサポートしているわけではありません。クライアントがgzipをサポートしているかどうかがわかっている場合は、リクエストヘッダーにAccept-Encodingがあり、圧縮のサポートを識別できます。クライアントのhttpリクエストヘッダーは、ブラウザがサポートする圧縮方法を宣言し、サーバー構成は圧縮、圧縮ファイルタイプ、および圧縮方法を有効にします。クライアントがサーバーにリクエストすると、サーバーはリクエストヘッダーを解析します。クライアントがgzip圧縮をサポートしている場合、リクエストされたリソースは圧縮され、レスポンスとしてクライアントに返されます。ブラウザは独自の方法でリソースを解析します。HTTPレスポンスヘッダーでは、 content-encoding：gzipを参照してください。これは、サーバーがgzip圧縮を使用することを意味します。
ここに画像の説明を挿入
resourceリソースのリダイレクトを回避
読み込み時間を長くすると、ユーザーエクスペリエンスが低下します。
thirdサードパーティの重要ではないコードの非同期遅延読み込み
モバイル端末のネットワークリソースは限られています。これらの重要でないコードが最初の画面のレンダリングに影響を与えないようにするために、少し遅れてロードすることができます。
ここに画像の説明を挿入
localローカルキャッシュ（sessionstorageおよびlocalstorage）を合理的に使用して、Cookieに不要なデータをすべて入れないようにします。
クライアントは多くのCookieを追加するため、要求されるたびにすべてのCookieがサーバーに送信されます。Cookieが多すぎると400エラーが発生します。
service Service Workerを使用して、ページのオフラインエクスペリエンスとページの読み込みエクスペリエンスを向上させ
ます。ページがリクエストを送信すると、最初にSWスクリプトを通過します。これにより、キャッシュする必要があるファイルをプログラムで作成し、同時にService Workerにキャッシュできます。オフラインでアクセスできます。
参照：https://segmentfault.com/a/1190000012353473?utm_source=tag-newest
conditions条件が許せば、HTTP2.0プロトコルを使用できます。
HTTP2.0プロトコルを使用すると、ネットワークリンクの再利用性が向上し、リソースの読み込み効率が向上します。http2.0と1.1の比較をご覧ください。
- HTML
tagsタグのセマンティクスに注意を払い、必要な機能を完了するために最も簡潔なタグを維持する
タグのセマンティクス（HTML5の新しいセマンティックタグを参照）は、コードの保守性を向上させ、ページがCSSのロードに失敗したときに醜くなりません。同時に、タグは最小限に抑える必要があり、無意味なタグは疑似クラスで表すことができます。
CSS CSSが頭に配置される場合、JSは本体の最後に配置され、JSとCSSの両方を頭に配置する必要があります。JSは前に配置されます。
ページ上のJSおよびCSSの位置は、他のリソース（imgなどの非jsおよびcssリソースを参照）の読み込み順序に影響します。理由は、注目に値する3つの点です。
jsはDOMを変更する場合があります。通常、document.writeが存在する可能性があります。つまり、現在のjsが読み込まれて実行される前に、後続のすべてのリソースのダウンロードが不要になる場合があります。これがjsがその後のリソースのダウンロードをブロックする根本的な原因です。
jsの実行は、最新のスタイルに依存する場合があります。たとえば、var width = $（ '＃id'）。width（）がある場合があります。つまり、jsコードが実行される前に、ブラウザはこのJS（外部または埋め込み）の前にすべてのcssがダウンロードして解決しました。これがcssが後続のjs実行をブロックする根本的な原因です。
最新のブラウザーはスマートで、プリフェッチを最適化します。パフォーマンスは非常に重要なため、最新のブラウザは競合しています。UI更新スレッドに加えて、後続のJSとCSSを事前にダウンロードするために別のスレッドが開かれます（事前にダウンロードされ、実行されないことに注意してください）。プリフェッチ最適化を使用すると、ブロッキングがない場合、場所に関係なく、jsおよびcssのダウンロードタイミングが理論的に非常に優先されます。
リファレンス：https://www.erdangjiade.com/topic/133487.html
https://www.jianshu.com/p/0291ad9ac8fb
⑶HTMLコードの圧縮、コメントと空白の削除
ネットワーク送信のファイルサイズを小さくしてください。
i iframeの使用は避けてください
iframe内のリソースのダウンロードプロセスは、親ページの静的リソースのダウンロードと、CSSおよびHTML DOMの解析をブロックします。ウィンドウのonloadイベントは、すべてのiframe（内部の要素を含む）が読み込まれた後にトリガーする必要があります。
- CSS
the CSSコードを圧縮し、重複するCSSスタイルを除外する
ネットワーク送信のファイルサイズを小さくしてください。
CSSコンポーネントに従ってCSSファイルをパッケージ化する
オンデマンドでロードし、ネットワーク転送のファイルサイズを減らします。
CSS CSS @import構文の使用を避ける
ページの読み込みをブロックする可能性があります。@ importによって参照されるCSSは、読み込まれる前にページがダウンロードされるまで待機します。したがって、インターネットの速度が制限されている場合、フレームのみが含まれ、スタイルのないWebページが読み込まれ、@ importには数の制限があります。
S Sass、Stylus、Lessなどの事前コンパイルされた言語を使用する場合、CSS
の解析効率を向上させるために、CSSのネストのコーディングは3レベルを超えません。
auto autoprefixerを使用して、CSSコードにプレフィックスを自動的に追加する
予期しないブラウザーの互換性の問題を回避するために、ブラウザーヘッダーの追加を自動的に支援します。
c cssワイルドカード（*）はできるだけ使用しないでください（特に、複数レベルのネストの最後）。
CSSの解析プロセスは、右から左への逆マッチングであり、CSSワイルドカードを使用すると、解析計算の量が増えます。
high消費量の多いスタイルを乱用しないでください
ボックスシャドウとボーダー半径の属性は、描画する前に多くの計算を必要とします。
- アニメーション
⑴シンプルなアニメーションは、変換、不透明度、遷移、およびその他の属性のみを使用して完了しようとします
幅、高さ、上、左、右、下、マージンなどの属性を変更すると、ページの再配置がトリガーされます。モバイル環境で頻繁に再配置すると、アニメーションがフリーズします。
⑵より複雑なアニメーションはcssフレームアニメーションを使用できます
モバイル端末での互換性、パフォーマンス、操作性が向上しています。
j jsアニメーションにはsetTimeout、setIntervalを使用せず、requestAnimationFrameを使用してください
SetTimeoutとsetIntervalは、アニメーションの実行でパフォーマンスの問題があり、フレーム数を正確に制御できません。
ここに画像の説明を挿入
5. JavaScript
⑴JSコード圧縮、コードサブモジュールの読み込み
コードサイズを削減し、ページ要件に従ってオンデマンドでリソースをロードし、ユーザーがロードする必要があるリソースのサイズを最小化し、ページ表示を高速化します。
long長いリストや多数のDOM要素を扱う場合は、あまり多くのイベントリスナーをバインドしないでください。
メモリを節約し、イベントエージェントの使用など、監視イベントの登録を減らします。
ページに追加されるイベントの数は、ページのパフォーマンスに影響します。追加するイベントが多すぎると、ページのパフォーマンスが低下します。イベントプロキシを使用すると、登録されたイベントの数を大幅に減らすことができます。
イベントの委任時に、特定の子孫要素が動的に追加され、それを再びイベントにバインドする必要はありません。
イベントに登録されたDOM要素が削除された後、そのイベントハンドラーがリサイクルされない可能性があることを心配しないでください。イベントハンドラーを上位レベルの要素に委任する限り、この問題を回避できます。
theスロットルおよびデバウンス機能を使用して、頻繁にトリガーされる機能を処理しますが、スクロール、タッチムーブなどの頻繁に実行される機能は必要ありません
無効な操作やページジャムが頻繁に発生することを避けてください。詳細については、シェイクとスロットルの記事をご覧ください：https://blog.csdn.net/zl13015214442/article/details/90600153;
set setIntervalの代わりにsetTimeoutを使用します
setIntervalには、ページがフリーズする原因となる命令の蓄積の問題がある可能性があります。
mass大量の再配置と再描画（リフロー）を避けるようにしてください
ページのリフロー、特にリフロー（リフロー）は非常にパフォーマンスを消費します。
- 画像
toolsツールを使用して画像を圧縮する
モバイル端末のネットワーク条件は限られています。画像が大きいほど、読み込み時間が長くなります。画像を圧縮するツールを適切に使用すると、画像の品質と画像サイズを考慮することができます。
higherより高い圧縮率のファイルwebp
webpなど、より高い圧縮率の画像を使用してください。同じ画質の場合、高圧縮率形式の画像サイズは小さくなり、ファイル転送をより速く完了し、ネットワークトラフィックを節約できます。ファイル転送のサイズを減らし、画像サイズの不適切な使用の問題を回避します。小さなアイコンは大きな画像を使用します。
Spスプライトを使用
CSSスプライトの基本原則は、Webサイトで使用されるいくつかの画像を1つの画像に統合することで、WebサイトへのHTTPリクエストの数を減らすことです。画像はCSSのbackgroundおよびbackground-positionプロパティを使用してレンダリングされるため、ラベルはより複雑になり、画像はラベルではなくCSSで定義されます。http要求の数を減らしますが、httpプロトコルが1.1、2.0にアップグレードされると、http要求の数を減らすSpriteの効果は明らかではありません。
pictures画像の遅延読み込み
ユーザーが多くの無駄なリソースを事前に読み込んでユーザートラフィックを浪費しないようにするには、遅延読み込みの実装に関するブログ投稿で詳細を参照してください。https：//blog.csdn.net/zl13015214442/article/details/88600300;
differentさまざまな画面ピクセル比率に応じてさまざまなサイズの画像を読み込みます
ピクセル比が大きい画面に小さいサイズの画像をロードすると、画像がぼやけます。ピクセル比が小さい画面に大きい画像をロードすると、ユーザートラフィックとCDNトラフィックが無駄になります。
2 2KB未満の画像はbase64形式で置き換えることができます
ページで使用される背景画像が多くて小さくない場合、画像をbase64コードに変換してHTMLページまたはCSSファイルに埋め込むことができるため、ページのHTTPリクエストの数を減らすことができます。画像を確実に小さくするために、2KBを超える画像にbase64埋め込みディスプレイを使用することは一般に推奨されないことに注意してください。画像をbase64形式に変換すると、http要求の数を減らすことができますが、base64アルゴリズムはファイルサイズを3分の1に増やすため、より大きいサイズの画像にはbase64形式を使用できません。
ここに画像の説明を挿入
7.フォント
theフォントサイズを圧縮し、無用なリソースをあまり読み込まないようにし、フォントスパイダーツールを推奨
ページで必要なフォントファイルのみが必要であり、ユーザーが必要としないトラフィック読み込みリソースを無駄にする必要はありません。
fontフォントの表示戦略を最適化する
font-displayプロパティを使用して、フォントのロードプロセス中にテキストが表示されない問題を回避します。
special特別なテキストの量が少なく、コンテンツが固定されている場合は、代わりに画像を使用することができます
迅速で完璧な復元インターフェース。