Скорость загрузки сайта - как ускорить в 2026 году

Каждый второй клиент приходит ко мне с одной и той же историей: «Сайт вроде работает, контент хороший, а позиции стоят на месте». Открываю PageSpeed - и вижу красное. LCP четыре секунды, CLS скачет, половина картинок весит по мегабайту. И человек искренне удивляется: «А это разве влияет?»

Влияет. HTTP Archive за 2025 год показывает: по всем трем Core Web Vitals на мобильных укладываются лишь 48% сайтов. Больше половины интернета проваливает хотя бы одну метрику. Что это за метрики? Google выделил три порога, по которым оценивает каждую страницу: LCP отвечает за скорость появления основного контента (норма - 2.5 сек), INP - за отзывчивость интерфейса при кликах и касаниях (норма - 200 мс), CLS - за визуальную стабильность, то есть «дерганья» макета (норма - ниже 0.1). Не уложились - рискуете проиграть конкурентам, которые уложились.

За 10 лет работы в SEO я перевидал сотни «медленных» проектов. Ниже - практический гайд: на какие метрики смотреть, чем проверять и что чинить в первую очередь. Подходы работают и на лендингах, и на интернет-магазинах с тысячами карточек. Но полноценный технический аудит они не заменяют - у каждого сайта свои узкие места.

Почему скорость загрузки влияет на позиции

Посетители уходят, не дождавшись контента. Google измерял это: если время загрузки растет с одной секунды до трех, вероятность отказа подскакивает на 32%. Дотянули до пяти секунд - отказов уже на 90% больше. И это лишь верхушка айсберга.

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

Механизм работает через NavBoost - систему Google, которая оценивает поведение пользователей. NavBoost накапливает данные за 13 месяцев и анализирует три типа кликов: goodClicks (пользователь нашел ответ), badClicks (быстрый возврат в выдачу) и lastLongestClicks (последний долгий клик - сильнейший сигнал). Медленная загрузка приводит к тому, что посетитель не дожидается контента и возвращается в выдачу - это pogo-sticking. Алгоритм фиксирует badClicks. Накапливается негативная статистика - позиции падают.

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

И еще один момент, который часто упускают, - медленные страницы расходуют crawl budget впустую. Google выделяет каждому сайту ограниченный бюджет сканирования. Тяжелые страницы (2 МБ и больше) скачиваются роботом втрое реже легких (200 КБ). А если Googlebot скачал страницу, но не смог ее прорендерить из-за тяжелого JavaScript - она превращается в «zombie render». Бюджет потрачен, индексации нет.

Отдельная история - контекстная реклама. AdsBot-Google проверяет посадочные страницы кампаний независимо от основного индекса. Тормозит лендинг - падает Quality Score - растет цена клика. На одном проекте я ускорил страницу заявки, и CPC снизился на 15-20% без изменения ставок.

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

Core Web Vitals - три метрики, которые оценивает Google

С 2021 года Core Web Vitals входят в page experience update Google. Но путаница вокруг них до сих пор огромная. Многие слышали про LCP, INP, CLS - и на этом познания заканчиваются. Что реально считает алгоритм, какие границы отделяют «хорошо» от «плохо» - мало кто разбирал до конца.

Разложу каждую метрику: как она работает, где старые показатели уже неактуальны и что конкретно нужно сделать, чтобы попасть в зеленую зону.

LCP - Largest Contentful Paint

LCP фиксирует момент, когда на экране отрисовался самый крупный элемент - обычно это баннер на первом экране, фоновое изображение секции или заголовок с подложкой. Проще говоря, LCP отвечает на вопрос: «Через сколько секунд человек увидит что-то осмысленное?» До этого момента перед ним - белый (или серый) экран.

По данным HTTP Archive (2025), в зеленую зону по LCP на мобильных попадают 62% сайтов. Звучит терпимо. Но если считать все три метрики сразу - только 48%. Попасть в эти 48% уже означает обогнать больше половины конкурентов по техническим показателям.

