Скорость загрузки сайта: на что влияет и как её измерить
Скорость загрузки сайта — время от перехода по ссылке до момента, когда страница показала содержимое и стала пригодной для взаимодействия. Единого числа тут нет: скорость описывают набором метрик, каждая из которых отвечает за свой этап загрузки.
Ниже — какие метрики считаются основными и с какими порогами, чем их измерить, что реально ускоряет сайт и почему одинаковая страница у двух посетителей грузится по-разному.
Какие метрики измеряют скорость
Основной набор — Core Web Vitals: три показателя, описывающих загрузку, отзывчивость и стабильность страницы. У каждого есть пороговое значение, ниже которого опыт считается хорошим.
| Метрика | Что измеряет | Хорошее значение |
|---|---|---|
| LCP (Largest Contentful Paint) | Когда отрисовался самый крупный элемент экрана — обычно главная картинка или заголовок | до 2,5 с |
| INP (Interaction to Next Paint) | Насколько быстро страница отвечает на действия пользователя | до 200 мс |
| CLS (Cumulative Layout Shift) | Насколько сильно содержимое прыгает при загрузке | до 0,1 |
| TTFB (Time to First Byte) | Сколько сервер думает, прежде чем начать отдавать страницу. Не входит в Core Web Vitals, но задерживает всё остальное | до 0,8 с |
INP пришёл на смену метрике FID: старый показатель учитывал только первое взаимодействие, новый — все, и потому честнее описывает ощущение «тормозит». CLS часто недооценивают, а он отвечает за самый раздражающий сценарий: человек целится в кнопку, страница дорисовывает баннер, кнопка уезжает, палец попадает не туда.
Чем измерять
Инструменты делятся на два типа, и они дают разные ответы на разные вопросы. Путать их — источник бесконечных споров «а у меня всё быстро».
- Лабораторные — Lighthouse, PageSpeed Insights в части синтетического теста. Прогоняют страницу в контролируемых условиях. Отвечают на вопрос «что чинить»: дают список проблем и их вклад.
- Полевые — данные реальных пользователей: отчёты в PageSpeed Insights по накопленной статистике, собственные замеры в аналитике. Отвечают на вопрос «плохо ли на самом деле».
Практическое правило: решение о том, нужно ли вообще ускорять, принимают по полевым данным, а список работ составляют по лабораторным. Лабораторный тест на быстром канале легко покажет отличный результат там, где реальные посетители с телефона в метро ждут восемь секунд.
Что реально ускоряет сайт
Порядок работ определяется вкладом, а не простотой. На большинстве сайтов 80% проблемы дают изображения и скрипты, и начинать нужно с них, а не с настроек сервера.
- Изображения. Современные форматы, правильные размеры под контейнер, отложенная загрузка того, что ниже первого экрана. Картинка на 3 МБ в шапке перечёркивает любую оптимизацию кода.
- Сторонние скрипты. Счётчики, виджеты чатов, пиксели, карты. Каждый добавляет запросы и время. Убирать нужно не все, а те, которыми никто не пользуется.
- Кэширование. Браузерное и серверное: повторные заходы должны обходиться дешевле первого.
- Сжатие и минификация. Текстовые файлы передаются сжатыми, лишние пробелы и комментарии убираются.
- Шрифты. Подключение с отображением запасного шрифта до загрузки основного — иначе текст невидим первые секунды.
- Сервер и хостинг. Время ответа сервера — фундамент: если он отвечает за секунду, быстрее секунды страница не появится никак.
Если медленный сервер: TTFB больше секунды
При таком ответе сервера хорошего LCP не получится при любой вёрстке, поэтому начинают с сервера. Типичные причины:
- Виртуальный хостинг. Процессор и диск делятся с сотнями соседей, и в пиковые часы ответ проседает без изменений на сайте. Признак — TTFB «гуляет» в течение дня. Зарубежный дата-центр добавляет задержку каждому запросу.
- Тяжёлый бэкенд. Фильтры без индексов в базе, запросы в цикле, синхронный обмен с 1С или внешним API прямо во время загрузки страницы. Лечится профилированием: какой запрос медленный и можно ли вынести его в фон.
- Нет кеша. Сервер заново собирает одну и ту же страницу на каждый визит. Уровни кеша: скомпилированный PHP (OPcache), объектный (Redis, Memcached), готовый HTML в nginx и браузерный для статики.
- Цепочки редиректов. http → https → www → слеш: каждый шаг — отдельный запрос. Ссылки в меню, рекламе и карте сайта должны вести сразу на конечный адрес.
Что включают на сервере: PHP 8.x вместо 7.x, OPcache с достаточной памятью, HTTP/2, сжатие gzip или brotli, кеш страниц в nginx и долгий Cache-Control для статики, при аудитории по всей стране — CDN. Это работа администратора: настройка сервера и настройка nginx.
Ускорение в Битриксе и WordPress
1С-Битрикс. Диагностику начинают с монитора производительности: он показывает медленные страницы, компоненты и SQL-запросы. Дальше — проверить, что автокеширование компонентов включено (его часто выключают при отладке и забывают), включить композитный режим, который отдаёт статическую копию страницы и подгружает корзину и авторизацию отдельно, и перенести кеш из файлов в Redis или memcached.
WordPress. Кеш-плагин страниц, объектный кеш на Redis и ревизия плагинов: каждый подключает свои файлы и запросы. Визуальные конструкторы утяжеляют вёрстку — ключевые шаблоны иногда выгоднее переверстать вручную.
Ошибки при ускорении
- Гнаться за 100 баллами Lighthouse. Балл — лабораторная оценка, поисковики его не используют, а путь с 85 до 100 часто требует убрать виджеты, которые приносят заявки. Цель — зелёные полевые показатели.
- Чинить вёрстку при медленном сервере. При TTFB в две секунды фронтенд не спасёт.
- Не следить за скоростью после запуска. Сайт медленнеет постепенно: новые скрипты, тяжёлые фото, плагины. Без мониторинга это замечают по падению заявок.
На что скорость влияет
На две вещи сразу: на конверсию и на позиции. Первое прямее и заметнее, второе работает как один из факторов среди многих.
Про конверсию: медленная загрузка увеличивает долю тех, кто ушёл, не дождавшись. Особенно на мобильных, где соединение хуже, а терпение меньше. Это видно в аналитике как рост отказов на входных страницах при неизменном трафике.
Про позиции: скорость и удобство страницы учитываются поисковыми системами, но не перевешивают соответствие запросу. Быстрый сайт с нерелевантным содержанием не обгонит медленный, который отвечает на вопрос точнее. Порядок приоритетов — сначала релевантность, потом скорость.
Почему у разных людей грузится по-разному
Потому что итоговое время складывается не только из сайта. На него влияют устройство, качество соединения, удалённость от сервера, установленные расширения и то, заходил ли человек раньше.
Отсюда практическое следствие: ориентироваться нужно на распределение, а не на среднее. Средняя скорость может быть приличной при том, что четверть посетителей ждёт втрое дольше, — и именно эта четверть уходит. Полевые отчёты показывают такие распределения, лабораторный тест — нет.
Чек-лист ускорения
- Снять полевые данные: PageSpeed Insights и отчёт «Время загрузки страниц» в Метрике
- Прогнать Lighthouse по каждому шаблону, мобильная версия в приоритете
- Если TTFB больше 0,8 с — начать с сервера, кеша и базы данных
- Проверить PHP 8.x, OPcache, HTTP/2, сжатие и кеш статики
- Включить кеш CMS: компоненты и композит в Битриксе, кеш-плагин и Redis в WordPress
- Изображения: WebP или AVIF, размеры под контейнер, lazy-load ниже первого экрана, приоритет главной картинки
- Сторонние скрипты: удалить лишние, остальные грузить отложенно
- JS с defer или async, критический CSS, шрифты — 2–3 начертания в WOFF2
- Убрать цепочки редиректов во внутренних ссылках
- После правок проверить формы, корзину и оплату; повторный полевой замер — через 28 дней
Коротко
- Скорость описывается набором метрик: LCP (до 2,5 с), INP (до 200 мс), CLS (до 0,1).
- INP заменил FID и учитывает все взаимодействия, а не только первое.
- Лабораторные тесты показывают, что чинить; полевые данные — насколько это срочно.
- Основной вклад обычно дают изображения и сторонние скрипты; но если TTFB больше 0,8 с, начинать нужно с сервера.
- Скорость влияет на конверсию прямо, на позиции — как один фактор среди многих.
- Смотреть нужно распределение по пользователям, а не среднее значение.
Проводим технический аудит и выводим сайты в топ — поисковое продвижение сайтов. Смежное: что проверять при SEO-аудите.