HTML5 パフォーマンス分析について開発者が知っておくべきこと_html5 チュートリアルのスキル

パフォーマンスの観点から見ると、HTML5 では、まず HTML ドキュメントを縮小して簡単にします。
まず、ユーザーの読みやすさという点では、もともと初心者が初めて見ると理解できない部分が多かったのですが、明らかにHTML5の宣言方法の方が使いやすいです。
2 番目に、HTML5 を使用すると、ドキュメントのエンコーディングの宣言が非常に簡単になります。多くの人が HTML5 とは何ですか? と尋ねます。現在、多くのページが依然として従来の方法を使用しているため、HTML5 を使用するにはまず DOCTYPE を変更する必要があります。 HTML5 メソッド自体は、IE6 から IE10 までの高度なブラウザを含む IE ブラウザと互換性があります。したがって、HTML5 を採用する最も簡単な方法は、DOCTYPE を変更することです。

1. より簡潔なタグ
次は、あまり一般的ではないかもしれませんが、私がお勧めするものであり、より簡単に使用できます。 . ラベル付け方法。名前からわかるように、HTML5 は HTML4 を継承しています。 HTML4 にはストリクト モードとトランジション モードがあり、HTML5 はこのトランジション モードをサポートしています。つまり、一部のタグを閉じることができません。ただし、すべてのタグを推奨するわけではありません。たとえば、BODY タグが閉じられていない場合は、これをお勧めしません。ただし、最も一般的に使用される P タグはリスト タグ LI です。なぜそう言えるのでしょうか? まず、視覚的な観点から言えば、この方法のほうが簡単です。次に重要なのは、文書転送プロセス中にコンテンツが少なくなるということです。
HTML5 タグの属性宣言は、単一括弧、二重括弧、および括弧なしの 3 つの方法をサポートしています。ドキュメントのサイズを減らすために、二重引用符を使用しない方法または単一引用符を使用する方法を選択します。ただし、「仮定」はクラス属性の宣言であることに注意してください。属性には複数のクラスが含まれる可能性があり、複数のクラスがある場合は括弧で囲む必要があるためです。この点に関して、Google の実践例を紹介しましょう。 Google 自体には、上記を完全に実装したページがあり、ドキュメントのサイズが 20% 削減され、HTML ドキュメントの送信が 20% 削減されています。すべてを実践すれば、5%から20%の削減が可能です。これは最初のステップであり、HTML ドキュメントのサイズを削減します。
2. 画像の最適化
次は画像の最適化です。写真が多いと、ページ全体の読み込み速度が著しく遅くなるからです。画像の最適化方法については、「ハイパフォーマンスWebサイト」という書籍で多く紹介されていますが、要約すると、スプライトの使用、画像のサイズの最適化、DATA URIの使用の3つです。 。
画像最適化のもう 1 つのアイデアは、画像なしです。画像を捨てて CSS3 を採用しましょう。元々は角丸効果のある画像を設定する必要がありましたが、現在は CSS3 で border-radius を使用しています。以前は影効果のある画像を設定する必要がありましたが、現在は CSS3 で box-shadow を使用しています。グラデーションを設定する必要がある背景画像であり、CSS3 で使用されるようになりました。
3. プリフェッチ
次に、最適化のもう 1 つのアイデアであるプリフェッチについて説明します。現在私たちが行っている最適化のアイデアはほんのわずかです。その多くは、文書のサイズを小さくしたり、写真のサイズを小さくしたりといった、縮小の観点からのものです。送信されるリクエストの数を減らすために、多くの画像がスプライト画像に変換されます。プリフェッチは別の考え方です。ユーザーがリソースをクリックすると、リソースはすでに読み込まれているため、確実に高速になります。
プリフェッチには 2 つの部分があります。1 つはリソースのプリフェッチで、もう 1 つは DNS の事前解決です。
リソースのプリロードについては、いくつか注意すべき点があります。
プリロードはブラウザがアイドル状態のときにのみ実行されますが、実行されるという保証はありません。これは非常に重要な点です。ブラウザ自体には内部インターフェイスであるグローバル リスナーがあるため、ブラウザがアイドル状態のときにブラウザが行うべき処理を実行しますが、このアイドル コールバックはトリガーされない可能性があるため、それが実行されるという保証はありません。プリロードが実行されます。
Chrome は HTTPS リソースのプリロードをサポートしていません。たとえば、Alipay が HTTPS ページである場合、Chrome はそれをプリロードしません。
プリフェッチされたページは存在しても表示されませんが、実際には正常に解析されています。ログイン ページをプリフェッチすると、ログイン ページには画像、CSS ファイル、JS ファイルなどの多くのリソースが含まれるとします。通常、解析プロセス中はこのページは表示されませんが、実際には存在します。 HTML5 では、現在のページの状態は document.visibilityState を通じて取得できます。通常、ページには表示と非表示の 2 つの状態がありますが、プリレンダリング状態と呼ばれる新しい状態が追加されました。 document.visibilityState が prerender と等しいかどうかによって、ページが事前レンダリング状態にあるかどうかを直接判断できます。
4.DNS解析
次にDNSの解析です。ログイン ページでは、ユーザーがクリックする可能性のある場所を検出するのが比較的難しい場合があります。もちろん、ユーザーの次のアクションのほとんどが内部に向かうものであることを確認するために調査を行うこともあります。ただし、場合によっては、ユーザーが次にどのページに移動するかはわかりませんが、どのドメインに移動するかはわかっています。現時点では、DNS を事前解決できます。実際には、ページ要求プロセス全体に長い DNS 解決プロセスが存在するため、これを事前に実行すると、ユーザーがこのページをさらに閲覧できるようになります。
以下はQの壁紙の例です。 Q 壁紙は Q の特定のシステムです。まず、Q のアーキテクチャ全体は WEB クライアントに基づいています。私たちが今見ているのは WEB ページですが、その中身は WEB です。初めてすべてのプロセスを完了したとき、画像が多かったので、すべての静的リソースが十数台の静的サーバーに割り当てられました。つまり、プルしたい場合は 10 個の DNS を解決する必要があり、これは非常に時間がかかり、最も遅い場合は数秒遅れることがあります。 DNS 事前解決を行うと、それがどのリソースであるかわかりませんし、すべての画像がランダムになるため、DNS 事前解決を頑張って速度を向上させる必要があるとしか言えません。この場合、2 秒かかる場合がありますが、1 秒かかります。
次にQのアプリケーションについて説明します。 QQ と Q には多くのテキスト リンクがあります。つまり、ウィンドウの左下隅に APP 情報のテキスト プッシュがあります。ここでは、Web を通じてバックエンドが時々引っ張られ、バックエンドが引っ張られてフォアグラウンドに表示されます。しかし、ある時期になると、すべてのアプリがプッシュする操作情報は固定されてしまいます。特定の APP に従って各テキスト リンクに対応する配列を分析すると、非常に大量のデータになります。最適化の観点から、ここでの各ファイルは約 300 ～ 400 バイトであるため、毎回これらのファイルをローカルに保存します。次に、それをローカルの localStorage に保存します。私たちは同じドメイン内にあり、APP 間のすべての情報に相互にアクセスできます。その後、プルされたすべての ID は再度プルされなくなります。
ここで注意が必要な点もあります。現在の多くのメーカーによる localStorage の実​​装は同期です。 localStorage インターフェイスを頻繁に呼び出すと、実際にはレンダリング プロセスがブロックされてしまいます。このとき、ユーザーがページを下にドラッグし、この時点でデータを保存していて、そのデータが比較的大きい場合、ユーザーはページが非常に行き詰まっていると感じます。彼らは以前にこの問題について議論しました。IE のインターフェイス設計は非同期ですが、IE の設計は同期です。これにより、ディスクにシリアル化するシリアル化プロセスが存在するため、このインターフェイスを調整するときに多数のプログラムがあることが想定されます。この場合、プロセス全体が遅くなるように見えます。さらに、localStorage 自体は、このデータを異なるウィンドウ間で共有でき、このデータをロックします。大量のデータがこのローカル インターフェイスを呼び出している場合、スタックしているように見えます。したがって、現時点では特に優れた解決策はありませんが、心に留めておくべきことはあります。現在の最大値が 5 メガバイトを超えているとしても、5 メガバイトを超えて使用すると、ユーザーは悲惨になります。なぜなら、これを言い訳にしてユーザーがマウスをドラッグすると、非常に行き詰まったように感じるからです。
5. オフライン ストレージ
次に、オフライン ストレージがパフォーマンスの面でユーザーにもたらすメリットについて説明します。 1 つ目は、オフライン ストレージの定義ファイルです。Q のすべてのシステム モジュールにはオフライン サポートが定義されています。これは、ネットワークが切断されてもすべてのアプリケーションを引き続き使用できることを意味します。 MANIFEST ファイルをドキュメントに追加します。MANIFEST は、現在のページのどの部分をローカルに保存する必要があるかを宣言する定義ファイルです。リクエストが失敗した場合に、どの部分を新しい画像などに置き換える必要がありますか? ? この方法は 3 つの部分に分かれています:
まず、CACHE、これはローカルに保存する必要があります。
次に、NETWORK はローカルに保存されません。毎回戻って要求されます。ただし、ここで注意しなければならないのは、ローカル ストレージとブラウザー ストレージは実際には 2 つの異なる場所に保存されるということです。 。ネットワークがアプリに毎回プルする必要があることを伝える必要がある場合でも、Chrome と同様に、そのストレージ キャッシュは非常に厄介で、完全に効果を発揮するには手動でクリアする必要があるためです。したがって、ローカルに保存しないように設定した場合でも、ブラウザは 2 つの異なる場所に保存するため、ブラウザ自体が保存する可能性があります。
3 番目、フォールバック。画像にリクエストが失敗したことが示されている場合、それは 404 です。代わりにどの写真を使用すればもっと楽しいと思いますか？
MAEIFEST の設定方法は次の 3 つです。
MANIFEST の同一オリジン制限。
その他の場合、MIME タイプは text/cache-manifest でなければなりません。フォーマットでは機能しません;
CHROME さん、これが効果的かどうかを確認したい場合は、疑似プロトコル CHROME (chrome://appcache-internals) を介してブラウザに入力してください。
アプリケーションキャッシュの更新方法について。オフライン ストレージがローカルである理由 ブラウザは、オフライン ストレージがあることを認識すると、まずオフライン ストレージ ディレクトリにアクセスして、リソースがキャッシュされているかどうかを確認します。キャッシュされている場合、リソースはここから直接取得され、別のリクエストは送信されません。ブラウザのリクエストはこんな感じなので、オフラインストレージがあるとリクエストすら送信されないので高速になります。 時々更新する必要がある場合、更新時に何をすべきですか?
ユーザーはブラウザのキャッシュを手動でクリアでき、この時点でローカル ストレージも自動的にクリアされます。
MANIFEST の内容を変更する これは推奨される方法であり、オンラインでも使用されます。つまり、内部の特定の項目を変更できますが、公開するたびに、上のコメントを変更するだけで自動的に公開される仕組みになっているため、ここでコメントを変更するのが最善です。この場合、コンテンツが公開されるたびに、ローカル クライアントにリアルタイムで同期されます。
これはプログラムを通じて実行され、プログラムは window.applicationCache.update() です。つまり、オフライン ストレージを運用したいと考えています。実際、セマンティクスがアプリケーション ストレージであるため、私はそれをアプリケーション ストレージと呼ぶこともあります。アプリケーションストアを手動で更新しましょう。
6.Web Worker
次に Web Worker です。 Web Worker はマルチスレッド JS プロセスです。実際、オンラインにはアプリケーション シナリオがないため、説明しません。ただし、私がこれまで見てきた特定のアプリケーション シナリオについては話すことができます。
まず、WEBWORK とは何かを紹介します。これは OS レベルのスレッドです。マルチスレッドを模倣する前に、実際にはもう 1 つのウィンドウを開きました。しかし、現在はブラウザ自体がそれを提供するため、操作がより便利になりますが、ドキュメント全体が重くなります。これはあまりお勧めできる方法ではありません。
その場合、WebWorker のアクセス機能は制限されており、多くのグローバル オブジェクトにアクセスできません。たとえば、documnet オブジェクトにアクセスできません。 WebWorker に最も適したシナリオは、CPU を集中的に使用するコンピューティング操作です。以前ゲームを作っていた時はBOX2Dを使っていました。ページ全体で、以下のすべてのオブジェクトの衝突関係を計算する必要があり、この計算量が非常に大きいということを聞いたことがある人も多いと思います。しかし、現状のJSプロセスで実行すると計算量が膨大になり、ページ全体が滞ってしまいます。しかし、WebWorker を使用してこれを行う場合、それは非同期プロセスであり、リアルタイムで送信され、計算プロセス中に他のことを行うことができます。これはマルチスレッドです。
7. デバイス API
デバイス API について説明します。デバイス API はパフォーマンスの点で最も重要であると考えており、現在実装されている最も初期の API でもあります。 1 つは CONNECTION、つまりネットワーク帯域幅です。これは何を意味するのでしょうか? 中国のこのシナリオでは、多くのユーザーのインターネット速度が依然として非常に遅いことを覚えておく必要があります。ネットワーク速度が遅い場合、ユーザーが自動的に下位プランにダウングレードできるようにしたいと考えています。既存の技術ではそれはできません。ただし、デバイス API は使用できます。この情報はデバイスから取得できることがわかっているからです。その帯域幅はどれくらいですか?その帯域幅で何ができるでしょうか?たとえば、ブロードバンドが良好な場合は、高解像度の画像を使用します。帯域幅が比較的低い場合、解像度の低い画像が使用されます。
8. バッテリー
次はバッテリーについてです。パフォーマンスの観点から見ると、主にパワーが重要だと思います。ユーザーのバッテリー残量が比較的少ない場合は、できる限り何もしないほうがよいと思います。携帯電話のバッテリー技術にはこれまでにない進歩があり、APP をより高性能に見せることも宣伝のハイライトだと思います。
9.CANVAS
次はCANVASです。 CANVAS のパフォーマンス最適化のポイントをいくつか紹介します。これらを使用すると、パフォーマンスが 10 倍向上します。
まず、各 CANVAS はグラフィックをレンダリングするときにレイヤー化できます。 PS と同様に、1 層、2 層、3 層があります。多くのユーザーがゲームを作成する場合、すべてを 1 つのレイヤーに直接配置し、更新されるとすべてが更新されます。ただし、レイヤー化する場合は、背景レイヤーに背景を配置し、キャラクターレイヤーにキャラクターを配置します。この場合、キャラクターを更新したい場合はキャラクターのみが更新され、背景レイヤーを変更する必要はありません。 CPU の仕事を減らすと、パフォーマンスは自然に向上します。
2 番目は context.drawImage です。画像を拡大縮小しないでください。アーティストが作成した画像は常に私たちの画像と一致しませんでした。デバイス自体の画像サイズはこのようなものなので、画像を比例して拡大縮小する必要があります。画像を拡大してみると、iPad や iPhone などのローエンド デバイスでは非常にスタックすることがわかりました。なぜこの方法を使用すると、時間がかかるのかを考えました。
3 番目、requestAnimationFrame。これは、レンダリング用に特に最適化された方法です。その原理は、ブラウザがフレームを渡すたびに、このメソッドがトリガーされ、ブラウザが次のフレームを実行する準備ができていることを取得します。従来の方法を使用すると、それ以上のことは考慮されず、経過時間だけがわかり、それを実行します。ユーザーが以前にブロックされており、このメソッドが 10 秒ごとに 10 秒以内に実行される場合、そのユーザーの以前の作業は実際には完了していないため、この作業は遅れます。各フレームで何かを実行できることが通知されるため、アニメーションがよりスムーズに見えるように最適化されています。 (文: infoq)