INP - Interaction to Next Paint

С марта 2024 года Google заменил устаревший FID на INP. Разница принципиальная: FID считал только задержку при первом клике, а INP отслеживает каждое действие пользователя - любой клик, касание, нажатие клавиши. На пальцах: вы тапнули «В корзину», а кнопка подвисла. Полсекунды ничего не происходит. Вот это INP и ловит.

На мобильных 77% сайтов укладываются в норму, на десктопе - 97%. Формально самая простая из трех метрик. Но стоит нагрузить страницу скриптами - и INP быстро покраснеет.

CLS - Cumulative Layout Shift

CLS фиксирует визуальные сдвиги элементов при загрузке. Наверняка сталкивались: читаете текст на странице, а сверху подгружается баннер - и все прыгает вниз. Или тянетесь к кнопке, а она «убегает», потому что выше появился новый блок. Это и есть CLS - страница «прыгает» у вас под пальцами.

72% десктопных сайтов проходят порог, а на мобильных - целых 81%. Парадокс: обычно мобильные метрики хуже, но с CLS все наоборот. Почему проваливаются остальные? В 9 случаях из 10 причина одна - изображениям и iframe не задали width/height, и макет «плывет» после загрузки.

Почему FID заменили на INP

До марта 2024 года третьей метрикой CWV был FID - First Input Delay. FID измерял задержку только при первом взаимодействии: первый клик, первое касание. И на этом останавливался.

Проблема очевидна: сайт мог молниеносно обработать первый клик, а при втором, третьем и десятом - тормозить. Разработчики быстро смекнули и научились оптимизировать именно первый клик, забивая на остальные. Хитрость, а не реальная скорость. Я встречал сайты с идеальным FID, на которых навигационное меню открывалось с задержкой в полсекунды.

INP решает эту проблему. Он фиксирует все взаимодействия на протяжении жизни страницы и берет наихудшее из них (с оговорками - при большом количестве взаимодействий используется более сложная формула). Если хоть один клик обрабатывается медленнее 200 мс - страница попадает в желтую зону.

Все пять конкурентов из топа по запросу «скорость загрузки сайта» до сих пор используют устаревший FID в своих статьях. Если вы читаете гайд, где упоминается FID как актуальная метрика - он устарел.

Field Data vs Lab Data - что на самом деле видит Google

Тут ведь чаще всего и начинается путаница. Открыли PageSpeed Insights, увидели балл 40 - паника. Или обратная ситуация: 95 баллов, расслабились. А позиции не двигаются. Разберемся, почему.

В PageSpeed два блока данных, и они отвечают за разное:

Lab Data - синтетический прогон через Lighthouse. Мощный виртуальный компьютер, стабильная сеть, никаких помех. Число от 0 до 100 в шапке отчета - именно Lab Data.

Field Data - агрегат из Chrome User Experience Report (CrUX). Это статистика за 28 дней от людей, которые реально заходили на ваш сайт через Chrome.

В формулу ранжирования попадает только Field Data. Утечка внутренней документации Google 2024 года подтвердила это - сигналы mobileCwv и desktopCwv хранятся в модуле CompressedQualitySignals. Порог считается по 75-му перцентилю: три четверти ваших посетителей должны получить «хороший» результат.

Что из этого следует? Lighthouse нужен для поиска проблем - он подсказывает, что именно тормозит. Гоняться за заветной соткой смысла нет, если Field Data уже зеленые. Бывает и наоборот: в Lighthouse все красиво, а реальные пользователи жалуются. Потому что заходят с бюджетных Android-смартфонов через сотовую сеть, а не с рабочей станции по оптике.

Показательный случай из моей практики: маркетолог интернет-магазина потратил три месяца, выбивая 95 баллов в Lighthouse. Нанимал фрилансеров, менял хостинг. А Field Data все эти три месяца были зелеными - настоящие покупатели проблем не испытывали. Итог? Ноль роста позиций. Боролись не с тем.

Как проверить скорость сайта - 7 инструментов

