Как проверить скорость загрузки сайта и устранить задержки

Как проверить скорость загрузки сайта: короткий маршрут

Чтобы проверить скорость сайта, откройте нужную страницу в PageSpeed Insights, посмотрите мобильный и компьютерный отчёты, затем разберите причины задержек в Lighthouse. Если есть доступ, добавьте данные Search Console, Вебмастера и Метрики. Исправляйте конкретный этап: ожидание ответа, загрузку изображения, шрифта или работу JavaScript. После каждого изменения повторяйте замер в сопоставимых условиях.

Одна цифра «сайт загружается за столько-то секунд» мало объясняет. Посетитель может уже видеть заголовок, но ещё ждать главное фото. Или страница выглядит готовой, а меню не отвечает на нажатие. Поэтому мы предлагаем смотреть отдельно на появление содержимого, реакцию на действия и сдвиги блоков во время загрузки.

Начните с набора адресов: главная, важная услуга, категория, карточка товара, статья. Выберите страницы с настоящими фотографиями, фильтрами и формами. Если замерить только лёгкую главную, можно пропустить проблему в каталоге. Это рабочая выборка для диагностики, а не обязательный список для каждого сайта.

Эти инструменты отвечают на разные вопросы. Источники данных PSI описаны в официальной справке PageSpeed Insights. Возможности остальных отчётов разберём ниже. Для общей проверки проекта полезен также чек-лист SEO-аудита: скорость — одна из его технических частей.

PageSpeed Insights и Lighthouse: что именно смотреть

Сначала отделите реальные посещения от теста

Полевые данные описывают опыт реальных пользователей. В PSI они поступают из Chrome User Experience Report — CrUX — за предыдущие 28 дней. Это накопленная история, поэтому изменение сайта сегодня не переписывает весь результат немедленно. Посмотрите, относится ли блок к этому URL или к origin — совокупности страниц с той же схемой, хостом и портом.

Лабораторные данные — результат отдельного запуска с определёнными условиями устройства и сети. Они помогают воспроизвести задержку и найти ресурс или участок кода. По разъяснению web.dev, расхождение с полем естественно: у аудитории разные устройства, география, состояние кэша и действия на странице.

Если статистики конкретной страницы недостаточно, PSI может показать данные origin. Если недостаточно и их, полевой блок будет недоступен. Это не оценка «всё хорошо». Сохраните лабораторный отчёт и продолжайте диагностику; отсутствие истории посещений не мешает искать тяжёлые изображения или задержку ответа.

Порядок проверки одного адреса

1. Откройте PageSpeed Insights, вставьте полный адрес страницы и запустите анализ.
2. Посмотрите отдельно мобильный и компьютерный результаты. Запишите дату, URL, тип устройства и уровень полевых данных: страница или origin.
3. Отделите оценку Core Web Vitals от балла лабораторной производительности. Это разные результаты, даже если рядом используются одинаковые цвета.
4. В диагностике найдите LCP-элемент и причины задержек. Отметьте тяжёлые ресурсы, работу скриптов и сдвиги содержимого.
5. Сохраните отчёт. Повторите запуск в тех же условиях, если результат заметно отличается от предыдущего, и разбирайте устойчивые причины.

Для подробной проверки откройте страницу в Chrome, затем инструменты разработчика и вкладку Lighthouse. Выберите нужное устройство и анализ производительности, запустите проверку загрузки. Документация Lighthouse описывает запуск в DevTools и командной строке; точные подписи кнопок зависят от версии браузера.

Какие показатели важнее общего балла

Это ориентиры Web Vitals для 75-го перцентиля (p75), отдельно на мобильных устройствах и компьютерах: страница проходит порог, если как минимум у 75% загрузок значение не хуже указанного. Подробности оценки разобраны в статье серии о Core Web Vitals и их улучшении.

INP требует взаимодействий. Обычный тест открытия страницы не воспроизводит все действия посетителя. Лабораторный TBT помогает искать занятость главного потока при загрузке, но не заменяет пользовательский INP. Отдельно пройдите открытие меню, применение фильтра и отправку формы.

Что добавят Вебмастер, Search Console и Метрика

В отчёте Core Web Vitals в Search Console страницы объединяются в группы похожих URL. Найдите проблемную группу, откройте её примеры и разберите несколько страниц соответствующего шаблона. Исправление общей ошибки карточек товара может дать больше пользы, чем работа над отдельным замечанием к редко посещаемой странице.

