JavaScript価格

私たちのサイトがますますJavaScriptに依存するようになるにつれて、ユーザーに送信するものに対して料金を支払う必要があります。 時々、価格が一目で見えないことがあります。 この記事では、モバイルデバイスでの読み込みとパフォーマンスを高速化するために、少し規律を守ることがなぜ役立つのかを説明します。

tl; dr：コードの削減=解析/コンパイルの削減+転送の削減+解凍の削減

ネットワーク

ほとんどの開発者は、JavaScriptのコストについて考えるとき、ダウンロード時間と実行時間について考えます。 より多くのJavaScriptバイトを送信するには時間がかかり、ユーザーとのチャネルが薄くなります。



ユーザーの効果的なネットワーク接続のタイプは必ずしも3G、4G、またはWiFiではないため、これは最初の世界の国でも問題になる可能性があります 。 WiFiを備えたカフェに座っても、2Gの速度で携帯電話を介してホットスポットに接続できます。

JavaScriptネットワークの伝送コストは、次の方法で削減できます。

• ユーザーが必要とするコードのみを渡します 。 ここでコードを部分に分割すると役立ちます。
• ミニフィケーション （ES5の場合はUglify、 ES2015の場合はbabel-minifyまたはuglify-es ）。
• 最大圧縮 （ Brotli〜q11 、Zopfliまたはgzipを使用）。 Brotliは、圧縮においてgzipよりも優れています。 CertSimpleでは、JSコードを17％削減し、LinkedInはロード時間を4％削減しました 。
• 未使用のコードを削除します 。 DevToolsのコードカバレッジツールで識別できます。 不要なコードの削除については、 ツリーシェー キング 、高度なクロージャーコンパイラの最適化、およびLodash-babel-pluginやMoment.js などのライブラリ用のWebpack ContextReplacementPluginなどのライブラリ用の対応するプラグインを参照してください。 babel-preset-envとbrowserlistを使用して、最新のブラウザーでの翻訳を回避します。 上級開発者は、 Webpackバンドルを慎重に分析して、不要な依存関係を削除できます。
• ネットワークトラフィックを減らすためのキャッシュ 。 最適なスクリプトの有効期間（max-age）を決定し、変更されていないバイトを送信しないように検証トークン（ETag）を提供します。 サービスワーカーをキャッシュすると、アプリケーションがネットワークの停止に対して回復力を持ち、V8のコードキャッシュなどの機能への歓迎されたアクセスを提供できます。 ファイル名をハッシュすることで長期キャッシュについて学習します 。

ユーザーに渡されるJavaScriptコードの量を減らすための重要なヒント

解析/コンパイル

JavaScriptコードをダウンロードした後、 最も重要なコストの1つは、JSエンジンでこのコードを解析/コンパイルする時間です。 Chrome DevToolsでは、解析とコンパイルはパフォーマンスパネルの黄色のスクリプト時間の一部です。



[ボトムアップ]タブと[コールツリー]タブで、解析とコンパイルの正確な時間を確認できます。


Chrome DevToolsパフォーマンスパネル>ボトムアップ。 V8 Runtime Call Stats機能をアクティブにすると、解析およびコンパイルの段階に費やされた時間が表示されます

しかし、なぜこれが重要なのでしょうか？



コードの解析とコンパイルに多大な時間を費やすと、ユーザーがサイトを操作する際の遅延が大幅に増加する可能性があります。 送信するJavaScriptコードが多いほど、サイトがユーザーのアクションに応答し始めるまでの解析およびコンパイルフェーズが長くなります。

バイト単位で比較すると、 JavaScript処理は、同等のサイズの画像またはフォントよりもブラウザーのコストが高くなります -トムデール

JavaScriptと比較して、同じサイズの画像にも多数の処理コストがかかります（これらもデコードする必要があります！）が、平均的な携帯電話の機器では、ページの対話性に悪影響を与えるのはJSです。


JavaScriptと画像バイトはリソースを異なる方法で使用します。 通常、画像はメインストリームをブロックせず、デコードおよびラスタライズ中にインターフェイスをフリーズしません。 ただし、JSは、解析、コンパイル、コード実行により、対話性に影響を与えることができます。

遅い解析とコンパイルについて話すとき、コンテキストが重要です-ここでは、中型の携帯電話について話しています。 通常のユーザーは、L2 / L3キャッシュがなく、メモリが限られている場合でも、CPUとGPUが遅い電話を使用できます。

ネットワーク機能とデバイス機能は常に一致するとは限りません。 優れた光ファイバーチャネルを使用しているユーザーは、デバイスに付属するJavaScriptを解析および評価するために優れたCPUを持っている必要はありません。 逆もまた真です...ひどいネットワーク接続ですが、非常に高速なプロセッサです。 -クリストファー・バクスター、LinkedIn

「 JavaScript起動パフォーマンス 」の記事で、弱くて強力なハードウェアで約1メガバイトの解凍された（単純な）JavaScriptコードの解析時間に注目しました。 最速のスマートフォンと平均の違いは、解析/コンパイル時間の2〜5倍です。


異なるクラスのPCおよびモバイルデバイスでの1 MBのJavaScriptバンドル解析時間（gzipで約250 KB） 。 解析コストを考慮する場合、約250 MBのファイルを約1 MBのJSコードに展開する追加コストを追加する必要があります。

CNN.comのような実際のサイトはどうですか？

最新のiPhone 8は、CNNスクリプトの解析/コンパイルに約4秒かかりますが、平均的な電話（Moto G4）では約13秒かかります。 これは、ユーザーがサイトとやり取りする機会を得るまでの時間に大きく影響します。


