出典：Chaos Fuwang
http://www.alloyteam.com/2019/10/h5-performance-optimize/
上司は、ページを開く速度が遅すぎると言いましたか？ページの読み込みパフォーマンスが標準に達していませんか？すべての主要な工場とチームのクラシックなソリューションを見てみましょう。
このページでは、クライアントと組み合わせるように偏っているハイブリッドの2番目のオープニングソリューションを一覧表示して要約します。純粋なフロントエンドソリューションについても部分的に説明します。
一般的に使用される加速方法
H5パフォーマンス最適化プログラムといえば、これは一般的なトピックですが、通常のWeb最適化手法は、基本的に、リソースの読み込みとHTMLレンダリングの2つの側面を中心に展開します。前者は最初の画面用で、後者はインタラクティブ用です。リソースの最適化に関して、私たちの一般的な方向性は、一般的なものなどのより小さなリソースパッケージに焦点を当てることです：圧縮、パッケージの削減、アンパック、パッケージの動的読み込み、イメージの最適化。HTMLレンダリングの一般的な方向は、CDN、DNS解決、httpキャッシング、データ事前要求、データキャッシング、ファーストスクリーン最適化キラーストレートアウトなどによる配信など、コンテンツをより速く表示することです。
これらのプログラムは、さまざまなフロントエンドインタビューとフロントエンド開発に必要です。これは、パフォーマンスの問題が発生し、パフォーマンスの問題を解決する必要がある場合に最も重要で基本的なアイデアです。使用する必要がある特定のソリューションは、実際の開発ニーズ、優先度、全体的なコスト、および入出力比によって異なります。
リアクティブネイティブ、weex、フラッターなどのクライアントテクノロジーは従来のハイブリッドに影響を与え続けていますが、ハイブリッドもその過程で進化および加速しており、ネイティブに匹敵する方向に発展しています。以下は、ハイブリッド開発におけるいくつかのプログラムの要約で、順不同です。
ストレート+オフラインパッケージキャッシュ
最初の画面を最適化するために、ほとんどのメインストリームページはサーバーを通じてレンダリングされ、htmlファイルはフロントエンドに吐き出されて、長時間実行される菊の問題を解決します。さまざまな種類のメインストリームフレームワークには、vue-server-rendererなどの一連のバックグラウンドレンダリングソリューションがあります。 react-dom / serverなど ストレートアウトは、フロントエンドレンダリングとajaxリクエストの時間を節約します。ストレートアウトは、さまざまなキャッシュ戦略を通じて最適化できますが、htmlのロードには時間がかかります。
オフラインパッケージテクノロジーは、htmlファイル自体のロードに必要な時間の問題を解決できます。オフラインパッケージの基本的な考え方は、webviewを介してURLを均一にインターセプトし、リソースをローカルオフラインパッケージにマップし、ローカルキャッシュディレクトリでリソースを更新、ダウンロード、および維持するときにバージョンリソースを確認することです。TencentのwebsoやAlloykitのオフラインパッケージソリューションなど。
オフラインパッケージ戦略は、多くの大規模な工場で比較的成熟しており、Webに対して比較的透過的で、非常に煩わしいものです。
VasSonicクライアントエージェント
ハイブリッドh5では、ユーザーがクリックしてページを表示するまでの間に、webviewがリソースを初期化してリクエストする時間はまだあり、ここでのプロセスはシリアルです。より極端なエクスペリエンスを追求するために、最適化の余地があり、五月。VasSonicは、Tencentの付加価値メンバーシップチームによって開発された軽量ハイブリッドフレームワークであり、上記のオフラインパッケージ戦略をサポートします。さらに、次の最適化を行いました。
Webviewの初期化とクライアントプロキシを介したリソースリクエストの並列実行
リクエストのストリーミングインターセプト、読み込み中のレンダリング
動的キャッシュと増分更新を実現します。
方法について簡単に説明します。並列クライアントプロキシリソースリクエストについては何も言えません。つまり、webviewが作成される前に、クライアントプロキシを介してネットワーク接続が確立され、htmlがリクエストされてからキャッシュされ、webviewスレッドがhtmlリソースリクエストを開始するのを待ちます。 、クライアントはインターセプトし、キャッシュされたhtmlをWebビューに返します。
動的キャッシュと増分更新を行う方法は？
VasSonicは、htmlのコンテンツをhtmlテンプレートと動的データに分割します。これらの2つのタイプを区別するにはどうすればよいですか？htmlアノテーションマークアップルールのセットを定義して、動的データとテンプレートデータをタグで分割します。次に、httpヘッダーが拡張され、バックエンドを要求するための一連の規則がカスタマイズされました。webviewがhttpリクエストを開始すると、ページコンテンツのIDが含まれます。バックグラウンド処理が判断された後、部分的なデータを更新する必要があるかどうかがクライアントに通知されます。更新が必要な場合、キャッシュされたhtmlテンプレートと新しいデータが新しいhtmlにスプライスされ、データが計算されます。違いの部分では、jsを介してページにコールバックし、レイアウトを更新します。
【画像ソースネットワーク】
VasSonicのソリューションの全体的なアイデアと効果は、特にほとんどのWebシーンで非常に優れています。通常、テンプレートはほとんど変更されず、そのほとんどはデータ変更の一部であり、部分的な更新によって2番目のオープニング効果を達成できます。最初のロードでは、同時リクエストとWebViewの作成によりパフォーマンスが向上し、オフラインパッケージ戦略をシームレスにサポートできます。
ただし、VasSonicは一連の特別な注釈マークを定義し、ヘッダーを拡張します。バックエンドを含むフロントエンドとバックエンドを変更する必要があり、これはWebに非常に煩わしく、アクセスのワークロードとメンテナンスコストは非常に大きくなります。
PWA +ストレートアウト+プリロード
PWAは、オフラインパッケージテクノロジーでもWebViewプロキシリクエストでも、フロントエンドに非常に煩わしいものです。PWAは、Web標準として、純粋なWebソリューションを通じてロードパフォーマンスを高速化および最適化できます。
まず、PWAはcacheStorageを通じて一般的な画像、JS、CSSリソースをキャッシュできます。一方、従来のhttpキャッシュでは、通常、HTMLをキャッシュしません。これは、ページのmax-ageが長すぎると、ユーザーは常にブラウザーのキャッシュ有効期限内に古いページを表示するためです。
PWAのHTMLページを使用する場合、直接キャッシュできますか？PWAはキャッシュを細かく制御できるため、答えは「はい」です。
ストレートアウトHTMLの場合、PWAと連携してファイルをバックグラウンドから直接cacheStorageにキャッシュし、次のリクエストが行われたときに最初にローカルキャッシュからファイルを取得し、ローカルhtmlファイルを更新するネットワークリクエストを開始します。
ただし、ハイブリッドh5アプリケーションでは、初回起動時のリソースの読み込みにはまだ時間がかかります。PWAキャッシュを必要とするページの事前読み込みをサポートするために、アプリ側からJavaScriptスクリプトを事前に読み込むことができ、事前にキャッシュを完了することができます。
まっすぐでないページの場合でも、ブラウザーがHTML時間をレンダリングする問題を回避することはできません。
ここに2つのポイントがあります。最初はプリロードのみに頼ることができるので、上記のプリロードスクリプトの最後は引き続き有効です。2番目のポイントはページからまっすぐではなく、各ページにハッシュなどの一意のマークが必要です。ブラウザはデータを取得してhtmlをレンダリングします。htmlページは、outerHTMLメソッドを介してcacheStorageにキャッシュできます。2番目のアクセスは引き続き優先的にローカルで取得され、同時にhtmlリクエストが開始されます。一意の識別子の違いを比較することにより、更新する必要があります。
一連のPWAソリューションは、オフラインパッケージ戦略に代わるものです。利点は、それがWeb標準に属し、サービスワーカーをサポートできる通常のH5ページに適していることです。互換性の問題を許容する場合は、追加することをお勧めします。
NSRレンダリング
GMTC2019グローバルフロントエンドテクノロジーUCチームは、0.3秒の「飛行」ソリューションについて言及しました。NSRはSSRのフロントエンドバージョンであり、非常に啓発的です。
中心となるアイデアは、ブラウザーの助けを借りてJS-Runtimeを有効にし、ダウンロードしたHTMLテンプレートとプリフェッチされたフィードストリームデータを事前にレンダリングし、次にHTMLをメモリレベルのMemoryCacheに設定して、クリックと表示の効果を実現することです。 。
NSRは、SSRレンダリングプロセスを各ユーザーの最後に分散します。バックグラウンドリクエストのプレッシャーを軽減しながら、究極のページオープン速度も高速化します。
問題は、データのプリフェッチとプリレンダリングにより、トラフィックとパフォーマンスのオーバーヘッド、特にトラフィックが増えることです。ユーザーの行動をより正確に予測してヒット率を上げる方法は非常に重要です。NSRに類似したソリューションを徐々に検討しています。
クライアントPWA
実際のテスト、およびブラウザチームのクラスメートとの理解とコミュニケーションでは、WebViewでのサービスワーカーのパフォーマンスは期待したほど良くありませんでした。プロジェクトがswを落とした後、市場の全体的なアクセス速度は約300ms増加しました。ハイブリッドアプリケーションの場合、これは新しいアイデアと課題を提示します。基本的なサービスワーカーAPIのセットを顧客に実装できますか？Web標準との互換性を実現するため。これは一種の思考とアイデアであり、WebView SWの特定のパフォーマンスステータス、将来のサポート状況、自己実現のコスト、最終的な効果と価値など、検討すべき多くの問題があります。
ミニプログラム
ミニプログラムエコシステムは非常に成熟しており、大手メーカーも独自のプラットフォームミニプログラムを立ち上げており、国内メーカーもMiniApp w3c標準の宣伝に常に取り組んでいます。ロード速度やページの流暢さに関係なく、ミニプログラムはH5ページよりも高くなります。理由は、アーキテクチャの開発を標準化および制約することにより、ミニプログラムはWebViewレンダリングとJS実行を分離し、オフラインパッケージを介して、ページ分割やページのプリロードなどの一連の最適化手法により、アプレットはWebの柔軟性を犠牲にしてH5に最適化された多くの効果をもたらします。しかし、ハイブリッド開発の場合、ネイティブクライアントの最下層でこの種の小さなプログラム環境をサポートし、小さなプログラムソリューションを使用して多数のビジネスロジックを開発し、反復速度とパフォーマンスの効果を達成することは非常に良い方向です。
結び目
この記事は主に、Miaokaiに関する12を超える記事を読んだり、組み合わせたりするための過去数日間の最近の考えや実践をまとめ、いくつかの代表的な解決策を抽出します。プログラムのタイプに関係なく、一般的なアイデアと方向性は次のとおりです。
リンク全体の中間リンクを減らします。たとえば、小さなプログラムの内部実行メカニズムを含め、シリアルをパラレルに変更します。
可能な限りプリロードして実行します。たとえば、データのプリフェッチからページのプリフェッチのレンダリングまで。
あらゆる変換には代償が伴います。加速は基本的に、ネットワーク、メモリ、CPUの速度と速度、スペースの時間とのトレードオフです。
交換留学
パブリックアカウント[フロントエンドユニバース]をフォローして、毎日良い記事の推奨事項を入手してください
WeChatを追加し、グループに参加してコミュニケーションする
「監視と転送」が最大のサポート