Одним из самых важных показателей сайта является его скорость загрузки. И тут речь не только о скорости генерации html кода на сервере, но и скорость построения(рендеринг) страницы на устройстве посетителя сайта (компьютер, планшет, телефон и т.д.). Это увеличивает позиции в результатах поисковых систем, да и любому пользователю более комфортно находится на сайте, который более отзывчивый на его действия. А это всё увеличивает посещаемость, продажи и т.п.
Мне на техподдержку часто приходят неоптимизированные сайты. И первые работы по техподдержке сайта, я предлагаю делать именно по оптимизации. Во-первых, это в любом случае надо, т.к. напрямую влияет на прибыль заказчика. Во-вторых, быстро открывающие страницы удешевляют доработки по сайту, т.к. некоторые доработки подразумевают частое открытие страниц на сайте, а если они открываются по 5-10 секунд вместо 0.05-0.3с, то это и увеличивает время решения поставленной задачи.
Процесс оптимизации сайта может длится бесконечно. В начале происходит анализ на самые критичные проблемы и параллельно исправлять мелкие баги. Далее озвучивается грубая оценка с диапазоном и заказчик уже решает по бюджету насколько сильно оптимизируем сайт.
Обычно начинается с оптимизация бэкенда. Чаще всего проблемы связаны с:
- Большим количеством запросов к базе данных - важно избавляться от запросов в цикле и вместо ста обращений к базе данных с получением по одной записи (товар, новость и т.п.) нужно делать один запрос на получение ста записей. Еще бывают случаи, когда получают одни и те же данные несколько раз, как вариант решения такой проблемы это кеширование.
- Неоптимальным php-кодом - чаще всего это неоптимальные алгоритмы обработки данных из базы, поиск данных в виде циклов, выполнение лишних действий, которые не нужны для генерации страницы - последнее распространенное для битрикса, потому что это универсальный CMS, чтобы угодить максимальной аудитории нуждающейся в сайте, а значит код выполняет много различных сценариев, но для конкретного сайта выполнение всех сценариев не требуется.
- Отсутствием кеширования - чаще всего кеширование не используют, из-за того, что часть кода должна всегда выполняться, то есть не быть "под кешем", например, проставлять SEO теги (title, keywords, description, canonical, noindex и т.д.). Но это только из-за незнания документации 1С-Битрикс, поэтому данная проблема легко решается и можно разделять код, который должен быть под кешем, а который нет. Но важно также и настроить кеширование грамотно, чтобы под кешем были всегда актуальные данные, поэтому надо писать обработчики событий, которые отслеживают изменение записей в базе данных и сбрасывают кеш. Но и этого не достаточно, важно еще понимать как работает кеширование компонентов битрикса, например, есть случаи когда в кеш добавляется html шаблона компонента и получается, что получить данные записей из кеша и выполнить код генерации шаблона быстрее, чем получать их кеша готовый html шаблона компонента и много других случаев.
В оптимизации фронтенда больше случаев:
- Используются несжатые js/css файлы - почему это плохо? Потому что приходится больше скачать данных, чтобы отрисовать страницу. Битрикс умеет их сжимать и объединять и вроде бы это оптимально, но не совсем, т.к. не учтено такое понятие, как браузерное кеширование и сетевой протокол http2. Об этом в следующем пункте.
- Не объединяются js и css файлы в один (один js и один css) - если весь css код упаковать в один файл и его скачать, то это будет быстрее, чем скачать сто css файлов в которых часть css кода, то есть количество кода одинаковое, разница только в количестве файлов. Это связано с количеством запросов браузера на скачивание файлов и еще браузеры параллельно могут скачать ограниченное количество файлов, поэтому пока часть файлов качается, другая часть ждёт своей очереди. И битрикс может объединять файлы, но в этом есть минусы - это большой объем и для каждой страницы уникальные объединенные js и css файлы, а значит малоэффективно браузерное кеширование. Суть в том, что браузер скачивает js и css только первый раз, второй раз он берет его из своего кеша и не качает с сайта, а это намного быстрее. Но из-за разных файлов на разных страницах получается, что браузер каждый раз будет добавлять скачивать,а не брать из кеша. Еще момент, что часть кода объединенного файла использовалось на другой странице и могло бы на следующей странице браться из кеша, а часть только скачиваться, но с объединенным файлом так не получится. На это есть решение использования протокола http2 и создания нескольких сжатых файлов - один общий и один для конкретного типа страниц. Плюс http2 в том, что он может скачивать много файлов в одном потоке, то есть по аналогии как будто это один файл. А сжатые файлы можно компилировать с помощью gulp или webpack, тогда мы получаем самый оптимальный вариант - общие данные берутся из кеша, новые погружаются только новые, нет задержек по загрузке большего количества файлов, нет множества уникальных больших объединенных файлов кешей. А если для между разными страницами есть еще общий css или js помимо основного общего, то это тоже можно вычислить автоматически и дополнительно разбить на дополнительный файл тем самым еще лучше оптимизировать браузерное кеширование и каждая следующая новая страница сайта с большей вероятностью будет открываться быстрее.
- Не используется отложенная загрузка изображений - важный пункт, т.к. по умолчанию скачиваются все изображения, а это задерживает показ страницы. Чтобы правильно оптимизировать, нужно отложено подгружать изображения, но не все, а только те, которые ниже первого экрана, то есть ниже высоты экрана устройства, с которого просматривается сайт.
- Сжатие изображений и использование нужного формата - необходимо для уменьшения размера(веса) изображения, чтобы файлы быстрее скачивались. Тут тоже несколько моментов. Всегда нужно удалять метаданные из изображений, т.к. эта информация не нужна для показа, а вот уменьшение веса в основном зависит от потери качества изображения, и тут зависит от бизнес процессов на сайте. К примеру бывает требование, чтобы изображения продаваемых товаров были в наилучшем качестве, тогда можно использовать 5% потери качества - это не заметно человеческому глазу и сделать прогрессивный jpeg, чтобы изображения появлялись на страницах сайта моментально, но в плохом качестве и постепенно качество улучшалось по мере загрузки. Но если этого требования нет, то лучше использовать формат изображений webp, а еще лучше avif, т.к. при качестве в 65-70% вес изображения становится во много раз меньше по сравнению с 95% качества jpg и даже 75% качества jpg, и еще плюс этих форматов, что у них лучше алгоритмы сжатия и цвета-градиенты остаются плавные, а не ступеньками как у jpg. Но также важно понимать, что не все браузеры поддерживают webp и тем более avif, поэтому перед отдачей с бэкенда изображений, нужно понимать какой в каком формате отдавать в зависимости от поддержки браузером клиента.
- Использование векторной графики - необходимо использовать вместо иконок и одноцветных изображений. Плюсы векторной графики:
- Меньше вес изображений.
- Увеличение габаритов размеров без потери качества, особенно важно для экранов с повышенной плотностью пикселей (почти все современные смартфоны, retina и т.п.)
- Перекрашивание в другие цвета, например, при наведении курсора. В случае с растровым изображением пришлось бы делать два изображения.
- Для разных разрешений экрана показывать разные изображения по размеру. Чаще всего это используется в слайдере баннеров, когда отображается одно изображение на весь экран. И в этом случае для размеров экрана шириной 320px неправильно показывать изображение шириной 1920px, т.к. это изображение будет весить как минимум в 8-10 раз больше, а это критично если у мобильного устройства низкая скорость интернета. Ну и дополнительно это решит проблему масштабирования сохраняя пропорции, то есть для экрана шириной 320px можно показать изображение другой пропорции - с большей высотой. Важно учитывать, что реализация должна быть, чтобы оба изображения не скачивались одновременно при загрузке страницы, а только то, которое подходит под разрешение экрана.