開発者がHTML5パフォーマンス分析について知っておくべきこと

コメント：次の記事は、Zhang Limingという名前のIT技術者によって書かれ、InfoQ Webページに掲載されました。今回、彼は全文の9つの異なる側面からHTML5のパフォーマンスを分析しましたが、これは対応する開発者がまだ読む価値があります。

第一に、ユーザーの読みやすさの観点から見ると、これらのことを見るために初めて初心者が理解していなかった多くのことがあり、HTML5宣言方法は明らかにユーザーにより優しいものです。

第二に、宣言をコードするドキュメントは、HTML5にある場合、非常に簡単です。多くの人がHTML5とは何かを尋ねますか？多くのページがまだ従来の方法であるため、最初にHTML5を使用できる方法は、最初にDoctypeを変更することです。 HTML5メソッドはIEブラウザと互換性があり、IE6からIE10からIE10に使用でき、高度なブラウザでサポートできます。したがって、HTML5を採用する最も簡単な方法は、Doctypeを変更することです。

次のことはあまり一般的なものではないかもしれませんが、よりシンプルなラベル法を使用して、私が好むものです。この名前からわかるように、HTML5はHTML4から継承されます。 HTML4には、厳密なモードと遷移モードがあります。 HTML5はこの遷移モードをサポートしているため、いくつかのタグを閉じることはできません。ただし、すべてのタグをお勧めしません。たとえば、ボディータグが閉じられていないため、推奨されません。しかし、最も一般的に使用されるP-LabelもList Tag Liです。なぜこれを言うのですか？まず第一に、視覚的な観点から見ると、この方法は少し簡単です。次に、ドキュメント転送プロセス中にコンテンツが少なくなることです。

HTML5タグ属性の宣言は、シングルブラケット、ダブルブラケット、枝分かれしていないブラケットの3つの方法をサポートしています。ドキュメントのサイズを減らすために、二重引用符または単一の引用なしにメソッドを選択しました。ただし、属性には複数のクラスが含まれる場合があり、複数のクラスが括弧内に囲まれている必要があるため、クラスの属性の宣言であると仮定すると、それは注意する必要があります。この点で、Googleの練習をお見せしましょう。 Google自体には、上記を完全に練習するページがあり、ドキュメントのサイズを20％削減し、HTMLドキュメントの転送を20％削減します。全体が実践されている場合、5％から20％の減少を達成できます。これが最初のステップであり、HTMLドキュメントのサイズを縮小します。

次は写真の最適化についてです。これは常に愛と憎む要素です。写真が多すぎると、ページ全体の読み込み速度を真剣にドラッグするからです。写真の最適化方法に関して、本「High Performance Webサイト」には多くの紹介があります。要約すると、3つの主なポイントがあります。エルフの使用、写真のサイズの最適化、データURIの使用です。ここでは詳しく説明しません。

画像の最適化のもう1つのアイデアは、イメージなしです。写真を放棄し、CSS3を受け入れます。もともと、私は丸い角効果を持つ写真を設定する必要がありましたが、今ではCSS3で国境とラジウスを使用しました。私は写真をシャドウ効果で使用しましたが、今ではCSS3でBox-Shadowを使用しています。以前はグラデーションの背景画像を設定していましたが、今ではCSS3でグラデーションを使用しています。

3。プレフェッチ

次に、プリフェッチについて説明しましょう。これは最適化のもう1つの方法です。私たちの現在の最適化のアイデアは少数に過ぎません。それらの多くは、より少ないものの観点からのものです。たとえば、ドキュメントのサイズが以前に縮小され、画像サイズが縮小されました。送信リクエストの数を減らすために、多くの写真がエルフになります。プリフェッチのために、それは別の考え方です。リソースを早期にロードします。ユーザーがポイントに進むと、実際にロードされたため、間違いなく速くなります。

プリフェッチには2つの部分があります。1つはリソースのプリフェッチで、もう1つはDNSの事前分解です。

リソースのプリロード時に注意すべき点がいくつかあります。

