Як пришвидшити сайт: практичний чеклист

Щоб пришвидшити сайт, спочатку виміряйте його за допомогою PageSpeed Insights, а потім виправте найбільшу причину, яку він покаже, — зазвичай це завеликі зображення, забагато JavaScript, важкі шрифти або сторонні скрипти. Прагніть до «добрих» цілей Core Web Vitals від Google: основний вміст видно за 2,5 секунди, реакція на дотик — за 200 мілісекунд і майже без стрибків макета. Більшість сайтів досягає цього кількома змінами, а не переписуванням.

Спочатку виміряйте

Вгадування марнує час. Два безплатні інструменти покривають майже всіх:

• PageSpeed Insights (pagespeed.web.dev) — вставте адресу живої сторінки. Він показує польові дані від реальних користувачів Chrome (якщо на сайті достатньо трафіку) і лабораторні дані з імітованого завантаження, а також список конкретних проблем.
• Lighthouse в інструментах розробника Chrome — той самий лабораторний тест, який можна запустити на будь-якій сторінці, до якої є доступ, зокрема на прев’ю. Тестуйте в мобільному режимі; проблеми помітні на телефонах із повільнішою мережею.

Найважливіші числа — це Core Web Vitals від Google. Станом на вересень 2026 року документація Google на web.dev дає такі «добрі» пороги, виміряні на 75-му перцентилі завантажень сторінок:

INP замінив старішу метрику First Input Delay у 2024 році. Якщо якийсь інструмент досі показує FID, він застарів.

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

Куди йде час: варіанти і компроміси

Кожна поширена причина має виправлення, і кожне виправлення має ціну. Почніть з тих, що вгорі списку: вони найдешевші і найпоширеніші.

Зображення

Зображення — найпоширеніша проблема і найлегше виправлювана. Фото 4000 пікселів, показане на 800 пікселях у ширину, змушує кожного відвідувача завантажувати в п’ять разів більше, ніж він бачить.

• Віддавайте зображення в тому розмірі, в якому їх показують, з адаптивними srcset для телефонів і комп’ютерів.
• Використовуйте сучасні формати (WebP або AVIF) і розумне стиснення.
• Вказуйте width і height для кожного зображення, щоб браузер резервував місце. Це саме по собі усуває більшість зсувів макета.
• Відкладайте завантаження зображень нижче першого екрана через loading="lazy".
• Ніколи не відкладайте головне зображення у верхній частині сторінки. Рекомендації Google щодо LCP тут категоричні: відкладене завантаження LCP-зображення завжди його затримує. Дайте йому fetchpriority="high".

JavaScript

Багато сайтів, створених ШІ, є односторінковими застосунками (SPA): браузер завантажує пакет JavaScript, а потім малює сторінку. Чим більший пакет, тим довше порожній екран. Виправлення в порядку зусиль:

1. Приберіть те, чим не користуєтеся. Попросіть список залежностей і вилучіть бібліотеки, які колись додали і забули — бібліотеку дат для однієї дати, повний пакет іконок для п’яти іконок.
2. Розбийте по маршрутах. Завантажуйте код адмін-панелі лише тоді, коли її відкривають, а не на головній сторінці.
3. Попередньо рендеріть публічні сторінки. Маркетингова сторінка, яка надходить як справжній HTML, з’являється ще до того, як запуститься JavaScript. Це також допомагає пошуковим системам; див. SEO для сайтів, створених ШІ.

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

Шрифти

Кожна родина шрифтів і кожне начертання — ще один файл. Зазвичай достатньо двох родин і трьох-чотирьох начертань. Попередньо завантажуйте шрифт, який використовується над першим екраном, застосовуйте font-display: swap, щоб текст відображався одразу, і хостіть шрифти самі, якщо зовнішній сервіс шрифтів повільний для ваших відвідувачів.

Сторонні скрипти

Віджети чату, аналітика, теплові карти, пікселі реклами, вбудовані відео і стрічки соцмереж завантажують код з інших серверів. Кожен виглядає маленьким; разом вони часто найповільніша частина сторінки. Залишайте ті, якими ви справді користуєтеся. Решту завантажуйте після того, як сторінка стане інтерактивною, а важкі вбудування (плеєр YouTube, карту) замінюйте легкою заставкою, яка завантажує справжнє при кліку.

Відповідь сервера

Time to first byte (TTFB) — скільки часу сервер витрачає, щоб почати відповідати, — лежить під кожною іншою метрикою. Статичні сторінки, які віддає CDN (мережа серверів поблизу відвідувачів; див. що таке CDN), швидкі майже скрізь. Сторінки, які сервер будує при кожному запиті, залежать від нього і його бази даних. Кешування повторюваної роботи і індекси бази даних для повільних запитів — звичайні виправлення.

