Как ускорить сайт и найти причину медленной загрузки

Медленная работа веб-проекта редко объясняется одной «тяжёлой картинкой». Пользователь нажимает ссылку, а задержка может возникнуть ещё до того, как браузер вообще начнёт загружать изображения: сервер долго формирует ответ, HTML поздно указывает на главный ресурс, JavaScript занимает основной поток или интерфейс перестраивается уже после появления контента.

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

PageSpeed показывает симптом, а не готовый диагноз

Первое, что обычно открывают при проверке, — PageSpeed Insights. Сервис полезен, но одна цифра в круге мало что говорит о реальном состоянии проекта. Два ресурса с одинаковой оценкой могут тормозить совершенно по разным причинам.

В отчёте есть два принципиально разных слоя данных. Полевые показатели отражают опыт реальных пользователей Chrome. Это не результат только что запущенного теста, а накопленная статистика. Лабораторная часть Lighthouse, напротив, моделирует загрузку в заданных условиях и помогает разобрать конкретный URL технически.

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

Для нового или малопосещаемого URL отдельных полевых данных вообще может не хватать. Тогда сервис способен показывать агрегированную статистику по домену либо не выводить её вовсе. Это не ошибка проверки.

Где на самом деле теряются секунды

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

Замедлиться может любой из этих этапов. Поэтому фраза «сайт грузится пять секунд» сама по себе почти бесполезна. Важно узнать, что происходило в эти пять секунд.

До появления HTML: сервер ещё думает

Если браузер отправил запрос и долго не получает начало ответа, проблема находится раньше изображений, CSS и JavaScript. Здесь смотрят на TTFB — время до первого байта.

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

В таком случае перевод фотографий в WebP почти ничего не изменит в начале загрузки. Картинки ещё даже не начали скачиваться, а значительная часть времени уже потеряна.

HTML пришёл быстро, но главный элемент обнаруживается поздно

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

Если ссылка на главное изображение находится прямо в HTML, запрос может начаться рано. Если же адрес картинки появляется только после загрузки CSS, выполнения скрипта или создания слайдера, возникает дополнительная пауза.

Именно поэтому плохой LCP нельзя автоматически приравнивать к «слишком тяжёлому JPEG». Файл может весить вполне разумно, но браузер начинает загружать его с опозданием.

Отдельная ошибка — lazy loading для крупного элемента первого экрана. Ленивая загрузка полезна для фотографий далеко ниже видимой области, но приоритетный контент не стоит искусственно откладывать.

Всё видно, но интерфейс словно завис

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

Браузеру приходится выполнять JavaScript в основном потоке. Пока там идёт длинная задача, пользовательское действие ждёт своей очереди. Чем слабее процессор телефона, тем заметнее задержка.

Особенно быстро такая проблема накапливается на коммерческих проектах. Сначала есть собственный код, затем добавляются аналитика, рекламные пиксели, чат, callback-виджет, карта, A/B-тестирование, трекинг и ещё несколько сервисов. Каждый по отдельности кажется небольшим. Вместе они способны загрузить процессор в самый неудобный момент.

Контент появляется, а затем всё сдвигается

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

Здесь проблема не столько во времени загрузки, сколько в стабильности макета. Для изображения или iframe желательно заранее резервировать пространство. Тогда браузер знает размер блока ещё до получения самого содержимого и не перестраивает уже показанную часть страницы.

Что означают Core Web Vitals на практике

LCP, INP и CLS удобно воспринимать не как три SEO-аббревиатуры, а как три разных вопроса о работе интерфейса.

Эти значения оценивают разные процессы. Можно исправить LCP и почти не изменить INP. Можно получить моментальный первый экран, но сохранить раздражающие прыжки интерфейса. Поэтому задача «улучшить Core Web Vitals» без уточнения проблемной метрики слишком расплывчата.

При оценке реального пользовательского опыта используется 75-й процентиль. Проще говоря, хороший результат должен сохраняться не только у владельца проекта на новом ноутбуке и быстром Wi-Fi, а у значительной части аудитории при реальных условиях использования.

Как найти виновника, а не оптимизировать всё подряд

Удобнее начинать не с списка рекомендаций Lighthouse, а с наблюдаемого симптома.

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

Если текст появляется быстро, а большая фотография — спустя несколько секунд. Нужно найти этот файл в сетевой последовательности и посмотреть, когда началась его загрузка. Важны размер, формат, приоритет и то, насколько рано браузер обнаружил адрес.

Если экран уже собран, но кнопки «тормозят». Подозрение смещается в сторону JavaScript и длинных задач основного потока. Здесь полезнее искать тяжёлые обработчики и ненужные сторонние модули, чем заниматься картинками.

Если блоки скачут. Проверяются размеры медиа, рекламные места, iframe, баннеры, уведомления и шрифты.

