ナビゲーションをスキップ
部 I 章 1

JavaScript

序章

JavaScriptはウェブ上で、対話可能で複雑な体験を構築することを可能にするスクリプト言語です。これには、ユーザーの会話への応答、ページ上の動的コンテンツの更新などが含まれます。イベントが発生したときにウェブページがどのように振る舞うべきかに関係するものはすべて、JavaScriptが使用されています。

言語の仕様自体は、世界中の開発者が利用している多くのコミュニティビルドのライブラリやフレームワークとともに、1995年に言語が作成されて以来、変化と進化を続けてきました。JavaScriptの実装やインタプリタも進歩を続けており、ブラウザだけでなく多くの環境で利用できるようになっています。

HTTP Archiveは毎月数百万ページをクロールし、WebPageTest のプライベートインスタンスを通して実行し、各ページのキー情報を保存しています(これについての詳細は方法論 で学べます)。JavaScriptのコンテキストでは、HTTP Archiveはウェブ全体の言語の使用法に関する広範な情報を提供しています。この章では、これらの傾向の多くを集約して分析します。

どのくらいのJavaScriptを使っているのか?

JavaScriptは、私たちがブラウザに送るリソースの中で最もコストのかかるものでダウンロード、解析、コンパイル、そして最終的に実行されなければなりません。ブラウザはスクリプトの解析とコンパイルにかかる時間を大幅に短縮しましたが、WebページでJavaScriptが処理される際には、ダウンロードと実行が最もコストのかかる段階になっています

ブラウザに小さなJavaScriptのバンドルを送ることは、ダウンロード時間を短縮し、ひいてはページパフォーマンスを向上させるための最良の方法です。しかし、実際にどのくらいのJavaScriptを使っているのでしょうか?

図1. ページあたりのJavaScriptバイト数の分布
p10パーセンタイルで70バイト、p25で174バイト、p50で373バイト、p75で693バイト、p90で1,093バイトのJavaScriptを使用していることを示す棒グラフ
図 1. ページあたりのJavaScriptバイト数の分布

上の図1を見ると、JavaScriptを373KB使用しているのは、50パーセンタイル(中央値)であることがわかります。つまり、全サイトの50%がこれだけのJavaScriptをユーザーに提供していることになります。

この数字を見ると、これはJavaScriptの使いすぎではないかと思うのは当然のことです。しかし、ページのパフォーマンスに関しては、その影響はネットワーク接続や使用するデバイスに完全に依存します。モバイルクライアントとデスクトップクライアントを比較した場合、どのくらいのJavaScriptを提供しているのでしょうか?

図2. デバイス別のページあたりのJavaScriptの分布。
デスクトップとモバイルでそれぞれp10パーセンタイルで76バイト/65バイトのJavaScriptを使用していることを示す棒グラフで、p25で186/164バイト、p50で391/359バイト、p75で721/668バイト、p90で1,131/1,060バイトとなっています。
図 2. デバイス別のページあたりのJavaScriptの分布。

どのパーセンタイルでも、モバイルよりもデスクトップデバイスに送信するJavaScriptの数がわずかに多くなっています。

処理時間

解析とコンパイルが行われた後、ブラウザによって取得されたJavaScriptは、利用する前に処理(または実行)される必要があります。デバイスは様々であり、その計算能力はページ上でのJavaScriptの処理速度に大きく影響します。ウェブ上での現在の処理時間は?

V8のメインスレッドの処理時間を異なるパーセンタイルで分析すると、アイデアを得ることができます。

図3. デバイス別のV8メインスレッド処理時間。
処理時間をデスクトップとモバイルでそれぞれp10パーセンタイルで141ms/377ms、p25で352/988ms、p50で849/2,437ms、p75で1,850/5,518ms、p90で3,543/10,735msとした棒グラフ。
図 3. デバイス別のV8メインスレッド処理時間。

すべてのパーセンタイルにおいて、処理時間はデスクトップよりもモバイルの方が長くなっています。メインスレッドの合計時間の中央値はデスクトップでは849msであるのに対し、モバイルでは2,437msと大きくなっています。

このデータはモバイルデバイスがJavaScriptを処理するのにかかる時間が、より強力なデスクトップマシンに比べてどれだけ長いかを示していますが、モバイルデバイスは計算能力の点でも違いがあります。次の表は、1つのWebページの処理時間がモバイルデバイスのクラスによって大きく異なることを示しています。

Reddit.comのJavaScript処理時間
3つの異なるデバイスを示す棒グラフ: 上部のPixel3は、メインスレッドとワーカースレッドの両方で400ms未満と量が少ないです。Moto G4の場合、メインスレッドで約900ms、ワーカースレッドでさらに300msです。そして最後のバーはAlcatel 1X 5059Dで、メインスレッドで2,000ms以上、ワーカースレッドで500ms以上となっています。
図 4. reddit.comのJavaScript処理時間。2019年のJavaScriptのコストより。

リクエスト数

Webページで使用されているJavaScriptの量を分析しようとする場合、1つの方法として、送信されたリクエスト数を調べる価値があります。HTTP/2では、複数の小さなチャンクを送信することで、より大きなモノリシックなバンドルを送信するよりもページの負荷を改善できます。また、デバイスクライアント別に分解してみると、どのくらいのリクエストがフェッチされているのでしょうか。

図5. 総JavaScriptリクエスト数の分布。
p10パーセンタイルではデスクトップとモバイルそれぞれ4/4のリクエストを示す棒グラフ、p25では10/9、p50では19/18、p75では33/32、p90では53/52が使用されています。
図 5. 総JavaScriptリクエスト数の分布。

中央値では、デスクトップ用に19件、モバイル用に18件のリクエストが送信されています。

ファーストパーティ対サードパーティ

これまでに分析した結果のうち、全体のサイズとリクエスト数が考慮されていました。しかし、大多数のウェブサイトでは、取得して使用しているJavaScriptコードのかなりの部分がサードパーティのソースから来ています。

サードパーティのJavaScriptは、外部のサードパーティのソースから取得できます。広告、分析、ソーシャルメディアの埋め込みなどは、サードパーティのスクリプトを取得するための一般的なユースケースです。そこで当然のことながら、次の質問に移ります。

図6. デスクトップ上のファーストスクリプトとサードパーティスクリプトの分布。
デスクトップ上でp10パーセンタイルでは0/1リクエストがファーストパーティとサードパーティであることを示す棒グラフが表示されています、p25では2/4、p50では6/10、p75では13/21、p90では24/38となっています。
図 6. デスクトップ上のファーストスクリプトとサードパーティスクリプトの分布。
図7. モバイル上のファーストパーティとサードパーティのスクリプトの分布。
モバイルでp10パーセンタイルでは0/1リクエストがファーストパーティとサードパーティであることを示す棒グラフが表示されています、p25では2/3、p50では5/9、p75では13/20、p90では23/36となっています。
図 7. モバイル上のファーストパーティとサードパーティのスクリプトの分布。

モバイルクライアントとデスクトップクライアントの両方において、すべてのパーセンタイルにおいて、ファーストパーティよりもサードパーティのリクエストの方が多く送信されています。これが意外に思える場合は、実際に提供されるコードのうち、サードパーティのベンダーからのものがどれくらいあるのかを調べてみましょう。

図8. デスクトップ上でダウンロードされたJavaScriptの総ダウンロード数の分布。
p10パーセンタイルでは、ファーストパーティとサードパーティのリクエストに対してデスクトップ上で0/17バイトのJavaScriptがダウンロードされていることを示す棒グラフ、p25では11/62、p50では89/232、p75では200/525、p90では404/900である。
図 8. デスクトップ上でダウンロードされたJavaScriptの総ダウンロード数の分布。
図9. モバイルでダウンロードされたJavaScriptの総ダウンロード数の分布。
棒グラフは、p10パーセンタイルではファーストパーティとサードパーティのリクエストでそれぞれ0/17バイトの JavaScriptがモバイルでダウンロードされていることを示していますが、p25では6/54、p50では83/217、p75では189/477、p90では380/827です。
図 9. モバイルでダウンロードされたJavaScriptの総ダウンロード数の分布。

中央値では、モバイルとデスクトップの両方で、開発者が作成したファーストパーティのコードよりもサードパーティのコードの方が89%多く使用されています。これは、サードパーティのコードが肥大化の最大の要因の1つであることを明確に示しています。サードパーティの影響についての詳細は、"サードパーティ"の章を参照してください。

リソース圧縮

ブラウザとサーバの会話のコンテキストで、リソース圧縮とは、データ圧縮アルゴリズムを使用して変更されたコードを指します。リソースは事前に静的に圧縮することも、ブラウザからの要求に応じて急ぎ圧縮することもでき、どちらの方法でも転送されるリソースサイズが大幅に削減されページパフォーマンスが向上します。