Search Console опирается на реальные данные с 28-дневным окном. Это не полный перечень всех страниц сайта и не тест последней версии кода по нажатию кнопки. Запишите дату исправления, замерьте результат лабораторно, затем наблюдайте за изменением полевых показателей.

У Яндекса другая задача отчёта: в разделе «Оптимизация сайта → Диагностика сайта → Ошибки» есть сообщение «Долгий ответ сервера». Оно основано на наблюдениях робота при обходе: если некоторые страницы отвечают дольше 3 секунд, Вебмастер фиксирует ошибку, а индексирование сайта может задерживаться. В «Индексирование → Статистика обхода» можно посмотреть коды ответов и посещённые адреса.

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

Для пользовательской стороны у Яндекса есть отчёт Метрики «Время загрузки страниц»: «Отчёты → Мониторинг → Время загрузки страниц». При установленном счётчике и доступе к данным сравните отдельные URL, регионы и браузеры. Посмотрите, какой этап занимает больше времени. Названия и методику метрик не приравнивайте к LCP или TTFB.

Изображения: уменьшить файл и правильно начать загрузку

Сначала найдите изображение, которое влияет на первый экран. Это может быть обложка, фотография товара или фон, но крупнейшим элементом может оказаться и текст. В руководстве по оптимизации LCP предлагается разбирать всю цепочку: ответ сервера, начало загрузки ресурса, передачу файла и его отрисовку.

WebP и AVIF — после проверки размера и качества

WebP и AVIF могут дать более эффективное сжатие, чем PNG или JPEG. Сравните варианты одного изображения по фактическому весу и внешнему виду: фактура товара, мелкие детали и границы должны оставаться читаемыми.

Подготовьте версии под реальный размер вывода. Если на телефоне показывается небольшая карточка, не заставляйте браузер получать исходную фотографию для печати. Разработчик может использовать srcset и sizes, чтобы браузер выбирал подходящий ресурс. Уменьшение картинки только средствами CSS не заменяет подготовку файла.

Отложенная загрузка — для изображений ниже первого экрана

Атрибут loading="lazy" откладывает получение картинки до её приближения к видимой области. Он полезен для длинной статьи или каталога. Но главное LCP-изображение откладывать нельзя: это задерживает начало его загрузки. Для него убедитесь, что браузер обнаруживает ресурс рано; при необходимости разработчик задаст повышенный приоритет через fetchpriority.

Ниже — учебный фрагмент для фотографии ниже первого экрана. Путь и размеры условные: вместо них нужны файлы и пропорции вашего изображения. Для главной фотографии первого экрана loading="lazy" из этого примера использовать не следует.

<img
  src="/images/product-detail.webp"
  width="1200"
  height="800"
  loading="lazy"
  alt="Крупный план соединительного узла">

Атрибуты width и height сообщают браузеру пропорции картинки, а не задают требуемое разрешение файла. Браузер может заранее отвести место под картинку; в адаптивной вёрстке разработчик сохраняет её соотношение сторон. Резервирование места уменьшает сдвиги, но не уменьшает вес файла — это отдельная задача.

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

Шрифты: оставить нужные файлы и сохранить читаемость

Выясните, какие семейства, начертания и языковые наборы действительно используются. Файл, нужный лишь для декоративной подписи внизу, не должен автоматически становиться первым кандидатом на предварительную загрузку. В руководстве web.dev по веб-шрифтам разбираются WOFF2, сокращение наборов символов, preload и font-display.

• Формат. Используйте WOFF2 там, где это соответствует поддерживаемым браузерам проекта.
• Состав. Уберите неиспользуемые начертания и лишние языковые наборы. Сохраните кириллицу, знаки валют, специальные символы и всё, что встречается в контенте.
• Обнаружение. Для действительно важного шрифта первого экрана рассмотрите preload. Предварительная загрузка всех файлов подряд лишает этот выбор смысла.
• Отображение. Настройте font-display и подходящий запасной шрифт, затем проверьте текст до и после подмены.

Например, font-display: swap позволяет сразу показать текст запасным шрифтом. Но если его размеры сильно отличаются от основного, строки могут перестроиться после загрузки. Сверьте длину заголовков, переносы в меню и высоту кнопок. Совет «поставить swap» без визуальной проверки не закрывает задачу стабильности.

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