プリロードは、ブラウザがアイドル状態の場合にのみ引っ張られますが、それをプルすることは保証されていません。これは非常に重要なポイントです。ブラウザ自体には、内部インターフェイスであるグローバルリスナーがいるためです。ブラウジングエアがアイドル状態にある場合、アイドル状態の場合はブラウザが実行されますが、このアイドルコールバックはトリガーされない可能性があるため、プリロードが実行されることを保証しません。

Chromeは、HTTPSリソースのプリロードをサポートしていません。たとえば、AlipayはHTTPSページであり、Chromeはプリプルしません。

事前にプルされたページは存在した後は見えませんが、実際には正常に解析されています。ログインページを事前にプルすると、ログインページには、写真、CSSファイル、JSファイルなどの多くのリソースがあります。通常は上から下まで解析されます。解析プロセス中、このページは表示されませんが、実際には存在します。 HTML5では、document.visibilityStateを使用して現在のページステータスを取得できます。通常、ページには目に見える2つの状態がありますが、現在はプレレンダリング状態と呼ばれる新しい状態があります。 document.visibilitystateがプレレンダーに等しいかどうかにより、ページがプレレンダー状態にあるかどうかを直接判断できます。

4.DNS解像度

次はDNSの解像度です。ページにログインすると、ユーザーがクリックする場所を検出することが比較的困難な場合があります。もちろん、ユーザーの次の動作がほとんど入っていることを知るためにいくつかの埋葬ポイントを実行することもあります。しかし、場合によっては、ユーザーが次にどのページに行くかはわかりませんが、彼がどのドメインに行くかはわかります。現時点では、DNSを事前にできます。実際、ページ要求プロセス全体に長いDNS解像度プロセスがあるからです。事前にこれを行うと、ユーザーにこのページをさらに表示させることができます。

以下は、Q+壁紙のケースです。 Q+壁紙は特定のシステムです。まず、Q+のアーキテクチャ全体がWeb+クライアントに基づいています。私たちが今見ているのはウェブページです。それは外のクライアントのシェルですが、その心はウェブです。多くの写真があるため、プロセス全体を初めて完了すると、すべての静的リソースが12個以上の静的サーバーに割り当てられます。言い換えれば、引っ張りたい場合は、10 dnsを解析する必要があります。今回は非常に時間がかかり、最も遅い時間が数秒遅れている可能性があります。これは肉眼で感じることができます。 DNS前解像度を実行すると、どのリソースがリソースであるかわからないため、すべての写真がランダムであるため、速度を改善するためにDNS前解像度に懸命に取り組んでいるとしか言えません。このようにして、2秒かかる場合があり、1秒になります。

次に、Q+のアプリケーションについて話しましょう。 QQとQ+には、QQのように多くのテキストチェーンがあります。つまり、ウィンドウの左下隅にテキストアプリ情報が押し付けられます。これは、バックエンドがWebを介して時々引っ張られ、バックエンドが引き抜かれてからフォアグラウンドに表示されます。しかし、特定の期間では、すべてのアプリによって押し込まれた総操作情報が実際に固定されています。特定のアプリに従って各テキストチェーンの対応する配列を分析すると、現時点では非常に大きなデータです。ここには、最適化の観点からは約3〜400バイトがあるため、これらの領域をローカルに引き出します。次に、ローカルローカルストレージを保存します。私たちは同じドメインにあり、アプリ間のすべての情報に互いにアクセスできます。そうすれば、再びプルしたすべてのIDをプルするわけではありません。

ここに注意を払う必要があるポイントもあります。現在、LocalStorageの多くのメーカーが同期しています。 LocalStorageを大量に呼び出すと、実際にレンダリングプロセスをブロックします。この時点で、ユーザーがページをドラッグダウンすると、この時点でデータを保存しており、データは比較的大きくなります。現時点では、ユーザーはあなたのページが非常に立ち往生していると感じるでしょう。彼らは以前にこの問題について議論しました。このインターフェイスの設計は非同期に設計されており、同期として設計されています。これにより、シリアル化プロセス、ディスクのシーケンスがあるため、より多くのアプリを作成すると、この言い訳ができます。このようにして、プロセス全体が遅く表示されます。さらに、LocalStorageはこのデータを異なるウィンドウ間で共有でき、このデータをロックします。大量のデータがこのローカルインターフェイスを呼び出している場合、比較的詰まっているように見えます。したがって、現時点では特に良い解決策はありませんが、これは覚えておくべきことです。現時点で最大のものが5時以上であっても、5時以上に使用すると、ユーザーは非常に悲しくなります。この言い訳に電話して、ユーザーがマウスをドラッグして使用している場合、非常に詰まっていると感じるからです。

