Скорость сайта по Lighthouse: как улучшить каждый показатель

Скорость сайта по Lighthouse улучшают не одной настройкой, а последовательной работой с изображениями, JavaScript, CSS, сервером и сторонними виджетами. Начните с конкретных метрик: LCP до 2,5 секунды, INP до 200 миллисекунд и CLS ниже 0,1. На мобильной сети разница особенно заметна: посетитель может закрыть страницу ещё до появления предложения.

Что именно измеряет Lighthouse

Lighthouse запускает страницу в смоделированных условиях и отдельно оценивает производительность, доступность, SEO и технические практики. Отчёт не объясняет бизнес-причину сам по себе, но показывает направление поиска: тяжёлый первый экран, медленный сервер, лишний JavaScript, ошибки разметки или элементы, которые меняют положение во время загрузки.

Проверку можно запустить в Chrome DevTools или через PageSpeed Insights. Результат состоит из нескольких частей:

• Lab Data - тестовый прогон в заданных условиях. Он помогает найти техническую причину проблемы на конкретной странице.
• Field Data - измерения реальных пользователей Chrome, если для страницы накоплено достаточно данных. Они ближе к тому, что видит аудитория.
• Performance - оценка скорости и список рекомендаций. Низкий балл сам по себе не объясняет, какую задачу нужно решать первой.
• SEO и Accessibility - отдельные проверки. Они находят проблемы с заголовками, мета-данными, контрастом, доступностью элементов и базовой разметкой.

Результат не бывает постоянным: на него влияют устройство, браузер, регион, кэш, нагрузка на сервер и подключённые сервисы. Страница может получить высокий лабораторный балл, но медленно открываться у владельцев старых смартфонов или при нестабильном мобильном интернете. Поэтому оценивайте не один прогон, а повторяющуюся картину.

Какие показатели Lighthouse считаются хорошими

Для Core Web Vitals ориентиры следующие: LCP - не выше 2,5 секунды, INP - не выше 200 миллисекунд, CLS - ниже 0,1. Значения до 4 секунд, до 500 миллисекунд и до 0,25 соответственно относятся к зоне улучшения. Более высокие показатели указывают на заметные проблемы с загрузкой или взаимодействием.

FID, который встречается в старых материалах, больше не используется как основная пользовательская метрика. Его заменил INP. Если в отчёте или статье остались рекомендации по FID, смотрите на текущие данные INP и на долгие задачи JavaScript, которые задерживают реакцию интерфейса.

Как улучшить LCP и ускорить первый экран

LCP чаще всего ухудшается из-за главного изображения, фонового видео, медленного ответа сервера или шрифта, который задерживает отображение текста. Сначала определите элемент, отмеченный Lighthouse как Largest Contentful Paint, а затем работайте с ним. Общая минификация не поможет, если баннер первого экрана весит несколько мегабайт.

На корпоративной странице таким элементом бывает фотография, крупный заголовок или блок с предложением. В каталоге это обычно изображение товара, а на рекламной посадочной странице - баннер или текстовый блок. Причина зависит от шаблона, поэтому одинаковый список настроек для всех URL редко даёт хороший результат.

• Сожмите изображение и отдавайте его в WebP или AVIF. Сначала уменьшите физические размеры: картинка шириной 5000 пикселей не нужна экрану смартфона.
• Для главного изображения используйте fetchpriority="high", но не назначайте этот атрибут всем картинкам. Иначе браузер потеряет приоритеты.
• Не применяйте loading="lazy" к элементу первого экрана. Отложенная загрузка нужна изображениям ниже видимой области.
• Задайте width и height либо соотношение сторон через CSS. Браузер заранее зарезервирует место и не будет ждать загрузки для расчёта размеров.
• Оставьте только нужные начертания шрифта, подключите font-display: swap и не загружайте пять вариантов веса, если используются два.
• Если проблема связана с TTFB, проверьте кэширование, запросы к базе данных, хостинг и способ формирования страницы. Оптимизация картинки не исправит ответ сервера в две секунды.

Частая практическая ошибка - публикация оригиналов фотографий офиса, товара или команды без подготовки. Снимок с телефона может весить несколько мегабайт, хотя на экране занимает небольшую область. Проверьте размер файла, его реальное отображение на смартфоне и поведение страницы через мобильную сеть, а не только в офисной сети.

INP и CLS: как убрать задержки и прыжки интерфейса

INP улучшают сокращением задач JavaScript, а CLS - резервированием места под изображения, баннеры, формы и виджеты. Если кнопка реагирует с задержкой или после загрузки меню сдвигается вниз, проблема уже затрагивает пользовательский сценарий. Исправлять нужно не оценку в отчёте, а конкретное действие: клик, поиск, фильтр или отправку формы.

INP учитывает путь от действия пользователя до следующего визуального обновления. Тормозить могут обработчики кликов, фильтры каталога, маски телефона, открытие модальных окон и сторонние чаты. Одна тяжёлая задача, которая выполняется после нажатия, способна сделать интерфейс неповоротливым даже при быстрой загрузке первого экрана.

• Разделите тяжёлую обработку на небольшие задачи, чтобы браузер успевал отвечать на ввод.
• Не запускайте сложный пересчёт каталога на каждую букву в поле поиска. Используйте задержку обработки и отменяйте устаревшие запросы.
• Подгружайте чаты, карты, формы обратного звонка и другие второстепенные виджеты после основного контента, если они не нужны для первого действия.
• Проверьте рекламные пиксели, аналитику и платёжные модули. Каждый внешний сервис добавляет запросы и JavaScript, а иногда меняет разметку страницы.
• Задайте размеры рекламным блокам, баннерам, iframe, изображениям и видео до момента их загрузки.
• Не вставляйте уведомление о скидке или форму поверх контента без заранее выделенного места. На мобильном экране такой блок может сдвинуть весь первый экран.

Отдельно проверьте cookie-баннеры, всплывающие окна и динамические цены. В магазине скачок CLS может появляться не на главной, а при выборе города, доставки или оплаты. Сценарий нужно тестировать в том состоянии, в котором его проходит клиент, а не только на чистой странице без выбранных параметров.

JavaScript и CSS: где сайт теряет скорость

Если Lighthouse показывает Reduce unused JavaScript, Long tasks или блокирующие ресурсы, ищите лишний код и неправильный порядок загрузки. Разделите JavaScript по страницам, отложите второстепенные функции, удалите неиспользуемые библиотеки и оставьте небольшими стили первого экрана. Одна минификация редко заметно ускоряет сайт, если браузер всё равно выполняет ненужную логику.

На сайтах малого бизнеса нередко остаются библиотеки от старых форм, рекламных кампаний и подрядчиков. Для одной кнопки подключается несколько пакетов, а прежние счётчики продолжают работать после смены настроек. В отчёте это выглядит как код, который скачивается, разбирается и выполняется, но не помогает текущему пользователю.

• Настройте code splitting: код каталога не должен загружаться на странице контактов, а код личного кабинета - на рекламной посадочной странице.
• Удалите плагины и счётчики, которыми никто не пользуется. До удаления сохраните список целей и событий, чтобы не потерять данные рекламы.
• Минифицируйте CSS и JavaScript, включите Brotli или gzip на сервере и проверьте кэширование статических файлов.
• Вынесите критические стили первого экрана в приоритетную загрузку, а второстепенные стили не заставляйте браузер ждать до первой отрисовки.
• Не подключайте внешние шрифты и сервисы без проверки. Локальная загрузка нужных начертаний часто стабильнее для посетителей из разных городов.
• Не ставьте несколько инструментов аналитики для одной задачи. Сначала составьте список отчётов и событий, которые действительно используются.

В React-проектах проверьте, какие компоненты действительно требуют браузера. Интерактивный калькулятор или фильтр может быть клиентским, но текст, заголовки, цены и описания не должны ждать выполнения большого пакета JavaScript. Такой разбор одновременно улучшает скорость, доступность контента и возможность поискового робота прочитать страницу.

SSR или статическая генерация: что выбрать для SEO

Для корпоративного сайта, блога и большинства лендингов обычно подходит статическая генерация: готовый HTML отдаётся быстро и не требует сборки интерфейса в браузере. SSR нужен, когда содержимое зависит от запроса, пользователя или актуального состояния системы. Архитектуру лучше выбрать до разработки, чтобы не переделывать шаблоны после замеров скорости.

Полностью менять платформу из-за одного низкого балла не всегда разумно. Определите, где теряются пользователи: на всех страницах или только в каталоге, после рекламного перехода или при повторном открытии. Иногда хватает настройки кэша, изображений и скриптов. Если старая CMS не даёт управлять разметкой и ресурсами, редизайн может быть практичнее постоянных точечных исправлений.

Как проверять скорость сайта в Казахстане и не обмануться одним тестом

Одной проверки Lighthouse недостаточно: она показывает отдельный прогон, а не постоянное состояние сайта. Проверяйте главную, рекламную посадочную страницу, страницу услуги, карточку товара и оформление заказа отдельно. После изменений сравнивайте одинаковые URL, устройство и условия, а реальные данные смотрите в отчётах о пользовательском опыте.

• Составьте список из 5-10 важных URL. Для магазина добавьте категорию, товар, корзину и оформление заказа.
• Проведите несколько тестов: сервер и внешние сервисы отвечают с разной скоростью. Ищите повторяющуюся картину, а не лучший или худший единичный результат.
• Проверьте группы страниц с реальными проблемами в инструментах для владельцев сайта. Лабораторный тест отдельного URL не показывает состояние всего раздела.
• После обновления повторно проверьте рекламные страницы. Новый пиксель, чат или скрипт ремаркетинга способен ухудшить скорость без изменения дизайна.
• Настройте автоматическую проверку перед публикацией, если сайт регулярно обновляется. Для небольшого проекта достаточно ежемесячного контроля и проверки после крупных изменений.
• Тестируйте на телефоне через мобильную сеть. Посетитель из Алматы или Астаны может открыть страницу не в тех условиях, в которых её проверяет разработчик на компьютере.

Для SEO важны не только цифры Lighthouse. Проверьте, что текст и заголовок видны в HTML, страницы доступны роботам, есть понятные URL, canonical, sitemap, корректные редиректы и описания изображений. Высокий Performance не компенсирует закрытый от индексации раздел или пустую страницу, которая получает контент только после выполнения JavaScript.

Что делать, если сайт уже медленный

Начните с технического аудита и расставьте исправления по влиянию на бизнес: сначала рекламные и коммерческие страницы, затем шаблонные проблемы всего сайта. Обычно выгоднее исправить несколько причин, связанных с LCP, INP и CLS, чем заказывать полную переделку без списка задач и проверки результата на реальных сценариях.

Если нужна отдельная посадочная страница под рекламу, лендинг под ключ стоит от 200 000 ₸, срок - от 7 дней. Для сайта-визитки ориентир составляет от 150 000 ₸ и от 5 дней. Точная цена фиксируется после брифа: на неё влияют количество страниц, интеграции, контент и состояние текущего проекта.

Остерегайтесь обещаний «100 баллов на всех устройствах». Такой результат не заменяет проверку реальных сценариев и может быть достигнут ценой отключения формы, аналитики или чата. Исполнитель должен показать список проблем, порядок исправлений и возможные последствия для дизайна, рекламы и функциональности.

Частые вопросы

Ниже - короткие ответы на вопросы, которые возникают при проверке скорости и выборе способа оптимизации. В каждом случае смотрите не только на цифру в отчёте, но и на страницу, устройство и действие пользователя: один показатель может быть нормальным, пока другая часть сценария остаётся медленной.

• Нужно ли добиваться 100 баллов Lighthouse? Не обязательно. Лучше стабильно пройти пороги Core Web Vitals и не сломать формы, аналитику, каталог или оплату ради нескольких дополнительных баллов.
• Может ли медленный сайт ухудшить SEO? Может, особенно если пользователи долго ждут контент или не могут взаимодействовать со страницей. Но скорость оценивается вместе с качеством контента и другими техническими сигналами.
• Нужно ли ставить loading="lazy" на все изображения? Нет. Для картинок первого экрана отложенная загрузка может ухудшить LCP, а для изображений ниже видимой области она обычно уместна.
• Поможет ли переход на Next.js автоматически? Нет. Архитектура даёт возможности для SSR, SSG и разделения кода, но тяжёлые изображения, лишние скрипты и неудачная логика компонентов всё равно замедлят страницу.
• Как часто проверять Lighthouse? Для сайта без частых изменений достаточно проверки после релиза и контроля раз в месяц. Магазин и проект с активной рекламой лучше проверять после заметных обновлений.
• Можно ли ускорить старый сайт без редизайна? Иногда да - за счёт изображений, кэша, CSS, JavaScript и сторонних сервисов. Если CMS не позволяет управлять HTML и ресурсами, новый сайт может быть выгоднее постоянных компромиссов.

С чего начать улучшение скорости

Соберите список важных страниц и сохраните исходные результаты Lighthouse, отчёты о пользовательском опыте и проверку на телефоне. Отдельно отметьте LCP, INP, CLS, TTFB, вес изображений, сторонние скрипты и ошибки, которые видит пользователь: долгое открытие меню, скачок баннера, задержка формы или медленный фильтр.

Мы можем провести технический разбор, подготовить порядок исправлений и оценить, хватит ли точечных доработок или нужен редизайн. В разработке используем Next.js и React, закладываем SEO-структуру с первого дня, даём гарантию 12 месяцев и два бесплатных круга правок. Pozhidayev работает из Алматы с клиентами по всему Казахстану удалённо; домен .kz, хостинг и SSL на первый год входят в стоимость разработки.