ブログ記事
「推測するな、計測せよ」——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）というパイプラインに対応するかたちで改善アプローチが解説されるため、「今自分はどの処理段階の話を読んでいるか」が常に明確だ。
flowchart LR
A["Loading\nリソース読み込み\n（ネットワーク）"] --> B["Scripting\nJS実行\n（イベントループ）"]
B --> C["Rendering\nレイアウト計算\n（リフロー）"]
C --> D["Painting\n描画・GPU合成\n（レイヤー）"]
D -->|"DevToolsで計測\n→ ボトルネックを特定"| A
style A fill:#e8f4fd,stroke:#4a9eda
style B fill:#fff8e1,stroke:#f5a623
style C fill:#e8f8e8,stroke:#4caf50
style D fill:#f3e5f5,stroke:#9c27b0
たとえば、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、投機的なリソース先読みといったアプローチが紹介される。
数値を詰めるだけでは届かない「遅く感じさせない設計」の話で、パフォーマンスを純粋な速度問題として見ている人には少し意外な章かもしれない。個人的にはここだけでも読む価値があると思っている。UI設計の議論に使える材料が多い。
5. この本が効く場面
「アニメーションがカクつくという報告を受けたが、JavaScriptが重いのかレイアウト計算が重いのか、どこから調べればいいかわからない」——この詰まりの原因は知識の量ではなく、ブラウザのどの処理段階で時間が消えているかを切り分ける手順を持っていないことにある。本書のDevToolsによる計測手順とLoading/Scripting/Rendering/Paintingの区分を使えるようになると、「なんとなく重い」という感想が「レイアウト再計算が多発している」という診断に変わり、対処もその段階にピンポイントで打てるようになる。
「表示速度の改善を任されたが、施策の効果を客観的なデータで証明できない」という場面にも効く。計測してから直すという順序が習慣になると、改善報告が「速くなった気がする」から数値の前後比較に変わり、次の施策の優先順位も数字で議論できるようになる。
6. 向いている人・向いていない人
向いている人：
- すでに動いているサービスの表示改善を担当していて、感覚頼みの修正から抜け出したい
- ReactやVue.jsを実務で使っており、抽象化の下で起きているブラウザの物理的な挙動を自分の言葉で説明できるようになりたい
- HTML・CSS・JavaScriptの基本的なコーディングには不自由しない
向いていない人：
- HTML・CSS・JavaScriptをこれから学ぶ人。本書は動くサービスを運用している開発者を想定しており、入門書ではない
- Reactのメモ化のような、フレームワークのレイヤーでの最適化の処方箋を探している人。本書の主戦場はその一段下のブラウザレイヤーで、フレームワーク固有のテクニックは扱わない
7. 読み方ガイド
全9章はブラウザの処理の進行に沿って並んでおり、前から順に読む設計になっている。第1〜3章で「ウェブパフォーマンスとは何か」の定義、ブラウザのレンダリングの仕組み、チューニングの基礎を固め、第4〜7章はリソース読み込み・JavaScript実行・レイアウトツリー構築・描画の各チューニングと、パイプラインの順序そのままに対応する。初読ならここまでを順番に通すと、どの処理段階にどの施策が効くかという地図が頭に残る。
目の前の問題が既に絞り込めているなら、該当する章からの拾い読みも成立する。各章の冒頭にはブラウザ内部のどのイベントを扱うかを示す構成図が置かれているため、途中の章から入っても現在地を見失いにくい。第9章「認知的チューニング」は他の章への依存が薄く、UI設計への関心が強ければここだけ先に読む手もある。
8. 読後の次の一歩
本書で手に入るのは、速さという「測れる品質」を計測で追い込む道具立てだ。次の一冊として、DevBookPathのマップでは『Webアプリケーションアクセシビリティ』への接続を置いている。アクセシビリティはパフォーマンスと同じく後から付け足すことが難しい横断的な品質で、測れる品質を追求した後に視野を広げる先として据わりがいい。計測と改善を繰り返してきた人は、「誰もが使えるか」という問いにも同じ姿勢で向き合いやすい。
実務での最初の一歩は、担当プロダクトの画面を一つ選び、DevToolsで記録を取って、Loading/Scripting/Rendering/Paintingのどの段階に時間が使われているかを眺めること。修正はまだしなくていい。「推測するな、計測せよ」を自分のプロダクトで一度実行することが、本書の内容を知識から手癖に変える入口になる。
筆者の体験から
社内の管理画面で「一覧がカクつく」という声が届き対応を任されたのが、本書を買った経緯だ。怪しい箇所にuseMemoを足すような直し方しかできず、上司に効果を聞かれても体感でしか答えられなかった。見かねた先輩にタイムラインを見てから直せと言われ、その手順を解説する本として勧められた。
この本のあとは修正前にタイムラインを記録する習慣がつき、報告の言葉も体感頼みから、レイアウトの発生回数がどれだけ減ったかという具体的な数字ベースに変わった。惜しいのは、DOM操作を直接最適化するコード例で、実装がほぼReact経由の自分の環境ではそのまま使える場面が少なかった点だ。
象徴的だったのは、絞り込みタグを追加するたびアニメーションがガクつく不具合だ。JSが重いと当たりをつけロジックを軽くしてみたが変わらず、タイムラインを取ると原因はレイアウト再計算の多発で、CSSがtop/left系のプロパティを毎回動かしていたことだった。transform/opacityへ書き換えると再計算はほぼ消え、疑った場所と原因の食い違いを思い知った。
DevBookPath のマップで確認する
この本の学習パス上の位置づけ・前後の読書順は、DevBookPath のグラフで辿れます。
本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。
この記事を共有
この地図を共有