Скорость загрузки сайта: как проверить и ускорить на примере 1С-Битрикс

Скорость загрузки сайта стоит проверить первой, когда подрядчик, сервис или клиенты говорят, что сайт «медленный». Разберу, как сделать замер самому, какие цифры действительно важны и какие работы брать первыми. Практика — на 1С-Битрикс.

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

Ниже кейс с реальными замерами до и после. С разбросом, без «было 40 — стало 95».

Зачем нужна скорость загрузки сайта и влияет ли она на SEO

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

Что говорит Яндекс

В справке Яндекс Вебмастера «Как сделать сайт быстрее» скорость загрузки страниц названа одним из важных показателей качества сайта. Логика там пользовательская: при низкой скорости человек может не дождаться открытия страницы и уйти на другой ресурс. Это снижает доверие к сайту, посещаемость и влияет на другие статистические показатели. Слов «фактор ранжирования» и обещаний роста позиций в справке нет.

Что говорит Google

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

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

Я считаю скорость гигиеной. Сама по себе она сайт не продвигает. Но тяжёлая страница теряет посетителей ещё до того, как они увидели предложение.

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

Одного «лучшего сервиса» нет: разные инструменты отвечают на разные вопросы. Главный — PageSpeed Insights, остальные уточняют картину.

PageSpeed Insights: полевые и лабораторные данные

PageSpeed Insights показывает два вида данных. Полевые берутся из Chrome User Experience Report (CrUX): как страница загружалась у реальных пользователей Chrome за предыдущие 28 дней, значение считается по 75-му процентилю. Лабораторные — это один смоделированный запуск Lighthouse с диагностикой. Мобильную и десктопную версии смотрите отдельно.

Поле и лаборатория часто расходятся. Лаборатория — одна загрузка на эмулированном устройстве, поле — история реальных людей на разных телефонах и сетях. Хороший лабораторный балл ещё не означает хороший реальный опыт.

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

Балл Performance считает Lighthouse:

• 90 и выше — хорошо;
• 50–89 — нужно улучшить;
• ниже 50 — плохо.

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

Один запуск — ещё не результат.

Lighthouse, Search Console, Метрика и curl

Lighthouse встроен в Chrome DevTools и даёт ту же лабораторию локально. INP он не измеряет, вместо него смотрят Total Blocking Time (TBT).

Google Search Console показывает отчёт Core Web Vitals по группам страниц. Это полевой взгляд Google.

Яндекс Метрика. Для анализа работы сайта справка Вебмастера советует специальные отчёты Метрики.

curl — мой быстрый способ без браузера. С собственной машины видно время до первого байта и протокол ответа, например HTTP/2. Это замер из одной точки, PageSpeed Insights он не заменяет.

Core Web Vitals: какие метрики смотреть и какие у них пороги

В Core Web Vitals сейчас три метрики. Они отвечают на три вопроса: загрузилось ли главное, реагирует ли страница на действия, стоит ли макет на месте.

LCP (Largest Contentful Paint) — время отрисовки самого крупного изображения, текстового блока или видео в видимой области, считая от начала перехода на страницу. Хорошо — 2,5 с или меньше.

INP (Interaction to Next Paint) — отзывчивость на клики, касания и нажатия клавиш за всё время на странице; обычно в расчёт идёт худшее взаимодействие. Хорошо — не более 200 мс. Если посетитель ничего не нажимал, данных по INP может не быть.

CLS (Cumulative Layout Shift) — визуальная стабильность, то есть наибольший всплеск неожиданных сдвигов макета. Хорошо — 0,1 или меньше.

Значения берут по 75-му процентилю, отдельно для мобильных и десктопа. Оценку Core Web Vitals страница проходит, если все три метрики в зелёной зоне. Если данных по INP мало, достаточно хороших LCP и CLS.

Перед тем как лечить LCP, посмотрите в отчёте Lighthouse, какой элемент им считается. Это не всегда картинка. На моей главной LCP — текстовый блок в первом экране, поэтому перевод картинок в WebP на LCP почти не повлиял. Если LCP у вас тоже текст, ищите причину в ответе сервера и ресурсах, блокирующих отрисовку.

TTFB: когда тормозит сервер, а не страница

TTFB (Time to First Byte) — время от запроса ресурса до начала получения первого байта ответа. В него входят редиректы, поиск DNS, соединение и TLS, а также ожидание ответа сервера.

Ориентир web.dev: большинству сайтов стоит стремиться к TTFB 0,8 с или меньше. Это грубая планка, не жёсткий порог. В PageSpeed Insights TTFB помечен как экспериментальный, границы зон — 800 и 1800 мс. В Core Web Vitals он не входит, но помогает понять, почему плохой LCP.

