Как ускорить сайт: что реально влияет на скорость загрузки

Как скорость связана с SEO: без преувеличений

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

Что говорит сам Google

Core Web Vitals — подтверждённый сигнал ранжирования с 2021 года, но сигнал небольшого веса. Джон Мюллер формулировал это так: Core Web Vitals не являются крупным фактором ранжирования, и заметного падения только из-за них ждать не стоит. В другой раз он уточнил: это больше, чем инструмент разрешения ничьей, но релевантность содержимого важнее. Дэнни Салливан отдельно пояснял, что оценка страницы — не самостоятельная система ранжирования, а набор сигналов, которые используют другие системы.

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

Где скорость работает по-настоящему

Основной эффект скорости лежит за пределами формулы ранжирования:

• Поведение пользователей. По данным исследования Google, вероятность ухода со страницы вырастает примерно на 90% при увеличении времени загрузки с одной секунды до пяти. Ушедший обратно в выдачу посетитель — сигнал, который поисковые системы фиксируют.
• Конверсия. Совместное исследование Google и Deloitte показало, что ускорение мобильной загрузки всего на 0,1 секунды повышало конверсию в розничной торговле на 8,4%.
• Бюджет обхода. Медленный ответ сервера снижает интенсивность обхода: робот бережёт ресурсы сайта. Для крупных проектов это напрямую тормозит индексацию нового.

Какая скорость считается нормальной

Единого «времени загрузки» не существует — страница загружается не мгновенно и не одним куском, поэтому измеряют несколько моментов. Основной ориентир — три метрики Core Web Vitals.

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

Ещё один нюанс: чтобы страница получила общую оценку «хорошо», в зелёной зоне должны быть все три метрики одновременно.

Дополнительные ориентиры

Core Web Vitals не покрывают всё. При диагностике полезны ещё две величины:

• TTFB — время до первого байта ответа сервера. Ориентир: до 0,8 секунды хорошо, больше 1,8 секунды — проблема. Это фундамент: если сервер думает две секунды, никакая оптимизация картинок LCP не спасёт.
• Вес страницы. Формального порога нет, но для контентной страницы разумный ориентир — до полутора мегабайт на первый экран, из которых изображения занимают львиную долю.

Лабораторные и полевые данные: главная путаница

Это различие объясняет большинство ситуаций вида «у меня 95 баллов, а сайт всё равно не проходит проверку».

Лабораторные данные

Результат одного тестового прогона в контролируемых условиях: заданное устройство, заданная скорость канала, чистый браузер без расширений. Так работает Lighthouse — движок внутри PageSpeed Insights и вкладки в браузере. Данные воспроизводимы и подробны, поэтому незаменимы для поиска причин. Но это симуляция.

Полевые данные

Агрегированная статистика от реальных пользователей Chrome — отчёт CrUX. Здесь настоящие телефоны, настоящие сети, настоящие расширения браузера. Именно на этих данных строится оценка Core Web Vitals, и именно они используются как сигнал.

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

Как измерять правильно, с учётом региона

Пункт, который русскоязычные руководства почти всегда упускают, а он критичен для проектов с аудиторией в СНГ.

Проблема географии

Лабораторный тест в PageSpeed Insights запускается с серверов Google, а не из города вашей аудитории. Если сайт размещён в России, а тест идёт из другого региона, к результату добавляются сетевые задержки, которых у реального посетителя нет. И наоборот: сайт на зарубежном хостинге может показать приличный результат в тесте и быть заметно медленнее для посетителя из Новосибирска.

Что с этим делать

• Опирайтесь на полевые данные. Они собраны с реальных пользователей вашего сайта, то есть уже учитывают географию аудитории. Смотреть их удобнее всего в отчёте Core Web Vitals в Google Search Console — там сразу видно распределение по группам страниц.
• Используйте Яндекс Метрику. В отчётах по времени загрузки — данные вашей реальной аудитории, а не выборка Chrome. Для проектов, где основной трафик из Яндекса, это ближе к действительности.
• Для лабораторных тестов выбирайте локацию. Сервисы вроде WebPageTest позволяют задать город и тип соединения — так можно проверить, как сайт открывается именно из вашего региона.
• Тестируйте мобильную версию. Пороги одинаковы для мобильных и десктопа, но пройти их на мобильных заметно труднее, а индексирование идёт по мобильной версии.

