Производительность
Скорость загрузки сайта: что измерять и как ускорить
Один общий балл не объясняет, почему сайт медленный. Нужны полевые данные, лабораторная диагностика и разбор критического пути: сервер, изображения, шрифты, JavaScript и стабильность макета.
Коротко
Скорость загрузки сайта оценивают по реальному пользовательскому опыту и технической диагностике. Основные Core Web Vitals — LCP, INP и CLS — показывают скорость появления главного контента, отзывчивость и визуальную стабильность, а лабораторные инструменты помогают найти конкретную причину.
Какие метрики описывают скорость загрузки сайта
Пользователь воспринимает скорость как последовательность: увидел основной контент, смог нажать кнопку, не потерял место из-за прыгающего макета. Поэтому одной длительности полной загрузки недостаточно. Core Web Vitals описывают три разные части опыта.
LCP измеряет момент отображения крупнейшего видимого элемента. Хорошим считается значение не более 2,5 секунды. INP оценивает задержку взаимодействий на протяжении визита; хороший ориентир — не более 200 миллисекунд. CLS показывает неожиданные сдвиги макета; хорошее значение — не более 0,1.
Порог оценивают по 75-му процентилю реальных загрузок отдельно для мобильных и настольных устройств. Это значит, что быстрый тест на мощном ноутбуке не доказывает, что сайт удобен аудитории с бюджетным телефоном и нестабильной сетью.
| Метрика | Что чувствует пользователь | Хорошее значение |
|---|---|---|
| LCP | Когда появился главный контент | ≤ 2,5 с |
| INP | Насколько быстро интерфейс отвечает | ≤ 200 мс |
| CLS | Насколько стабилен макет | ≤ 0,1 |
| TTFB | Как быстро сервер начал ответ | Диагностический показатель |
Полевые и лабораторные данные: почему результаты отличаются
Полевые данные собираются у реальных пользователей. Они учитывают устройства, сеть, географию, кеш, страницы и поведение аудитории. Именно они показывают, проходит ли сайт пороги Core Web Vitals в реальной эксплуатации.
Лабораторный тест запускается в контролируемых условиях и повторяет загрузку с заданным профилем. Он полезен для отладки: строит водопад запросов, показывает блокирующие ресурсы, длинные задачи JavaScript и кандидата LCP. Но один запуск не представляет всю аудиторию.
Рабочий процесс сочетает оба источника. Полевой отчет отвечает, где проблема действительно массовая; лаборатория помогает воспроизвести и объяснить ее; мониторинг после релиза проверяет, улучшился ли реальный опыт.
- Search Console и Chrome UX Report — агрегированные полевые показатели.
- Real User Monitoring — собственные данные по страницам, устройствам и релизам.
- PageSpeed Insights — полевой срез и лабораторная диагностика в одном отчете.
- Lighthouse и DevTools Performance — воспроизведение и поиск конкретной причины.
- WebPageTest — детальный водопад и сравнение повторных загрузок.
Как найти причину медленной страницы
Начинайте не со списка рекомендаций, а с конкретного шаблона и пользовательского действия. Главная, категория, карточка товара и кабинет могут иметь разные ограничения. Для каждой страницы фиксируют устройство, сеть, холодную или повторную загрузку и проблемную метрику.
Для LCP находят сам элемент и проверяют четыре части: время ответа сервера, момент обнаружения ресурса, время его загрузки и задержку от готовности до отрисовки. Изображение может быть маленьким, но обнаруживаться слишком поздно из-за CSS-фона или клиентского рендера.
Для INP ищут длинные задачи основного потока, тяжелые обработчики и лишний рендер. Для CLS определяют элементы без зарезервированного места: изображения, реклама, баннер cookie, подгружаемый шрифт или вставка формы над текущим контентом.
- Выбрать страницу и сценарийЗафиксировать URL, устройство, сеть и действие пользователя.
- Проверить полевые данныеПонять масштаб, сегмент и проблемную метрику.
- Записать трассировкуНайти LCP-элемент, длинные задачи, запросы и сдвиги.
- Сформулировать гипотезуСвязать изменение с ожидаемым влиянием на метрику.
- Измерить после релизаСравнить лабораторный тест и реальные данные на стабильном периоде.
Как выбрать первую задачу по скорости
Список Lighthouse нельзя переносить в бэклог без приоритета. Мы оцениваем каждую проблему по четырём параметрам: доля затронутых визитов, критичность сценария, уверенность в причине и стоимость исправления. Практическая формула: приоритет = охват × влияние × уверенность ÷ трудоёмкость.
Это не академическая метрика, а способ принять решение между разными типами работ. Например, поздно загружаемое hero-изображение на всех посадочных обычно важнее тяжёлого отчёта, который открывают два сотрудника раз в месяц. Но зависание кнопки оплаты получает высокий приоритет даже при небольшом охвате.
| Гипотеза | Охват | Влияние | Решение |
|---|---|---|---|
| LCP-изображение обнаруживается после CSS | Все визиты на посадочные | Высокое | Исправить первым релизом |
| Сторонний виджет блокирует главный поток | Страницы с формой | Высокое | Отложить загрузку и измерить INP |
| Шрифт меняет размеры заголовка | Первое открытие сайта | Среднее | Зафиксировать fallback и preload |
| Медленный внутренний отчёт | Небольшая группа сотрудников | Высокое | Оптимизировать отдельным потоком |
Изображения, шрифты и JavaScript
Изображения часто дают самый быстрый выигрыш. Размер файла должен соответствовать реальному контейнеру, формат — содержанию, а варианты srcset — плотности экрана. Главный визуал нельзя лениво загружать как контент ниже первого экрана; второстепенные изображения, наоборот, не должны конкурировать с ним.
Шрифты сокращают до нужных начертаний и символов, размещают предсказуемо и задают стратегию отображения. Предзагрузка полезна только для критичного файла: если объявить приоритет всем ресурсам, браузер теряет возможность выбирать.
JavaScript влияет и на загрузку, и на отзывчивость. Удаляют неиспользуемые зависимости, делят код по маршрутам, откладывают виджеты и не гидратируют статичный контент без необходимости. Особое внимание — сторонним чатам, аналитике, картам и A/B-платформам: их стоимость должна быть видна в бюджете производительности.
| Ресурс | Типичная проблема | Практическое действие |
|---|---|---|
| Изображение | Оригинал больше контейнера | Responsive sizes, сжатие, современный формат |
| Шрифт | Много начертаний и поздняя замена | Subset, preload одного критичного файла, fallback |
| CSS | Блокировка первого отображения | Критичные стили и удаление неиспользуемого |
| JavaScript | Большой bundle и длинные задачи | Code splitting, defer, сокращение работы |
| Сторонний код | Загрузка без контроля | Согласие, задержка, замена или удаление |
Сервер, кеш и работа с данными
Медленный ответ сервера отодвигает все последующие события. Проверяют DNS и соединение, регион размещения, кеш страницы и API, запросы к базе, внешние зависимости и формирование HTML. В приложении полезно разделять время на gateway, backend, database и сторонние сервисы.
Кеширование проектируют по типу данных. Публичная статья может долго храниться на CDN, остаток товара требует короткого срока и обновления по событию, личные данные не должны попадать в общий кеш. Неверный кеш ускоряет страницу ценой устаревшей или чужой информации.
API не должен заставлять интерфейс ждать весь массив данных. Используют пагинацию, выбор нужных полей, предварительное вычисление тяжелых отчетов и параллельные запросы там, где нет зависимости. Если внешний сервис нестабилен, интерфейс должен показывать контролируемое состояние, а не бесконечный спиннер.
- CDN для статических ресурсов и подходящего публичного HTML.
- Кеш приложения и базы с правилами инвалидации.
- Индексы и анализ медленных SQL-запросов.
- Таймауты, повторы и circuit breaker для внешних API.
- Пагинация и ограничение размера ответа.
- Наблюдаемость по endpoint, релизу и percentile, а не только среднему.
Как сохранить стабильность интерфейса
У изображения и видео задают width, height или aspect-ratio, чтобы браузер зарезервировал место до загрузки. Динамический блок получает стабильный контейнер, skeleton соответствует будущей геометрии, а сообщения об ошибке не должны сдвигать всю страницу.
Баннер cookie, уведомление и форма появляются в предусмотренной зоне или поверх контента без неожиданного перемещения. Если пользователь уже начал читать или нажимать, интерфейс не должен перестраиваться из-за поздней рекламы или виджета.
Оптимизация шрифта включает похожий по метрикам fallback. Иначе заголовок сначала занимает одну высоту, затем переносится после загрузки фирменного начертания. Проверять нужно длинные тексты, мобильный экран и системное увеличение масштаба.
План оптимизации скорости без бесконечной переделки
Сначала исправляют ошибки измерения и критический путь, затем самые тяжелые ресурсы и длинные задачи, после — системные ограничения архитектуры. Каждая задача получает исходную метрику, ожидаемый эффект и страницу проверки.
Чтобы скорость не ухудшилась через месяц, задают performance budget: максимальный вес критичных ресурсов, допустимое количество JavaScript и пороги метрик. Проверки добавляют в CI, а реальные показатели — в мониторинг релизов.
Оптимизация особенно полезна перед рекламным масштабированием, редизайном и ростом каталога. Ее можно начать с технического аудита, а затем перейти к ускорению конкретных шаблонов.
- Базовая линияПолевые данные и повторяемые лабораторные сценарии.
- Критические исправленияLCP-ресурс, сервер, блокирующие файлы и крупные сдвиги.
- Сокращение работыJS, изображения, шрифты, API и сторонние виджеты.
- Защита результатаБюджеты, CI-проверки и наблюдение за реальными пользователями.
FAQ
Частые вопросы
01Какая скорость загрузки сайта считается хорошей?
Ориентируйтесь не на полную загрузку, а на Core Web Vitals в полевых данных: LCP до 2,5 с, INP до 200 мс и CLS до 0,1 по 75-му процентилю.
02Почему PageSpeed показывает разные баллы?
Лабораторный тест зависит от сети, устройства, состояния сервера и сторонних ресурсов. Сравнивайте одинаковые условия и используйте полевые данные для оценки реального опыта.
03Поможет ли CDN ускорить любой сайт?
CDN ускоряет доставку статических и кешируемых ресурсов, но не исправляет тяжелый JavaScript, медленную базу, неправильную архитектуру API или нестабильный макет.
04Нужно ли добиваться 100 баллов?
Нет. Приоритет — стабильное прохождение ключевых сценариев реальными пользователями. После достижения хороших порогов выгоднее защищать результат и улучшать бизнес-сценарий.
Источники и документация
Материал подготовлен редакцией ХЭМС на основе проектной практики. Цены и технические условия актуальны на дату публикации и уточняются после разбора задачи.
Обсудить проект
Найдем, что действительно тормозит сайт
Проверим реальные метрики, критические шаблоны, сервер и frontend. Сформируем приоритетный план и измерим результат после исправлений.