Инструментов для замера скорости десятки, но большинство показывают одно и то же разными словами. Я на проектах использую семь - и делю их на две группы. Первая группа - Lab, лабораторные тесты в идеальных условиях. Вторая - Field, статистика от настоящих посетителей.

Рекомендую начинать с PageSpeed Insights и Google Search Console. PageSpeed покажет и Lab Data (для диагностики), и Field Data (для понимания реальной ситуации). Search Console даст картину по всему сайту - там видно, какие группы страниц в зеленой зоне, а какие нет.

Отдельно проверяйте Яндекс.Вебмастер - там свои метрики, не совпадающие с Google CWV. Об этом подробнее ниже.

Чеклист ускорения сайта - 18 действий по приоритету

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

Высокий приоритет - максимальный эффект

1. Конвертировать изображения в WebP или AVIF. Формат WebP дает сжатие на 25-35% лучше JPEG при том же качестве. AVIF экономит еще 20% поверх WebP. Для адаптивной загрузки используйте srcset - браузер сам выберет нужный размер.

2. Включить lazy loading для медиа ниже первого экрана. Все, что пользователь не видит сразу, должно загружаться отложенно. Атрибут loading="lazy" для img и iframe решает задачу без JavaScript.

3. Встроить критический CSS в HTML, остальное грузить отложенно. Стили для первого экрана - прямо в <style> внутри <head>. Оставшиеся файлы подключайте через media="print" onload="this.media='all'" или preload. Разница - видимая: контент появляется раньше, экран не моргает.

4. Настроить кэширование на сервере. Правильные заголовки Cache-Control и ETag. Шрифты, картинки, стили - кэш на год (immutable). Страницы HTML - короткий кэш с обязательной ревалидацией.

5. Раздать статику через CDN. Картинки, шрифты, CSS, JS - пусть летят с ближайшего узла сети доставки контента. В условиях российской географии это экономит от 200 до 800 мс, особенно для регионов за Уралом.

6. Ускорить ответ сервера (TTFB). Time to First Byte - промежуток между запросом браузера и первым байтом ответа. Больше 800 мс? Проблема на бэкенде: тяжелые SQL-запросы, громоздкая серверная логика, или хостинг не тянет нагрузку. На одном проекте я убрал лишний JOIN из запроса - и TTFB упал с 900 до 350 мс.

Средний приоритет - заметный выигрыш

7. Минифицировать CSS, JS и HTML. Вырезать пробелы, комментарии, переносы строк из кода. Объем уменьшается на 5-15% - немного, но это бесплатная оптимизация, которая ничего не ломает.

8. Некритичные скрипты - на defer или async. Аналитика, чат-виджеты, карты - все это грузите отложенно. Defer запускает скрипт после разбора HTML, не блокируя отрисовку страницы.

9. Включить Brotli-сжатие на сервере. Brotli сжимает текстовый контент (HTML, CSS, JS) на 15-25% лучше Gzip. Поддерживается всеми современными браузерами. Если ваш хостинг до сих пор на Gzip - переключайтесь.

10. Оптимизировать шрифты. font-display: swap - чтобы текст отображался сразу системным шрифтом, пока загружается кастомный. Preload для основного начертания. Подмножества (subset) - загружайте только кириллицу и латиницу, а не полный набор символов.

11. Предзагрузить LCP-ресурс. Найдите LCP-элемент на странице (обычно hero-изображение) и добавьте <link rel="preload"> в head. Браузер начнет загрузку раньше.

12. Перейти на HTTP/2 или HTTP/3. HTTP/3 (QUIC) снижает время установки соединения на 30-50% по сравнению с HTTP/2 за счет объединения TLS-хендшейка с транспортным. Если ваш хостинг и CDN поддерживают - включайте.

Низкий приоритет - доводка до идеала

13. Добавить dns-prefetch и preconnect для внешних доменов. Если на странице есть ресурсы с внешних доменов (CDN, аналитика, шрифты), заранее установите DNS-соединение. Экономия 100-300 мс на каждый домен.