テキスト圧縮アルゴリズムは複数ありますが、HTTPネットワークリクエストの圧縮(および解凍)に使われることが多いのはこの2つだけです。

  • Gzip (gzip): サーバーとクライアントの相互作用のために最も広く使われている圧縮フォーマット。
  • Brotli (br): 圧縮率のさらなる向上を目指した新しい圧縮アルゴリズム。90%のブラウザがBrotliエンコーディングをサポートしています。

圧縮されたスクリプトは、一度転送されるとブラウザによって常に解凍される必要があります。これは、コンテンツの内容が変わらないことを意味し、実行時間が最適化されないことを意味します。しかし、リソース圧縮は常にダウンロード時間を改善しますが、これはJavaScriptの処理で最もコストのかかる段階の1つでもあります。JavaScriptファイルが正しく圧縮されていることを確認することは、サイトのパフォーマンスを向上させるための最も重要な要因の1つとなります。

JavaScriptのリソースを圧縮しているサイトはどれくらいあるのでしょうか?

図10. JavaScript リソースをgzipまたはbrotliで圧縮しているサイトの割合。
バーチャートを見ると、デスクトップとモバイルでそれぞれJavaScriptリソースの67%/65%がgzipで圧縮されており、15%/14%がBrotliで圧縮されていることがわかります。
図 10. JavaScript リソースをgzipまたはbrotliで圧縮しているサイトの割合。

大多数のサイトではJavaScriptのリソースを圧縮しています。Gzipエンコーディングはサイトの〜64-67%で、Brotliは〜14%で使用されています。圧縮率はデスクトップとモバイルの両方でほぼ同じです。

圧縮に関するより深い分析については、"圧縮"の章を参照してください。

オープンソースのライブラリとフレームワーク

オープンソースコード、または誰でもアクセス、閲覧、修正が可能な寛容なライセンスを持つコード。小さなライブラリから、ChromiumFirefoxのようなブラウザ全体に至るまで、オープンソースコードはウェブ開発の世界で重要な役割を果たしています。JavaScriptの文脈では、開発者はオープンソースのツールに依存して、あらゆるタイプの機能をWebページに組み込んでいます。開発者が小さなユーティリティライブラリを使用するか、アプリケーション全体のアーキテクチャを決定する大規模なフレームワークを使用するかにかかわらずオープンソースのパッケージに依存することで、機能開発をより簡単かつ迅速にできます。では、どのJavaScriptオープンソースライブラリが最もよく使われているのでしょうか?

ライブラリ デスクトップ モバイル
jQuery 85.03% 83.46%
jQuery Migrate 31.26% 31.68%
jQuery UI 23.60% 21.75%
Modernizr 17.80% 16.76%
FancyBox 7.04% 6.61%
Lightbox 6.02% 5.93%
Slick 5.53% 5.24%
Moment.js 4.92% 4.29%
Underscore.js 4.20% 3.82%
prettyPhoto 2.89% 3.09%
Select2 2.78% 2.48%
Lodash 2.65% 2.68%
Hammer.js 2.28% 2.70%
YUI 1.84% 1.50%
Lazy.js 1.26% 1.56%
Fingerprintjs 1.21% 1.32%
script.aculo.us 0.98% 0.85%
Polyfill 0.97% 1.00%
Flickity 0.83% 0.92%
Zepto 0.78% 1.17%
Dojo 0.70% 0.62%
図 11. デスクトップとモバイルでのトップ JavaScript ライブラリ

これまでに作成された中で最も人気のあるJavaScriptライブラリであるjQueryは、デスクトップページの85.03%、モバイルページの83.46%で使用されています。FetchquerySelectorなど、多くのブラウザAPIやメソッドの出現により、ライブラリが提供する機能の多くがネイティブ形式に標準化されました。jQueryの人気は衰退しているように見えるかもしれませんが、なぜ今でもウェブの大部分で使われているのでしょうか?

理由はいくつか考えられます。

  • WordPressは、30%以上のサイトで使用されているため、デフォルトでjQueryが含まれています。
  • アプリケーションの規模によってはjQueryから新しいクライアントサイドライブラリへの切り替えに時間を要する場合があり、多くのサイトでは新しいクライアントサイドライブラリに加えてjQueryで構成されている場合があります。

他にもjQueryの亜種(jQuery migrate、jQuery UI)、ModernizrMoment.jsUnderscore.jsなどがトップで使用されているJavaScriptライブラリです。

フレームワークとUIライブラリ

方法論で述べたように、HTTP Archive(Wappalyzer)で使用されているサードパーティ製の検出ライブラリには、特定のツールを検出する方法に関して多くの制限があります。JavaScriptライブラリやフレームワークの検出を改善するための未解決の問題があります、それがここで紹介した結果に影響を与えています。