Если плохо работают почти все URL. Вероятность общей причины выше: сервер, шаблон, глобально подключённый скрипт, система управления контентом или внешний сервис.

Если тормозит один тип страниц. Например, только карточки товаров или только статьи. Тогда искать нужно в конкретном шаблоне: галерея, фильтры, отзывы, рекомендации, рекламные вставки или другой компонент, которого нет на остальных разделах.

Изображения: проблема чаще не в формате, а в способе отдачи

Совет «переведите всё в WebP» слишком упрощает задачу. Современный формат действительно способен уменьшить объём передаваемых данных, но этого недостаточно, если посетителю всё равно отправляется фотография шириной 4000 пикселей для блока размером 600 пикселей.

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

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

Есть и третья проблема — фотографии, добавленные редактором без обработки. На старых CMS легко встретить ситуацию, когда сотрудник загрузил многомегабайтный исходник с камеры, а шаблон просто визуально уменьшил его через CSS. На экране картинка маленькая, но по сети передаётся оригинал.

JavaScript: несколько маленьких виджетов превращаются в большую проблему

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

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

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

Не стоит и бездумно откладывать абсолютно все скрипты. Код, от которого зависит интерфейс первого экрана, может понадобиться сразу. Задача — расставить приоритеты, а не поменять одно универсальное правило на другое.

Когда проблема находится в CSS и шрифтах

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

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

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

Почему сервер нельзя проверять последним

Оптимизацию часто начинают с фронтенда просто потому, что его легче увидеть. Между тем медленный backend способен испортить результат ещё до начала работы браузера.

Особенно это характерно для CMS с большим количеством модулей. Запрос пользователя запускает PHP, несколько обращений к базе, формирование меню, выборку товаров, проверку сессии, построение блоков рекомендаций. Если всё выполняется при каждом открытии заново, задержка накапливается до отправки HTML.

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

Но ставить кеш «на всё» без понимания архитектуры тоже опасно. Корзина, персональные данные, остатки или индивидуальные цены требуют другой логики, чем публичная информационная статья.

CDN не ускоряет медленный код

CDN полезен, когда нужно быстрее отдавать статические ресурсы аудитории из разных регионов. Фотография может прийти с ближайшего узла, а не каждый раз с основного сервера в другой части мира.

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

Поэтому CDN имеет смысл подключать после того, как понятно, какую именно задержку он должен сократить.

Мобильная версия почти всегда честнее показывает слабые места

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

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

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

Почему оценка 100 не должна быть техническим заданием

Баллы Lighthouse удобны как индикатор. Они позволяют быстро заметить ухудшение после релиза или сравнить две версии. Но само число не является бизнес-результатом.

Если для перехода с 93 до 100 требуется удалить онлайн-чат, который приносит обращения, такая оптимизация сомнительна. Если рекламный скрипт действительно нужен для измерения продаж, его наличие нельзя оценивать только через потерю нескольких пунктов.

Другая крайность — игнорировать производительность полностью, оправдывая каждую задержку «нужной функцией». Правильнее посмотреть, можно ли сохранить функцию, но изменить момент её загрузки или уменьшить стоимость выполнения.

Google также не рассматривает идеальную оценку Lighthouse как пропуск в верхние позиции выдачи. Core Web Vitals учитываются системами ранжирования, но релевантность и полезность содержимого остаются критически важными. Быстрый документ без нужного пользователю ответа не становится сильнее только из-за технической оценки.

Практический порядок работ

Если задача звучит просто как «ускорить сайт», работу удобно разбить на несколько проходов:

1. Выбрать реальные типовые URL: главную, основную услугу, статью, категорию или карточку товара.
2. Проверить отдельно мобильный и десктопный вариант, не смешивая их результаты.
3. Определить проблемную метрику или этап: ответ сервера, первый экран, интерактивность либо стабильность макета.
4. Найти конкретный ресурс или процесс, который создаёт задержку.
5. Исправить одну существенную причину и повторить измерение.
6. После технических тестов дождаться обновления данных реальных пользователей и посмотреть, изменился ли полевой результат.

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

Когда работу можно считать законченной

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

Если задерживалось главное изображение, оно должно стабильно обнаруживаться и загружаться раньше. Если интерфейс зависал после клика, нужно проверить именно взаимодействия. Если макет прыгал, следует убедиться, что проблемные блоки получили зарезервированное пространство.

Полевые данные обновятся не моментально: PageSpeed Insights использует статистику CrUX за скользящий 28-дневный период. Поэтому сегодняшняя техническая правка какое-то время будет соседствовать в отчёте со старыми пользовательскими посещениями.

На крупном ресурсе одной страницы для контроля мало. Изменение общего шаблона может ускорить или, наоборот, ухудшить сразу сотни URL. Поэтому после релиза полезно смотреть не только отдельный тест, но и группы страниц в Search Console.

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