14. Удалить неиспользуемый CSS и JS. Tree shaking для JavaScript-бандлов, PurgeCSS для стилей. На крупных проектах неиспользуемый код может составлять 40-60% от общего объема.

15. Задать width и height для img и video. Без заданных размеров браузер не знает, сколько места выделить - и контент «прыгает» после загрузки. Это прямая причина высокого CLS.

16. Минимизировать third-party скрипты. Каждый виджет (чат, аналитика, карты, пиксели ретаргетинга) - это дополнительные запросы и время загрузки. Оставьте только то, что реально используете. Загружайте с defer или по событию (по клику, по скроллу).

17. Использовать плейсхолдеры для динамического контента. Рекламные баннеры, виджеты, встраиваемые элементы - резервируйте для них место в макете. Это предотвращает CLS.

18. Добавить resource hints для вероятных следующих страниц. <link rel="prefetch"> загружает ресурсы следующей страницы в фоне. Если пользователь с высокой вероятностью перейдет дальше - он увидит мгновенную загрузку.

Как я оптимизирую LCP на проектах

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

Шаг 1. Найдите LCP-элемент. В Chrome DevTools откройте вкладку Performance, запишите загрузку. В секции Timings будет маркер LCP - кликните, и увидите конкретный DOM-элемент. Чаще всего это hero-картинка, крупный текстовый блок или баннер с фоновым изображением.

Шаг 2. Ускорьте загрузку этого элемента. Для изображений - сжатие, конвертация в WebP или AVIF, атрибут fetchpriority="high". Для текстовых блоков - preload основного шрифта и font-display: swap, чтобы текст не ждал загрузки кастомного начертания.

Шаг 3. Подскажите браузеру, что грузить первым. Добавьте <link rel="preload" as="image" href="hero.webp"> в <head>. Без этой подсказки браузер обнаруживает картинку только при разборе CSS - а это потерянные сотни миллисекунд.

Шаг 4. Разберитесь с TTFB. Даже идеально оптимизированная картинка не спасет, если сервер думает полсекунды. Замерьте TTFB через WebPageTest. Выше 600 мс - ищите узкое место на бэкенде или меняйте хостинг.

Шаг 5. Уберите блокирующие ресурсы. CSS и JS, загружаемые синхронно в head, блокируют рендеринг. Критический CSS - inline, все остальное - defer или async.

По моему опыту, самый частый виновник плохого LCP - незжатое hero-изображение весом 2-3 МБ в формате PNG. Дизайнер выгрузил, разработчик залил «как есть». Конвертация в WebP с качеством 80 и правильным srcset обычно решает проблему за один коммит. Банально, но работает.

Оптимизация INP и CLS

INP - реакция интерфейса на действия

Главная причина плохого INP - JavaScript, блокирующий основной поток браузера. Пользователь жмет кнопку, а браузер в этот момент пережевывает тяжелый скрипт и не может отреагировать. Знакомо? Я такое вижу на каждом втором проекте с «богатым» интерфейсом.

Что делать:

• Разбивайте длинные задачи. Любой скрипт, выполняющийся дольше 50 мс, - это Long Task. Разбейте его на части через scheduler.yield() или setTimeout(0) - браузер сможет обработать клик между ними.
• Выносите тяжелые вычисления в Web Workers. Все, что не трогает DOM (обработка данных, валидация, парсинг), можно перенести в отдельный поток.
• Code splitting. Не загружайте весь JavaScript сразу. Подключайте модули по мере необходимости - при скролле, при клике, при открытии определенной секции.
• Обработчики scroll и resize - с passive: true. Без этого флага браузер ждет, пока скрипт решит, блокировать ли прокрутку.

CLS - когда страница «прыгает»

С CLS разобраться легче всего - при условии, что вы понимаете, откуда берутся сдвиги. Четыре приема, которые решают 9 из 10 случаев:

