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