Из чего складывается время загрузки

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

1. Определение адреса сервера. Браузер выясняет, к какому серверу обращаться. Десятки миллисекунд, но на каждый сторонний домен — отдельно.
2. Установка соединения. Согласование защищённого соединения — несколько обменов с сервером. Чем дальше сервер географически, тем дороже каждый обмен.
3. Ответ сервера (TTFB). Сервер обрабатывает запрос, обращается к базе, собирает страницу. Здесь теряется больше всего у сайтов на слабом хостинге.
4. Загрузка и разбор HTML. Браузер получает разметку и начинает искать в ней ссылки на стили, скрипты, шрифты и картинки.
5. Загрузка ресурсов. Стили и скрипты в шапке блокируют отрисовку: пока они не загружены, пользователь видит пустой экран.
6. Отрисовка и выполнение скриптов. Браузер строит страницу и выполняет JavaScript. Тяжёлые скрипты занимают главный поток — отсюда проблемы с откликом.

Полезное следствие: ускорять нужно то, что стоит раньше в цепочке. Оптимизация картинок не поможет, если сервер отвечает две секунды, — вы просто сдвинете задержку, а не уберёте её.

Шаг 1. Сервер и TTFB — фундамент

Самая недооценённая часть работы. Всё, что делается дальше, наслаивается на время ответа сервера.

• Хостинг под нагрузку. На дешёвом виртуальном хостинге ресурсы делятся между сотнями сайтов, и время ответа скачет в зависимости от соседей. Если TTFB нестабилен при неизменном сайте — это первый подозреваемый.
• Кеширование на сервере. Отдавать готовый HTML вместо того, чтобы собирать страницу заново на каждый запрос. Для сайтов на системах управления это обычно даёт самый большой единичный выигрыш.
• Актуальная версия языка и базы. Переход на свежую версию PHP нередко ускоряет обработку в полтора-два раза без единой правки кода.
• Современный протокол. HTTP/2 позволяет грузить множество файлов по одному соединению, HTTP/3 дополнительно ускоряет установку соединения на нестабильных мобильных сетях. Проверьте, что на сервере включён хотя бы HTTP/2 — это часто вопрос одной настройки.

Шаг 2. Изображения — где лежит основной вес

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

Современные форматы

WebP меньше JPEG примерно на треть при сопоставимом качестве, AVIF сжимает ещё сильнее. Поддержка обоих в браузерах сегодня практически повсеместная. Простое правило: фотографии — в WebP или AVIF, простая графика и иконки — в SVG. Перевести изображения можно конвертером изображений, а поджать без потери качества — компрессором.

Правильный размер

Классическая ошибка — отдавать снимок 4000 пикселей шириной в блок, который занимает 400. Браузер загрузит все мегабайты и уменьшит их при отрисовке. Изображения нужно готовить под реальные размеры блока, а для разных экранов отдавать разные версии через атрибут srcset. Обрезать под нужный размер удобно кроппером.

Отложенная загрузка и приоритеты

Картинкам ниже первого экрана добавьте loading="lazy" — браузер загрузит их, когда пользователь до них доскроллит. А вот главному изображению первого экрана атрибут lazy ставить нельзя: это прямо ухудшает LCP. Наоборот, ему стоит указать высокий приоритет:

<!-- Главное изображение первого экрана -->
<img src="hero.webp" width="1200" height="630"
     fetchpriority="high" alt="Описание">

<!-- Изображения ниже по странице -->
<img src="photo.webp" width="800" height="600"
     loading="lazy" decoding="async" alt="Описание">

Атрибуты width и height обязательны у всех изображений — по ним браузер резервирует место до загрузки файла и не допускает скачка вёрстки. Это прямая профилактика проблем с CLS.

Шаг 3. Сжатие и кеширование в браузере

Две настройки на стороне сервера, которые внедряются один раз и работают для всего сайта.

Сжатие текстовых файлов

HTML, CSS, JavaScript, JSON и SVG сжимаются в три-пять раз. Есть два алгоритма: привычный gzip и более новый Brotli, который сжимает примерно на 15–20% лучше. Оптимально включить Brotli основным, а gzip оставить запасным вариантом. Сжимать уже сжатые файлы — изображения, видео — бессмысленно, они только займут процессор.

