Как быстрее работает 1с битрикс
От скорости сайта зависит многое: количество отказов, брошенных корзин. Согласно исследованию Google, большинство посетителей не ждёт загрузки больше 3 секунд и уходит к конкурентам. Бывает, что сайт тормозит только в момент пиковых нагрузок (часы наибольшей посещаемости, периоды акций) и вы теряете всех, кого так тщательно привлекали.
От чего зависит скорость сайта на Битриксе?
- оптимизация компонентов сайта
- набор модулей
- оптимизация серверного ПО
- достаточное количество ресурсов сервера
С оптимизацией компонентов сайта вам поможет разработчик. Но если есть навыки администрирования, можно перейти на nginx+php-fpm и оптимизировать настройки.
В большинстве случаев, чтобы повысить производительность, нужен анализ текущей нагрузки на сервер. Такое умеют наши администраторы. Но есть и базовые настройки, которых достаточно, чтобы улучшить производительность Битрикс на большинстве серверов. Америку не открываем, если вы хорошо знакомы с *nix, едва ли вы обнаружите что-то новое.
В качестве ОС будем использовать минимальную версию Debian 9. В конце сравним показатели получившейся конфигурации с BitrixVM.
Веб-сервер — Nginx
Лучшим решением будет использование в качестве веб-сервера Nginx. Он шустро работает со статичным контентом и не плодит форков, как это делает apache2. Форки apache2 часто оказываются причиной перерасхода сервером оперативной памяти, потому выбор Nginx снижает требования к объему RAM.
Ставим и конфигурируем Nginx:
Важно! Это только базовая конфигурация, для специфичных функций могут понадобится дополнительные настройки. Наиболее совместимую конфигурацию можно взять из битрикс-окружения. Это учитывается в нашем GT-рецепте.
Сервер БД
В качестве сервера БД используем MariaDB 10.1 из репозитория ОС. Практика показывает, что для нашей задачи гнаться за последними версиями MySQL/MariaDB совершенно не обязательно — значительной разницы в производительности нет.
Важно! После развертывания сайта нужно выполнить «Проверку системы» с исправлением ошибок структуры БД, а также «Оптимизацию БД», оба действия выполняются в админке Битрикс. Эти операции создадут индексы и устранят фрагментацию, что благотворно скажется на производительности.
Ставим и конфигурируем MariaDB:
PHP-FPM
Ещё одна причина отказа от apache2 — использование php-fpm, наиболее быстрого режима работы php-интерпретатора. Наиболее производительной на текущей момент является php7.3, однако в официальном репозитории Debian 9 мы имеем php7. Из соображений связности с предыдущей статьей про производительность Битрикс тут мы тоже будем использовать php7 из репозитория Debian.
Ставим и конфигурируем php-fpm:
Governor
Этот пункт актуален только для выделенных серверов. Планировщик частоты процессора нужен для работы функций энергосбережения. Более низкие частоты процессора требуют меньше напряжения. В нашем случае потребности экономить электричество нет, потому нужно переключить планировщик в режим performance.
Настраиваем и применяем:
Сравниваем производительность
Производительность получившейся конфигурации:
Производительность в окружении BitrixVM:
Если вы оптимизировали сервер по инструкции, но производительность всё равно не устраивает — нужно провести диагностику нагрузки и решить, что вам требуется:
1. Обратиться к разработчику для оптимизации кода
2. Найти дополнительные варианты оптимизации
Например, перенести сессии в оперативную память, настроить Nginx кеширование, заблокировать нежелательных ботов.
3. Добавить ресурсов сервера
Даже в случае с идеально написанным сайтом и не менее идеально оптимизированным сервером в какой то момент узким местом окажутся ресурсы.
Недостаток оперативной памяти не позволит полностью задействовать процессор, а избыток памяти при полностью загруженном работой процессоре не принесёт никакой пользы. Если узким местом оказывается пропускная способность сети — пришло время задуматься о переходе на выделенные серверы с гигабитным каналом.
Часто приходится слышать вопрос: у нас свой сервер (или два), много ядер, памяти. почему же монитор производительности битрикса дает оценку производительности не выше (или ниже), чем на маленькой виртуальной машине?
Давайте разберемся в этом вопросе.
[spoiler]
Подтекст вопроса обычно такой: "ваш тест не правильный, раз он не распознает наше железо".
Ответ: "мы и не пытаемся распознать ваше железо, мы показываем как работает наш продукт на вашем железе относительно того, как он может работать".
Чтобы понять смысл этого утверждения, надо знать, как мы получаем оценку.
Эта цифра - есть величина, обратная времени исполнения ядра продукта [среднему на 10 измерений].
Т.е. на основе приведенной картинки можно сказать, что публичная страница сайта с пустым шаблоном (например, версия для печати), с пустой рабочей областью будет создаваться за 1/40,32 или 0,0248 сек.
Обратите внимание, мы получили "Среднее время отклика".
Если говорить проще, то сервер сгенерирует 40 [пустых, но с подключением ядра] страниц в секунду.
А значит, она не вычисляется на основе "попугаев", приведенных ниже относительно файловой системы, работы базы, сессий и почты. Эти цифры нужны для того, чтобы помочь системному администратору найти узкое место (если такое есть). Оценка производительности всегда обратна величине среднего времени отклика.
почему же на хорошем железе php работает медленно?
Как ни странно, основным препятствием в этом вопросе являются сами администраторы.
На скриншоте видно, что наши рекомендации по оптимальной настройке php не выполнены.
- Потому что мы считаем, что эти параметры не значительны и существенно повлиять на производительность не могут.
На этом этапе важно победить себя и выполнить рекомендации. Если в силу каких-то причин затруднительно выпустить такую конфигурацию в продакшн (например, убрать ограничение open_basedir), попробуйте сделать это для теста и вы убедитесь, что может быть и быстрее.
-
Не установлен акселератор php
Наличие акселератора php просто жизненно необходимо, в общем случае без дополнительных настроек страницы открываются в три раза быстрее, во столько же раз снижается нагрузка на процессор. Сегодня можно рекомендовать сборку Zend Server CE , быстрее любого акселератора в два раза. К сожалению, на некоторых конфигурациях он работает не стабильно, тогда ставьте (в порядке приоритета) APC, EAccelerator, XCache.
-
Конфигурация
Собственно, оценка производительности.
Понимание того, как вычисляется и от чего зависит оценка производительности должно помочь по-другому взглянуть на эту цифру. Не надо стремиться к каким-то заоблачным показателям, возьмите ненагруженную систему, добейтесь хорошего значения (по сравнению с эталонным, а может быть ниже и это будет нормально). А затем возьмите нагрузочное ПО и посмотрите, как будет меняться величина при планируемой пиковой посещаемости на сайте. Убедидесь, что сервер не просто дает хороший результат, но и сохраняет его при нагрузке.
Нагрузочное тестирование отдельная тема, но сразу хочу сказать одно: не надо имитировать 100 параллельных пользователей, которые открывают страницы без перерыва. Между хитами обязательно должна быть задержка в несколько секунд (5-20), иначе это будет имитация DOS атаки. Если сервер будет тянуть 5 одновременных потоков без пауз, это очень и очень неплохо.
Если вы готовите к выпуску крупный проект или работающий проект испытывает трудности с производительностью, наша новая услуга "Экспертиза производительности" поможет получить оптимальную производительность на вашем железе. Наши специалисты сделают анализ конфигурации сервера и дадут конкретные рекомендации по его настройке. Если удобно, мы можем сами сделать необходимые изменения.
Вроде бы и времена, когда скачать песню в 3мб на компьютер можно было где-то за час, уже давно прошли. Да и на телефоне трафик уже много лет как исчисляется десятками гигабайт. Но как бы ни было парадоксально, сейчас вопрос скорости работы сайтов стоит как никогда остро.
Трафик все больше уходит в мобильные устройства, об этом мы писали еще в 2018 году. Значимость скорости загрузки для SEO продвижения тоже сложно переоценить. При долгой загрузке страниц возрастает показатель отказов, уменьшается конверсия.
Итак, важность скорости работы сайта мы обсудили, давайте посмотрим что можно предпринять, чтоб ускорить ваш Битрикс.
1. Минимизируйте CSS и JS файлы
Первое и самое простое, что можно сделать – это сжать JS и CSS файлы. Логика работы очень простая, из файлов убираются все «лишние» символы: пробелы, переносы строк, комментарии, переменные в JS приводятся к 1-2 символьному виду.
Если при разработке сайта на Битрикс вы подключали скрипты и стили правильно, то вам достаточно в настройках главного модуля проставить все галочки в блоке «Оптимизация CSS».
Что значит «правильно»? Это значит, что в коде шаблонов сайтов и компонентов у вас нет вставок .
Что делать, если все подключено как попало? Переподключать!
Вот пример подключения на D7:
Пробегитесь по шаблонам сайтов и компонентов и убедитесь, что у вас нет блоков нигде. Исключением может быть разве что счетчики метрик, а лучше одного счетчика – Google Tag Manager.
Про подключение файлов на старом ядре я писал в этой статье.
Второй вариант минификации файлов – использование Grunt или Gulp. Мне больше нравится Grunt, но любители Gulp легко найдут аналоги грантовских тасков:
- grunt-contrib-cssmin – минифицирует CSS.
- grunt-contrib-uglify – минифицирует JS.
- grunt-contrib-concat – обычное объединение нескольких файлов в один.
Важно: сжатие скриптов и стилей с помощью стороннего софта не освобождают вас от правильного подключения в bitrix.
2. Оптимизируйте изображения
Большую часть контента (по весу) на всех сайтах составляют изображения. Главное, чего нужно избежать – неоправданное использование изображений в высоком разрешении.
Зайдите в настройки любого информационного блока во вкладку «Поля» и в строках «Картинка для анонса» и «Детальная картинка» проставьте галочки «Уменьшать если большая», а потом введите оптимальные ширину и высоту изображений.
Проанализируйте какого размера картинки используются у вас на сайте и настройте все инфоблоки.
Если одни и те же изображения используются в нескольких местах с разным разрешением, то их вывод можно обернуть в CFile::ShowImage($img, $width, $height); Функция вернет HTML изображения, масштабированного в зависимости от указанных размеров. В первый параметр надо передать или ID изображения, либо путь к файлу.
В идеале, отдавать изображения в webp, но это чуть более трудоемкий процесс. Если хотите, чтоб я написал статью на эту тему, пишите в комментариях.
3. Используйте CDN
Еще один пункт, внедряемый буквально за пару минут.
CDN – сеть распределенных серверов, которая помогает быстрее загружать контент. Фактически, любые тяжелые ресурсы можно подтягивать с серверов, которые находятся ближе к конкретному посетителю. Супер актуально для компаний, чьи сайты расположены на наших серверах, а клиенты по всему миру.
Плохая новость №1: для использования технологии вам нужна активная лицензия 1С-Битрикс. Не продлили вовремя – CDN перестанет работать, ресурсы будут отдаваться как обычно.
Плохая новость №2: CDN трафик ограниченный. На разных редакциях по-разному: от 5Гб на «Старте», до 40Гб на «Бизнесе». Если вы исчерпаете лимит – ресурсы станут отдаваться в обычном режиме. Без ограничений на CDN трафик только редакция Энтерпрайз. Но у вас ведь не она, правда? :)
Плохая новость №3: битрикс пользуется услугами совершенно определенной сети CDN – CDNvideo. Если вам по каким-то причинам захочется сменить CDN провайдера, без команды опытных разработчиков вам не обойтись. Ну и не забывайте, CDN работает только на активной лицензии, а купить продление 1С-Битрикс можно здесь.
4. Избегайте 301 редиректа
Редиректы - убийцы производительности. Избегайте их везде, где это возможно. Они будут генерировать дополнительные Round Trip Time (RTT) и, следовательно, удваивает время загрузки изначальной HTML страницы, еще до того, как браузер начнет загружать контент.
SEO специалисты на этом пункте завоют. И серьезно, иногда 301 не решить определенные задачи. Просто пробегитесь по сайту (или воспользуйтесь софтом) и проанализируйте все ли действующие редиректы вам все еще нужны.
5. Используйте хостинг, рекомендуемый 1С-Битрикс или виртуальный сервер
Еще одна очень частая проблема – не оптимальная настройка хостинга. При этом сайт может работать абсолютно корректно.
Чтобы проверить все ли у вас в порядке, можно прямо из админки битрикса, протестировав производительность.
Настройки -> Производительность -> Панель производительности. Запустите тест на 1 минуту, после завершения, на вкладке «Конфигурация» вы увидите сравнение текущей конфигурации с эталоном.
Мы перепробовали какое-то количество хостингов за последние 7 лет (даже запускали свой), могу сказать, что оценка в 30 баллов – очень средняя отметка. На минимальном тарифе под 1С-Битрикс моего любимого Спринтхоста выдает 30 глазом не моргнув.
Да и любой хороший хостинг на средних тарифах, выдает 50-80. Ходят слухи, что кто-то разгонял Битрикс до 290 попугаев, но тут уже нужен сервер с хорошим железом.
На второй вкладке - «Битрикс» - найдете вердикт по настройке конфигурации. Если настроено не оптимально – ознакомьтесь с документацией и исправьте.
Если все плохо и хостер отказывается изменять конфигурацию (или переносить ваш сайт на другой сервер), стоит задуматься о его смене. На официальном сайте битрикса есть целый раздел с рекомендованными хостинг-партнерами . Выберите себе исходя из цены, качества и дополнительных плюшек. :)
6. Настройте кеширование
Следующий пункт – кеширование. Оно бывает разное, а метериала хватило бы для целой серии статей. Я хочу поговорить про встроенное в Битрикс.
Идем в настройки битрикса: Настройки продукта -> Автокеширование и включаем (если выключено).
Если вы думали, что на этом все – вы очень ошибались. Проходим по всему сайту, заходим в настройки каждого компонента и выставляем кеширование на «Авто», либо «Кешировать» и время кеширования в секундах (минимум 86400).
Можно сделать замену в IDE, запустив поиск по всему проекту. За кеширование компонентов отвечают параметры:
7. Настройте композитный сайт
Композитный сайт – запатентованная технология 1С-Битрикс и её включение действительно приводит к хорошим результатам.
В идеале настроить на хранение в memcached.
Еще несколько лет назад на подговотку сайта и отладку композитного режима ушла бы пара дней, сейчас достаточно включить Автокомпозит в настройках и радоваться жизни. Этот вариант рекомендует и сам Битрикс.
8. Не используйте старые версии PHP
Этот пункт можно было бы отнести в раздел о Хостинге, но я решил выделить его отдельно. Перестаньте сидеть на старых версиях php. Уже сам битрикс официально не поддерживает старые версии. Просто посмотрите на сравнение производительности. К сожалению, данных по Битрикс не нашел, но уверен там все примерно также.
Избавьтесь от устаревшего кода, протестируйте ваш сайт и переводите сервер/хостинг на php последней стабильной версии.
9. Включите Gzip
Это рекомендует и сам Google. Gzip – утилита сжатия файлов. По нашим наблюдениям, включение gzip на сервере заметно увеличивает скорость загрузки.
Для Apache вы можете включить сжатие в .htaccess.
Для Nginx сжатие необходимо включить в файле nginx.conf.
Вопрос быстродействия сайтов очень комплексный, не надо думать, что выполнение описанных действий – панацея. Но я прекрасно понимаю, что далеко не у всех владельцев сайтов есть знания (и время) для кропотливой и вдумчивой работы над быстродействием своего ресурса, а бюджеты на подобные работы у студий могут исчисляться сотнями тысяч.
Все описанные способы позволяют практически без затрат и буквально одним днем увеличить скорость работы. Уверен, для большинства сайтов этого будет достаточно. Если же нет – всегда готовы помочь - обращайтесь :)
Вроде бы и времена, когда скачать песню в 3мб на компьютер можно было где-то за час, уже давно прошли. Да и на телефоне трафик уже много лет как исчисляется десятками гигабайт. Но как бы ни было парадоксально, сейчас вопрос скорости работы сайтов стоит как никогда остро.
Трафик все больше уходит в мобильные устройства , об этом мы писали еще в 2018 году. Значимость скорости загрузки для SEO продвижения тоже сложно переоценить. При долгой загрузке страниц возрастает показатель отказов, уменьшается конверсия.
Итак, важность скорости работы сайта мы обсудили, давайте посмотрим что можно предпринять, чтоб ускорить ваш Битрикс.
1. Минимизируйте CSS и JS файлы
Первое и самое простое, что можно сделать – это сжать JS и CSS файлы. Логика работы очень простая, из файлов убираются все «лишние» символы: пробелы, переносы строк, комментарии, переменные в JS приводятся к 1-2 символьному виду.
Если при разработке сайта на Битрикс вы подключали скрипты и стили правильно, то вам достаточно в настройках главного модуля проставить все галочки в блоке «Оптимизация CSS».
Что значит «правильно»? Это значит, что в коде шаблонов сайтов и компонентов у вас нет вставок .
Что делать, если все подключено как попало? Переподключать!
Вот пример подключения на D7:
use Bitrix\Main\Page\Asset;
Asset::getInstance()->addJs('/js/jQuery.min.js'); - правильное подключение JS.
Asset::getInstance()->addCss('/css/bootstrap-grid.css'); - правильное подключение CSS.
Пробегитесь по шаблонам сайтов и компонентов и убедитесь, что у вас нет блоков нигде. Исключением может быть разве что счетчики метрик, а лучше одного счетчика – Google Tag Manager.
Про подключение файлов на старом ядре я писал в этой статье.
Второй вариант минификации файлов – использование Grunt или Gulp. Мне больше нравится Grunt, но любители Gulp легко найдут аналоги грантовских тасков:
- grunt-contrib-cssmin – минифицирует CSS.
- grunt-contrib-uglify – минифицирует JS.
- grunt-contrib-concat – обычное объединение нескольких файлов в один.
module .exports = function (grunt) grunt.initConfig( concat: dist: src: 'js/*.js',
dest: 'js/min/all.js'
>
>,
uglify: dist: files: 'js/min/all.min.js': ['js/min/all.js']
>
>
>,
cssmin: target: files: [ expand: true ,
cwd: 'css',
src: ['*css', '!*.min.css'],
dest: 'css',
ext: '.min.css'
>]
>
>
>);
grunt.loadNpmTasks('grunt-contrib-uglify');
grunt.loadNpmTasks('grunt-contrib-cssmin');
grunt.loadNpmTasks('grunt-contrib-concat');
grunt.registerTask('default', ['concat', 'uglify', 'cssmin']);
>;
Важно: сжатие скриптов и стилей с помощью стороннего софта не освобождают вас от правильного подключения в bitrix.
2. Оптимизируйте изображения
Большую часть контента (по весу) на всех сайтах составляют изображения. Главное, чего нужно избежать – неоправданное использование изображений в высоком разрешении.
Зайдите в настройки любого информационного блока во вкладку «Поля» и в строках «Картинка для анонса» и «Детальная картинка» проставьте галочки «Уменьшать если большая», а потом введите оптимальные ширину и высоту изображений.
Проанализируйте какого размера картинки используются у вас на сайте и настройте все инфоблоки.
Если одни и те же изображения используются в нескольких местах с разным разрешением, то их вывод можно обернуть в CFile::ShowImage($img, $width, $height); Функция вернет HTML изображения, масштабированного в зависимости от указанных размеров. В первый параметр надо передать или ID изображения, либо путь к файлу.
В идеале, отдавать изображения в webp, но это чуть более трудоемкий процесс. Если хотите, чтоб я написал статью на эту тему, пишите в комментариях.
3. Используйте CDN
Еще один пункт, внедряемый буквально за пару минут.
CDN – сеть распределенных серверов, которая помогает быстрее загружать контент. Фактически, любые тяжелые ресурсы можно подтягивать с серверов, которые находятся ближе к конкретному посетителю. Супер актуально для компаний, чьи сайты расположены на наших серверах, а клиенты по всему миру.
Плохая новость №1: для использования технологии вам нужна активная лицензия 1С-Битрикс. Не продлили вовремя – CDN перестанет работать, ресурсы будут отдаваться как обычно.
Плохая новость №2: CDN трафик ограниченный. На разных редакциях по-разному: от 5Гб на «Старте», до 40Гб на «Бизнесе». Если вы исчерпаете лимит – ресурсы станут отдаваться в обычном режиме. Без ограничений на CDN трафик только редакция Энтерпрайз. Но у вас ведь не она, правда? :)
Плохая новость №3: битрикс пользуется услугами совершенно определенной сети CDN – CDNvideo. Если вам по каким-то причинам захочется сменить CDN провайдера, без команды опытных разработчиков вам не обойтись.
4. Избегайте 301 редиректа
Редиректы - убийцы производительности. Избегайте их везде, где это возможно. Они будут генерировать дополнительные Round Trip Time (RTT) и, следовательно, удваивает время загрузки изначальной HTML страницы, еще до того, как браузер начнет загружать контент.
SEO специалисты на этом пункте завоют. И серьезно, иногда 301 не решить определенные задачи. Просто пробегитесь по сайту (или воспользуйтесь софтом) и проанализируйте все ли действующие редиректы вам все еще нужны.
5. Используйте хостинг, рекомендуемый 1С-Битрикс или виртуальный сервер
Еще одна очень частая проблема – не оптимальная настройка хостинга. При этом сайт может работать абсолютно корректно.
Чтобы проверить все ли у вас в порядке, можно прямо из админки битрикса, протестировав производительность.
Настройки -> Производительность -> Панель производительности. Запустите тест на 1 минуту, после завершения, на вкладке «Конфигурация» вы увидите сравнение текущей конфигурации с эталоном.
Мы перепробовали какое-то количество хостингов за последние 7 лет (даже запускали свой), могу сказать, что оценка в 30 баллов – очень средняя отметка. На минимальном тарифе под 1С-Битрикс моего любимого Спринтхоста выдает 30 глазом не моргнув.
Да и любой хороший хостинг на средних тарифах, выдает 50-80. Ходят слухи, что кто-то разгонял Битрикс до 290 попугаев, но тут уже нужен сервер с хорошим железом.
На второй вкладке - «Битрикс» - найдете вердикт по настройке конфигурации. Если настроено не оптимально – ознакомьтесь с документацией и исправьте.
Если все плохо и хостер отказывается изменять конфигурацию (или переносить ваш сайт на другой сервер), стоит задуматься о его смене. На официальном сайте битрикса есть целый раздел с рекомендованными хостинг-партнерами . Выберите себе исходя из цены, качества и дополнительных плюшек. :)
6. Настройте кеширование
Следующий пункт – кеширование. Оно бывает разное, а метериала хватило бы для целой серии статей. Я хочу поговорить про встроенное в Битрикс.
Идем в настройки битрикса: Настройки продукта -> Автокеширование и включаем (если выключено).
Если вы думали, что на этом все – вы очень ошибались. Проходим по всему сайту, заходим в настройки каждого компонента и выставляем кеширование на «Авто», либо «Кешировать» и время кеширования в секундах (минимум 86400).
Можно сделать замену в IDE, запустив поиск по всему проекту. За кеширование компонентов отвечают параметры:
7. Настройте композитный сайт
Композитный сайт – запатентованная технология 1С-Битрикс и её включение действительно приводит к хорошим результатам.
В идеале настроить на хранение в memcached.
Еще несколько лет назад на подговотку сайта и отладку композитного режима ушла бы пара дней, сейчас достаточно включить Автокомпозит в настройках и радоваться жизни. Этот вариант рекомендует и сам Битрикс.
8. Не используйте старые версии PHP
Этот пункт можно было бы отнести в раздел о Хостинге, но я решил выделить его отдельно. Перестаньте сидеть на старых версиях php. Уже сам битрикс официально не поддерживает старые версии. Просто посмотрите на сравнение производительности. К сожалению, данных по Битрикс не нашел, но уверен там все примерно также.
Избавьтесь от устаревшего кода, протестируйте ваш сайт и переводите сервер/хостинг на php последней стабильной версии.
9. Включите Gzip
Это рекомендует и сам Google. Gzip – утилита сжатия файлов. По нашим наблюдениям, включение gzip на сервере заметно увеличивает скорость загрузки.
Для Apache вы можете включить сжатие в .htaccess.
Для Nginx сжатие необходимо включить в файле nginx.conf.
gzip on;
gzip_comp_level 2;
gzip_http_version 1.0;
gzip_proxied any;
gzip_min_length 1100;
gzip_buffers 16 8k;
gzip_types text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;
gzip_disable "MSIE 2.(. *SV1)";
gzip_vary on;
Вопрос быстродействия сайтов очень комплексный, не надо думать, что выполнение описанных действий – панацея. Но я прекрасно понимаю, что далеко не у всех владельцев сайтов есть знания (и время) для кропотливой и вдумчивой работы над быстродействием своего ресурса, а бюджеты на подобные работы у студий могут исчисляться сотнями тысяч.
Все описанные способы позволяют практически без затрат и буквально одним днем увеличить скорость работы. Уверен, для большинства сайтов этого будет достаточно. Если же нет – всегда готовы помочь - обращайтесь :)
Узнавайте о выходе новых публикаций первыми, голосуйте за темы будущих статей в моем Телеграм канале .
Узнай как можно ускорить загрузку сайта на Битрикс в браузере. А так же основные понятия, используемые при оптимизации скорости сайта — CDN, минимизация css, минимизация js и прочее полезное.
Это перевод статьи на тему ускорения загрузки сайта, от 12 декабря 2006 года. Может показаться, что это пыльное старьё, но рекомендаций актуальны и на сегодняшний день.
CSS-спрайты предпочтительны для уменьшения числа изображений. Объедините фоновые изображения в одно и используйте такие свойства CSS, как background-image и background-position для отображения нужной области.
В системе есть штатная функция объединения и сжатия CSS- и JS-файлов, которая включается в настройках главного модуля. При включении этой опции в идеальном случае на странице подключается 3 CSS и 3 JS-файла.
Бывают ситуации, когда штатная опция работает не так как нужно, например, не учитывает условные комментарии для IE ( ), т.е. условие пропадёт, а «специальный файл» пойдёт в общую солянку. Из предыдущего абзаца следует, что Битрикс подключает служебные CSS- и JS-файлы, как сэкономить на их подключении можно прочитать в этом посте.
2. Использовать сеть доставки контента (CDN — Content Delivery Network)
Расстояние от пользователя до вашего веб-сервера влияет на время отклика. Размещение контента на множестве серверов с различным местоположением позволит пользователям быстрее загружать ваши страницы. Но с чего начать?
Прежде всего, не пытайтесь переписать ваше приложение для работы в распределенной архитектуре. В зависимости от приложения, изменение архитектуры может включать обескураживающие задачи, к примеру, синхронизацию состояния сессии и репликацию транзакций базы данных на различных серверах. Попытки сократить расстояние между пользователями и вашим контентом могут застрять и не пойти дальше этого шага в разработке архитектуры.
Помните, что 80-90% времени отклика для конечного пользователя определяется временем загрузки компонентов страницы: картинок, стилей, скриптов, Flash-роликов. Это — золотое правило производительности. Лучше заняться распределением статического контента, чем браться за сложную задачу модификации архитектуры приложения. Это не только существеннее сократит время отклика, но это и легче благодаря сетям доставки контента.
Сеть доставки контента (CDN) — это группа веб-серверов, распределенных по различным местоположениям, чтобы обеспечить наиболее эффективную доставку контента пользователям. Обычно для доставки контента конкретному пользователю выбирается ближайший по сети сервер, например, с минимальным количеством перенаправлений между сетями или минимальным временем отклика.
Некоторые крупные интернет-компании располагают собственной CDN, но экономичнее использовать CDN-службу провайдера, к примеру, Akamai Technologies, EdgeCast или level3. Стартапы и частные веб-сайты, возможно, не могут позволить себе CDN-службу, но с ростом вашей целевой аудитории и переходом на глобальный уровень CDN становится необходимой. В Yahoo! службы, перенесшие свой статический контент с веб-серверов приложений на CDN (как сторонние, так и внутренние CDN-службы Yahoo), улучшили время отклика для конечных пользователей на 20% и более. Переход на CDN — относительно легкое изменение программного кода, которое значительно улучшит время загрузки вашего сайта.
«1С-Битрикс: Управление сайтом» — первая российская CMS, интегрированная с сетью CDN на уровне самой платформы! Любой владелец сайта может значительно ускорить свой проект буквально в «один клик» без каких-либо дополнительных настроек!
Подключение: в административной панели вашего сайта в разделе «Настройки» — «Облачные сервисы Битрикс» — «Ускорение сайта (CDN)» отметьте галочку «Включить ускорение сайта» и сохраните изменения.
3. Добавить заголовок Expires или Cache-Control
Это правило включает в себя два аспекта:
- Статические компоненты: установите политику «Never expire» в заголовке Expires
- Динамические компоненты: используйте подходящий заголовок Cache-Control для условных запросов браузера.
Если ваш сервер работает на Apache, используйте директиву ExpiresDefault для срока кэширования по отношению к текущей дате. Этот пример директивы ExpiresDefault устанавливает срок хранения на 10 лет относительно текущей даты.
Имейте в виду, что, если вы используете заголовок Expires, вам придется изменить имя компонента при изменении его содержания. В Yahoo! это входит в процесс сборки: номер версии содержится в имени компонента, к примеру, yahoo_2.0.6.js.
4. Использовать сжатие GZip
Gzip — самый распространённый и эффективный метод сжатия (на дату написания статьи — 12 дек. 2006 г. — Прим. перев.). Другой алгоритм сжатия, который может вам встретиться, — deflate, но он менее эффективен и популярен.
Gzip-сжатие сокращает размер отклика примерно на 70%. Приблизительно 90% интернет-трафика (на дату написания статьи) передается через браузеры, заявляющие о поддержке gzip. Если вы используете Apache, модуль, определяющий настройки сжатия, зависит от версии: Apache 1.3 использует mod_gzip, а Apache 2.x — mod_deflate.
Известны некоторые проблемы с браузерами и прокси-серверами, которые могут вызвать несоответствие между тем, что браузер ожидает получить, и получаемым сжатым контентом. К счастью, эти проблемы сокращаются по мере обновления браузеров. Модули Apache автоматически добавляют к отклику подходящие заголовки Vary.
Веб-серверы определяют, что сжимать, на основании типа файла, но обычно довольно ограничены в этом выборе. Большинство сайтов сжимают HTML-документы. Также стоит сжимать скрипты и стили, но многие сайты упускают эту возможность. В принципе, имеет смысл сжимать любой текстовый отклик, включая XML и JSON. Изображения и PDF- файлы сжимать не стоит, так как они уже сжаты. Применение к ним gzip не только напрасно увеличивает нагрузку на процессор, но также может увеличить размер файла.
Максимально широкое применение сжатия к различным типам файлов — простой способ уменьшить размер страницы и улучшить впечатление пользователя.
5. Располагать таблицы стилей в начале документа
Во время исследования производительности в Yahoo! мы обнаружили, что в результате переноса таблиц стилей в раздел страницы HEAD страница кажется более быстрой. Причина этого в том, что при расположении стилей в разделе HEAD страница визуализируется постепенно.
Разработчики фронт-энда, заинтересованные в высокой производительности, предпочитают постепенную загрузку страницы, то есть, мы хотим, чтобы браузер отображал имеющийся контент по мере его получения. Это особенно важно для высоконагруженных страниц и пользователей с медленным подключением. Существуют исследования и документы, доказывающие важность обратной связи для пользователей, например, индикаторов загрузки. В нашем случае HTML-страница и есть индикатор загрузки! При постепенной загрузке шапки, навигационной панели, логотипа в шапке все эти компоненты выполняют функцию обратной связи для пользователя, ожидающего загрузки страницы. Это улучшает общее впечатление пользователя.
Проблема с расположением стилей в нижней части документа состоит в том, что это блокирует постепенную загрузку во многих браузерах, включая Internet Explorer. Эти браузеры блокируют визуализацию, чтобы не пришлось перерисовывать элементы в случае изменения стилей. В результате пользователь видит пустую белую страницу.
Спецификация HTML явно подчеркивает, что таблицы стилей должны находиться в разделе HEAD: «В отличие от элемента A, элемент LINK может находиться только в разделе HEAD, но появляться может неограниченное число раз». Ни одна из альтернатив, пустой белый экран или поток нестилизованного контента, риска не стоит. Наилучшее решение — следовать спецификации HTML и загружать стили в разделе HEAD.
Для ещё большего ускорения загрузки сайта объединённый CSS-файл можно перенести вниз страницы, перед закрывающим тегом
Читайте также: