Автор блогу прибрав Next.js і отримав 100 балів у всіх категоріях Lighthouse

Автор платформи Bloffy прибрав Next.js із публічної частини свого блогу й отримав 100 балів у всіх категоріях Lighthouse. У матеріалі від 26 жовтня 2026 року він пояснює, чому для майже неінтерактивних сторінок обрав Hono. Як пише автор блогу, кешування та оптимізацію зображень уже було налаштовано, але на сторінки й далі завантажувався JavaScript фреймворку.

Чому кешування та оптимізації зображень виявилося недостатньо

Автор хотів зробити легкий блог із можливістю вести кілька блогів і сторінками, доступними користувачам. Наявні сервіси не підійшли йому з різних причин: одні здавалися перевантаженими, інші не забезпечували потрібної зручності під час роботи з Markdown, HTML і CSS. Так він узявся розробляти власну платформу.

Спочатку відмовлятися від Next.js не планували. Автор використовував кешування фреймворку та CDN, щоб зменшити затримки для відвідувачів із різних регіонів. Згодом вирішив, що статичному сайту достатньо CDN: під час публікації допису було незручно керувати ще й кешем Next.js, скидаючи обидва кеші.

Обробку зображень він довірив Cloudflare Image Transformations замість власного рішення для обробки файлів, яке довелося б підтримувати. За його словами, на безкоштовному тарифі доступно 5000 зображень. Після цих змін блог на Next.js 16.1.6 уже отримував високі оцінки, але не 100 балів. Вимірювання автор проводив через pagespeed.web.dev.

Що змінилося після переходу на Hono

Під час подальшого аналізу автор виявив застарілий JavaScript, якого сам не додавав. Він прибрав клієнтські компоненти застосунку й залишив лише серверні, але оцінка не змінилася. За його спостереженнями, на статичній сторінці все одно залишалися частини клієнтського середовища Next.js: скрипти, потрібні для маршрутизації та гідратації. Компоненти next/link і next/image також підключали клієнтський код.

Навіть відмова від цих двох компонентів не усувала код App Router. Щоб повністю прибрати скрипти, довелося б обхідним шляхом вирізати їх із готового HTML. Автор вирішив перенести публічну частину на Hono: йому підійшли простота фреймворку та підтримка JSX. Застосунок для керування блогом при цьому залишився на Next.js — для нього автор вважає цей інструмент доречним.

До переходу обсяг невикористовуваного JavaScript становив 230 460 байтів, після — 407 байтів. На новій публічній сторінці, за словами автора, JavaScript не завантажується. Час збірки скоротився приблизно на 40%. Тривале завдання перед відображенням сторінки займало 309,3 мс на Next.js і 68,01 мс на Hono — приблизно на 78% менше.

Автор повідомляє про 100 балів у всіх категоріях для сторінки блогу. Водночас у матеріалі є й результат тестового сайту з оцінкою SEO 69: на ньому навмисно заборонено індексацію. Ці показники стосуються різних сторінок, а виграш у мілісекундах не варто сприймати як обіцянку такого самого результату на будь-якому сайті.

Що це означає для власника сайту

Головне практичне питання — що відвідувач робить на конкретній сторінці. Якщо він переважно читає матеріал, розробнику варто перевірити, скільки коду завантажується заради можливостей, якими сторінка не користується. Для інтерфейсу зі складними діями рішення може бути іншим: автор залишив Next.js у застосунку для керування блогом.

Перш ніж змінювати фреймворк, розумно виміряти швидкість і перевірити склад завантажуваного коду. У цьому випадку кешування та оптимізацію зображень уже було налаштовано, а причиною подальшої переробки став JavaScript, що залишався на статичних сторінках. Перехід означав переробку створеної публічної частини, тому оцінювати варто не лише бали Lighthouse, а й обсяг самої роботи.

Моя думка: простота має виправдовувати переробку

Мені близька думка, що не варто залишати на сторінці складний інструмент лише тому, що його вже обрали. Але я б не ставив за мету 100 балів у всіх чотирьох категоріях за будь-яку ціну. Для невеликого магазину, як-от наша майстерня із запчастинами, швидкість важлива, проте мені ще потрібно самому оновлювати залишки. Якщо гонитва за оцінкою ускладнить це звичне завдання, користь буде сумнівною.

Я б спочатку визначив обсяг робіт і бюджет, а потім порівнював варіанти на тих сторінках, які справді потрібні магазину. Поки асортимент і процеси прості, готова платформа здається мені розумнішим вибором, ніж власне рішення. WordPress для невеликого магазину теж підходить, якщо за ним регулярно стежити. Фіксована вартість зручна, коли заздалегідь зрозуміло, які сторінки та процеси змінюються. Тому я сприймаю цей досвід не як пораду відмовитися від Next.js, а як привід звірити можливості інструменту з повсякденною роботою сайту.

Джерела

Звідки новина. Текст — переказ своїми словами, факти — з джерела, думка — автора.

1. Removing Next.js Got My Blog to 100 on Every Lighthouse Category korindiehacker.bloffy.blog

Про автора

Фелікс Уус

Власник майстерні з ремонту велосипедів

У нас невелика майстерня й магазин запчастин у Тарту; хочу поступово перевести частину продажів в інтернет. Порівнюю CMS і способи оплати, але спершу перевіряю, чи зручно мені самому оновлювати залишки.

Усі публікації автора