Кейс: как ускорить сайт на Bitrix в 3,5 раза

На момент начала работ показатели скорости были очень низкими. 
Для оценки скорости загрузки веб-страниц мы использовали Google PageSpeed Insight  — инструмент Гугл для проверки быстродействия сайта.

А также проанализировали время загрузки страниц через браузер Google Chrome. Данную проверку быстродействия сайта можно провести следующим образом: через F12 открыть вкладку «Network» (предварительно очистив фильтр) и запустить действие клавишей F5

Показатели были следующие:

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

На старте работ провели полный аудит, выявили ошибки, составили план и чек-лист оптимизации скорости сайта:

• Перенос на VDS и настройка сервера
• Проверка системы
• Работа с БД
• Минификация исходного кода страницы, css и js файлов
• Оптимизация изображений
• Оптимизация JS

Сайт изначально был на виртуальном хостинге, технология которого подразумевает совместное размещение нескольких ресурсов на общем, уже настроенном сервере, а значит нет возможности установить туда собственное программное обеспечение, которое по умолчанию не поддерживается хостинг-провайдером. Виртуальный хостинг, на котором ранее был сайт, был ограничен версией php, mysql, nginx. Физические ресурсы виртуального хостинга (мощность процессора, оперативная память) распределяются между всеми размещенными на виртуальном хостинге сайтами. Иногда бывает, что один сайт потребляет больше ресурсов, чем положено. В таком случае соседние сайты на хостинге испытывают дефицит в оперативной памяти и мощности процессора: они начинают медленнее загружаться, начинаются сбои.

Было решено перенести сайт заказчика на VDS (Виртуальный Выделенный Сервер).
Так как Bitrix довольно прожорлив и ресурсоёмок, с небольшим заделом на будущее выбрали тариф с 8гб ОЗУ и с 4-х ядерным CPU.

После переноса на VDS установили все необходимые для работы программы (nginx, mysql, php и т.д.). 
Важную роль в увеличении скорости сайта сыграла версия php, так как ранее стояла версия 5.6, которая давно уже устарела. Новая (на момент установки) версия 7.2 работает почти в два раза быстрей версии 5.6, что неплохо сказалось на работе сайта.

Еще одним из важных моментов в работе по ускорению сайта является кеширование.

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

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

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

Настроили на сервере Memcached. Он представляет собой огромную хэш-таблицу в оперативной памяти, доступную по сетевому протоколу. Обеспечивает сервис по хранению значений, ассоциированных с ключами. Доступ к хэшу мы получаем через простой сетевой протокол, клиентом может выступать программа, написанная на произвольном языке программирования — в нашем случае это PHP. За счет своей технологи Memcached можно использовать в высоконагруженных web-проектов для решения различных задач, в том числе и для кэширования данных. 

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

В процессе проверки были выявлены проблемы, связанные с работой php, в частности неправильно заданные значения переменных: post_max_size, upload_max_filesize, pcre.recursion_limit и др.

Причины и пути решения выводятся в виде подсказок  в результатах проверки. В нашем случае переменные php настраивались в конфигурационном файле init.php.

Провели диагностику БД в разделе «Диагностика» для выявления возможных проблем и оптимизации базы. 

На странице Оптимизация БД (Настройки > Инструменты > Диагностика > Оптимизация БД) есть стандартные средства для оптимизации и анализа таблицы базы данных, что позволяет повысить эффективность обработки запросов сервером БД. После диагностики в случае, если таблицу пришлось восстанавливать и проверять, выводится сообщение об успехе.

В нашем случае проблем при диагностике выявлено не было.

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

Что было сделано для сокращения этих данных в нашем случае:

1. Изучили компонент каталога на предмет лишнего кода. Код страниц был огромен, например: листинг занимал 16977 строк в коде. Удалили лишний код/скрипты с шаблонов компонента каталога, сократили шаблоны для умного фильтра, пагинации (удалили лишние комментарии, ненужные скрипты, убрали лишние отступы, пробелы, переносы, избыточные директивы и т.д.). В итоге листинг стал занимать 2449 строк. 
В файл init.php добавили функцию по сжатию всего контента и сократили весь исходный код в 1 строку.

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

— Добавили кеширование меню. Вызов меню из кеша во много раз быстрее. Глобально это не сильно сказывается на скорости сайта, но в будущем, если меню будет расширяться, разница без кеширования и с кешированием будет ощутимая.

3. Почистили неиспользуемые стили, сжали все css файлы.

4. Добавили gzip сжатия текста для ускорения выдачи страницы.
Gzip сжатие можно отнести к одному из основных способов сокращения ответа от сервера. Оно позволят получить хороший прирост в скорости по Google PageSpeed Insight. Степень сжатия задается в диапазоне от 1 до 9. На сайте unfire-shop.ru задано значение 9, т.е максимальное сжатие (значение подбиралось опытным путем).

5. Была переделана логика вызова попапов с покупкой товара и быстрым заказом (главная, страницы с листингами и страницы детального просмотра товара). Изначально они загружались на сайте сразу, тем самым загромождая код страницы. Поэтому все вызовы были реализованы ajax-запросами, что позволило избавиться от загрузки лишнего кода на страницах и увеличить скорость загрузки сайта.

6. Блок «вы смотрели» также сделали с подгрузкой ajax, теперь выводится только последний просмотренный товар, а при нажатии на "показать все" аяксом подгружаются все остальные (выводятся 10 последних товаров).

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

Какие меры были приняты по их оптимизации:

1. Оптимизировали картинки: уменьшили вес картинок, сохранив при этом их качество. 
Для оптимизации изображений на сервере были установлены утилиты: pngquant и jpegoptim по сжатию jpeg/png и утилита cwebp по переводу изображений в формат webp. Далее написали скрипт на php по обходу всех изображений на сайте, их сжатию и переводу в формат webp. 

В случае если картинки на сайте часто обновляются, можно данный скрипт поставить на крон, чтобы, к примеру, раз в неделю запускался и переводил новые картинки на сайте в webp с предварительным сжатием.

В конфигурации сервера (nginx) дописали условия по выдаче webp только в случае, если браузер позволяет открывать такой формат. Если браузер не поддерживает данный формат картинок, то выдает исходный формат.

2. Сделали lazy load (отложенную загрузку изображений): картинки на сайте подгружаются с сервера по скроллу.

Наличие чатов на сайтах могут очень сильно повлиять на скорость загрузки. На сайте unfire-shop.ru используется чат jivosite, который загружался сразу и заметно снижал скорость загрузки страницы. Для решения данной проблемы было принято решение отложить загрузку скрипта по вызову jivosite на 4 сек (т. к. целиком вся страница загружается ~3 сек и +1 сек запас). С точки зрения пользователя, который зашел на сайт и увидел чат чуть позже чем обычно — это не страшно, но при этом по скорости получили выигрыш в ~20%, что не может не радовать.

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

Показатели по Google PageSpeed Insights вышли в «зеленую зону» для ПК и оранжевую для мобильных устройств:

Время загрузки посадочных страниц:

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