Lighthouse 56点だった——サイトの表示速度を改善した話

マッハでサイトを公開してから数日、細かい修正をちまちま重ねていた。フォントを変えたり、余白を調整したり、ページを増やしたり減らしたり。

そうやっていじっているうちに、ふと気づいた。

Journalページだけ、明朝体になっている。

フォントがチグハグだった

Aboutページはゴシック体（Noto Sans JP）なのに、Journalページは明朝体（Noto Serif JP）。修正を重ねるうちに、どこかで指定がズレていたらしい。

Claude Codeに調べてもらったら、原因は1行だった。Journalのh1に font-serif が残っていた。Aboutは font-sans。直すのは一瞬。

でも、ここで気になった。明朝体のフォント、もう使ってないのにまだ読み込まれてるんじゃないか。

そのまま、サイト全体の速度を測ってみることにした。

Lighthouse 56点

GoogleのLighthouseで計測した結果がこれだった。

Performance: 56点
First Contentful Paint: 5.4秒
Largest Contentful Paint: 13.7秒
Speed Index: 11.8秒

ヘッドレスCMS（Sanity）＋ Next.js ＋ Vercelという構成を選んだ理由のひとつは、速さだった。WordPressのようにサーバーでページを生成するのではなく、静的に配信できる。CDNでキャッシュも効く。それなのに、56点。

サーバーの応答時間は20ms。ここは狙い通り、爆速。でもユーザーが体感する表示速度はそれとは別の話だった。

原因を調べる

Lighthouseの詳細を見ると、ボトルネックが見えてきた。

1. 使っていないフォントの読み込み（Noto Serif JP）

明朝体はもうどこにも使っていない。なのにCSSの@font-face宣言と、フォントファイルのダウンロードが走っていた。

2. フォントのウェイトが多すぎる

Noto Sans JPを400/500/700/900の4ウェイトで読み込んでいた。500（medium）はほとんど使っていない。

3. DM SansとDM Mono の取り違え

仕様書には「日付等にはDM Mono」と書いてあるのに、実装ではDM Sans（プロポーショナル）が入っていた。似た名前だから気づかなかった。

4. Sanity Visual Editingのバンドル

Sanityの編集プレビュー機能（Visual Editing）が、一般ユーザー向けのページにもJSとして配信されていた。約180KB。使うのは管理者がプレビューするときだけなのに。

一つずつ潰す

やることは見えた。一個ずつ片付けていく。

Noto Serif JPを完全削除。Tailwindの設定ファイルからも、CSSからも、全部消した。

Noto Sans JPのウェイトを4種から3種に減らした。500はどこにも使ってなかったので、迷わず削除。

DM SansをDM Monoに差し替えた。仕様書通りのモノスペースに統一。

Visual Editingは、Draft Mode（プレビューモード）のときだけ読み込むように変更した。普通にサイトを見ている人には、この182KBのJSは一切届かない。

全部合わせて、作業時間は1時間もかかっていない。

結果

改善後のLighthouseスコア。

Performance: 62〜66点（+10）
Speed Index: 4.1〜7.0秒（11.8秒からほぼ半減）
First Contentful Paint: 3.8秒（-1.6秒）
Largest Contentful Paint: 7.4〜8.1秒（13.7秒からほぼ半減）

10点。数字だけ見ると地味かもしれない。

でも体感は明らかに変わった。Speed Indexが11.8秒から4秒台になっているので、ページが見え始めるまでの時間が半分以下になっている。開いた瞬間の「待たされてる感」がなくなった。

これ、昔だったら自分ではやらなかった

ここからが、この記事で本当に書きたかったこと。

パフォーマンスチューニングの基本は、実は知っている。過去にWebディレクターをやっていたから。計測して、ボトルネックを特定して、優先順位をつけて改善する。考え方自体は知っていた。

でも「知っている」と「自分でやる」の間には、けっこうな距離がある。

ディレクターの仕事は、課題を整理してエンジニアに渡すことだった。「フォントが重いから削ってください」「このJSは条件付きロードにしてください」。指示は出せる。

でも自分でコードを書いて、設定ファイルを直して、ビルドして確認するってのところは人に頼んでいた。

今回、それを全部AIと二人でやった。

「このフォント、もう使ってないけど読み込まれてる？」と聞いたら、設定ファイルを全部調べてくれる。「Visual Editingって一般ユーザーにも配信されてる？」と聞いたら、バンドルサイズまで出してくれる。自分は「何がおかしいか」を言語化するだけでよかった。

ディレクションと実装の境界が、溶けた感じがした。

知識はある。でも手が動かせなかった領域。そこをAIが埋めてくれた。逆に言えば、AIだけでは「何がおかしいか」は見つけられない。最初に「明朝体が残ってるの、気持ち悪いな」と思ったのは自分だし、「使ってないフォントがまだ読み込まれてるんじゃないか」と疑ったのも自分。

人間の直感と、AIの実行力。この組み合わせが、たぶん一番速い。

「Webは下火だ」って最近よく聞く。たしかにそうかもしれない。ちょっとしたサイトならAIで余裕で全部作れてしまう。でも今回の経験で、ちょっとだけ思ったことがある。その話はまた別で書く。

まだLCPは7秒台で、理想の4秒以下には届いていない。日本語Webフォントの重さに加えて、画像の最適化もまだ手をつけていないので、改善の余地はある。

続きはまたそのうち。