Пример с моего сайта. 27.10.2026 curl показал TTFB главной 0,23–0,25 с, а Lighthouse в тот же день — вес главной 10,1 МБ на мобильном.

Быстрый ответ сервера не делает страницу лёгкой.

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

Нехватку памяти я записываю в риски. На моём сервере 1,7 ГБ RAM, для Битрикса это мало. Но причину медленной работы показывает замер, цифра в тарифе её не доказывает.

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

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

От самого тяжёлого ресурса переходите к его слою. Медленно отвечает сервер — смотрите TTFB, HTTP/2 и gzip. Страница каждый раз собирается заново — нужен кеш, на Битриксе прежде всего композит. Тяжелее всего сами ресурсы — это фронтенд: картинки, CSS и JS, шрифты, сторонние скрипты. Схема задаёт порядок проверки, а не очередь исправлений: при хорошем TTFB и тяжёлых картинках начинают с картинок.

У меня сработала именно ветка «Фронтенд». TTFB был хорошим, а почти весь вес главной давали четыре PNG.

Что советует справка Яндекса

Справка Яндекс Вебмастера предлагает такой список мер:

• уменьшить количество HTTP-запросов: CSS-спрайты, объединение JS и CSS;
• устранить ресурсы, блокирующие отрисовку: перенести вниз страницы, загружать асинхронно или отложенно;
• минифицировать CSS, JS и HTML;
• использовать CDN для изображений, JS и CSS;
• настроить кеширование и Gzip-сжатие;
• сжимать изображения;
• откладывать загрузку изображений вне видимой области;
• оптимизировать серверный код и системные ресурсы;
• использовать только быстрые CSS-анимации;
• сократить количество редиректов.

Выполнять всё подряд не нужно. Выбирайте пункты по тому, что показал отчёт, а серверные (кеш, gzip, серверный код) отдавайте программисту или хостингу.

Изображения

Картинка должна соответствовать своему реальному размеру на экране. Скриншот шириной 3000 px в маленькой карточке — это лишние мегабайты. Я перевожу такие картинки в WebP. Чтобы макет не прыгал, у изображений задают width и height: web.dev называет это лучшим способом избежать сдвигов от картинок. Атрибут loading="lazy" ставят только картинкам вне первого экрана. Если изображение и есть LCP, lazy с него убирают, адрес держат прямо в HTML, а web.dev советует ещё добавить fetchpriority="high".

Скрипты и шрифты

Виджеты, чаты, счётчики и шрифты проверяйте по вкладу каждого в отчёте Lighthouse, не удаляя вслепую. Неиспользуемый JavaScript ищут вкладкой Coverage в Chrome DevTools. Теги в менеджере тегов web.dev советует периодически чистить: лишний JS ухудшает отзывчивость.

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

Ускорение сайта на Битриксе

«Битрикс медленно работает» — прежде чем винить CMS, сделайте замер и найдите самый тяжёлый ресурс. У меня виноватыми оказались картинки.

Что такое композитный сайт

Композитный сайт в Битриксе — дополнительный уровень кеширования. Статическая часть страницы отдаётся из кеша, а динамическая (корзина, персональные данные, часто меняющиеся блоки) подгружается отдельным AJAX-запросом. Ускорение идёт за счёт времени ответа сервера, и с другими механизмами кеширования композит не конфликтует. Первый посетитель получает страницу, собранную как обычно, выигрыш достаётся следующим.

Граница у композита чёткая. По документации 1С-Битрикс он влияет только на время ответа сервера и не влияет на DNS, TCP-соединение и загрузку JS, CSS и изображений. Мои 16 МБ PNG композит бы не спас.

Автокомпозит или Композит

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

Как включить и проверить композит

Включается он в разделе «Настройки > Настройки продукта > Композитный сайт»: выбираете режим и включаете на вкладке. Перед включением очистите кеш компонентов. Для работы технологии нужен настроенный NGINX. В BitrixVM это пункт меню, в другом окружении — ручная настройка, то есть задача программиста.

Проверить работу можно самому. Откройте сайт в режиме инкогнито и зайдите на одну страницу несколько раз. Видна кнопка «Быстро с 1С-Битрикс» — композитный кеш работает. В ответе сервера появляется заголовок X-Bitrix-Composite со значением Cache (200), значит, страница отдана из композитного кеша. В разделе «Композитный сайт > Страницы» есть список закешированных страниц со счётчиком перезаписей. Большое число перезаписей указывает на проблему.

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

Кеширование компонентов

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

Обновление PHP и ядра — отдельная задача, её я разбирал в статье «Обновление Битрикса без поломки».

Кейс: как я ускорял собственный сайт на Битриксе