過去数年の間に、JavaScriptのエコシステムでは、シングルページアプリケーション (SPA) の構築を容易にするオープンソースのライブラリやフレームワークが増えてきました。シングルページアプリケーションとは、単一のHTMLページを読み込み、サーバーから新しいページを取得する代わりにJavaScriptを使用してユーザーの対話に応じてページを修正するWebページのことを指します。これはシングルページアプリケーションの大前提であることに変わりはありませんが、このようなサイトの体験を向上させるために、異なるサーバーレンダリングアプローチを使用できます。これらのタイプのフレームワークを使用しているサイトはどれくらいあるのでしょうか?

図12. デスクトップで最もよく使われるフレームワーク
Reactを使用しているサイトは4.6%、AngularJSを使用しているサイトは2.0%、Backbone.jsを使用しているサイトは1.8%、Vue.jsを使用しているサイトは0.8%、Knockout.jsを使用しているサイトは0.4%、Zone.jsを使用しているサイトは0.3%、Angularを使用しているサイトは0.3%、AMPを使用しているサイトは0.1%、Ember.jsを使用しているサイトは0.1%という棒グラフになっています。
図 12. デスクトップで最もよく使われるフレームワーク

ここでは人気のあるフレームワークのサブセットのみを分析していますが、これらのフレームワークはすべて、これら2つのアプローチのいずれかに従っていることに注意することが重要です。

コンポーネントベースモデルへの移行が進んでいるとはいえ、MVCパラダイムを踏襲した古いフレームワーク(AngularJSBackbone.jsEmber)は、いまだに何千ページにもわたって使われています。しかし、ReactVueAngularはコンポーネントベースのフレームワークが主流です(Zone.jsは現在Angular coreの一部となっているパッケージです)。

差分ロード

JavaScriptモジュール、またはESモジュールは、すべての主要ブラウザでサポートされています。モジュールは、他のモジュールからインポートおよびエクスポートできるスクリプトを作成する機能を提供します。これにより、サードパーティのモジュールローダーに頼ることなく、必要に応じてインポートとエクスポートを行い、モジュールパターンで構築されたアプリケーションを誰でも構築できます。

スクリプトをモジュールとして宣言するには、スクリプトタグがtype="module"属性を取得しなければなりません。

<script type="module" src="main.mjs"></script>

ページ上のスクリプトにtype="module'を使用しているサイトはどれくらいあるでしょうか?

図13. type=moduleを利用しているサイトの割合。
デスクトップでは0.6%のサイトが「type=module」を使用しており、モバイルでは0.8%のサイトが使用していることを示す棒グラフです。
図 13. type=moduleを利用しているサイトの割合。

ブラウザレベルでのモジュールのサポートはまだ比較的新しく、ここでの数字は、現在スクリプトにtype="module"を使用しているサイトが非常に少ないことを示しています。多くのサイトでは、コードベース内でモジュールを定義するためにモジュールローダー(全デスクトップサイトの2.37%がRequireJSを使用しています)やバンドラー(webpackを使用しています)にまだ依存しています。

ネイティブモジュールを使用する場合は、モジュールをサポートしていないブラウザに対して適切なフォールバックスクリプトを使用することが重要です。これは、nomodule属性を持つ追加スクリプトを含めることで実現できます。

<script nomodule src="fallback.js"></script>

併用すると、モジュールをサポートしているブラウザはnomodule属性を含むスクリプトを完全に無視します。一方、モジュールをサポートしていないブラウザは ¥type="module"属性を持つスクリプトをダウンロードしません。ブラウザはnomoduleも認識しないので、type="module"属性を持つスクリプトを普通にダウンロードします。このアプローチを使うことで、開発者は最新のコードを最新のブラウザに送信してページ読み込みを高速化するできます。では、ページ上のスクリプトにnomoduleを使っているサイトはどれくらいあるのだろうか。

図14. nomoduleを使用しているサイトの割合。
デスクトップでは0.8%のサイトが「nomobule」を利用しており、モバイルでは0.5%のサイトが利用していることを示す棒グラフ。
図 14. nomoduleを使用しているサイトの割合。

同様に、スクリプトにnomodule属性を使用しているサイトはほとんどありません(0.50%-0.80%)。

プリロードとプリフェッチ