JavaScript: страница должна реагировать на действия

JS приходится не только скачать, но и выполнить. По документации web.dev, главный поток браузера обрабатывает задачи по очереди. Когда он занят длинной работой, действие пользователя ждёт своей обработки. Поэтому небольшой по весу скрипт тоже может создавать заметную задержку.

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

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

Это задачи для разработчика. Не стоит просто переносить все скрипты в конец страницы: сначала выясните порядок зависимостей и момент, когда код нужен. В руководстве по INP разбор включает ожидание обработки, выполнение обработчиков и отрисовку результата.

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

Сервер и TTFB: где начинается ожидание

TTFB — время от начала перехода до получения первого байта ответа. По определению web.dev, сюда могут входить перенаправления, DNS, установка соединения и TLS, а также ожидание ответа. Это не синоним времени выполнения PHP и не измерение только базы данных.

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

Это направления исследования, а не готовый диагноз по одному признаку. Попросите разработчика приложить к выводу данные о времени генерации и найденных запросах. Если проблема действительно в ресурсах сервера, тогда сравнивайте окружение и нагрузку. Критерии выбора площадки разобраны в статье о хостинге для сайта.

Кэширование, сжатие и CDN: три разные задачи

Кэш помогает повторно использовать готовый результат

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

Для неизменяемых CSS, JS и изображений разработчик задаёт правила хранения через Cache-Control и меняет версию или хеш в URL при обновлении файла. Так новый ресурс получает другой адрес. В руководстве MDN по HTTP-кэшу описаны этот подход и различие частного и общего кэша.

Не задавайте одно правило всему сайту. Корзина, личный кабинет и персональные цены требуют отдельного решения. Убедитесь, что общий кэш не отдаёт одному пользователю ответ другого. Директива private ограничивает хранение частным кэшем; no-cache разрешает хранить ответ, но требует проверки его актуальности перед повторным использованием из HTTP-кэша; no-store запрещает хранить ответ. Их нельзя считать взаимозаменяемыми переключателями.

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

Сжатие сокращает объём передаваемого текста

Минификация убирает из CSS и JS лишние пробелы и комментарии. HTTP-сжатие — другой механизм: сервер передаёт сжатое тело ответа, а браузер его распаковывает. Проверьте поддержку gzip или Brotli и фактический заголовок Content-Encoding у текстовых ресурсов. MDN описывает настройку и согласование сжатия.

Смотрите HTML, CSS и JS, а не пытайтесь оценить всё по фотографии: для уже сжатых форматов повторное сжатие часто не даёт пользы. Приёмка должна показать, какие ответы действительно передаются в сжатом виде.

CDN меняет путь доставки ресурсов

CDN может уменьшить сетевую задержку за счёт расположения узлов и кэширования. Решение особенно стоит рассмотреть, если существенна география аудитории. Но эффект зависит от попаданий в кэш, настроек и маршрута: само подключение не исправляет долгий запрос к базе или тяжёлый обработчик кнопки.

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

Как ускорить сайт на 1С-Битрикс

У платформы есть несколько механизмов ускорения, но они решают разные задачи. Кэш компонента уменьшает повторную работу компонента, композит меняет выдачу страницы, а оптимизация CSS/JS — доставку клиентских ресурсов. Если вы выбираете CMS, общий контекст есть в статье о возможностях 1С-Битрикс.

Проверьте кэш компонентов и обновление данных

В документации автокэширования описаны режимы «Авто + Управляемое», «Кешировать» и «Не кешировать». Глобальное включение и параметры конкретного компонента нужно рассматривать вместе. Если компонент настроен работать без кэша, одна общая настройка не подтверждает его ускорение.

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

Настройте композит с учётом динамических блоков

По описанию технологии «Композитный сайт», страница делится на статическую и динамическую части. Готовая статическая часть берётся из кэша, динамическая догружается в фоне. Это помогает раньше показать подготовленное содержимое, но не является измерением скорости каждой операции магазина.

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

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

Объединяйте CSS/JS после проверки зависимостей

В настройках главного модуля описаны «Объединять CSS файлы», «Объединять JS файлы» и «Подключать минифицированные версии CSS и JS файлов». Есть и отдельная опция переноса JavaScript в конец страницы. Сверьте названия и расположение с установленной версией.

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

Для приёмки сохраните список изменённых настроек, отчёты до и после, результаты проверки обновления данных и функциональных сценариев. Такой набор понятнее формулировки «включили ускорение Битрикса» и позволяет вернуть конкретное изменение при ошибке.

