--- title: "Lighthouseの点数だけを追いかけると、体感速度を見失うかもしれない" description: "個人技術ブログに CSS View Transitions を実装して気づいた、パフォーマンスの実測値と体感速度の違い。Lighthouse、MPA、SPA、アニメーションについて。" lang: ja url: "https://engineer-blog.tomoki-ttttt.workers.dev/articles/performance-and-transition-ux/" publishedAt: "2026-05-16T17:00:00.000Z" tags: ["performance", "frontend", "astro", "ux", "web"] projectIds: ["tech-blog"] --- ## はじめに 最近、個人技術ブログを作り直している。 今回のブログでは、かなりパフォーマンスを意識している。 できるだけ軽く、できるだけ速く、できるだけ余計な JavaScript を持たない。 そんな方針で Astro を使い、静的なブログとして作っている。 最初はとにかく Lighthouse のスコアを見ていた。 FCP、LCP、TBT、CLS、Speed Index。 数字が良くなると嬉しいし、改善した実感もある。 ただ、作っていくうちに少し考えが変わってきた。 **Lighthouse の点数が良いことと、実際に使って気持ちいいことは、必ずしも同じではない。** このことを実感したのが、SPA 風のページ遷移アニメーションを実装したときだった。 この記事では、その体験をもとに、パフォーマンスの実測値と体感速度の違いについて書いてみる。 ## 最初は Lighthouse のスコアをかなり気にしていた パフォーマンス改善をするとき、最初に見るものとして Lighthouse はかなり分かりやすい。 スコアが出る。 指標が出る。 改善すべき項目も出る。 特に個人開発では、何を改善すればいいか分からない状態になりやすいので、Lighthouse はかなりありがたい。 実際、自分も最初はかなり Lighthouse の点数を気にしていた。 - Performance が何点か - FCP は何秒か - LCP は何秒か - TBT は出ていないか - CLS は 0 に近いか - Speed Index は悪くないか こういう数字を見ながら、CSS を減らしたり、不要な JavaScript を削ったり、画像やフォントを見直したりしていた。 それ自体は悪いことではない。 むしろ、初期表示の改善にはかなり役立つ。 ただ、途中から少し違和感が出てきた。 ## 点数は良いのに、なんか気持ちよくない Lighthouse のスコアは良い。 初回表示も速い。 LCP も悪くない。 TBT もほぼない。 CLS も問題ない。 でも、実際に触ってみると、なんとなく気持ちよくないことがある。 たとえば、 - リンクを押してから画面が変わるまでに一瞬待つ - ページ遷移が急に切り替わる - クリックに対する反応が薄い - 戻る・進むの体験が少し硬い - 数字上は速いのに、体感では少し遅く感じる みたいなことがある。 これは Lighthouse のスコアだけを見ていると気づきにくい。 Lighthouse は主にページの読み込み性能を評価する。 特に初回ロードの指標を見るにはとても便利。 でも、ユーザーが実際にサイトを使うときは、初回表示だけを見ているわけではない。 記事一覧から記事に移動する。 記事から別の記事に移動する。 トップに戻る。 タグページを開く。 何度もページを行き来する。 このときの体験は、Lighthouse のスコアだけでは測りきれない。 ## 初回表示の速さと、ページ遷移の気持ちよさは別物 Webサイトの速さには、いくつか種類があると思う。 たとえば、 - 最初にページが表示される速さ - 画像や本文が見えるまでの速さ - クリックしてから反応があるまでの速さ - ページ遷移が完了するまでの速さ - スクロールや操作が引っかからない軽さ - 操作していて気持ちいいかどうか これらは似ているようで、少しずつ違う。 Lighthouse が得意なのは、主に最初の読み込みに関する評価だと思う。 もちろんそれはとても大事。 特にブログの場合、検索やSNSから直接記事に入ってくることが多いので、初回表示が速いことはかなり重要。 ただ、サイト内を回遊する体験まで考えると、初回表示だけでは足りない。 ページ遷移が気持ちいいか。 クリックした瞬間に反応があるか。 画面の切り替わりが自然か。 読んでいる流れを邪魔しないか。 このあたりも、かなり大事だと感じた。 ## MPAの方が速い。でもSPAの方が速く感じることがある 今回のブログは、基本的には MPA 的な構成で作っている。 Astro を使って静的HTMLを生成し、必要以上にクライアントサイド JavaScript を持たない。 ブログとしてはかなり自然な構成だと思う。 MPA はシンプルで強い。 各ページが独立したHTMLとして配信されるので、初回表示が速くしやすい。 JavaScript への依存も少ない。 壊れにくい。 SEO やアクセシビリティの面でも扱いやすい。 個人ブログにはかなり向いていると思う。 一方で、SPA には SPA の強さがある。 ページ遷移時に画面全体を再読み込みしない。 必要なデータやコンポーネントだけを差し替える。 リンクを押した瞬間に反応を返しやすい。 遷移アニメーションも入れやすい。 その結果、実際の通信や処理の速度とは別に、**体感として速く感じる** ことがある。 これは結構大事だと思っている。 たとえば、MPA の方が実測では速かったとしても、ページがパッと白くなってから次のページが表示されると、ユーザーには少し遅く感じることがある。 逆に SPA では、実際には裏で多少処理が走っていても、クリック直後にアニメーションが始まったり、画面が滑らかに切り替わったりすると、体感としては速く感じる。 つまり、速度には **実測値としての速さ** と **体感としての速さ** がある。 この2つは近いけれど、完全には一致しない。 ## CSS View Transitions を実装してみた このブログに、実際に SPA 風のページ遷移を実装してみた。 使ったのは Astro の `ClientRouter` と、CSS の View Transitions API だ。 `ClientRouter` は、Astro が提供するクライアントサイドルーターで、ページ遷移時にフルリロードをなくして SPA 的な挙動を実現する。 ブラウザのネイティブな View Transitions API と組み合わせることで、ページ間で要素をスムーズに切り替えるアニメーションが実装できる。 やったことは大きく2つだ。 まず、ヘッダー・メインコンテンツ・フッターにそれぞれ `view-transition-name` を設定する。 これにより、ページ遷移時にどの要素をどう扱うかをブラウザに伝えられる。 ```css .site-header { view-transition-name: site-header; } .site-main { view-transition-name: site-main; } .site-footer { view-transition-name: site-footer; } ``` 次に、ヘッダーとフッターはアニメーションなし（即時切り替え）にして、メインコンテンツだけに遷移アニメーションを当てる。 ヘッダーが毎回フェードすると落ち着かない。メインだけ動かすことで、「ページが変わった」という自然な文脈が生まれる。 ```css ::view-transition-old(site-header), ::view-transition-new(site-header), ::view-transition-old(site-footer), ::view-transition-new(site-footer) { animation: none; } ``` この実装の前後で、Lighthouse のスコアはほとんど変わらなかった。 Performance、FCP、LCP、TBT、CLS——数字は動かない。 でも、実際にリンクをクリックしたときの体感はかなり変わった。 実装前は、クリックするとページが一瞬白くなり、次のページが表示される。 実装後は、コンテンツがフッと消えて、次のコンテンツが現れる。 ヘッダーはその間もずっとそこにある。 「速くなった」というより「引っかかりがなくなった」に近い感覚だ。 これが、実測値と体感速度の差を最も強く感じた体験だった。 Lighthouse では測れない部分に、体感の改善が確かにあった。 ## アニメーションは悪ではない パフォーマンス改善をしていると、つい「アニメーションは重いから削るべき」と考えがちになる。 もちろん、やりすぎたアニメーションは良くない。 - スクロールに追従して大量に動く - JavaScript で重い計算をする - レイアウトを何度も再計算させる - 低スペック端末でカクつく - 読む邪魔になる こういうアニメーションは、体験を悪くする。 ただ、アニメーション自体が悪いわけではない。 むしろ、適切なアニメーションは体感速度を上げると思っている。 たとえば、 - リンクを押した瞬間に反応がある - ページが自然に切り替わる - 表示の変化に文脈がある - いきなり切り替わらず、視線が迷わない - 待ち時間が「待たされている感」になりにくい こういう効果がある。 パフォーマンスの数字だけを見ると、アニメーションは余計なものに見えるかもしれない。 でも、ユーザー体験として見ると、むしろ必要な場合もある。 大事なのは、アニメーションを入れるかどうかではなく、**何のために入れるのか** だと思う。 装飾のためだけに入れるなら、削った方がいいかもしれない。 でも、操作へのフィードバックや画面遷移の自然さのために入れるなら、多少のコストを払ってでも入れる価値がある。 ## 「速いサイト」と「気持ちいいサイト」は少し違う 今回ブログを作りながら思ったのは、速いサイトと気持ちいいサイトは少し違うということ。 速いサイトは、数字である程度見える。 FCP が速い。 LCP が速い。 TBT が小さい。 CLS がない。 JavaScript が少ない。 HTML が軽い。 こういうサイトは、確かに速い。 でも、気持ちいいサイトにはそれだけでは足りない。 クリックしたときにすぐ反応する。 遷移が自然。 スクロールが軽い。 画面の切り替わりに違和感がない。 読んでいる途中で集中が切れない。 こういう部分は、スコアには出にくい。 だから、パフォーマンス改善では Lighthouse だけではなく、実際に触ることが大事だと思った。 特にスマホで触る。 何度もページ遷移する。 戻るボタンを押す。 記事一覧から記事に入る。 記事を読み終わって別の記事に移る。 そういう普通の動きを何度も試して、気持ち悪いところを見つける。 これは地味だけど、かなり大事だと思う。 ## 個人ブログでは、どこまでやるべきか とはいえ、個人ブログで SPA のようなリッチな構成に寄せすぎるのも違うと思っている。 ブログは、まず文章を読む場所。 初回表示が遅くなったり、JavaScript が増えすぎたり、壊れやすくなったりするなら、本末転倒だと思う。 なので、今の自分の考えとしてはこんな感じ。 - 初回表示はできるだけ静的に速くする - 基本は MPA 的なシンプルな構成にする - ただしページ遷移の体感はちゃんと見る - 必要なら軽いアニメーションを入れる - prefetch はやりすぎず、効果がありそうなところに限定する - SPA風の体験は、必要な範囲だけ取り入れる 全部を SPA にする必要はない。 でも、MPA だからといって、ページ遷移体験を諦める必要もない。 静的なブログでも、CSS View Transitions や限定的な prefetch を使えば、ある程度 SPA っぽい気持ちよさは作れる。 重要なのは、技術的な分類ではなく、実際に使ったときにどう感じるかだと思う。 ## Lighthouseはゴールではなく、出発点 Lighthouse は便利だ。 パフォーマンス改善の入口としては、今でもかなり信頼している。 自分も今後も使うと思う。 ただ、Lighthouse のスコアを上げること自体をゴールにすると、少し危ない。 スコアは良いのに、使っていて気持ちよくない。 数字を守るために、必要なフィードバックまで削ってしまう。 初回表示だけを見て、ページ遷移や回遊体験を見落とす。 そういうことが起きるかもしれない。 だから今は、Lighthouse はゴールではなく、出発点だと思っている。 まず Lighthouse で明らかな問題を見つける。 そのうえで、実際に触って確認する。 数字と体感の両方を見る。 このバランスが大事だと思う。 ## おわりに 個人技術ブログを作る中で、パフォーマンスについてかなり考えた。 最初は Lighthouse の点数を上げることばかり気にしていた。 でも、作って触っているうちに、ページ遷移の気持ちよさや、操作したときの反応も同じくらい大事だと感じるようになった。 Webサイトのパフォーマンスは、数字だけでは決まらない。 もちろん、FCP や LCP などの指標は大事。 でも、それと同じくらい、ユーザーが触ったときにどう感じるかも大事。 速いだけではなく、気持ちよく読めるブログにしたい。 今後も、初回表示の速さとページ遷移体験のバランスを見ながら、少しずつ改善していきたい。