パフォーマンスとはなにか？mizchi氏が見てきた現実
Node.jsやフロントエンドのパフォーマンス領域を専門とするフリーランスエンジニア・竹馬光太郎氏。SNSなどでは「mizchi」の名前でも知られる彼は、現在、各社のクライアントに1ヶ月単位で参画し、Web Vitalsの改善やCI/CD環境の最適化を担う“パフォーマンスの傭兵”として活動している。
現在のスタイルに至った背景には、前職での経験があった。当時、Googleタグマネージャーなどで読み込まれるスクリプトの開発に従事していた時、「このスクリプトのせいでサイトが遅くなっているのでは」と指摘されることが度々あった。疑念を払拭するために、自らスクリプトの有無によるパフォーマンス比較を実施し、無実を証明する術を磨いていった。
多様な現場を訪れるなかで目にしたのは、明らかなボトルネックが放置されている現実だった。「数か月かけて直すような課題ならまだしも、たった1行の修正で改善する問題ですら手つかずのまま残っていることが珍しくなかった」と語る竹馬氏。そんな状況に業を煮やし、“簡単に直せるもの”を素早く特定・可視化するスキルを高めていったという。
本セッションでは、そうした経験をベースに、竹馬氏が「パフォーマンス」と呼ぶものの正体を解き明かした。どのような指標を見て、何をもって“遅い”と判断するのか。サーバーサイドのメトリクスでは捉えきれない、ユーザー体験としての速度を紐解くアプローチに迫っていこう。
Webパフォーマンスの指標Web Vitalsとは？
「Webパフォーマンスとは何か」。現在のフロントエンド領域においては、Web Vitalsを指標とするのがスタンダードとなっている。
Googleが運営するweb.devでは、Web Vitalsの定義や具体的な計算式が公開されている。Chrome DevToolsやPageSpeed Insightsといったツールを使えば、その数値を手軽に確認できる。
では、Web Vitalsにはどんな指標があるのか。以下に代表的な項目を見ていこう。
最も重視されるのがLCP（Largest Contentful Paint）。これは「ユーザーにとって意味のある最大要素（画像や本文など）が表示されるまでの時間」を示す指標で、たとえばブログであれば、タイトルやメイン画像が該当する。GoogleはLCPを2.5秒以内に抑えることを推奨している。
次に重要なのがFCP（First Contentful Paint）。これは、画面に最初の何らかの視覚要素（テキストや画像など）が表示されるまでの時間で、1.5秒以内が理想とされる。
一方、少し難解なのがTBT（Total Blocking Time）やINP（Interaction to Next Paint）だ。これらは、ページが表示されたあとにユーザーの操作がブロックされてしまう時間を測定する指標である。「表示はされているけど、タップしても反応しない」といった状態を捉えるものだ。
TBTやINPは多くの場合、JavaScriptやCSSの評価・実行によってメインスレッドがブロックされていることに起因する。見た目は素早く描画されていても、実際に操作できなければ、それは“遅い”体験に等しい。
「ここで強調しておきたいのは、Web Vitalsはサーバーサイドのメトリクスとは別物だということです。たとえば、APMやRUMで『99パーセンタイルでレスポンス1秒です！』と言われたとしても、それがエンドユーザーにとって快適かどうかはまた別問題なんです」と竹馬氏は語る。
なぜなら、Webページの読み込みには、単なるサーバーレスポンスだけでなく、ブラウザ上でのJS・CSSの評価や描画といったプロセスが含まれるためだ。仮にAPIが900msで返ってきたとしても、それが複数あれば合計3〜4秒。そしてJSの評価にさらに300〜500msかかれば、最終的には5秒以上待たされることになる。
つまり、「サーバーは速いのに、ユーザーには遅く見える」。このギャップを捉えるためにこそ、Web Vitalsは存在しているわけだ。
