Как ускорить сайт: практический чек-лист

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

Сначала измерьте, потом меняйте

Догадки тратят время. Два бесплатных инструмента подходят почти всем:

• PageSpeed Insights (pagespeed.web.dev) — вставьте живой URL. Он показывает полевые данные от реальных пользователей Chrome (если у сайта достаточно трафика) и лабораторные данные от имитированной загрузки, а также список конкретных проблем.
• Lighthouse в Chrome DevTools — тот же лабораторный тест, который можно запустить на любой странице, до которой можно дотянуться, включая превью. Тестируйте в мобильном режиме: проблемы проявляются на телефонах с медленной сетью.

Важны показатели 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 DevTools покажет, какая именно.

Шрифты

Каждое семейство шрифтов и каждое начертание — ещё один файл. Обычно достаточно двух семейств и трёх-четырёх начертаний. Предзагружайте шрифт, который используется над первым экраном, применяйте 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 тормозит. Добавь debounce для фильтра, не перерисовывай весь список при каждом нажатии клавиши и разбей список на страницы или виртуализируй его, если в нём больше 200 элементов.

Пошагово

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

Частые ошибки

• Тестирование только на быстром ноутбуке. Ваши посетители сидят с телефонами среднего класса и нестабильным мобильным интернетом. Тестируйте в мобильном режиме.
• Гонка за идеальными 100 баллами. Лабораторная оценка — ориентир. Когда Core Web Vitals в хорошем диапазоне, контент и удобство важнее последних нескольких баллов.
• Ленивая загрузка всего, включая главное изображение. Это ухудшает LCP.
• Добавление плагина или библиотеки для ускорения. Удаление лишнего почти всегда лучше, чем добавление кода для управления им.
• Оптимизация превью, а не живого сайта. Режимы разработки работают с неоптимизированными сборками. Измеряйте опубликованный URL.
• Ускорение один раз. Каждый новый виджет, изображение и функция добавляют вес. Перепроверяйте после крупных изменений.

Чек-лист скорости

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

Скорость и мобильная вёрстка идут вместе; см. как сделать сайт адаптивным для телефонов. Для полной проверки перед запуском как вывести прототип ИИ в продакшен описывает остальное.

Скорость на Mythex

На Mythex вы вносите эти изменения, попросив в чате, или в редакторе кода на Pro. Проверяйте опубликованный URL, а не Preview, потому что Preview работает на сервере разработки. Статические фронтенды развёртываются как статические сайты при публикации (статические сайты), что подходит для контентных страниц. Приложения с сервером масштабируются до нуля: они засыпают, когда простаивают, и просыпаются при следующем визите, поэтому первый запрос после тихого периода медленнее, а подключённая база данных засыпает через 5 минут простоя (ограничения хостинга). Если публичная страница медленная только при первом визите, скорее всего, причина в этом. Статические маркетинговые страницы помогают. После изменений опубликуйте снова и обновите страницу с полной перезагрузкой.

Вопросы