В каком порядке исправлять и что принять у разработчика

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

Учебный пример: в карточке товара поздно появляется основное фото, а переключение характеристик работает быстро. Сначала найдите LCP-элемент. Если им оказалось фото, посмотрите его фактический размер, формат, момент начала загрузки и то, что для него не включена отложенная загрузка (loading="lazy"). Если LCP — текст, разберите шрифт и задержку отрисовки.

У задачи должна быть проверяемая формулировка: «подготовить адаптивные версии изображений карточки и проверить LCP на выбранных URL». Рядом запишите адреса, условия запуска, исходный отчёт и способ проверки качества. Формулировка «ускорить сайт» без этих данных оставляет слишком много вариантов трактовки.

Чек-лист проверки и ускорения

1. Выборка. Собраны адреса основных шаблонов с настоящим содержимым и рабочими сценариями.
2. Исходные данные. Сохранены мобильный и компьютерный отчёты, дата и условия запуска; полевые данные отделены от лабораторных.
3. Область статистики. Проверено, относится результат к URL, origin или группе страниц; отсутствие данных отмечено отдельно.
4. Сервер. Проверены ожидание первого байта, перенаправления, генерация страницы и работа кэша.
5. Изображения. Подготовлены подходящие размеры и форматы, главное изображение не отложено, место под картинки зарезервировано.
6. Шрифты и код. Убраны лишние ресурсы, проверены отображение текста, меню, фильтры, формы и сторонние виджеты.
7. Доставка. Подтверждены правила кэша и сжатие текстовых ответов; при CDN проверены регионы, обновления и исключения.
8. 1С-Битрикс. Проверены кэш компонентов, композит, CSS/JS и корректность динамических блоков.
9. Повторный замер. Условия сопоставимы, изображения и текст не потеряли качество, функциональные сценарии проходят.
10. Наблюдение. Дата выпуска записана; назначен следующий просмотр полевых данных по мере накопления новой истории.

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

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

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

Нужно ли добиваться 100 баллов в PageSpeed Insights?

Не делайте балл единственным условием приёмки. Смотрите конкретные задержки, полевые метрики и возможность пользоваться сайтом. Google сообщает, что Core Web Vitals используются его системами ранжирования, но хорошие результаты не гарантируют верхних позиций, а добиваться идеальной оценки только ради SEO он не советует.

Почему на компьютере быстро, а на телефоне медленно?

У тестов и посетителей различаются устройство, сеть и видимая область. На телефоне может оказаться другой LCP-элемент, а код — занимать больше времени. Сравните мобильную диагностику, реальные данные и конкретные действия; не переносите результат компьютера на смартфон.

Что делать, если в PageSpeed нет данных реальных пользователей?

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

Достаточно ли заменить все фотографии на WebP?

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

Когда будет виден результат ускорения?

Повторный лабораторный тест позволяет оценить текущую версию сразу после изменений. Полевые отчёты отражают накопленные посещения: PSI и Search Console используют 28-дневную историю. Наблюдайте динамику после даты выпуска; не обещайте точный день изменения оценки или поисковой позиции.

Источники

• Устройство PSI и источники данных — Google for Developers, About PageSpeed Insights; термин origin — глоссарий MDN; запуск диагностики — Chrome for Developers, Lighthouse overview.
• Различия лаборатории и поля — Philip Walton, web.dev, Why lab and field data can be different; метрики и пороги — Web Vitals.
• Реальные метрики и группы URL — Google Search Console Help, Core Web Vitals report; ограничения SEO-выводов — Google Search Central, Understanding page experience.
• Проверки Яндекса — Вебмастер, «Ошибки на сайте» и «Статистика обхода»; Метрика, «Время загрузки страниц».
• Загрузка и геометрия — web.dev, Optimize LCP, Optimize CLS, Time to First Byte.
• Ресурсы и взаимодействия — web.dev, Image performance, Optimize web fonts, Optimize long tasks, Optimize INP и Code-split JavaScript.
• Доставка — MDN Web Docs, HTTP caching и Compression in HTTP; Katie Hempenius, web.dev, Content delivery networks; минификация — web.dev, Optimize resource loading.
• Средства платформы — 1С-Битрикс, «Автокеширование», «Настройки главного модуля», «Композитный сайт».