ホームページ >ウェブフロントエンド >htmlチュートリアル >[翻訳] Web アプリケーションのパフォーマンスをパッケージ化する方法_html/css_WEB-ITnose
原文: Packaging for Performance
Jie Weikan は非常勤翻訳者の Miao Chen によって翻訳され、Jie Weikan はレビューされて出版されました。最近、Web アプリケーションの静的リソース (JS/CSS) のパッケージ化に関する非常に興味深いトピックがありました。 Craig Silverstein と Rebecca Murphey によるこの主題に関するいくつかの記事は、今日のフロントエンドの世界におけるパッケージングの性質についての深い理解を示しています。ここでの主な疑問は、HTTP/2 に移行する際に、JavaScript と CSS のパッケージ化戦略 (既存のベスト パフォーマンス プラクティスに基づく) に変更を加える必要があるかどうかということです。 HTTP/2 でのパッケージ化の役割 (HTTP リクエストの数を減らす) は役に立たなくなりましたが、実際には HTTP/2 に移行していません。上記の記事はこの事実を証明しています。 eBay は数か月前、Web サイトを HTTPS に移行する準備をしていたときに同様のテストを実施しました。この記事では、私たちのパッケージ化方法と、それがどのようにパフォーマンスを向上させるかを簡単に紹介します。
eBay ページの大部分は、ローカル テンプレートに従って静的リソースをパッケージ化しています。ページ内のすべての CSS と JavaScript は 1 つのリソースにパッケージ化されており、CSS は head タグにロードされ、JS は下部にロードされます。これは HTTP リクエストの数を減らすという点で優れていますが、まだ改善の余地があります。主な改善点は、ブラウザのキャッシュをより効率的に使用することです。ユーザーが eBay ページにアクセスすると、未訪問のすべてのページで JS および CSS 全体をダウンロードする必要がありますが、これらのページには前のページで使用されたコア クラス ライブラリ (jQuery など) が含まれています。 HTTPS (および HTTP/2) への移行を計画したとき、この粗いパッケージング戦略は機能しないことに気づきました。私たちの調査と他の調査によると、全体をまとめてパッケージ化し、ページごとにリソースを個別に読み込むこの方法は、パフォーマンスの最適化には向いていないことがわかりました。バランスが必要だったので、独自のパッケージング ソリューションを思いつきました。
インセプション
まず、すべての eBay ページが呼び出すコア JS と CSS をマークし、次にそれらを 1 つのリソースに集約しました。この目標を達成するために、Inception という内部 Node.js モジュールを作成しました。このモジュールには、すべての一般的な JS および CSS モジュールが含まれており、すべてのチーム (eBay ページの所有者) によって依存関係として追加されます。注釈付きのコア JS ライブラリは、jQuery、marko (テンプレート エンジン)、marko-widgets (UI コンポーネントの抽象化)、および内部分析および追跡ライブラリです。 CSS については、Skin と呼ばれる独自のクラス ライブラリがあり、そこからコア、ボタン、アイコン、ダイアログ、フォームなどのモジュールを抽出します。 eBay で使用しているパッケージング ツールは Lasso と呼ばれます。 Lasso のプラグインとして、Inception モジュールは次の機能を提供します。
1. すべてのモジュール (購入、販売、閲覧、決済など) がコア JS および CSS の正確なバージョンに従うように強制します。図書館。これに従わないと、ビルドが失敗します。
2. Inception のリソースを URL にパッケージ化し、すべてのモジュールが同じ URL を参照します (例: inception-hashcode.js と inception-hashcode.css)。
3. を使用します。チームは引き続き、独自のモジュールの依存関係の一部として Inception の JS/CSS を参照できます。 Lasso のオプティマイザーは重複したロードを削除し、1 つのコピーのみがブラウザーに送信されるようにします。この機能が優れているのには 2 つの理由があります。まず、モジュール レベルのカプセル化を促進して、チームがモジュールを構築するときに、特定のコア ライブラリを 2 回ロードすることを気にせずに依存関係として自由に追加できるようにしたいと考えています。これにより、このモジュールは独立して実行できるようになります。第 2 に、チームは依存関係が Inception にあるかどうかを追跡する必要がありません。依存関係を自由に追加でき、ツールはこの最適化を処理できます。
Inception によって得られるメリットを見てみましょう:
1. ブラウザ キャッシュ: 前述したすべてのリソースを URL にパッケージ化することに関して、1 つの欠点は次のとおりです。ブラウザのキャッシュを有効に活用できません。インセプションはこの問題を解決します。コアの JS ライブラリと CSS ライブラリ (ちなみに、これがメインのロードです) は異なるモジュールの同じ URL で参照されるため、ユーザーが eBay を閲覧するときにブラウザのキャッシュが効果的に使用されます。このキャッシュにより、特に低速接続時のパフォーマンスが大幅に向上します。ちなみに、新しいブラウザはさまざまな方法でコード キャッシュをサポートしているため、Inception で大量の JS を繰り返し解析してコンパイルすることを回避できます。
2. ライブラリ ファイルの一貫性: 以前のパッケージング システムでは、各モジュールのコア クラス ライブラリのバージョンに一貫性がないことがわかりました。各チームは独自のコア クラス ライブラリを維持するため、たとえば、ユーザーがあるモジュールから別のモジュールにジャンプする場合、異なるバージョンの jQuery またはボタン スタイルが使用されます。実際の結果は、一貫性のない UI だけでなく、実装も一貫性のないものになります。 Inception は、コア クラス ライブラリを維持するための統合された場所であるため、この問題を解決します。
3. 高度な Web アプリケーションへの導き: すべてのモジュールのページが同じコア クラス ライブラリに依存すると、ブラウジング プロセス中に JS と CSS のみがサポートされるため、移行が非常に簡単になります。このアプリケーションに必要なファイルのみをダウンロードする必要があります。これにより、アプリケーション シェル アーキテクチャを使用して Web アプリケーションを構築できるようになり、eBay を高度な Web アプリケーションに構築する道が開かれます。過去に同様のアプローチ (モジュール内) を検討しました。構造化ページ フラグメント メソッドを使用すると、次のことが可能になります。知覚パフォーマンスの大幅な向上が見られます。
4. 簡単なアップグレード方法: 最後に、Inception では、コア クラス ライブラリをコア プレイスで新しいバージョンにアップグレードできます。 Inception 自体はセマンティック バージョニングに準拠しているため、Inception を使用しているすべてのチームはセマンティック アプローチに基づいて更新を取得できます。以前はアップグレードをチームごとに手動で行う必要があったため、問題がありました。
Module
コア クラス ライブラリは Inception によって管理されていますが、ページ内の他のリソースはどうなるのでしょうか?アプリケーション/モジュール固有の CSS と JS だけです。モジュールごとに別のパッケージ化方法を使用し、定数と変数の 2 つのグループに分けます。
定数: すべてのリクエストにわたって変更されない CSS および JS が定数として設定されます。これらは主に、異なるリクエスト パラメーターが使用されても変化しない各モジュールの UI コンポーネントに適用されます。定数モジュールはリソースにパッケージ化されているため、ブラウザーのキャッシュを引き続き利用できます。ユーザーが同じページを繰り返し閲覧すると、通常、このパッケージはブラウザーのキャッシュにヒットするため、パフォーマンスが向上します。
変数: 要求されたパラメーターに基づいて、各ページで少数のリソースが変更されます。これらの変更は、実験、ユーザーのログイン ステータス、ビジネス ロジックなどによるものです。このようなリソースは変数グループにグループ化され、実行時に個別にパッケージ化されます。これらはキャッシュ ヒット率が非常に低いため、セッションごとにネットワーク経由で再ダウンロードする必要がある場合があります。
概要
概要として、各ページには 6 つのリソース パッケージ (3 つの JS と 3 つの CSS) があり、各パッケージには独自の目的があります。すべての URL はコンテンツに基づいてハッシュされるため、キャッシュは自動的に期限切れになります。
1.Inception — パッケージ化されたコア JS および CSS、最大ペイロード。
2. 定数 — アプリケーション内で変更されない CSS と JS をパッケージ化します。中間負荷。
3. 変数 — パッケージ化されたアプリケーションの変更、最小負荷。
現状では、このパッケージング戦略がパフォーマンス要件に最も適していると思われます。彼は、HTTP リクエストの数とブラウザのキャッシュの間の適切なバランスを見つけました。来年、私たちは HTTP/2 に移行する予定ですが、引き続きこの方法を改善し、よりきめ細かいパッケージング ソリューションを試していきます。もちろん、パフォーマンスが鍵となります。
------------お久しぶりです、境界線------------
Jie Weibo は共有を目指しています質の高いコンテンツ。
私たちのレベルは限られていますが、私たちの理想は高いです。
私たちはまた、あなたの世界への理想的な貢献を楽しみにしています。
目的を問わずご連絡をお待ちしております。
Jie Weibo のフォローを歓迎