プリロードプリフェッチリソースヒントであり、どのリソースをダウンロードする必要があるかを判断する際にブラウザを助けることができます。

  • <link rel="preload">でリソースをプリロードすると、ブラウザはこのリソースをできるだけ早くダウンロードするように指示します。これは、ページの読み込みプロセスの後半に発見され、最後にダウンロードされてしまう重要なリソース(例えば、HTMLの下部にあるJavaScriptなど)に特に役立ちます。
  • <link rel="prefetch">を使用することで、ブラウザが将来のナビゲーションに必要なリソースを取得するためのアイドル時間を利用できるようにします。

では、プリロードやプリフェッチディレクティブを使っているサイトはどれくらいあるのでしょうか?

図15. スクリプトにrel=preloadを使用しているサイトの割合。
バーチャートを見ると、デスクトップでは14%のサイトがスクリプトに'rel=preload'を使用しており、モバイルでは15%のサイトがスクリプトにrel=preloadを使用していることがわかります。
図 15. スクリプトにrel=preloadを使用しているサイトの割合。

HTTP Archiveで測定したすべてのサイトで、デスクトップサイトの14.33%、モバイルサイトの14.84%が<link rel="preload">をページ上のスクリプトに使用しています。

プリフェッチについて以下のようなものがあります。

図16. スクリプトにrel=prefetchを使用しているサイトの割合。
デスクトップでは0.08%のサイトが「rel=prefetch」を使用しており、モバイルでは0.08%のサイトが使用していることを示す棒グラフ。
図 16. スクリプトにrel=prefetchを使用しているサイトの割合。

モバイルとデスクトップの両方で、0.08%のページがスクリプトのいずれかでプリフェッチを利用しています。

新しいAPI

JavaScriptは言語として進化を続けています。ECMAScriptと呼ばれる言語標準そのものの新バージョンが毎年リリースされ、新しいAPIや機能が提案段階を通過して言語そのものの一部となっています。

HTTP Archiveを使用すると、サポートされている(あるいはこれからサポートされる)新しいAPIを調べて、その使用法がどの程度普及しているかを知ることができます。これらのAPIは、サポートしているブラウザで既に使用されているかもしれませんし、すべてのユーザに対応しているかどうかを確認するためにポリフィルを添付しています。

以下のAPIを使用しているサイトはどれくらいありますか?

図17. 新しいJavaScript APIの利用法
バーチャートを見ると、デスクトップとモバイルのサイトの25.5%/36.2%がWeakMap、6.1%/17.2%がWeakSet、3.9%/14.0%がIntl、3.9%/4.4%がProxy、0.4%/0.4%がAtomics、0.2%/0.2%がSharedArrayBufferを使用していることがわかります。
図 17. 新しいJavaScript APIの利用法

Atomics(0.38%)とSharedArrayBuffer(0.20%)は、使用されているページが少ないので、このチャートではほとんど見えません。

ここでの数値は概算であり、機能の使用状況を測定するためのUseCounter を活用していないことに注意してください。

ソースマップ

多くのビルドシステムでは、JavaScriptファイルはサイズを最小化し、多くのブラウザではまだサポートされていない新しい言語機能のためにトランスパイルされるようにミニ化されています。さらに、TypeScriptのような言語スーパーセットは、元のソースコードとは明らかに異なる出力へコンパイルされます。これらの理由から、ブラウザに提供される最終的なコードは読めず、解読が困難なものになることがあります。

ソースマップとは、JavaScriptファイルに付随する追加ファイルで、ブラウザが最終的な出力を元のソースにマップできます。これにより、プロダクションバンドルのデバッグや分析をより簡単にできます。

便利ではありますが多くのサイトが最終的な制作サイトにソースマップを入れたくない理由は、完全なソースコードを公開しないことを選択するなど、いくつかあります。では、実際にどれくらいのサイトがソースマップを含んでいるのでしょうか?

図18. ソースマップを使用しているサイトの割合。
デスクトップサイトの18%、モバイルサイトの17%がソースマップを使用していることを示す棒グラフ。
図 18. ソースマップを使用しているサイトの割合。

デスクトップページでもモバイルページでも、結果はほぼ同じです。17~18%は、ページ上に少なくとも1つのスクリプトのソースマップを含んでいます(sourceMappingURLを持つファーストパーティスクリプトとして検出されます)。

結論

JavaScriptのエコシステムは毎年変化し続け、進化し続けています。新しいAPI、改良されたブラウザエンジン、新しいライブラリやフレームワークなど、私たちが期待していることは尽きることがありません。HTTP Archiveは、実際のサイトがどのようにJavaScriptを使用しているかについての貴重な洞察を提供してくれます。

JavaScriptがなければ、ウェブは現在の場所にはなく、この記事のために集められたすべてのデータがそれを証明しているに過ぎません。

著者