「推測するな、計測せよ」——2017年刊行のパフォーマンス本がReact時代でも通用する理由

ReactやVue.jsを使いこなしていても、スクロールのカクつきや表示の重さが解消できない——そういう場面で、多くの人は感覚でコードに手を入れ始める。「このDOMの更新が重そう」「このAPIが遅い気がする」。当たっているかどうかは計測しないとわからないのに。

久保田光則の『Webフロントエンド ハイパフォーマンス チューニング』（技術評論社、2017年）は、2017年刊行でありながら今もフロントエンドのパフォーマンス改善を論じる場でよく名前が挙がる一冊だ。モダンフレームワークが当たり前になった現在でも参照され続ける背景には、本書が扱うテーマがフレームワーク固有の話ではなく「ブラウザがHTMLを受け取って画面に描画するまでの物理的な処理」に根ざしているからだろう。

1. 勘ではなくDevToolsの数字で語る

本書が一貫して主張するのは「推測するな、計測せよ」という姿勢だ。

Chrome DevToolsのタイムラインを使ってJavaScriptの実行負荷やレイアウト再計算の発生箇所を可視化し、数値として問題を特定してから対処する——この手順を実践として身につけることが本書の目的のひとつだ。計測の前段階として「RAILモデル」も紹介されており、応答性・アニメーション・アイドル処理・読み込みという4つの観点から何ミリ秒以内に応答すべきかの目標値を定める枠組みが提示される。主観的な「遅い・速い」をUXの定量指標に落とし込むことで、改善の効果も数値で検証できるようになる。

2. パイプラインに沿った章構成が知識を整理しやすい

本書の特徴的な構成は、ブラウザのレンダリング処理の順番に沿って章が並んでいる点にある。リソース読み込み（Loading）、スクリプト実行（Scripting）、レイアウト計算（Rendering）、描画とGPU合成（Painting）というパイプラインに対応するかたちで改善アプローチが解説されるため、「今自分はどの処理段階の話を読んでいるか」が常に明確だ。

たとえば、CSSアニメーションで top や left を動かすのではなく transform や opacity を使うべき理由も、単なるTipsとしてではなく「どちらがGPUレイヤーを活用できるか」という描画パイプラインの文脈で説明される。このような「なぜそうするか」の根拠がパイプラインに紐づいているため、新しい状況でも応用が効く。

3. モダンフレームワーク時代でも通用する理由

2017年以降、ReactやVue.jsによる仮想DOM中心の開発が普及し、直接DOMを操作する機会は大きく減った。本書で登場するDOMの手動最適化コードが現代の実務に直結しにくい場面があるのは事実だ。また、asm.jsなど現在は主流でない技術についての記述や、Chrome以外のブラウザ固有の検証手順が薄い点はレビューでも指摘されることが多い。

それでも本書の価値が失われていない理由は、Core Web Vitalsとの接続にある。近年のWebパフォーマンスの評価指標であるLCP（読み込み性能）やCLS（視覚的安定性）は、本書が扱うリソース読み込みの最適化やimg要素のサイズ固定といった施策と直接つながっている。フレームワークの抽象化層の下で何が起きているかを理解していると、フレームワークのパフォーマンス問題にぶつかったときの調査の起点が変わる。仮想DOMを使っていても、最終的にはブラウザのレンダリングパイプラインを経て画面に表示されるという事実は変わらない。

4. 技術的限界を「知覚設計」で補う

本書の第9章「認知的チューニング」は、通信帯域や処理速度という物理的な制約を前提にしながら、ユーザーの体感時間をどう設計するかというテーマを扱う。スケルトンスクリーン（コンテンツが読み込まれる前に全体の骨格を表示する手法）や、処理完了前に完了したように見せる楽観的UI、投機的なリソース先読みといったアプローチが紹介される。

数値の最適化だけでは届かない「遅く感じさせない設計」の話はUXエンジニアリングの領域にも踏み込んでおり、パフォーマンスを純粋な速度問題として捉えるより広い視野を提供してくれる。この章単独でも、UI設計の議論に使える材料が多い。

DevBookPath のマップで確認する

この本の学習パス上の位置づけ・前後の読書順は、DevBookPath のグラフで辿れます。

フロントエンドの地図を見る

---

本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。