SLAMSOFT 
Тендеры и лиды
Информация
Меня зовут Игорь Повшок, я сооснователь и коммерческий директор в SLAM.
SLAM — компания с фокусом на разработку и развитие eСommerce-проектов.
Мы разрабатываем, поддерживаем и продвигаем сайты, внедряем CRM Битрикс24, создаем мобильные приложения.
В основу стандартов положены рекомендации от Google, а именно от сервиса PageSpeed Insights. Не все требования PageSpeed Insights оказывают прямое влияние на скорость загрузки, однако по нашему мнению, следование этим рекомендациям формирует правильный подход к разработке. За 2 года мы детально изучили документацию по каждому пункту и выработали решение персонально каждого пункта для Битрикс. Все решения были успешно протестированы и обкатаны на всех наших последних проектах. Большинство решений автоматизированы или собраны в модули/компоненты.
В этой публикации мы привели краткую версию статьи, потому что у платформы Wokspace есть определённые ограничения по размещению html-тегоа. Полный разбор, примеры и технические детали доступны по ссылке в нашем блоге.
Делать быстрые сайты не просто и только полное выполнение всех требований обеспечивает результаты не менее 90/90. Основное требование к команде: сайт должен быть в «Зеленой зоне» для мобильных устройств (выше 90) и грузиться не более 3-х секунд. Данный результат возможно получить только слаженно работая над оптимизацией скорости в составе программиста (backend), верстальщика (frontend) и серверного администратора. Поэтому стандарты разбиты на три ключевые части с тезисным описанием наших подходов.
Для всех наших клиентов абсолютно всегда мы (как и вендор) рекомендуем виртуальную машину Битрикс. Это компромиссная сборка между удобством и быстродействием. Работа на виртуальной машине в дальнейшем сэкономит огромное количество времени и любой разработчик в любой момент сможет свободно ориентироваться в базовых серверных настройках.
Также для BitrixVM есть готовый скрипт для автоматической настройки всех пунктов, описанных ниже. Если на сервере не BitrixVM, то все это придется делать вручную.
Кеш статики должен быть настроен на 1 год.
Опытным путем было установлено, что тип сжатия br на 30% сжимает лучше, чем gzip. В настройках степени сжатия для br мы указываем значение 6 (всего можно указать значения от 1 до 11). В виртуальной машине Битрикс доступен и gzip, и br.
Для сжатия и конвертации картинок PageSpeed Insights рекомендуем использовать библиотеки mozjpeg, pngquant, cwebp, как самые эффективные. Данные библиотеки будет использовать модуль slam.image для обработки изображений «на лету» (при интеграции на стороне Битрикс). На сервере должны быть установлены последние версии данных библиотек.
Модуль slam.image наряду со сжатием любого изображения всегда создает копию формата .webp. Картинки формата .webp, как правило, сильно «легче» оригинальных форматов, однако не поддерживаются многими браузерами (например, Safari).
Для корректного отображения картинок .webp во всех браузерах необходимо внести правки в конфигурацию NGNIX, после которых браузерам, поддерживающим технологию WebP будут отдаваться картинки .webp, а остальным — оптимизированные копии оригинальных форматов (.jpeg и .png). Примеры и инструкции вы найдёте по ссылке в полной версии статьи.
На всех проектах используем HTTP2. Штатно поддерживается в BitrixVM. Насколько быстрее работает не тестили, но в статьях пишут, что разница есть.
PageSpeed Insights пока явно не требует HTTP2 и баллы за это не дает.
Классической и частой ошибкой является создание общих минимизированных файлов стилей и скриптов для всего сайта (для всей верстки). На практике сайты с такой версткой практически всегда разогнать невозможно. А на огромных сайтах с большим количеством страниц и функционала эти сборные файлы со временем разрастаются до нескольких Mb. Это грубая архитектурная ошибка!
Для обеспечения высокой скорости на конкретной странице должны быть подключены только те стили, библиотеки и скрипты, которые используются на текущей странице. Эту проблему решает компонентный подход. То есть создается отдельный файл CSS и отдельный файл JS для каждого блока. Для удобства дальнейшей интеграции в HTML обязательно нужно оставить комментарии для разработчика, какие стили подключать и где. Например, наш сборщик делает это вот так:
Для реализации компонентного подхода мы используем сборщик GULP.
Gulp создает отдельные файлы стилей и JS для каждого компонента. Битрикс поддерживает такой подход и впоследствии автоматически собирает все стили и весь JS в один-два файла с именами page_ и template_.
Ресурсы, блокирующие отображение страницы, — это JS, стили и подключение шрифтов.
Поэтому:
Если указанный способ по подключению стилей слишком сложен для вашего проекта (или вас), тогда обратитесь к программистам. У них есть модули, которые могут сделать на Backend.
Все картинки в теге и в styles="background:src«, которые находятся ниже первого экрана должны грузиться при помощи Lazy Load. Грузить абсолютно все картинки через Lazy ошибка! Первый экран должен быть без Lazy, т.к. отрисовка первого экрана дотошно замеряется в секундах и крайне критична (параметр Largest Contentful Paint).
В PageSpeed Insights на данный момент нет прямого пункта, который обязывает подгружать картинки при помощи Lazy Load,. Но это жизненно важный пункт, который максимально влияет на вес страницы.
Страница с выключенным JS должна отображаться корректно. А именно:
Пример отображения страницы с выключенным JS:
Для основных слайдеров на главной странице зачастую используются слайдеры с картинками широкого формата. Как правило, это картинки с разрешением на всю ширину экрана 1920px и шире. Если сделать этот слайдер без должного подхода, то только лишь этот блок снимет не менее 20 баллов PageSpeed .
Однозначно, широкоформатные слайдеры — это самый тяжелый контент на странице, и верстать его необходимо с особым вниманием.
Для PageSpeed Insights данный пункт критично важен, т. к. несколько широкоформатных тяжелых картинок могут весить в разы больше, чем вся остальная страница. Особенно от этого страдают показатели мобайл.
Такие элементы сайта, как форма обратной связи в модальном окне, выпадающее меню или форма авторизации, могут быть вовсе и не задействованы во время посещения вашей страницы. Так зачем же тогда грузить все эти скрытые элементы на страницу сразу?
Показательным примером является форма авторизации в модальном окне. Для валидации подключается JS-библиотека bootstrap.validator, для маски jq.inputmask, да еще JS Recaptcha. Целесообразно загрузить все эти библиотеки, только если пользователь открыл модальное окно с формой.
Аналогичного подхода требуют любые другие скрытые объемные блоки. Например:
Если дизайн страницы перегружен, то в рекомендациях PageSpeed неизбежно появляется пункт «Сократите размер структуры DOM». Большое количество блоков на странице дольше анализируется, дольше загружается и дольше отрисовывается. Основными проблемными блоками в таких случаях, как правило, являются слайдеры с товарами. Такие блоки, как «Хиты продаж», «Рекомендуемые товары», «Акции» и т. д.
Верстать такие блоки следует при помощи простого стартового шаблона Skeleton. Другими словами, для блока создается 2 состояния:
Для PageSpeed Insights данный пункт критично важен.
При последнем обновлении Lighthouse до шестой версии особое значение стало уделяться времени выполнения скриптов. Данный показатель — не что иное, как Total Blocking Time, и очень сильно снимает баллы для мобильных устройств. Мы решаем эту проблему, запуская все основные скрипты по первому событию на странице: первый клик, скролл, тап или ховер по основному экрану.
Все скрипты, которые можно инициализировать и грузить по персональным событиям, подключаются отдельно. На текущий момент, на версии Lighthouse 6.3, только благодаря данному пункту возможно делать «зеленые показатели» на мобильных устройствах (и то не всегда).
Разработка любого проекта всегда должна начинаться с интеграции шаблона сайта или пустой внутренней страницы. На данной странице должен быть реализован полноценный хедер, футер, содержимое в виде обычного текста и полноценный мобайл со всеми элементами.
Интеграции данной страницы необходимо уделить максимальное внимание, т.к. впоследствии любая внутренняя страница вашего проекта будет состоять из пустого шаблона + контент страницы. Если ваш шаблон будет занимать 2Mb, то и любая ваша внутренняя страница будет весить 2Mb + контент. Оптимизируя шаблон сайта, вы оптимизируете весь сайт.
Основные моменты:
После интеграции пустую страницу следует замерить всеми сервисами. Если вы все сделаете правильно, то она должна показать PageSpeed Insights 100\100. Обычно, в наших проектах нам удается оптимизировать шаблон сайта до 200-300Kb.
Все стили и JS стоит подключать через определённую конструкцию, которую вы можете увидеть по ссылке в полной версии статьи.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13202 тендера
проведено за восемь лет работы нашего сайта.
Важный момент. Стили и JS шаблона подключаются в шаблоне сайта. Стили и JS компонентов должны подключаться непосредственно из компонентов. Это объемная работа по «Разнесению стилей» не всем понравится, но именно этот подход дает наибольший результат.
Соблюдение правильного подключения стилей и JS обеспечит корректную работу штатных инструментов оптимизации. А это наше все) После всей оптимизации зажмите все галочки и вы получите 95\95. Уберите эти галочки и вы получите 40\70. Проверено!
Реальность такова, что для использования любой, хоть самой мелкой функции BitrixJS, тянется огромная библиотека, размером в 314kB. Вдобавок подключаются все зависимости и дополнительные стили. И итого мы будем иметь все 400 kB. 400 kB — это очень много, с учетом, что вся наша главная весит до 1000 kB.
На тему отключения kernel в сети есть множество статей, которые призывают «выпиливать» данный JS при помощи функции preg_replace, но это лишь замедлит загрузку и обязательно что-то сломает.
Kernel стили и JS подключаются только тогда, когда на текущей странице их использует хоть один компонент или модуль. Это может быть модуль аналитики или галочка «Показывать пользователям сообщение об окончании сессии», умный фильтр или штатный JS корзины — в каждом случае что-то свое.
Отключить эти стили просто и одновременно сложно — не использовать BitrixJS на сайте. Если вы на 100% не пользуетесь им, то kernel грузиться не будут — проверено.
Поэтому в нашей компании действует запрет на использование BitrixJS и любых компонентов и модулей, использующих BitrixJS. В разработке мы используем свой умный фильтр, свой JS добавления в корзину, свое оформление заказа и прочие компоненты, не требующие BitrixJS. Поэтому задача каждого разработчика контролировать отсутствие Kernel вот таким вот способом.
Все изображения сайта:
Все эти пункты реализует наш модуль картинок slam.image, который обжимает изображения «на лету», а также создает копию картинки .webp.
С картинками следует работать при помощи простой функции, которую вы найдете по ссылке в полной версии статьи.
Настройки модуля позволяют выбрать оптимальный режим модуля и установить настройки по умолчанию.
Модуль slam.image позволяет на 100% закрыть все пункты про картинки в тесте PageSpeed Insights.
Также для проверки степени сжатия картинок необходимо пользоваться сервисом webspeedtest.cloudinary.com.
Кеширование в Битрикс — это одна из сильных сторон, позволяющая минимизировать нагрузку на сервер. Каждый разработчик SLAM обязан в деталях разбираться в типах кеширования Битрикс, а также в подходах к использованию кеширования.
Разработчик SLAM обязан использовать кеширование всегда и везде. Абсолютно любой запрос должен быть закеширован с оптимальными параметрами обновления кеша. Общее количество запросов с включенным кешем на страницах вашего проекта должно стремиться к нулю. Обычно, это 20-30 системных запросов.
Опытным разработчикам известны слабые стороны Битрикс: объемные каталоги свыше 30 тыс. элементов, большое количество свойств, большая вложенность SKU, сложные скидочные системы. Все это работает крайне медленно из-за сложного построения запросов в штатных компонентах Битрикс.
Допустимое время генерации любой страницы на сайте НЕ более 0.5 сек. Это максимальное время задержки, которое пользователь потенциально не заметит глазами. Задержка в 1 сек уже очевидна невооруженным глазом.
Это означает, что сложный функционал необходимо заранее проектировать и продумывать с точки зрения производительности. Это не сложно, если об этом подумать заранее. Иногда достаточно кастомизировать несколько компонентов, иногда приходится использовать кастомный индекс, но в 100% случаев решение всегда есть. Если самому продумать не удалось, старший товарищ всегда поможет.
Контролировать время генерации страницы можно, включив отладку и сбросив кеш.
Если вы не вложитесь в норматив, придется все переписывать и оптимизировать, пока нужные цифры не будут достигнуты. Более подробную информацию можно найти в стандартах программистов и на собраниях разработчиков.
Композитный режим — это «палочка-выручалочка» для проектов с проблемами производительности. Иногда можно сделать все очень неправильно, но включить композит и сайт будет работать достаточно приемлемо.
Однако, композит для своей работы использует Kernel стили и JS (а мы знаем, что это + 400kB к странице). Поэтому на практике для наших сверх оптимизированных проектов композитный режим лишь снимает баллы. Это можно проверить на любом проекте, который в зеленой зоне. Поэтому при разработке проектов полного цикла мы НЕ используем композитный режим. Включение композита у наших проектов отнимает 15-20 баллов.
При поддержке сторонних проектов, которые достались нам по наследству, работа композита обязательна (при корректных настройках, естественно).
На практике проверено, что Яндекс.Метрика и другие счетчики снимают в среднем от 10 до 40 баллов PageSpeed, при подключении по инструкции от вендора. Вендор всегда рекомендует подключать счетчики как можно выше в . Однако, такое подключение блокирует отрисовку страницы и замедляет ее. Все всегда пишут об асинхронной загрузке счетчиков, не влияющих на скорость, но по факту это выглядит вот так:
Поэтому подключать счетчики всегда необходимо в конце страницы и загружать их по событию: первый скролл, клик, тап, ховер. Данный тип подключения на несколько процентов искажает аналитику по сайту, но очень значительно экономит время первичной загрузки и добавляет баллы PageSpeed.
В стандартах есть заготовки для правильного подключения счетчиков. Также для этих целей есть модуль slam.yametrika.
Без отложенного подключения счетчиков, к сожалению, сделать зеленую зону на мобайле практически невозможно.
Проблема аналогична проблеме счетчиков и решается похожим образом. Как правило, мы создаем заглушку мессенджера и погружаем весь код мессенджера только по клику на эту заглушку. Для посетителя же все выглядит абсолютно естественно.
Также возможно открытие мессенджера по таймеру. Если это необходимо, то стоит поставить задержку не менее 7 секунд.
Бывают блоки или функционал, которые сильно портят производительность страницы в целом. Это может быть блок с картой в футере или сложный расчет скидочной цены, который выполняется 2 сек. и не меньше.
Как способ оптимизации стоит рассмотреть подгрузку данного блока аяксом при скролле или другом событии. Сервис PageSpeed замеряет только первичную загрузку и при использовании Ajax-подгрузки будет замерять страницу как будто без данного блока вовсе.
Битрикс — тяжелая CMS, это не секрет. Поэтому для комфортной работы сайта нужен хороший хостинг. Для интернет-магазина крайне рекомендованы сервера с HighCPU процессорами от 4500 MHz и NVMе дисками.
При выборе хостинга многие упускают эти важные детали, выбирая между VPS или «облаком» и указывая мощность сервера в «количестве ядер». На практике количество ядер влияет на пропускную способность сервера, но скорость генерации страницы напрямую зависит от частоты процессора. 2 ядра с частотой 4500 MHz будут сильно производительнее 4-х или даже 6-ти ядер со штатной частотой 2500 MHz.
Дисковая система на NVMe дисках — это лучшее, что сейчас есть на рынке. От скорости файловой системы зависит параметр чтения/записи данных в БД. У сайтов на 1С-Битрикс всегда много запросов к БД, поэтому этот вопрос крайне важен. Диски NVMe намного быстрее обычных SSD и обеспечивают наибольшую производительность БД.
Проверенные хостинги, с которыми мы партнеримся:
Самый частый вопрос: «Какой нужен хостинг для среднего магазина»?
Ответ: виртуальный или выделенный сервер.
В обоих случаях ПО только BitrixVM.
Примеры сайтов, где все это внедрено:
Вам понравилась статья? Подписывайтесь на наш телеграм-канал! Там мы делимся интересными кейсами и жизнью нашей компании!
