Next.js を削除したらブログの Lighthouse カテゴリがすべて 100 になった

Next.js を削除したらブログの Lighthouse カテゴリがすべて 100 になった

私のブログは、Lighthouse の全カテゴリで満点の 100 を獲得しました。ブログを書くのが大好きです。軽快で、高速で、ごちゃごちゃしておらず、複数のブログを運営でき、さらに完全にアクセシブルなブログを構築したいと思っていました。そしてついに、長い時間をかけて、ほぼそれを実現しました。それはかなり骨の折れるプロセスでした。うーん…そして、最も使用していたフレームワークである Next.js を削除しなければなりませんでした。予想以上にずっと、ずっと大変でした。このブログを構築しながらパフォーマンスを改善した道のりを共有したいと思います。

なぜ自分でブログを構築することにしたのか？

ブログと聞くと、いくつかの名前が思い浮かびます。Medium、Blogger、Ghost…しかし、どれも私を満足させませんでした。Medium と Blogger は機能が多すぎて、実際のパフォーマンスも満足のいくものではありませんでした。

Blogger

［画像: Blogger の PageSpeed Insights スクリーンショット］

Medium

［画像: Medium の PageSpeed Insights スクリーンショット］

［画像: しかめっ面］

本当に恐ろしい。

うーん……もう一つ問題がありました。私たちが愛するマークアップと生のコード（Markdown、HTML、CSS）を直接扱うのは面倒だということです。

ちなみに、すべてのパフォーマンス測定は pagespeed.web.dev で行われました。

もちろん、WordPress、Ghost、Hugo など、多くの代替手段があります。WordPress のプラグイン地獄は好きではありませんでした。Ghost はセルフホストする必要があり（ghost.org もありますが、高すぎます…）、バージョンアップのたびにエディターで何かが壊れるので、最新の状態に保つのは大変でした。Hugo はその中でも最高ですが、結局、セットアップはやはり面倒です。振り返ってみると、私が本当に欲しかったのは SaaS だったのだと思います。

私が最も気に入ったのは Bear Blog でした。パフォーマンスが素晴らしいです。製品の哲学も気に入っています。しかし、その極端なミニマリズムは私にとっては欠点でした。エディターの UX も私には合いませんでした。

もし AdSense を追加したり、無料で画像を添付できたりしたなら、おそらく Bear Blog を使っていたでしょう。

Bear Blog と同じくらい高速で、もう少し機能があり、使い勝手が良いもの。それが私が構築したかったブログです。 ああ、もし興味があれば、bloffy.co で確認できます。

とにかく。私自身の話はこれくらいにして、実際にパフォーマンスをどのように改善したかをお伝えしましょう。

Lighthouse パフォーマンスで 100 を目指しましょう。

［画像: 亀に乗る柴犬］

当然ですが、キャッシュは必須です。

キャッシュが不可欠であることは言うまでもありません。キャッシュを正しく設定すれば、パフォーマンスは劇的に向上します。そして、Next.js はキャッシュを非常に便利にしてくれます。ISR があり、また fetch をキャッシュ用の next オプションで拡張 することもできます。便利です。これらをうまく活用するだけでも、パフォーマンスは大きく向上します。

残念ながら、私たちのサイトは世界中どこからでもアクセス可能です。なぜ残念なのでしょうか？同じ地域内ではキャッシュによって高速になりますが、他の地域の訪問者は依然としてネットワーク遅延の影響を受けます。

いや、そんなことはありません。CDN があります。

はい。だからこそ CDN を使用します。そして、Next.js アプリを Vercel にデプロイすれば、CDN が標準で利用できます。Vercel が嫌いなわけではありません。信じられないほど便利です。しかし、Pro プランは最初から高価で、サーバーレスのコールドスタート問題があり、Vercel エコシステムへの依存も無視できません。

では、別の CDN サービスを使わないのはなぜでしょうか？例えば Cloudflare です。正直、Cloudflare は本当に素晴らしい会社だと思います。大規模なインフラストラクチャとほとんどのアプリを無料で実行できます。しかし、その時、Next.js のキャッシュはもう必要ないことに気づきました。投稿を公開するたびに 2 つのキャッシュを無効化しなければならないのは、管理が面倒です。

要するに、静的ウェブサイトであれば、CDN だけで十分だと考えました。そして、それが私が Next.js を必要としなかった理由の 1 つです。

画像最適化。

最近の画像は 10MB を超えることがあります。これらをそのままウェブで提供すると、パフォーマンスは完全に破綻します。

［画像: 後ろを振り返って驚いている白いフクロウ］

画像の最適化はかなり面倒です。デバイスごとにリサイズし、圧縮し、さらに CDN を処理する必要があります。以前のプロジェクトでは、ストレージ（S3）に画像が配置されるたびに画像を圧縮・リサイズするサーバーレス関数（AWS Lambda）を使用し、CDN として CloudFront を前面に配置しました。これは、私が望むとおりに正確に調整するための非常に合理的なセットアップでした。しかし、それはかなりのメンテナンスが必要なセットアップでもあります。

そこで今回は Cloudflare の Image Transformations を利用しました。無料ティアでも 5,000 枚の画像が利用できるので、何も考えずに使用しています。

この時点で、私は Cloudflare の営業担当者のように聞こえるかもしれません。私はただの普通の個人開発者です。

さて、あれこれキャッシュと画像最適化を行った後の Next.js ブログのパフォーマンスです。

［画像: Next.js で構築された Bloffy の PageSpeed Insights スクリーンショット］

参考までに、これは Next.js 16.1.6 でした。

かなり高いスコアです。しかし、これでは不十分です。私たちは 100 を求めています。 余計なものがない、純粋な 100 です。そこで、何が問題なのかを掘り下げました。

［画像: Lighthouse レガシー JavaScript 監査］

かなりの量のレガシー JavaScript が見つかり、それは私が書いたコードではないと表示されました。それは Next.js がバンドルに含めるフレームワークランタイムから来ていました。

しかし、このページはインタラクションがゼロの静的ページです。すべてのページは ISR で事前レンダリングされており、Next.js のガイドラインに沿ってうまくやっていると思っていました。そこで実験として、アプリが持つすべてのクライアントコンポーネントを剥ぎ取り、サーバーコンポーネントだけを残して再度測定しました。スコアは変わりませんでした。

最初は ハイドレーション を疑いましたが、掘り下げてみると、問題はハイドレーションだけではありませんでした。原因は、静的ページであっても Next.js が常に含めるクライアントランタイムでした。 サーバーコンポーネントだけの場合でも、ランタイムチャンク、ハイドレーション、ルーターの RSC ペイロードはすべて残ります。これは、next/link と next/image 自体がクライアントコンポーネント（'use client'）であるため、これら 2 つだけが含まれていてもランタイムが読み込まれ、ハイドレーションがトリガーされるからです。

では、next/link と next/image も削除したらどうなるでしょうか？App Router 独自のランタイム、ルーター、エラーバウンダリは依然として残ります。それをゼロに減らす公式な方法はありません。唯一の選択肢はハックでした。レンダリングされた HTML からスクリプトを削除することです。その時、私は思いました。「それをするなら、なぜ Next.js を使っているのだろう？」

そして、未使用のコード。

［画像: qa-a.bloffy.co のカバレッジ］

JavaScript の大部分が必要ないコードであることがわかります。未使用のコードだけでも 230,460 バイトです。これは良くありません。ほとんどの静的ウェブサイトは JavaScript を全く必要としません。未使用の JavaScript はさらに必要ありません。

ここで本当に悩みました。100 点のために Next.js をドロップするのは正しい判断なのか？公開されているウェブアプリの構築に多くの時間を費やしました。

Next.js を削除しましょう。

最終的に、ブログの品質（たとえ 5 点であっても）のために、Next.js を完全に削除することを決めました。長期的に見ても Next.js の過剰な機能は必要ないだろうと判断しました。完全にバニラにするか検討しましたが、フレームワークの生産性とインフラストラクチャの利点を諦めたくはありませんでした。適切なものを見つける必要がありました。

私は Hono を選びました。その技術哲学が好きでした。「高速でシンプル」はまさに私が最も必要としていたソリューションであり、JSX サポートもボーナスでした。移行コストも大きくないように見えました。

ジャジャーン。ついに、100 点です。

［画像: qa-b の Bloffy の PageSpeed Insights スクリーンショット］

ジャジャーン。そして、あっという間に、すべての項目で 100 点になりました。今読んでいるページ自体を pagespeed.web.dev で実行してみてください。

［画像: qa-b.bloffy.co のカバレッジ］

JavaScript はなく、未使用コードは 407 バイトに激減しました。さらに、ビルド時間も約 40% 短縮されました。

ああ、なぜ SEO が 69 点なのか？そのサイトはテスト用に構築されたもので、検索インデックスを意図的にブロックしています。だから 69 点なのです。

［画像: すべての Lighthouse スコアが 100］

ちなみに、DevTools で全て 100 点を獲得すると、Lighthouse は実際に花火を打ち上げてくれます。🎉🎉

Hono vs. Next.js パフォーマンス

Next.js パフォーマンス（サーバーコンポーネントのみ）

［画像: サーバーコンポーネントのみで構築された Next.js のパフォーマンス］

Hono パフォーマンス

［画像: Hono のパフォーマンス］

画面に何もレンダリングされる前に実行されるロングタスクは、Next.js では 309.3ms でしたが、同じページを Hono で構築した場合は 68.01ms でした。これは約 78% の改善です。

あなたの静的サイトは本当に Next.js が必要ですか？

JavaScript のペイロードとハイドレーションは、静的サイトに本当に良い影響を与えているのでしょうか？私はそうは思いません。不要な JavaScript を残してしまうため、ほとんどの場合、それは単に不要だと考えます。

とは言え、インタラクションが多いアプリであれば、Next.js は素晴らしいフレームワークになり得ると考えています。実際、このブログの管理アプリは Next.js で構築されています！