フロントエンド高速化の実践：計測なき最適化は、ただの当てずっぽうだ

「なんとなく重い」を、数字に変えるところから

「サイトが重い気がするので速くしてほしい」という相談を受けたとき、私たちがまず断るのは「いきなりコードをいじること」だ。体感の遅さと、実際のボトルネックは一致しないことが多い。画像が重いのか、JavaScriptの実行に時間がかかっているのか、それともサーバーの応答が遅いのか。まずはLighthouseやWebPageTest、Chrome DevToolsのPerformanceパネルで現状を数値化する。計測なき最適化は、当てずっぽうで薬を処方するようなものだ。

JavaScriptとCSSを「減らす」という発想

フロントエンド高速化で最も効果が大きいのは、多くの場合「送るコードそのものを減らす」ことだ。使っていないライブラリを削り、巨大なnpmパッケージを軽量な代替に置き換える。とくにアイコンフォントや日付処理ライブラリは、丸ごと読み込んで一部しか使っていないケースが目立つ。バンドルサイズを可視化するツールで内訳を確認し、上位の重量物から手を付けるのが定石だ。

コード分割で「今すぐ要らないもの」を後回しにする

初回表示に不要なコードまで一度に読み込ませる必要はない。ルート単位やコンポーネント単位で動的インポートを使い、必要になったタイミングで読み込む。モーダルやグラフ描画、リッチエディタのような重量級の機能は、ユーザーがその画面に来るまで読み込みを遅延させるだけで、初回の体感速度は大きく変わる。

レンダリングブロックを解消する

ページの描画を止めてしまう要素を取り除くのも重要だ。headに置かれた同期的なscriptや、巨大なCSSは、それらが読み込まれるまで画面を真っ白にする。クリティカルなCSSだけを先に配信し、残りは非同期で読み込む。外部スクリプトにはasyncやdeferを適切に付け、サードパーティのタグが描画をブロックしていないかを疑う。

フォントとレイアウトシフトへの目配り

Webフォントは表現力を高める一方で、読み込み中に文字が消えたり、後からガクッと表示が入れ替わったりする原因になる。font-displayの指定や必要な文字だけを含めるサブセット化で、この影響を抑えられる。あわせて、画像や広告枠にあらかじめ幅と高さを指定しておくことで、後から要素が押し出される「レイアウトシフト」を防ぐ。ユーザーがボタンを押そうとした瞬間に表示がずれる不快さは、数値以上に信頼を損なう。

一度きりで終わらせず、改善のループを回す

高速化は一度やって終わりではない。機能を追加すれば、また少しずつ重くなっていく。私たちが推奨するのは、計測を仕組みに組み込むことだ。CIにパフォーマンス計測を組み込み、一定のスコアを下回ったら気づける状態を作る。「速い状態を維持する」ことこそが、本当の意味でのパフォーマンスチューニングだと考えている。