Скорость загрузки сайта: диагностика и ускорение

Факторы скорости: где искать первое узкое место

Скорость загрузки сайта проваливается не «в целом», а в конкретном слое: сервер поздно отдает HTML, браузер долго находит главный ресурс первого экрана, CSS или JavaScript задерживают отрисовку, а сторонние скрипты забирают основной поток. Эксперимент начинается с выбора этого слоя.

В нашем тестовом подходе исходное состояние выглядит так: открываем важную страницу, фиксируем LCP, INP, CLS, FCP, TTFB и общий вес ресурсов, затем группируем проблемы по месту возникновения. Сервер и редиректы задерживают старт. LCP-ресурс первого экрана задерживает появление основного контента. Блокирующие CSS и JavaScript задерживают первую отрисовку. Сторонние скрипты аналитики, чатов, рекламы и виджетов могут добавлять отдельные соединения и задачи в браузере. CMS тоже влияет: плагины часто подключают CSS и JavaScript на всех страницах, хотя конкретный виджет нужен только на одном шаблоне.

Хорошие Core Web Vitals помогают page experience, но не заменяют релевантность и качество страницы как факторы ранжирования.

Для SEO это ограничение важно держать рядом с метриками скорости. Хороший LCP не делает слабую страницу полезной, но плохой LCP мешает сильной странице раскрыться: пользователь поздно видит контент, поисковая система получает слабый сигнал качества опыта, а команда разработки спорит с отчетом вместо проверки причины. Поэтому гипотеза должна звучать не «ускорить сайт», а «уменьшить задержку основного контента на шаблоне категории за счет LCP-ресурса и HTML-ответа».

Первичные классы задержек:

• Серверный старт: TTFB, редиректы, backend-рендеринг, кэш HTML и работа базы данных.
• LCP-ресурс: hero-изображение, крупный текстовый блок, баннер или карточка товара в первом экране.
• Блокирующие CSS/JS: файлы, которые браузер должен скачать и разобрать до первой отрисовки.
• Сторонние скрипты: аналитика, чаты, реклама, A/B-тесты, персонализация и виджеты.
• CMS-плагины: подключения, которые попадают на все страницы, хотя нужны одному шаблону.

Если задержка в серверном старте, проверяйте кэш HTML, редиректы, хостинг и CDN. Если проблема в первом экране, работайте с LCP-изображением, preload или fetchpriority. Если тормозит отрисовка и отклик, смотрите CSS, JavaScript, long tasks и DOM. Если метрики прыгают от релиза к релизу, отдельно инвентаризируйте плагины CMS и сторонние подключения.

В Web Almanac 2024 медианная страница запрашивала 71 ресурс на desktop и 66 ресурсов на mobile; JavaScript стал самым частым типом ресурса: медиана 24 JS-ресурса на desktop и 22 на mobile.

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

При росте времени мобильной загрузки с 1 до 10 секунд вероятность отказа увеличивалась на 123%; при росте числа элементов страницы с 400 до 6000 вероятность конверсии падала на 95%.

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

Не обещайте себе «100 баллов» как цель. Цель эксперимента - быстрее показать основной контент, быстрее ответить на действие пользователя и убрать неожиданные сдвиги макета.

Метрики скорости и Core Web Vitals

Core Web Vitals показывают три стороны пользовательского опыта: загрузку основного контента, отклик интерфейса и стабильность макета. Для практической диагностики рядом с ними смотрят FCP, TTFB и TBT, потому что они помогают найти причину провала.

Если в отчете красный LCP, это признак задержки главного видимого элемента, а не готовый диагноз. LCP говорит, что основной контент появился поздно, но не говорит сам по себе, виноваты ли сервер, изображение, CSS или JavaScript. INP показывает задержку реакции страницы, но причина может лежать в длинных JavaScript-задачах, большом DOM или тяжелом обработчике клика. CLS фиксирует сдвиги макета, а корень часто находится в изображениях без заданных размеров, поздно загружаемых рекламных блоках, iframe или шрифтах.

