Ускорение и оптимизация работы сайтов - разбор конкретного примера на основе сайта на 1C-Bitrix

Подробный технический разбор, как выполнялась оптимизация работы сайта barsles.ru: от Bitrix Composite и LCP до отложенной Метрики, lazy loading и проверки регрессий.

Ускорение сайта и оптимизация работы сайта на практике: разбор реального проекта barsles.ru на 1C-Битрикс. Это технический кейс о том, как выполняются услуги по ускорению сайта: от диагностики Lighthouse до правок LCP, кеширования, JavaScript и медиа.

Ускорение сайта: коротко о результате

Оптимизация проводилась поэтапно, с контрольными замерами Lighthouse mobile и проверкой живого сайта после каждого изменения.

Главная страница выросла с 55 до 95 баллов Lighthouse Performance. LCP сократился с 8.3 до 2.5 секунды. То есть основной контент первого экрана стал появляться примерно в 3.3 раза быстрее.

Каталог проектов вырос с 72 до 95-97 баллов. LCP сократился с 5.4 до 2.4-2.8 секунды.

Карточка проекта выросла с 73 до 89-91 балла. LCP сократился с 5.4 до 3.2 секунды, при этом удалось сохранить работу Slick-галереи и Lightbox.

Оптимизация работы сайта: исходная ситуация

На сайте уже был рабочий дизайн, большое количество контента и типичная для коммерческого сайта связка: 1C-Битрикс, композитный кеш, общий JavaScript шаблона, Slick-слайдеры, Lightbox-галереи, видеообзоры, Яндекс.Метрика, UIS calltracking, карты, отзывы и формы заявок.

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

Первый Lighthouse mobile показал: главная 55 баллов и LCP 8.3 s, каталог 72 балла и LCP 5.4 s, карточка проекта 73 балла и LCP 5.4 s.

Ускорение сайта на 1C-Битрикс: Bitrix Composite

Первым делом был проверен HTML-кеш. Это важно: если сервер каждый раз собирает страницу с нуля, оптимизация картинок и JavaScript не даст стабильного эффекта.

Проблема оказалась в настройке композита. Bitrix не записывал HTML-кеш для домена barsles.ru, потому что домен не был указан в конфигурации композитного кеша.

/bitrix/html_pages/.config.php

После включения AUTO_COMPOSITE и добавления домена ключевые страницы начали отдавать заголовок:

X-Bitrix-Composite: Cache (200)

HTML после прогрева отдавался примерно за 0.32-0.42 секунды. Это дало нормальную базу для дальнейшей оптимизации клиентской части.

Оптимизация LCP главной страницы

На главной LCP давал первый экран с большим фоновым изображением. Браузер видел его как CSS background, а не как обычную картинку, поэтому загрузка стартовала не так рано, как могла бы.

Был добавлен preload главного изображения только для главной страницы, preload разделен по media-условиям, а для мобильных создан отдельный banner-mobile.webp. Исходный desktop-баннер весил около 385 KiB, мобильный WebP весил около 79 KiB.

<link rel="preload" as="image" href="/bitrix/templates/barsles-template/img/banner-mobile.webp" type="image/webp" media="(max-width: 767px)" fetchpriority="high">
<link rel="preload" as="image" href="/bitrix/templates/barsles-template/img/banner.jpg" media="(min-width: 768px)" fetchpriority="high">

После этого главная улучшилась: LCP на промежуточном этапе сократился с 8.3 до 3.8 секунды, а после следующих JS-оптимизаций доходил до 2.5-2.6 секунды.

Оптимизация загрузки видео, фонов и нижних блоков

На сайте было много медиа ниже первого экрана. Часть видео и фоновых картинок подключалась слишком рано.

Видеообзоры были переведены с src на data-src, для видео установлен preload="none", в main.js добавлена загрузка через IntersectionObserver. Фоновые изображения карточек и секций переведены на .js-lazy-bg[data-bg].

<video data-src="/upload/iblock/example.mp4#t=0.001" preload="none" controls playsinline></video>

Ускорение каталога проектов

В каталоге LCP давала первая карточка проекта. После lazy background браузер не мог начать загружать LCP-картинку достаточно рано, потому что она появлялась только после работы JavaScript.