次に、パフォーマンスの面でユーザーにオフラインストレージの利点について話しましょう。まず、定義ファイルはオフラインストレージに入力されます。 Q+のすべてのシステムモジュールには、定義オフラインサポートがあります。つまり、すべてのアプリケーションが切断されている場合でも、それらを使用できます。ドキュメントにマニフェストファイルを追加します。マニフェストは、どのページをローカルに保存する必要があるかを宣言する定義ファイルです。保管する必要のないものはどれですか？リクエストが失敗した場合、どれを交換する必要がありますか？これは3つの部分に分かれています。

まず、地元で保管する必要があるキャッシュ。

第二に、ネットワークはローカルに保存されません。それは戻って毎回それをリクエストします。ただし、ここでは、ローカルストレージとブラウザのストレージが実際には2つの異なるものであることを指摘する必要があります。 2つの異なる部品を保存します。 Chromeのように、そのストレージキャッシュは非常に憎悪でクリアが難しいため、ネットワークは毎回1回それをプルする必要があることをアプリに伝える必要がある場合でも。有効にするために手動でクリアされる必要があります。したがって、それをローカルに保存しないように設定したとしても、ブラウザは2つの異なる場所を保存するため、それ自体を保存する場合があります。

第三に、フォールバック。写真が失敗した場合、それは404です。代わりにどの写真を使用する必要がありますか？これはもっと楽しいと思います。

Maeifestを設定する方法は？マニフェストについて注意すべきことは3つあります。

マニフェスト相同制限。

MIMEタイプはテキスト/キャッシュマニフェストでなければなりません。これは標準であり、他の形式の場合は有効になりません。

Chrome、このことが有効になるかどうかを確認したい場合は、擬似プロトコルクロム、Chrome：// appcache-internalsを介してブラウザに入力できます。

アプリのキャッシュを更新する方法について。なぜオフラインストレージが必要なのですか？地元でオフラインで保管してください。ブラウザがオフラインストレージがあることを知っている場合、最初にオフラインストレージディレクトリに移動して、このリソースがキャッシュされているかどうかを確認します。キャッシュされたとき、彼はここから直接リソースを取得し、別のリクエストを送信しません。ブラウザのリクエストはこのようなものであるため、オフラインストレージがある場合、リクエストも送信されないため、より速くなります。時々更新する必要がある場合、更新するときはどうすればよいですか？

ユーザーはブラウザのキャッシュを手動でクリアでき、現時点ではローカルストレージが自動的にクリアされます。

マニフェストのコンテンツを変更することは、より推奨される方法であり、オンラインで使用する方法でもあります。つまり、特定のプロジェクトを内部で変更できますが、ここでコメントを変更するのが最善です。なぜなら、私が公開するたびにメカニズムを自動的に公開し、公開時にコメントして変更するだけです。このようにして、コンテンツが公開されるたびに、クライアントのローカルエリアにリアルタイムで同期されます。

プログラムを介して実行すると、プログラムはwindow.applicationcache.update（）です。オフラインストレージを操作したいということです。実際、セマンティクスはアプリケーションストレージであるため、アプリケーションストレージと呼ばれることがあります。アプリケーションストレージを手動で更新します。

6.WEBワーカー

次のWebワーカー。 Webワーカーは、マルチスレッドJSプロセスです。実際、オンラインでアプリケーションシナリオがない場合、それらについては話しません。しかし、私が見た特定のアプリケーションシナリオについて話すことができます。

まず、Webworkとは何かを紹介させてください。 OSレベルのスレッドです。以前は、マルチスレッドを模倣しましたが、実際にはもう1つのウィンドウを開きました。しかし、今では、ブラウザ自体がそれを提供しているため、操作により便利な利便性が高まり、ドキュメント全体を重くし、あまりお勧めしません。