Актуальные пороги Core Web Vitals: LCP - хорошо до 2,5 с, INP - хорошо до 200 мс, CLS - хорошо до 0,1; оценка считается по 75-му перцентилю загрузок отдельно для mobile и desktop.

FCP показывает первую отрисовку контента: пользователь впервые видит текст, изображение или другой элемент. TTFB показывает старт ответа сервера и помогает понять, тормозит ли загрузка еще до CSS, картинок и скриптов. TBT показывает суммарную блокировку основного потока в лабораторном прогоне и полезен как подсказка для INP. FID встречается в старых материалах, но с 12 марта 2024 года INP официально заменил FID в Core Web Vitals, поэтому в новых аудитах держите фокус на INP.

Скорость одновременно работает на SEO и не решает SEO в одиночку. LCP до 2,5 секунды, INP 200 мс или меньше и CLS 0,1 или меньше дают нормальную техническую базу, но дальше развилка простая: если проседает шаблон с трафиком, чините его как системную проблему; если проседает один редкий URL, не отдавайте ему весь ресурс разработки.

Инструменты проверки скорости сайта

PageSpeed Insights нужен как первый замер, когда вы еще не знаете, где задержка: в реальном опыте пользователей или в лабораторном воспроизведении. Lighthouse, Chrome DevTools, Google Search Console, WebPageTest, GTmetrix и Pingdom закрывают разные этапы одного эксперимента.

Сначала снимите базовую картину в PageSpeed Insights по важной странице: главная, категория, карточка товара, статья или лендинг. Если есть полевые данные, сервис покажет опыт реальных пользователей на mobile и desktop. Затем откройте Lighthouse или Chrome DevTools, чтобы воспроизвести проблему в контролируемых условиях: увидеть waterfall, размер ресурсов, long tasks, заголовки Content-Encoding и Cache-Control. Google Search Console используйте для контроля групп URL, потому что один адрес может быть быстрым, а весь шаблон карточек - медленным.

PageSpeed Insights показывает пользовательский опыт страницы на mobile и desktop и объединяет полевые данные CrUX с лабораторной диагностикой Lighthouse, если для URL или origin хватает данных.

Для честного эксперимента делайте не один прогон, а серию. Один результат Lighthouse или GTmetrix меняется из-за региона теста, профиля устройства, сетевых ограничений, кэша, рекламных скриптов и состояния сервера. Практичная схема такая: фиксируете PageSpeed Insights как старт, повторяете Lighthouse в одинаковых условиях, открываете DevTools для причины, а после релиза смотрите Search Console по группе страниц.

Минимальный порядок проверки:

1. Выберите 3-5 типовых URL: главная, коммерческий шаблон, контентная страница, страница с формой и самый тяжелый шаблон.
2. Снимите PageSpeed Insights отдельно для mobile и desktop.
3. Запустите Lighthouse в одинаковом профиле устройства и сети.
4. Откройте DevTools Network и Performance для URL с худшим LCP или INP.
5. Сохраните исходные значения, чтобы сравнить их после правки.

Причины медленной загрузки: что ломает эксперимент

Медленная загрузка проявляется по-разному: LCP растет из-за тяжелого первого экрана, INP - из-за JavaScript и большого DOM, CLS - из-за нестабильной раскладки, TTFB - из-за сервера. Симптом подсказывает, где проверять причину.

Тяжелые изображения обычно ухудшают LCP и общий вес страницы. Если главное изображение первого экрана большое, отдается в PNG или JPEG без нужного размера, поздно обнаруживается браузером или загружается лениво, пользователь ждет основной контент. Блокирующие CSS и JavaScript задерживают first paint: браузер должен скачать, разобрать и выполнить ресурсы, прежде чем показать страницу. Большой DOM заставляет браузер дольше считать стили и раскладку, а это уже влияет на INP. Сторонние скрипты выглядят маленькими по отдельности, но вместе дают DNS/TLS-соединения, JavaScript-задачи и сдвиги макета.

