はじめに

昨今、Webページの表示速度・パフォーマンスは、以前よりも重要視されるようになってきています。

ChromeのDevToolsに同梱されているLighthouseというツールを利用することで、誰でも簡単にページのパフォーマンスを計測することもできます。

もし自分で計測したことがなくとも、視覚コンテンツの初期表示までの時間を表すFCPや、操作できるようになるまでの時間を表すTTIといった指標を目にする機会が多くなったと感じている人も多いのではないでしょうか。

Googleのモバイル検索では、ページの読み込み速度がランキングに影響するようになっていますし、ページの読み込みが遅いサイトでは、ユーザーの直帰率が上がりコンバージョン率も下がる傾向にあることも報告されています。ECサイトのAmazonでは、「ページの読み込み時間が100ms遅くなるごとに、売上が1%減少する」とまでレポートされていました。

補足：Amazonのレポート

AmazonのソフトウェアエンジニアのGreg Linden氏がスタンフォード大学で行ったデータマイニングクラスの講義で語られていました。

• Slides from my talk at Stanford

もちろん利用者としても、遅いページよりも速いページのほうが嬉しいです。電車の中でスマートフォンを使っていて、目的の情報がなかなか表示されずページを閉じた……といった経験をしたことがある人も多いと思います。

今回の記事では、そんなページの読み込み時間に影響するさまざまな要因のうち、「ブラウザがダウンロードするJavaScriptのサイズ」という要因にフォーカスして、それを「なぜ減らすべきなのか？」「いかにして減らすか？」について解説していきます。

テーマ初出

この記事は筆者が2022年12月14日に登壇したイベントでの口頭発表、およびその資料をベースに、一部を再構成して記事を執筆しています。

増え続けるJavaScript

まずはじめに、我々が置かれている現状をデータで確認しておきましょう。

The HTTP Archiveという、インターネット中のWebページの統計データを蓄積しているサイトが公開しているデータを見てみます。

まずは、"State of JavaScript"というレポートのデータです。

（出典：The HTTP Archive）

この図は、このサイトに登録のある上位1000サイトにおけるJavaScriptのサイズの中央値（もっとも頻度が高い値）に関するデータで、2017/12/15から2022/10/01までのものです。

これを見るに、この5年で20%以上もJavaScriptのサイズは増大していて、リクエスト数も同じく増加しているのがわかります。

そして、ことモバイルにおいては、その読み込みにかかる時間がなんと137.5%も増えているとのことです。日本のように、比較的モバイル回線も安定している国では、あまり実感がわかないかもしれませんが、単純に考えると、3.8秒も待たないとJavaScriptが実行すらされず、ページ内の機能が利用できません。このつらさは、想像に難くないはずです。

次に、同サイトが毎年公開している「Web Almanac」というレポートから、JavaScriptのチャプターを参照したデータです。

ページごとのJavaScriptのサイズを小さい順に並べたときに最小値から数えて、それぞれ10%から90%の値を示す。 （出典：The HTTP Archive「Web Almanac」）

ページごとの使われなかったJavaScriptの容量を小さい順に並べたときに最小値から数えて、それぞれ10%から90%の値を示す。 （出典：The HTTP Archive「Web Almanac」）

このデータは、とあるページを開いてロードされたJavaScriptのサイズと、ロードされたのに使用されなかったJavaScriptのサイズを示しています。

このデータによると、なんと30%から40%ものJavaScriptが未使用となっているのがわかります。低速なモバイル回線で、限りあるパケットを利用してダウンロードしたものが、使われないまま捨てられている可能性があるということです。

なにが問題なのか

このように、そもそも多量のJavaScriptが必要とされている状態や、使われもしないJavaScriptをたくさんダウンロードしてしまっている状態には、言うまでもなくさまざまな問題があります。

まず、ページを構成する要素はJavaScriptだけではありません。JavaScriptのダウンロードにブラウザのリソースが割かれてしまうと、他の画像やコンテンツのダウンロードが遅くなり、総じてページ全体の読み込み時間が長くなってしまいます。そしてそれが使われないJavaScriptなのであれば、そもそも無駄でしかありません。

また、そのページがJavaScriptを使用してコンテンツを描画する、いわゆるSPAとして構成されていた場合は、さらに問題があります。SPAの場合、JavaScriptのダウンロードが終わったあとにDOMを構築する必要があるため、ダウンロードを待った上に、JavaScriptの実行をも待つ必要があるからです。入力フォームなどが有効化されるのは、さらにその後です。

これでは、低速な回線やスペックの低いモバイル端末などでは、いつまでたっても目当てのコンテンツを見る・利用することができないといった状況になりえます。もちろんSSRといったテクニックを使うことで、初期表示を早めることはできますが、SPAが孕む他の問題を解決してくれるものではないです。

もちろん、JavaScriptの使用自体が問題なわけではありません。複雑なUIで構成されるアプリケーションや、UXのためにリッチな演出が必要だといった理由であれば、JavaScriptをたくさん使うこともあるでしょうし、それが問題であると即座に判断することはできません。

ただ、もしそういった理由がない場合、なんとなくJavaScriptを使ってしまっているのであれば、そのサイトをSPAとして構成する意味は本当にあるのか？ そのJavaScriptは本当に必要か？ ということを、今一度、考えてみる必要がありそうです。

ここまでのまとめ

さて、現状確認と問題提起をしたところで、次回の記事からは実際に「どうやってJavaScriptを減らしていくのか」を解説していきます。

• どんな状況のプロジェクトでも取り組むことができる比較的簡単な方法
• そもそもの技術選定・アーキテクチャについての指針
• 昨今のトレンドに沿った新しい考え方のフレームワーク

というように、さまざまなレベルのものを紹介していく予定です。