その後、ウェブワーカーはアクセス機能が制限されており、多くのグローバルオブジェクトにアクセスできません。たとえば、Ducumnetオブジェクトにアクセスできません。ウェブワーカーに最適なシナリオは、CPU集約型コンピューティング操作です。以前にゲームをしていたとき、私たちはbox2dを使用しました。多くの人がそれを聞いています。これには、多くの計算が含まれます。つまり、ページ全体の以下のすべてのオブジェクトが衝突関係を計算する必要があります。これは非常に大きいです。ただし、現在のJSプロセスで実行されている場合、計算は大きく、計算が計算されると、ページ全体が非常にst音になります。ただし、Webworkerを使用してそれを行う場合、それは非同期プロセスであり、リアルタイムで送信され、計算プロセス中に他のことを行うことができます。これはマルチスレッドです。

デバイスAPIについて話しましょう。デバイスAPIで最も重要なことはパフォーマンスであり、現在実装されている最も早いAPIでもあると思います。 1つは接続です。これはネットワーク帯域幅です。これの機能は何ですか？中国のこのシナリオでは、多くのユーザーのインターネット速度がまだ非常に低いことを覚えておく必要があります。ユーザーのインターネット速度が低い場合、比較的低いソリューションに自動的にダウングレードできることを願っています。既存のテクノロジーを使用すると、それを行うことはできません。ただし、デバイスAPIを使用できます。この情報はデバイスから取得できることを知っているからです。そのブロードバンドは何ですか？ブロードバンドとは何ですか？私たちがそれがそうであるときにできること。たとえば、ブロードバンドが優れている場合、高解像度の写真を使用します。ブロードバンドが比較的低い場合は、明確にする写真を使用してください。

8。バッテリー

次のものはバッテリーに関するものです。パフォーマンスの観点から、それは主に力に関するものだと思います。ユーザーのバッテリー電源が比較的低い場合、彼はより少ないことをしようとするべきだと思います。携帯電話自体のバッテリー技術は、まだブレークスルーを行っていません。アプリをより高性能に見せることも、宣伝のハイライトであると思います。

9.カンバス

次はキャンバスです。キャンバスのいくつかのパフォーマンス最適化ポイントについて話しましょう。これらのものを使用すると、パフォーマンスは10回改善されます。

まず、各キャンバスはキャンバスです。グラフをレンダリングしたい場合は、レイヤーできます。 PSの内側と同じように、それは1、2、および3層です。多くのユーザーは、ゲームを作成するときにすべてを1つのレイヤーで直接模倣し、更新されたらすべてを更新する必要があります。しかし、それを重ねると、背景層に背景と役割のキャラクターを置きます。このようにして、役割を更新したい場合は、役割を更新するだけで、背景層を変更する必要はありません。 CPUが少ないため、パフォーマンスは自然に向上します。

第二に、Context.Drawimage。写真をスケーリングしないでください。最初に間違いを犯しました。私たちの芸術家によって作られた写真は常に私たちと矛盾しています。そして、私たちは写真を拡大したいと思っています。デバイス自体の画像サイズはこのようなものであるため、画像を比率でスケーリングする必要があります。写真をズームインした後、LowEnd Devicesなど、iPadやiPhoneが非常に詰まっていることがわかりました。なぜ？コード分​​析を実施するだけです。この方法を使用すると、費用がかかります。

第三に、RequestAnimationFrame。これは、レンダリング専用に最適化された方法です。独自の原則は次のとおりです。ブラウザがフレームを渡すと、この方法がトリガーされます。トリガーすると、Canvasはブラウザが次のフレームを実行する準備ができています。従来の方法を使用している場合、これ以上のことを考慮しません。それは私がどのくらいの時間を過ごしたかを知っているだけで、私はそれを実行します。ユーザーが前にブロックされ、10秒以内に10秒ごとにこの方法を実行した場合、以前の作業は完了しておらず、作業は延期されます。アニメーションがよりスムーズに見えるように最適化されています。なぜなら、すべてのフレームはあなたが何かをすることができることをあなたに伝えるからです。 （テキスト：infoq）