1852 слова | 5 минут

Оптимизация

Как отлаживать скорость в Битрикс по шагам

1. Включаем монитор производительности на час. Смотрим на самые долго открывающиеся страницы (в магазине это обычно каталог).

В нашем случае еще страница бренда и карточка товаров

• /brands/detail.php — 24 секунды
• /catalog/index.php — 5.8 секунд

На фото эти же страницы после отладки

2. Открываем каталог
3. Включаем отладку, смотрим запросы

Почему вообще может тормозить каталог в Битриксе?

Три базовые проблемы:

Первая — огромные SQL запросы с 5-6 JOIN-ами.

Происходит это из-за того, что база сайта подстраивается под разные виды контента:

1. таблица для товаров
2. для цен
3. для складов
4. для свойств
5. И еще одна для значений свойств
6. для языков
7. для прав доступа

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

Например, этот огромный запрос будет выполняться почти мгновенно, если итоговая выборка небольшая (несколько тысяч товаров). И он же будет очень долгим, если в выборке полмиллиона товаров. Решение?

Перестроить архитектуру сайта так, чтобы нигде не выводилось больше тысячи товаров единым списком (нужны включенные фильтры или разделы). Это сократит запрос до приемлемых 0.05 — 0.1 секунд.

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

Вторая — sql запросы, вложенные в php-цикл. Это проблема уже на стороне разработчика, который вместо того, чтобы нормально настроить компонент на извлечение нужных данных, «дергает» их внутри каждого товара отдельным запросом.

Ну и третья — кеш. Неправильно настроенный кеш сайта заставляет насиловать базу запросами каждый раз вместо того, чтобы использовать повторно один раз извлеченные данные. В ётом случае ошибка с том, что не установлен параметр «кешировать при установленном фильтре». Поскольку та или иная фильтрация есть почти на каждой странице каталога, то и кеш в каталоге можно считать, что не использовался. Меняем параметр.

Также проблема Стандартных компонентов - Реализовано много функционала который не всегда нужен! Нужно:

• отключать в настройках неиспользуемый функционал (а не просто не выводить его в шаблоне!)
• если нужно 2 свойства, то только их и надо запросить в настройках компонента (а не все… каждое свойство свой запрос к базе!)
• писать свои компоненты

Теперь меряем производительность заново. Среднее время формирования страницы каталога теперь 0,2-0,3 секунды.

Вторая нагруженная страница — это страница бренда

На ней отображаются все товары и разделы бренда. Проблема в том, что она изначально создана неверно. Разделы ищутся путем перебора товаров и извлечения из них поля разделов. Это неоптимально. Заменяем на группировку средствами MYSQL.

Плюс также включаем кеширование при установленном фильтре. Измеряем производительность заново. Среднее время формирования страницы каталога теперь 0,2-0,4 секунды. Сократилось более чем в 100 раз!

Детальная карточка товара

В ней есть одна главная проблема — извлечение аналогов из SQL-таблицы. Поиск происходит по текстовым кодам (по идентификатору, пришедшему из 1С), на который также не создан индекс.

Формируем индекс и наблюдаем как скорость растет.

Там же — отключаем выборку свойств, не использующихся в блоке «просмотренные товары». И отвоевываем еще треть секунды.

Немного радости для Pagespeed

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

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

Скорость вырастает вдвое — в 33 до 62 пунктов. Это не очень много, но для синтетического теста, прямо не влияющего на юзабилити — более чем достаточно.

Промежуточные итоги

В битрикс отличный встроенный отчет по производительности. Через сутки он обновляет статистику и показывает уже, что время полного формирования страницы на стороне сервера не превышает 0,3 секунды. А полностью на стороне клиента она отрисовывается за секунду.

Композитный кеш

Теперь, отладив производительность основных компонентов сайта, можно переходить к композитному кешированию.

В двух словах, он делает HTML-копию страницы, а в нее уже «Догружает» изменяющиеся детали (вроде логина пользователя).

С включенным композитным кешированием, страница отдается сервером за 0,03 секунды. И соответственно, отрисовывается на клиентском браузере примерно за 0,5 секунды.

Анализ индексов

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

После получения списка медленных запросов на странице Анализ индексов (Настройки > Производительность > Индексы > Анализ индексов) необходимо воспользоваться кнопкой Выполнить анализ собранных SQL запросов и отобразится список всех запросов, которые были совершены за это время, отсортированных по имени таблицы:

В общем списке в первую очередь нужно обращать внимание на запросы с большей продолжительностью и на большое их количество. Но и в случае больших величин у этих параметров не на каждый запрос стоит создавать индекс (возможно нужно просто исправить код компонента). Косвенным критерием успешности создания индекса служит время выполнения запроса до и после создания индекса.

При необходимости можно посмотреть план выполнения любого запроса. Команда Детальный анализ позволяет перейти к анализу конкретного запроса и созданию его индекса.

На этой странице жирным шрифтом выделяются таблица и колонки, к которым обращается запрос.

Структура таблицы - информационная закладка. Главное в ней - размер таблицы. И если размер большой (к примеру, больше 100 мегабайт), то построение и удаление индексов лучше проводить в часы наименьшей нагрузки на сайт.

• Анализ запросов - закладка с собственно анализом запроса. При принятии решения о создании индекса учитывайте, селективен ли этот запрос и процент селективности . Информация об этом выводится в таблице.
• Создание индекса - закладка, на которой непосредственно принимается решение о создании (или нет) индекса. Те запросы, по которым не нужно создавать индекс, можно внести в список Не предлагать создавать.