В 2024 году медианная desktop-страница запрашивала 18 изображений, а mobile-страница - 16 изображений; изображения остаются крупным источником веса страницы, даже когда число запросов уменьшается.

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

Признаки причины по метрикам:

• LCP плохой при нормальном TTFB - проверьте главное изображение, CSS первого экрана и порядок загрузки ресурсов.
• TTFB высокий - смотрите хостинг, редиректы, backend-рендеринг, кэш HTML и работу базы данных.
• INP плохой - ищите длинные JavaScript-задачи, тяжелые обработчики событий и большой DOM.
• CLS плохой - проверьте размеры изображений, места под рекламу, iframe, баннеры и поведение шрифтов.

Опасная ошибка - удалить несколько килобайт CSS и оставить десятки сторонних скриптов без инвентаризации. Такой эксперимент создает ощущение работы, но не меняет главный пользовательский сценарий.

Ускорение контента и фронтенда

Фронтенд-правка имеет смысл, когда задержка сидит в первом экране, блокирующих ресурсах или работе основного потока. Начинайте с LCP-ресурса, затем переходите к CSS, JavaScript и шрифтам.

Первый фронтенд-эксперимент обычно касается LCP-ресурса. Найдите самый крупный видимый элемент первого экрана: hero-изображение, карточку товара, баннер, крупный текстовый блок. Если это изображение, проверьте реальный размер в пикселях, формат, вес файла и момент обнаружения браузером. Перевод в WebP или AVIF помогает, но качество нужно смотреть глазами: lossy WebP и lossy AVIF отбрасывают часть информации, поэтому один уровень компрессии на всю медиатеку может испортить фотографии, градиенты или мелкие детали товара.

В наших технических разборах WebP хорошо работает как проверяемая гипотеза, а не как массовая замена «на всякий случай»: lossless WebP-изображения на 26% меньше PNG, а lossy WebP-изображения на 25-34% меньше сопоставимых JPEG при эквивалентном SSIM-качестве. Это не отменяет визуальный контроль. Для товарных фотографий, градиентов, скриншотов интерфейса и изображений с мелкими деталями сначала сравните 5-10 образцов, потом переносите правило на шаблон.

Nuvemshop изменила логику приоритизации изображений и получила улучшение LCP на 68% и рост конверсий на 8,9%.

Последовательность фронтенд-правок:

1. Определите LCP-элемент в PageSpeed Insights или DevTools.
2. Если это изображение, подготовьте правильный размер под фактический контейнер и современный формат.
3. Не применяйте lazy loading к главному изображению первого экрана.
4. Сначала удалите лишний код, затем минифицируйте CSS и JavaScript.
5. Оставьте только нужные начертания шрифтов, используйте WOFF2 и предварительную загрузку только для критичного файла.

Минификация CSS и JavaScript - это удаление лишних символов без изменения работы файла; она уменьшает размер, но не решает проблему длинных задач. Если INP плохой, важнее разбить тяжелую JavaScript-работу, отложить некритичные скрипты и убрать обработчики, которые запускаются при первом взаимодействии пользователя. Для CLS проверьте, зарезервированы ли размеры изображений и динамических блоков до их загрузки.

Если вы не знаете, с чего начать, не сжимайте всю медиатеку подряд. Сначала оптимизируйте LCP-изображение на 3-5 самых посещаемых шаблонах и проверьте, изменился ли LCP.

Серверное ускорение, кэширование и CDN

Серверный эксперимент уместен, когда TTFB высокий, повторные загрузки почти не ускоряются или пользователи из разных регионов получают разное время старта. Здесь проверяют HTML-кэш, сжатие, заголовки кэша и CDN.