通常のAndroidスマートフォンのSnapdragon 617と比較したApple A11 Bionicチップでの解析時間

これは、ポケットにある電話だけでなく、中規模の機器（Moto G4など）でテストすることの重要性を示しています。 ただし、コンテキストは重要です。 ユーザーが持っているデバイスとネットワークの状態に合わせて最適化します 。



分析ツールは、サイトの実際のユーザーが持っているモバイルデバイスのクラスを表示できます。 これにより、CPU / GPUの実際の制限を理解することができます。

JavaScriptの出荷が多すぎますか？ まあ、多分:)

HTTPアーカイブ（約50万サイト）は、 モバイルサイトでのJavaScriptの使用を示しています 。 そして、サイトの50％がインタラクティブになるまでに14秒以上かかることがわかります。 これらのサイトは、JSの解析とコンパイルだけで最大4秒かかります。



JSやその他のリソースをロードして処理するのに必要な時間を考慮すると、ユーザーが「フリーズ解除」するのを待たずにページを離れることは驚くことではありません。 ここには間違いなく改善の余地があります。

重要でないJavaScriptをページから削除すると、ロード時間、CPU集中型の解析/コンパイル、および潜在的なメモリオーバーランが削減されます。 また、ページがインタラクティブモードに入るのが速くなります。

リードタイム

解析とコンパイルだけでは代価がかかります。 JavaScriptの実行（解析/コンパイル後のコード実行）は、メインスレッドで実行される操作の1つです。 リードタイムが長いと、ユーザーがサイトを操作できるまでの時間にも影響します。

スクリプトが50ミリ秒より長く実行される場合、サイトとの対話の開始までの時間は、JSのダウンロード、コンパイル、および実行にかかる時間全体で増加します-Alex Russell

これに対処するために、JavaScriptを小さな断片で渡して、メインスレッドを長時間キャプチャしないようにすることは理にかなっています。 スクリプトの実行時間を最適化する方法を学びます。

JavaScript配信を高速化する方法

JavaScriptの解析/コンパイルとネットワーク経由の送信の時間を短縮することが目標である場合、ルートベースのチャンキングやPRPLなどの便利なテクニックがあります 。

PRPLは、コードをフラグメントに積極的に分割してキャッシュすることにより、対話性を最適化するための手法です。



どのような効果が得られるか見てみましょう。

V8 Runtime Call Statsを使用して、人気のあるモバイルサイトとプログレッシブWebアプリケーションの読み込み時間を分析しました。 ご覧のとおり、解析時間（オレンジ色で表示）は時間コストの大きな部分を占めています。



Wego WebサイトはPRPLを使用し、解析時間を低く抑えようと試み、非常に迅速に対話します。 リストされている他のサイトの多くは、JSコストを削減するために、分割コードとパフォーマンス予算を使用しています。

その他の費用

JavaScriptは、多くの点でパフォーマンスに影響を与える可能性があります。

• メモリ。 ガベージコレクションのために、ページがぐったりすることがあります。 ブラウザーがメモリを必要とする場合、JSの実行は一時停止されるため、ブラウザーのガベージコレクションが頻繁に実行されると、必要以上に実行が停止する場合があります。 ページのスムーズな移動を維持するために、メモリリークや頻繁なガベージコレクションの一時停止を避けます。
• JavaScriptを長時間実行するとメインスレッドがブロックされ、ページがフリーズします。 requestAnimationFrame() requestIdleCallback()を使用してコードをパーツに分割することで、この問題に対処できます。

プログレッシブブートストラップ

多くのサイトは、インタラクティブ性を通じてコン​​テンツの可視性を最適化します。 大規模なJavaScriptバンドルでレンダリングをすばやく開始するために、開発者はサーバー側レンダリングを使用することがあります。 JavaScriptが最終的に処理されたときに画像を「更新」します。

注意してください-すべてに価格があります。 1）基本的に、より大きなHTML応答を送信します。これは、対話性に影響を与える可能性があります。 2）ユーザーを信頼できる「邪悪な谷」に放置することができます。実際には、JavaScript処理が完了するまで、双方向性の半分は利用できません。

プログレッシブブートストラップは、このアプローチよりも優れたオプションです。 最小限の機能を備えたページ（このパッセージで最も重要なHTML / JS / CSSのみで構成されています）を送信します。 残りのリソースが到着すると、アプリケーションはそれらを遅延ロードし、追加機能をロック解除します。


プログレッシブブートストラップ 、ポールルイスによるイラスト

画面に表示されている内容に応じてコードをダウンロードすることは、本当の目標です。 PRPLとプログレッシブブートストラップは、彼女に近づくのに役立つテクニックです。

結論

細いチャネルでは伝送サイズが重要です。 解析時間は、CPUが弱いデバイスにとって重要です。 最小限のパフォーマンスを目指して努力する必要があります。

さまざまな企業が、JavaScriptの転送、解析、およびコンパイルの期間に厳しいパフォーマンス予算を導入することで、ある程度の成功を収めています。 モバイルWebサイトおよびアプリケーション向けのAlex Russell予算ガイド「これを許可できますか？：現実世界のパフォーマンス予算」を参照してください。


アプリケーションロジック用にJSにどのくらいのスペースを確保するかを考慮すると便利です。

モバイルデバイス用のWebサイトを作成している場合は、特定の機器を使用し、JavaScriptの解析/コンパイル時間を最小限に抑え、パフォーマンス予算を実装して、開発者がJavaScriptコストを追跡できるようにします。

オプショナル

JavaScriptの価格に関するChrome Dev Summit 2017での私のプレゼンテーション。 その後、PinterestやTinderなどの実際のサイトを使用してパフォーマンスが分析されます。