Первая карточка получила обычный <img> с fetchpriority="high" и decoding="async". Остальные карточки остались ленивыми через data-bg.

<div class="image catalog-lcp-image" style="background-image: url(/upload/iblock/example.jpg)">
  <img src="/upload/iblock/example.jpg" alt="Дом из клееного бруса" fetchpriority="high" decoding="async">
</div>

Результат по каталогу: LCP 5.5 s -> 2.9 s на этом этапе, а финально каталог доходил до 95-97 баллов Lighthouse.

Оптимизация карточки проекта: Slick, LCP и CLS

Карточка проекта была сложнее. Там LCP давал первый слайд Slick-галереи, сделанный через background-image. Дополнительно после инициализации Slick появлялся CLS около 0.259.

Первый слайд получил реальный <img fetchpriority="high" decoding="async">, видимая картинка была переключена с оригинала на Bitrix resize preview, а ссылка Lightbox осталась на оригинальное изображение.

Результат: проблемный повтор до исправления показывал Lighthouse 55, LCP 10.0 s и CLS 0.259. После исправления и resize preview: Lighthouse 86, LCP 3.4 s, CLS 0.004.

Услуги по ускорению сайта: работа со сторонними скриптами

UIS calltracking и Яндекс.Метрика были заметными источниками раннего JavaScript. UIS был заменен с прямого подключения на loader по первому взаимодействию или через несколько секунд после window.load.

Метрика была оставлена с теми же настройками, включая Webvisor, но внешний tag.js стал грузиться позже. При этом ранняя очередь ym() сохранена, чтобы события инициализации не терялись.

Эффект после отложенной Метрики: TBT главной снизился с 404 до 59 ms, TBT каталога с 221 до 40 ms.

Оптимизация JavaScript: перенос шаблонных JS в footer

Глобальный перенос всего JS вниз дал хороший результат на главной и каталоге, но ухудшил карточку проекта: Slick-галерея на детальных страницах зависит от ранней инициализации.

Поэтому схема стала условной: главная и страницы списка получают шаблонные JS в footer, а детальные страницы с галереей оставляют JS в head через Bitrix-бандл.

Результат: главная выросла с 85 до 95 баллов после этого этапа, каталог с 93 до 95, карточка проекта осталась стабильной.

Lightbox по требованию

Lightbox раньше грузился глобально: CSS попадал в общий template CSS, JS грузился вместе с шаблонным бандлом, стартовали служебные ассеты. Теперь Lightbox подключается только при первом клике по галерее.

Проверка показала: до клика lightbox.js отсутствует в network, после клика Lightbox открывается корректно.

Slick и Bitrix analytics

Из slick-theme.css убраны служебные ресурсы ajax-loader.gif и webfont Slick. Стрелки сайта уже были переопределены собственным SVG, поэтому webfont был не нужен.

Также отключен публичный Bitrix analytics counter, который генерировал запрос к https://bitrix.info/ba.js. Использован штатный API:

if (class_exists('\\Bitrix\\Main\\Analytics\\Counter')) {
    \\Bitrix\\Main\\Analytics\\Counter::disable();
}

Что проверяли, но не оставили

Не все логичные оптимизации дали улучшение. font-display: swap для Circe не улучшил LCP стабильно и ухудшил Speed Index. WOFF2 без subset уменьшил размер шрифтов, но также ухудшил Speed Index. Замена hero background на <picture><img> визуально работала, но стабильного выигрыша по LCP не дала. Все эти эксперименты были откатаны.

Проверка результата

Использовались Lighthouse 13.4.1, Chromium из Playwright, mobile preset, curl для проверки заголовков, Playwright для визуальных и DOM-проверок, php -l для PHP-шаблонов и node --check для JavaScript.

Проверялись не только баллы Lighthouse, но и рабочее состояние: Slick-слайдеры, Lightbox, ленивые видео, карты Яндекса, формы, cookie-плашка и композитный кеш.

Вывод

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

Для barsles.ru это дало практический результат: главная 55 -> 95 Lighthouse, каталог 72 -> 95-97, карточка проекта 73 -> 89-91, LCP главной 8.3 s -> 2.5 s.

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