Серверный слой отвечает за старт эксперимента. Если HTML приходит поздно, браузер поздно узнает о CSS, JavaScript, изображениях и шрифтах. Здесь работают Кэширование сайта для страниц, где оно допустимо, оптимизация backend-рендеринга, устранение лишних редиректов и настройка ответа сервера. Для текстовых ресурсов включают Gzip или Brotli; браузер понимает примененное сжатие через заголовок Content-Encoding. Для повторных загрузок важны Cache-Control, Expires и max-age: они говорят браузеру, сколько времени ресурс можно считать свежим.

HTTP-сжатие для некоторых документов может уменьшать размер до 70%, снижая потребность в пропускной способности; уже сжатые форматы вроде JPEG, ZIP и видео обычно повторно не сжимают.

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

У Selectel CDN публичная базовая стоимость указана как 500-550 ₽ в месяц за CDN-ресурс, а перерасход трафика источника сверх 100 ГБ - 0,5 ₽ за 1 ГБ; цена на странице указана с НДС 22%.

Что проверить на сервере:

• Есть ли Content-Encoding: gzip или br для HTML, CSS, JavaScript и SVG.
• Не сжимаются ли повторно JPEG, ZIP, видео и другие уже сжатые форматы.
• Настроены ли Cache-Control, Expires и max-age для статических файлов.
• Нет ли цепочек редиректов перед загрузкой основного HTML.
• Отдает ли CDN статику из ближайшего узла для вашей аудитории.

Для сайтов на nginx настройки часто лежат в конфигурации сервера, для Apache - в .htaccess, для CMS - частично в плагинах и панели хостинга. Важно проверять результат в DevTools Network: смотрите не только наличие настройки, но и фактический transfer size, заголовки ответа и повторное поведение после обновления страницы.

Приоритизация работ по ускорению

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

Приоритет задает пользовательский сценарий

Хороший эксперимент начинается с вопроса о влиянии. Если LCP плохой на карточках товаров, где идет основная выручка, оптимизация hero-изображения и HTML-ответа важнее, чем экономия 20-30 КБ на редко используемом CSS. Если INP плохой после первого клика по фильтрам, работа с JavaScript и DOM важнее, чем замена формата изображений ниже первого экрана. Если CLS портит форму заказа, резервирование места под динамические блоки важнее косметической минификации.

Вес метрик помогает не спорить о мелочах

В Lighthouse performance score веса метрик распределены так: TBT - 30%, LCP - 25%, CLS - 25%, FCP - 10%, Speed Index - 10%; рекомендации Opportunities и Diagnostics сами по себе не являются прямыми слагаемыми итогового балла.

В наших технических разборах мы видим устойчивую связку: PageSpeed Insights помогает выбрать симптом, Lighthouse и DevTools помогают найти причину, а приоритет задают шаблоны страниц и бизнес-сценарии. Хорошие пороги Core Web Vitals: LCP должен быть не более 2,5 секунды, INP - не более 200 мс, CLS - не более 0,1. Если эти значения проваливает шаблон с органическим трафиком, задача получает высокий приоритет даже тогда, когда в отчете рядом есть десятки мелких замечаний.

Порядок работ фиксирует гипотезу

Рабочий порядок приоритизации:

1. Выберите шаблоны с трафиком, лидами или SEO-ценностью.
2. Для каждого шаблона отметьте худшую метрику: LCP, INP, CLS, TTFB или TBT.
3. Свяжите метрику с причиной: ресурс первого экрана, сервер, JavaScript, DOM, шрифты или динамический блок.
4. Оцените охват правки: один URL, один шаблон, вся CMS или общий серверный слой.
5. После внедрения сравните ту же метрику на тех же URL и устройствах.

Продвинутые техники идут после базы

Продвинутые техники вроде fetchpriority, prefetch, prerender, 103 Early Hints и Speculation Rules API имеют смысл после базовой оптимизации. Они помогают приоритизировать или предзагружать ресурсы, но не компенсируют тяжелые изображения, медленный сервер и лишний JavaScript. Если фундамент слабый, сложные приемы дают хрупкий результат.

Когда ускорение не даёт эффекта

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