• Явные размеры для каждого img и video. Прописывайте width/height в HTML или задавайте aspect-ratio через CSS. Если размеры не указаны, браузер сначала выделяет 0 пикселей, а потом - рывком раздвигает макет. Вот вам и CLS.
• Зарезервированное место под рекламу и виджеты. Выделите пустой контейнер нужной высоты заранее - баннер подгрузится, а страница не дернется.
• font-display: swap для кастомных шрифтов. Текст сначала рендерится системным шрифтом, потом подменяется кастомным. Swap минимизирует визуальный сдвиг.
• Динамический контент - только ниже viewport. Если нужно добавить элемент - добавляйте ниже того, что пользователь сейчас видит. Иначе страница «дернется».

Скорость загрузки в Яндексе - что учитывать

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

И вот к чему это приводит: сайт может быть в зеленой зоне по Google CWV - и в желтой по Яндексу. Или наоборот. Аудитория разная: Chrome и Яндекс.Браузер популярны на разных устройствах и в разных регионах.

Проверяйте индекс скорости в Яндекс.Вебмастере отдельно. Он находится в разделе «Диагностика» → «Скорость загрузки». Яндекс показывает оценку (хорошая, средняя, плохая) и конкретные рекомендации по улучшению.

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

Как скорость вписывается в общую картину факторов ранжирования, разбираю в руководстве по SEO-продвижению в 2026 году - там и про E-E-A-T, и про другие сигналы.

Метрики до и после оптимизации

Рассуждать можно долго - покажу на реальном проекте. В конце 2025 года пришел владелец интернет-магазина товаров для дома. Ситуация типичная: PageSpeed на мобильных выдавал 28 баллов, Field Data горели красным по LCP и CLS.

Что сделали:

• Конвертировали все изображения в WebP, настроили srcset для адаптивной загрузки
• Включили lazy loading для изображений товаров ниже первого экрана
• Вынесли критический CSS inline, остальные стили - асинхронная загрузка
• Настроили Brotli-сжатие на сервере
• Подключили CDN для статики
• Задали размеры для всех img и video, исправив CLS
• Минифицировали JS и перевели сторонние скрипты (чат, аналитика) на отложенную загрузку

Field Data стабилизировались через 28 дней - CrUX обновляется именно с такой периодичностью. Через два месяца органический трафик из Google вырос на 22%. Скорость ли одна виновата? Нет. Но она убрала барьер, который мешал контенту работать.

Похожий результат получила компания iSpring - восьмикратное улучшение показателей Core Web Vitals после комплексной оптимизации. Те же шаги: lazy loading, сжатие изображений, минификация кода, серверное кэширование.

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

Частые ошибки при оптимизации скорости

За годы работы я насмотрелся на одни и те же грабли. Некоторые промахи стоят месяцев работы впустую.

Оптимизация Lab Data вместо Field Data. Номер один в моем антирейтинге. Люди гонятся за баллом 100 в Lighthouse, хотя Google ранжирует по Field Data. Проверьте сначала реальные метрики - может, у вас уже все нормально.

Ориентир на FID вместо INP. Если в вашем отчете фигурирует FID - выбросите этот отчет. Метрика устарела два года назад. Актуален только INP.

Шрифты целиком, без подмножеств. Видел проекты, где Google Fonts подключены со всеми десятью начертаниями - это полмегабайта. Оставляйте только нужные начертания, только кириллицу с латиницей.

Гирлянда из сторонних скриптов. Чат-виджет, две аналитики, три пикселя ретаргетинга, виджет отзывов - каждый добавляет 200-500 мс к загрузке. А вы точно все это используете? Проведите ревизию.

Нет lazy loading. До сих пор встречаю сайты, где 30 картинок на странице загружаются одновременно. Зачем? Атрибут loading="lazy" на всех изображениях ниже первого экрана - и LCP сокращается в разы.

Проверка только на десктопе. Google давно перешел на mobile-first индексацию. Если смотрите скорость только на большом мониторе - вы видите половину картины. Мобильная версия - приоритет.

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

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