Исходная точка — мой аудит 21–22.09.2026. TTFB главной 0,19 с, gzip включён (HTML 154 КБ уходил по сети как 34 КБ), протокол HTTP/1.1, автокомпозит работает, HTML отдаётся с Cache-Control: no-store.

13 октября я включил HTTP/2 и проверил ответ через curl --http2. Тогда же при редизайне заменил Bootstrap на главной облегчённым CSS: было 307 КБ, стало 168 КБ.

Откуда взялись 10 МБ

27.10.2026 Lighthouse показал, что главная весит 10,1 МБ на мобильном и 16,8 МБ на десктопе. Причина — четыре скриншота портфолио в PNG шириной 3000–3400 px. На странице они выводятся маленькими карточками.

Четыре скриншота весили больше 16 МБ, после пережатия — около 0,2 МБ. Ширину и высоту в атрибутах я обновил, loading="lazy" оставил: карточки стоят не в первом экране.

Результат и как его читать

Замер: Lighthouse 12.2.1 локально, главная, эмуляция мобильного и десктопа, 27.10.2026.

Стабильно изменились две вещи. Вес главной уменьшился примерно в 17 раз на мобильном и в 24 раза на десктопе. Total Blocking Time упал с 7840 мс до 50–200 мс во всех трёх запусках.

А вот балл и LCP плавают. Performance в трёх запусках подряд — 86, 81 и 65, LCP — 2,9, 3,9 и 5,4 с. Это разброс лабораторного замера с одной машины. Причину ухудшения LCP я не устанавливал и следствием работ его не считаю. Элемент LCP главной — текстовый блок, так что WebP на него почти не влияет. По баллу одного запуска вывод мог бы быть любым.

PageSpeed Insights API в тот день вернул ошибку 429, поэтому замер локальный. Полевых данных CrUX в нём нет.

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

Ошибки и мифы о скорости сайта

Гнаться за 100 баллами одного запуска. Балл плавает, в моём кейсе — от 65 до 86. Смотрите на вес, метрики и полевые данные.

Путать лабораторию и поле. Один запуск Lighthouse не говорит, как сайт открывается у реальных людей.

Ждать, что ускорение поднимет позиции. Google прямо пишет, что гарантий нет.

Начинать со списка из 30 пунктов вместо самого тяжёлого ресурса.

Считать быстрый TTFB доказательством быстрой страницы. У меня было 0,23–0,25 с при весе главной 10,1 МБ.

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

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

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

Пройдите его сами или передайте программисту.

1. Замерить главную и ключевые шаблоны страниц в PageSpeed Insights, мобильный и десктоп; посмотреть полевые данные, если они есть.
2. Сделать несколько запусков Lighthouse и сравнивать не балл, а вес, LCP, TBT и CLS.
3. Проверить TTFB и HTTP/2 через curl.
4. Найти самый тяжёлый ресурс и убрать его первым.
5. Проверить gzip и кеширование; на Битриксе — работу композита и заголовок X-Bitrix-Composite.
6. Изображения: размер под вывод, WebP, width и height, lazy только вне первого экрана.
7. CSS и JS, шрифты, сторонние скрипты — по вкладу в отчёте.
8. Повторить замер и записать результат с датой.

Вопросы и ответы

Влияет ли скорость загрузки сайта на SEO?

Для Яндекса это важный показатель качества сайта. Google учитывает Core Web Vitals, но высоких позиций они не гарантируют.

Почему балл PageSpeed Insights меняется при каждой проверке?

Лабораторный замер зависит от сети, оборудования и нагрузки. Делайте несколько запусков и сравнивайте метрики.

Почему в PageSpeed Insights нет данных реальных пользователей?

Страница новая или у неё мало посещений, и CrUX не набрал данных. Тогда PSI берёт данные по всему сайту, а если мало и их, полевых данных не будет.

Какое значение LCP считается хорошим?

2,5 с или меньше по 75-му процентилю загрузок.

Нужен ли композитный сайт на Битриксе?

Композит помогает со временем ответа сервера, но не с тяжёлыми картинками и скриптами. Для простого сайта подходит Автокомпозит, для сложного с кастомными компонентами — Композит с ручной настройкой.

Сколько стоит ускорение сайта?

Зависит от того, где проблема (в сервере, картинках, скриптах или вёрстке) и сколько шаблонов она затрагивает. Я начинаю с замера, после него понятен объём. С этим помогу в рамках доработки сайтов на Битриксе, а если скорость — часть задачи по поиску, в рамках SEO-продвижения.

Можно ли ускорить сайт самому, без программиста?

Частично. Замерить, пережать картинки, проверить композит и поставить задачу владелец может сам. Сервер, nginx, код и композит на кастомных компонентах — работа программиста.