Кеширование в браузере

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

# --- Сжатие ---
<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/css text/javascript \
    application/javascript application/json image/svg+xml
</IfModule>

# --- Кеширование в браузере ---
<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/jpeg "access plus 1 month"
  ExpiresByType image/webp "access plus 1 month"
  ExpiresByType image/svg+xml "access plus 1 month"
  ExpiresByType text/css "access plus 1 week"
  ExpiresByType application/javascript "access plus 1 week"
  ExpiresByType text/html "access plus 0 seconds"
</IfModule>

Обратите внимание на обёртку <IfModule>: она проверяет, доступен ли модуль на сервере. Без такой проверки директива на сервере без нужного модуля обрушит сайт ошибкой 500 — типичная авария при ручном редактировании конфигурации.

Шаг 4. Скрипты, стили и метрика INP

Раздел, который в русскоязычных материалах обычно сводится к «уменьшите вес файлов». На деле проблема чаще не в весе, а во времени выполнения.

Почему INP — самая проблемная метрика

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

Причина плохого INP почти всегда одна: JavaScript занимает главный поток браузера. Пока выполняется длинная задача, браузер физически не может отреагировать на нажатие — интерфейс «залипает».

Что делать

• Убрать лишнее. Самый действенный шаг — проверить, какие сторонние скрипты реально нужны. Чаты, виджеты соцсетей, несколько систем аналитики разом, счётчики, всплывающие окна — каждый добавляет работы главному потоку. Часто половину можно выключить без потерь.
• Отложить неважное. Скриптам, не нужным для первой отрисовки, добавьте defer — они загрузятся параллельно и выполнятся после разбора разметки. Атрибут async подходит независимым скриптам вроде счётчиков.
• Разбивать длинные задачи. Если код выполняется дольше 50 мс подряд, его стоит разделить на части, отдавая управление браузеру между ними. Это техническая работа, но именно она чинит INP там, где удаление виджетов уже не помогает.
• Убрать неиспользуемый CSS. Типовая ситуация — подключённая целиком библиотека стилей ради десятка классов. Стили в шапке блокируют отрисовку, поэтому лишний вес здесь дороже, чем в других местах.
• Минифицировать. Удаление пробелов и комментариев даёт меньше сжатия, но работает вместе с ним. Подойдёт минификатор кода.

Шаг 5. Шрифты и стабильность вёрстки

Шрифты — частая причина и задержки отрисовки текста, и скачков вёрстки.

• Свойство font-display: swap заставляет браузер сразу показать текст запасным шрифтом и подменить его, когда загрузится основной. Без него посетитель какое-то время видит пустое место вместо текста.
• Размещайте шрифты у себя. Обращение к стороннему сервису — это лишнее определение адреса и установка соединения. Локальный файл экономит этот круг целиком.
• Формат WOFF2 — примерно на 30% компактнее предыдущего поколения и поддерживается всеми актуальными браузерами.
• Не тащите лишние начертания. Каждая толщина и курсив — отдельный файл. Обычно достаточно двух-трёх начертаний вместо восьми.
• Предзагрузка критичных шрифтов через <link rel="preload"> помогает, если шрифт нужен для текста первого экрана.

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

Шаг 6. Что можно сделать сверх базы

Приёмы для тех, кто закрыл предыдущие пункты и хочет большего.

• Сеть доставки содержимого. Копии статических файлов на серверах в разных регионах. Даёт ощутимый эффект, когда аудитория географически разбросана, и почти ничего — если весь трафик из одного города, где стоит сервер.
• Предварительное соединение. Тег <link rel="preconnect"> заранее устанавливает связь со сторонним доменом, с которого точно будут грузиться файлы. Экономит круг обмена, но применять стоит к двум-трём доменам, не больше.
• Кеш переходов «назад». Браузер умеет мгновенно возвращать предыдущую страницу из памяти, но эту возможность легко случайно отключить — например, заголовком Cache-Control: no-store. Проверить, доступен ли этот кеш, можно в инструментах разработчика, и восстановление даёт заметный выигрыш без переделки сайта.
• Предзагрузка следующей страницы. Современный механизм правил предзагрузки позволяет браузеру заранее подготовить страницу, на которую пользователь скорее всего перейдёт, — переход ощущается мгновенным. Важно не применять его к действиям, меняющим данные: выход из аккаунта, оформление заказа.
• Меньше редиректов. Каждая переадресация — дополнительный круг до сервера. Цепочка из трёх редиректов на входе съедает больше, чем экономит половина оптимизации картинок. Проверить и собрать корректные правила поможет генератор редиректов.