Первая ситуация - LCP уже нормальный, причем главным элементом первого экрана выступает текстовый блок, а тяжелые изображения находятся ниже. Гипотеза «переведем все картинки в WebP и улучшим LCP» здесь слабая: вмешательство может уменьшить общий вес страницы, но главный контент уже появляется вовремя. Проверка простая: сравните LCP-элемент в DevTools до правки и после нее. Если элемент не изменился и p75 LCP остался в хорошем диапазоне, результат нельзя продавать как ускорение первого экрана.

Вторая ситуация - INP и TBT хорошие, а проблема в TTFB. Тогда удаление части JavaScript даст аккуратный отчет, но пользователь все равно будет ждать первый байт HTML. Гипотеза должна сместиться на сервер: кэш HTML, редиректы, backend-рендеринг, база данных, CDN для кэшируемых ресурсов. Результат проверяется тем же TTFB и FCP, а не только итоговым Lighthouse score.

Третья ситуация - PageSpeed стал зеленее, а field data не двигаются. Это не обязательно провал: полевые данные обновляются медленнее и зависят от реальных устройств, регионов, кэша и шаблонов. Но если через 2-4 недели картина не меняется, проверьте охват: правили ли вы шаблон с трафиком, попали ли в mobile, не остались ли тяжелые сторонние скрипты на части страниц. Отдельно смотрите Google Analytics и Яндекс.Метрику: если формы, клики или заказы просели, ускорение задело пользовательский сценарий.

Не принимайте зеленый lab-замер за доказательство успеха. Для вывода нужны те же URL, те же метрики и понятное объяснение, почему изменение должно проявиться у реальных пользователей.

Проверка результата и регулярный контроль

Проверка результата строится на сравнении одинаковых замеров до и после правки. Смотрите не только Lighthouse score, но и Core Web Vitals в динамике, полевые данные, поведение пользователей и стабильность важных сценариев.

После изменения повторите тот же эксперимент: те же URL, те же устройства, те же инструменты, похожие условия теста. Лабораторный прогон должен подтвердить, что причина устранена: LCP-ресурс стал легче или раньше обнаруживается, TTFB снизился, JavaScript меньше блокирует основной поток, CLS ушел после резервирования места. Полевые данные реагируют медленнее. Для сайтов с достаточным трафиком практично сравнивать периоды до и после релиза минимум по 2-4 неделям, отдельно для mobile и desktop.

PageSpeed Insights считает прохождение Core Web Vitals по 75-м перцентилям INP, LCP и CLS; если хотя бы одна из трех метрик не находится в хорошем диапазоне, агрегация не проходит оценку.

Технический успех не должен ломать бизнес-сценарий. Если после оптимизации вырос Lighthouse score, но в Google Analytics или Яндекс.Метрике ухудшились конверсия, глубина просмотра, события формы, клики по кнопкам или заказы, проверьте отложенный JavaScript, ленивую загрузку, consent-скрипты, цели аналитики и виджеты оплаты. Скорость страницы ценна только тогда, когда пользователь быстрее доходит до нужного действия, а не когда отчет выглядит аккуратнее.

Контроль после релиза:

• Повторно измерить те же URL в PageSpeed Insights.
• Сравнить Lighthouse-прогоны в одинаковых условиях.
• Проверить DevTools Network на сжатие, кэш и размер переданных ресурсов.
• Посмотреть Core Web Vitals в Google Search Console по группам URL.
• Сверить пользовательские метрики в аналитике: формы, клики, заказы, глубину просмотра.
• Добавить проверку скорости в регламент перед крупными релизами.

Главное действие - не ускорять всё подряд, а поставить измеримый эксперимент: зафиксировать исходные LCP, INP, CLS и TTFB, выбрать один узкий слой, внедрить правку и проверить тот же набор метрик. Избегайте хаотичной гонки за баллом: сайт становится быстрее для людей, когда техническая правка попадает в реальную причину задержки и не ломает путь пользователя.