Промпти, які працюють

Будьте конкретними: назвіть сторінку, метрику і обмеження. Вставте знахідки PageSpeed Insights, якщо маєте їх.

PageSpeed Insights показує LCP 4,8 с на мобільному для головної сторінки, а LCP-елемент — головне зображення. Зміни розмір і конвертуй головне зображення у WebP, віддавай адаптивні розміри, задай width і height, дай йому fetchpriority="high" і переконайся, що воно не відкладається. Відкладай завантаження кожного зображення нижче першого екрана. Не змінюй дизайн.

Проаудитуй залежності цього застосунку. Перелічи кожен пакет, що його використовує і приблизно скільки він додає до пакета. Видали невикористані і розбий маршрути /admin і /settings на окремі частини, які завантажуються лише при відвідуванні.

Пошук на /products гальмує. Зроби дебаунс фільтра, уникай перемальовування всього списку на кожне натискання клавіші і розбий список на сторінки або віртуалізуй його, якщо в ньому більше 200 пунктів.

Покроково

1. Протестуйте живу сторінку в PageSpeed Insights на мобільному. Запишіть LCP, INP і CLS та три головні проблеми зі списку.
2. Спершу виправте зображення: розміри, формати, розміри в атрибутах, відкладене завантаження нижче першого екрана, пріоритет для головного.
3. Вимкніть сторонні скрипти, якими не користуєтеся, і відкладіть решту.
4. Обріжте шрифти до того, що потрібно дизайну.
5. Зменште JavaScript: приберіть невикористані пакети, розбийте по маршрутах.
6. Попередньо рендеріть публічні сторінки, якщо вони досі рендеряться на клієнті і LCP досі повільний.
7. Перевірте сервер: кешування, індекси бази даних, статичний хостинг для контенту, який рідко змінюється.
8. Опублікуйте знову і перетестуйте. Польові дані в PageSpeed Insights оновлюються протягом наступних тижнів, коли надходять реальні відвідування, тож ранні результати оцінюйте за лабораторними даними.

Типові помилки

• Тестування лише на швидкому ноутбуці. Ваші відвідувачі сидять на телефонах середнього класу і нестабільному мобільному інтернеті. Тестуйте в мобільному режимі.
• Погоня за ідеальними 100. Лабораторна оцінка — лише орієнтир. Коли Core Web Vitals у добрих межах, контент і зручність важать більше за останні бали.
• Відкладене завантаження всього, включно з головним зображенням. Це погіршує LCP.
• Додавання швидкісного плагіна або бібліотеки зверху. Прибрати вагу майже завжди краще, ніж додати код для її керування.
• Оптимізація прев’ю, а не живого сайту. Прев’ю для розробки працюють із неоптимізованими збірками. Вимірюйте опубліковану адресу.
• Виправлення швидкості один раз. Кожен новий віджет, зображення і функція додають вагу. Перетестовуйте після великих змін.

Чеклист швидкості

• LCP ≤ 2,5 с, INP ≤ 200 мс, CLS ≤ 0,1 на мобільному
• Зображення змінені в розмірі, стиснуті, сучасний формат, з width і height
• Головне зображення не відкладається; зображення нижче першого екрана — відкладені
• Немає невикористаних бібліотек JavaScript; важкі маршрути винесено окремо
• Дві родини шрифтів або менше, основний шрифт попередньо завантажений
• Лише ті сторонні скрипти, якими ви справді користуєтеся, завантажуються пізно
• Публічні сторінки попередньо відрендерені або статичні, де можливо
• Перетестовано на живій адресі після публікації

Швидкість і адаптивний макет йдуть разом; див. як зробити сайт адаптивним для телефонів. Для повної перевірки перед запуском як перевести прототип ШІ у продакшн охоплює решту.

Швидкість у Mythex

У Mythex ці зміни ви вносите, просячи в чаті, або в редакторі коду на Pro. Перевіряйте опубліковану адресу, а не Preview, бо Preview працює на сервері розробки. Статичні фронтенди розгортаються як статичні сайти під час публікації (статичні сайти), що добре підходить для сторінок з контентом. Застосунки з сервером масштабуються до нуля: вони засинають, коли неактивні, і прокидаються при наступному відвідуванні, тож перший запит після тихого періоду повільніший, а підключена база даних засинає після 5 хвилин бездіяльності (ліміти хостингу). Якщо публічна сторінка повільна лише при першому відвідуванні, ймовірна причина саме в цьому. Статичні маркетингові сторінки допомагають. Після змін опублікуйте знову і зробіть жорстке оновлення.

Запитання