Разработчик заменил Next.js на Hono и заявил о 100 баллах в Lighthouse

Разработчик-одиночка, который делает платформу для блогов Bloffy, рассказал, как довёл свой блог до 100 баллов в каждой категории Lighthouse. Для этого ему пришлось отказаться от Next.js (версия 16.1.6), с которым он работал чаще всего, и переписать сайт на фреймворке Hono. Все замеры сделаны на pagespeed.web.dev.

Сначала автор сделал всё, что обычно советуют. Он настроил кэширование (ISR и опцию next у fetch), но решил, что для статичного сайта хватит одного CDN: иначе при каждой публикации приходится сбрасывать два кэша. Vercel с готовым CDN он отверг из-за дорогого тарифа Pro, холодных стартов serverless-функций и привязки к экосистеме, а взял Cloudflare. Изображения (по его словам, сейчас они часто весят больше 10 МБ) он обрабатывал через Cloudflare Image Transformations; на бесплатном тарифе, как пишет автор, доступно 5000 изображений. Результат на Next.js был «довольно высоким», но не 100.

Любопытно, что Lighthouse жаловался на устаревший JavaScript, причём не на код автора, а на среду выполнения (runtime) самого Next.js. Тогда автор убрал все клиентские компоненты и оставил только серверные, но оценка не изменилась. Причина, по его словам, не только в гидратации: Next.js всегда отдаёт клиентский runtime, даже для статичных страниц. Остаются runtime-чанки, гидратация и RSC-данные для роутера. Компоненты next/link и next/image сами являются клиентскими ('use client'), так что одних их достаточно, чтобы подтянуть runtime и запустить гидратацию. Если убрать и их, всё равно остаётся собственный runtime App Router (роутер и границы ошибок). Официального способа свести его к нулю автор не нашёл: оставался только обходной приём, вырезать скрипты из готового HTML. После этого он задумался, зачем тогда вообще нужен Next.js. Неиспользуемого кода при этом набиралось 230 460 байт.

Автор признаёт, что решение далось тяжело: он долго делал публичную часть на Next.js. Но он решил, что ради качества блога (пусть даже ради 5 баллов) стоит выбросить фреймворк, а лишние возможности ему не пригодятся и в будущем. Писать на чистом JavaScript без фреймворка он не захотел и выбрал Hono: ему понравилась философия «быстро и просто», а поддержка JSX стала приятным дополнением. Стоимость миграции показалась небольшой.

Итог, по словам автора: 100 баллов во всех категориях, на странице нет JavaScript, неиспользуемый код сократился до 407 байт, а время сборки упало примерно на 40%. Длинная задача (long task) до первой отрисовки заняла 309,3 мс на Next.js (только серверные компоненты) и 68,01 мс на Hono, то есть, как пишет автор, примерно на 78% меньше. Оценка SEO на этом тестовом сайте равна 69, потому что он намеренно закрыт от индексации.

Вывод автора: статичному сайту Next.js в большинстве случаев не нужен, а для приложений со сложным взаимодействием Next.js может быть отличным выбором. Панель управления этим же блогом он как раз оставил на Next.js. В конце текста автор рекламирует собственный продукт Bloffy (bloffy.co).

Ключевые факты

Автор убрал Next.js 16.1.6 из статичного блога и переписал его на Hono; по его замерам на pagespeed.web.dev получилось 100 баллов в каждой категории Lighthouse.
Причина штрафа в том, что Next.js всегда отдаёт клиентский runtime, даже для статичных страниц: удаление всех клиентских компонентов оценку не изменило, а next/link и next/image сами клиентские.
На Next.js неиспользуемого кода было 230 460 байт, на Hono, 407 байт, JavaScript на странице нет; время сборки уменьшилось примерно на 40%.
Длинная задача до первой отрисовки: 309,3 мс на Next.js (только серверные компоненты) против 68,01 мс на Hono, примерно на 78% короче.
Автор считает, что статичным сайтам Next.js в большинстве случаев не нужен, а для интерактивных приложений он подходит; текст при этом рекламирует платформу Bloffy самого автора.

Почему это важно

Статья показывает конкретный случай, когда популярный фреймворк мешает набрать максимум в Lighthouse на статичной странице. По описанию автора, даже при одних серверных компонентах Next.js 16.1.6 тащит клиентский runtime, гидратацию и RSC-данные для роутера, а нулевого JavaScript без обходного приёма (вырезания скриптов из HTML) добиться нельзя. Для тех, кто выбирает инструмент для блога или сайта-визитки, это напоминание: «статичная» страница на фреймворке не всегда равна странице без JavaScript.

Кому это важно

Веб-разработчикам, которые делают блоги, документацию и лендинги и сомневаются, нужен ли им Next.js. Тем, кого волнуют показатели Lighthouse и вес страницы. Также тем, кто присматривается к Hono как к лёгкой альтернативе с поддержкой JSX.

Как это применить

Если сайт статичный и интерактивности на нём нет, автор советует начать с вопроса, нужен ли вам фреймворк. Его набор: готовый CDN (он выбрал Cloudflare вместо Vercel), обработка изображений через Cloudflare Image Transformations (по словам автора, на бесплатном тарифе доступно 5000 изображений) и Hono вместо Next.js. Автор оценил стоимость миграции как невысокую, но для собственного приложения, уже написанного на Next.js, переписывание требует времени, и ради нескольких баллов оно оправдано не всегда. Интерактивную панель управления блогом он оставил на Next.js.

Можно ли доверять

Это личный блог разработчика с рассказом о собственном опыте, а не независимый тест. Рекордные цифры (100 баллов, 309,3 мс против 68,01 мс) относятся к одному тестовому сайту автора, замерены на pagespeed.web.dev, при этом версия Lighthouse, число прогонов и параметры устройства и сети не указаны. Показатели версии на Next.js приведены на картинках, а в тексте сказано лишь, что оценки были «довольно высокими». Сам автор не утверждает, что Next.js в принципе не может дать 100: он описывает только свою конфигурацию. Кроме того, текст продвигает его собственный продукт Bloffy.

Риски и подводные камни

Оценка SEO на тестовом сайте равна 69, потому что индексация там специально закрыта, так что «100 везде» относится к остальным категориям. Метод вырезания скриптов из готового HTML автор сам называет хаком. Замена фреймворка стоила автору немалых усилий: он признаёт, что решение далось тяжело, а переход ради нескольких баллов Lighthouse подходит не каждому проекту. Для интерактивных приложений выводы автора не применимы: там он сам считает Next.js хорошим выбором.

«В общем, для статичного сайта я решил, что одного CDN достаточно.»

— автор блога на Bloffy