Запросы, по которым принято решение, пропадают из списка запросов и появляются на странице Список индексов.

Список индексов

Страница Список индексов (Настройки > Производительность > Индексы > Список индексов) отображает результаты ваших решений по анализу тех или иных запросов. "Зелёный" статус - индекс создан, "красный" статус - индекс не будет создаваться.

Не оптимизированная графика

Наиболее частый сценарий – это использование размеров изображений, которые не соответствуют отображению в браузере. Например, у нас на странице выводится список товаров с картинками. Сам контейнер в браузере имеет размер 152 190 пикселей, а вот картинка при этом используется 400 500 пикселей.

Чтобы исправить эту ситуацию, следует подогнать картинку под размер отображаемой области. Для сайтов на Битрикс для этого используется функция ResizeImageGet. Тут следует быть аккуратным, и учитывать то как выглядит данный блок в адаптивной версии сайта, чтобы не урезать картинку слишком сильно.

Вторым моментом, влияющим на скорость загрузки, является непосредственный «вес» картинки. Чтобы его уменьшить, целесообразно использовать дополнительные модули сжатия на сервере, такие как jpegoptim и optipng.

Третий момент - это количество картинок. Если в списке товаров десятки карточек, то пользователь не видит их все сразу. Особенно в мобильной версии, пользователь может и не долистать до конца страницы. А картинки ведь грузятся, и тормозят процесс загрузки остального контента. И тут нам на помощь приходит такой метод, как lazy load. Это JQuery плагин, скачать можно тут: https://appelsiini.net/projects/lazyload/

("img.lazyload").lazyload(); //вызов метода

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

И напоследок о картинках. Лучше использовать для графики формат jpeg нежели png. Разницы в отображении не заметно, зато можно сэкономить на размере изображения.

Сжатие ресурсов сайта

Тут следует остановиться на 2х моментах:

• Сжатие средствами Битрикс,
• Сжатие на стороне сервера.

Битрикс своими силами может сжимать и склеивать файлы скриптов и стилей. Включается это в настройках главного модуля по адресу:

Настройки – Настройки продукта – Настройки модулей

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

Объединять файлы CSS и JS надо в любом случае, это серьезно ускоряет загрузку файлов, т.к. позволяет вместо 20 подключений задействовать всего 1 или 2. Стоит отметить, что будут объединены файлы, которые подключены средствами Битрикс через методы SetAdditionalCSS и AddHeadScript, или их D7 аналоги. Файлы, подключенные напрямую через теги link или script в объединении не участвуют.

С переносом JS в конец страницы нужно быть аккуратным, особенно если проект достался вам на поддержку в наследство. Может случится ситуация, когда у вас инлайном прописана функция, которая использует подключаемые файлы. Это может быть обращение к методу JQuery. После переноса файлов в конец страницы следует внимательно пройтись по всему проекту и проверить его на предмет ошибок javascript в консоли.

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

Есть много сервисов проверки на то, включено ли у вас GZIP сжатие. В тесте мы воспользовались вот этим:

https://www.websiteplanet.com/ru/webtools/gzip-compression/

Видно, что данный метод позволяет экономить порядка 75% трафика, что особенно актуально для мобильных устройств.

Избыточные стили и скрипты

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

Какого-либо механизма для автоматического обнаружение неиспользуемых скриптов мы не нашли, все проверяется вручную. Тут все зависит от контекста и вы можете использовать console.log() либо точки остановки для того, чтобы понять, попали вы в скрипт или нет.

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

Сторонние плагины и скрипты

Тут правило простое: все что вы навешиваете на ваш сайт замедляет его работу. Будь то Яндекс.Метрика, Гугл Tagmanager, Онлайн чат или скрипт сбора статистики, вроде RetailRocket. Встречаются проекты, где этого добра навешано столько, что до момента начала нормального взаимодействия с пользователем проходит 10-20 секунд. Вычислить подобные подключения нам поможет вкладка Сеть(Network) в панели разработчика.

Опрашиваем маркетологов/директоров/менеджеров на предмет необходимости того или иного функционала и аккуратно отключаем. В этом случае лучше закомментировать на время подключение, т.к. кто-то может опомниться спустя неделю или месяц.

Еще один момент заключается в том, что большинство подобных плагинов лучше подключать через отложенную функцию, например спустя 3-5 секунд после загрузки документа. Исключение составляют различные метрики, которым важно быть загруженными как можно раньше.

Слишком большое дерево тегов

Общее правило веб-разработки гласит: можешь обойтись без лишнего элемента – обходись. Приведем пример: тут можно было не оборачивать строку в дополнительный span.

Конечно, единичный случай погоды не делает. Но бывает так, что подобным мусором забито до 20% проекта, что в конечном счете сказывается на производительности.

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

Чек-лист по отладке скорости Битрикс

• Настройки в мониторе производительности соответствуют рекомендуемым
• Все компоненты настроены на кеширование
• SQL-запросы не вызываются в циклах
• Страница формируется с функцией «Очистить кеш» не более чем 200 SQL-запросами
• Компоненты работают только со свойствами, которые им нужны
• Проверка прав доступа отключена там, где не нужна
• Если на сайте много скидок, сайт рассчитывает их только там, где нужно
• Кеширование фильтров включено
• При кешировании учитывается периодичность обновления
• Настроен композитный сайт
• Оптимизирована графика
• Присутствует сжатия используемых ресурсов
• Избыточных стилей и скриптов нет
• Сторонние плагины не грузят сайт
• Не слишком большое дерево тегов
• Есть нужные SQL индексы