Пять заблуждений об ускорении

• «Главное — 100 баллов в тесте». Балл лабораторный и сводный. Оценивают страницу по трём метрикам на реальных данных. Бывает и наоборот: 70 баллов при полностью зелёных полевых показателях.
• «Поставил плагин кеширования — и всё». Плагин закрывает часть задач, обычно серверный кеш и сжатие. Он не уменьшит вес картинок, не уберёт четыре сторонних виджета и не починит INP.
• «Ускорение поднимет позиции». Само по себе — почти нет. Оно уберёт причину терять позиции и посетителей. Это разные вещи, и вторая тоже стоит работы.
• «У меня открывается мгновенно». У вас закешированный сайт, быстрый компьютер и проводной интернет. Смотрите полевые данные — там аудитория, а не вы.
• «Скорость — это про вес страницы». Наполовину. LCP действительно про вес и порядок загрузки, а INP — про время выполнения кода. Лёгкая страница с тяжёлым скриптом провалит INP.

Порядок действий

Если начинать с нуля, разумная последовательность такая:

1. Снимите исходные данные. Отчёт Core Web Vitals в Search Console плюс PageSpeed Insights по нескольким типовым страницам: главная, категория, карточка, статья.
2. Определите худшую метрику и работайте с ней. Заниматься CLS, когда провален LCP, — трата времени.
3. Проверьте TTFB. Если он выше секунды, начинайте отсюда: кеширование на сервере, версия PHP, при необходимости смена хостинга.
4. Займитесь изображениями. Форматы, размеры, отложенная загрузка, приоритет для главного изображения.
5. Включите сжатие и кеширование в браузере. Разовая настройка, работающая на весь сайт.
6. Проведите ревизию скриптов. Выпишите все сторонние подключения и честно ответьте, что из этого нужно.
7. Подождите и перепроверьте. Полевые данные обновляются с задержкой: окно измерения — 28 дней, поэтому эффект в отчётах виден не сразу.

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

Какая скорость загрузки считается хорошей?

Ориентируйтесь на метрики, а не на «секунды загрузки страницы»: LCP до 2,5 секунды, INP до 200 миллисекунд, CLS до 0,1 — по реальным данным, у минимум 75% посетителей. Из дополнительного стоит держать TTFB в пределах 0,8 секунды.

Влияет ли скорость на позиции в Яндексе?

Яндекс не публикует набор метрик, аналогичный Core Web Vitals, но учитывает удобство сайта, а медленная загрузка бьёт по поведенческим показателям, которые для Яндекса значимы. Практический вывод одинаков для обеих систем: работать над скоростью нужно, ждать от неё скачка позиций — нет.

Почему у меня 95 баллов, но проверка не пройдена?

Балл — лабораторный, проверка — по полевым данным реальных посетителей. У них медленнее устройства и сети. Ориентируйтесь на полевые показатели.

Нужна ли сеть доставки содержимого небольшому сайту?

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

Что даёт больше всего при минимуме усилий?

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

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

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

Стоит ли отказываться от аналитики ради скорости?

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

Коротко

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

Нормой считается LCP до 2,5 секунды, INP до 200 миллисекунд и CLS до 0,1 — по реальным данным, а не по лабораторному баллу. Разница между лабораторными и полевыми данными объясняет большинство недоразумений: тест показывает, что чинить, полевые данные — помогло ли.

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

Источники

Сверено с источниками на 12 октября 2026 года. Использованы страницы web.dev, документации Google и PageSpeed Insights; пороговые значения Core Web Vitals и TTFB, разница лабораторных и полевых данных и рекомендация fetchpriority="high" для главного изображения сверены с оригиналами.

1. web.dev. Web Vitals.
2. web.dev. Time to First Byte (TTFB).
3. web.dev. Optimize resource loading with the Fetch Priority API.
4. Google Search Central. Understanding Core Web Vitals and Google search results.
5. PageSpeed Insights. About PageSpeed Insights.