Обзоры расширений Joomla

 

В предыдущей статье «Обзор Speed Cache. Сравнение систем кэш Joomla» был приведён тест сравнения расширений кэширования Joomla. Эти расширения помогут в таких важных вопросах как сокращение времени ответа сервера и снижение нагрузки на него. Также была рассмотрена разница между понятиями «скорости» и «степени оптимизации» загрузки сайта. В этой статье дам некоторые советы по оптимизации сайта Джумла на основании рекомендаций Google Page Speed Insights.

Рекомендации Page Speed Insights и Joomla

Ниже изложена информация на основании моего личного опыта. Из CMS работаю исключительно с Joomla (так сложилось). Но то, что изложено ниже, на мой взгляд, применимо к любой готовой CMS, исходный код которой не претерпевает существенных изменений в ходе оптимизации скорости загрузки (не самописной и не фреймворк). Применимо в разной степени и с учётом специфики каждой конкретной CMS.

В Google Page Speed Insights есть две степени важности рекомендаций. Их название и описание взяты с самого сервиса.

  1. Исправьте обязательно. Если это исправить, страница станет загружаться намного быстрее.
  2. Исправьте по возможности. Лучше это исправить, если не слишком сложно.

На данный момент (06.04.2017) есть 10 рекомендаций. У каждой из них разная степень важности в зависимости от каждой конкретной анализируемой страницы и от того, от «имени» какого устройства производится анализ (есть «Для мобильных» и «Для компьютеров»). То есть, для разных страниц сайта разные критерии могут иметь разную важность для внедрения, в зависимости от того, насколько, по мнению Google Page Speed Insights, тот или иной критерий влияет на степень оптимизации страницы.

Ниже приведу список рекомендаций в порядке убывания их важности. Первый – самый важный. Порядок основывается на моём собственно опыте (для большинства случаев, с которыми мне пришлось работать).

  1. Сократите время ответа сервера.
  2. Оптимизируйте загрузку видимого контента.
  3. Используйте кеш браузера.
  4. Включите сжатие.
  5. Оптимизируйте изображения.
  6. Удалите код JavaScript и CSS, блокирующий отображение верхней части страницы.
  7. Сократите CSS.
  8. Сократите JavaScript.
  9. Сократите HTML.
  10. Не используйте переадресацию с целевой страницы.

Ниже приведу список рекомендаций в порядке убывания их простоты реализации на сайтах Joomla. Первый – самый сложный. Порядок основывается на моём собственно опыте (для большинства случаев, с которыми мне удавалось работать).

  1. Сократите время ответа сервера.
  2. Удалите код JavaScript и CSS, блокирующий отображение верхней части страницы.
  3. Оптимизируйте загрузку видимого контента.
  4. Сократите JavaScript.
  5. Сократите CSS.
  6. Сократите HTML.
  7. Оптимизируйте изображения.
  8. Включите сжатие.
  9. Используйте кеш браузера.
  10. Не используйте переадресацию с целевой страницы.

Рекомендации по оптимизации скорости загрузки сайта по вышеописанным критериям, и не только, можно прочесть в официальной русскоязычной справке от Google. А вот раздел справки касательно загрузки сайта на мобильных устройствах. Для ускорения загрузки сайта на мобильных устройствах рекомендую ознакомиться с плагином JAmp и компонентом Responsivizer. А в статье «Обзор JAmp. AMP-страницы в Joomla 3» можно найти сравнение скорости загрузки и степени оптимизации страниц сайта по технологии AMP.

На основании собственного опыта дам советы по внедрению вышеперечисленных рекомендаций на сайт Joomla и подскажу, при помощи каких расширений можно реализовать ту или иную рекомендацию. Также кратко поясню сложности\тонкости некоторых советов.

Сократите время ответа сервера Joomla

Включите и настройте кэш Joomla. Встроенный, Speed Cache или JotCache или какой-то другой. Но без кэширования, скорее всего, будет очень сложно реализовать эту рекомендацию. Включение кэша (любого) может повлечь за собой негативные последствия в виде нарушения работоспособности и\или отображения сайта. Настройка кэша может быть длительным итерационным процессом, но это того стоит.

 

Нужен максимально быстрый хостинг. В статье «Обзор JAmp. AMP-страницы в Joomla 3» я описывал свой хостинг и его возможности. Если прочтёте список средств панели управления хостингом по оптимизации скорости загрузки сайта, то увидите, что большинство рекомендаций Google Page Speed Insights можно покрыть этими настройками. Также на этом хостинге есть Page Speed кэширование и Zend OPcache (ранее назывался "Zend Optimizer+"). Но выбор хостинга, перенос туда сайта – это не слишком простой и быстрый вопрос. Также стоит отметить, что стоимость такого хостинга не может быть ниже среднерыночной. Например, я плачу около 145$ за 2 года (с учётом наличия скидки 30% по программе лояльности и дополнительной скидки 45% за оплату на 2 года вперёд, по сравнению с помесячной оплатой). В эту стоимость входит хостинг с тарифом «Мастер SSD», 1 выделенный IP адрес и 160 Мб ОЗУ для Zend OPcache.

 

Нужно отключить\удалить абсолютно все лишние расширения Joomla (компоненты, модули, плагины). Скорее всего, это будет очень затратный по времени процесс. По сути, Вам нужно рассмотреть абсолютно каждый плагин, модули и компонент, который есть у Вас на сайте. Даже если это стандартный плагин, поставляемый с Joomla. Рассмотреть на предмет его необходимости. Если без него можно обойтись, то его нужно отключить. Но это следует делать с очень большой осторожностью и пониманием того, за что именно отвечает то или иное расширение. Придётся несколько раз протестировать весь сайт, чтобы убедиться, что ничего лишнего не отключено.

Если есть возможность, нужно определить, какие из оставшихся расширений создают самую большую нагрузку. Возможно, такие расширения нужно заменить на аналоги. Это достаточно сложно реализовать, так как выявить «тяжёлые» расширения без специальных инструментов, на стороне сервера\хостинга, не получится. Можно воспользоваться отладкой Joomla (Система – Общие настройки – Система – Отладка системы, также проверьте, чтобы был включён плагин «Система - Отладка»). Но она не даст полной картины. Лучше что-то типа New Relic, но для его применения, скорее всего, понадобится минимум VPS\VDS. На общих хостингах применять его не получится. На некоторых хостингах есть подобные инструменты. Но, к сожалению, с New Relic им не сравниться. Например, на моём хостинге есть такие инструменты (рисунки ниже):

  1. Отчёт «Нагрузка на сайт». С возможностью просмотра количества запросов на веб-сервер за последние 14 дней и за последние сутки, а также использование процессорного времени (в процессорных минутах). К сожалению, без разделения даже по сайтам (если у Вас их несколько на аккаунте).
  2. Отчёт «Нагрузка по URL».
  3. Отчёт «Нагрузка по Страницам».
  4. Отчёт «Нагрузка на MySQL сервер». С возможностью простора затраченного процессорного времени в минутах, трафик в мегабайтах и количества запросов к базе данных. Как для всех баз данных на аккаунте, так и для каждой отдельно.
  5. Отчёт «Медленные запросы».

Отчёт «Нагрузка на сайт» (рисунок ниже), отдалённо может помочь в проведении с экспериментами касательно нагрузки Joomla на аккаунт. Так, например, на рисунке ниже виден всплеск (137,27 минуты). Это я включил хранение кэша Joomla в Memcache (стандартное кэширование и JotCache). Так как посещаемость сайта маленькая (701 пользователь, 825 сеансов, 1309 просмотров страниц, 1,59 страниц за сеанс), то процессорные издержки на Memcache перекрыли выгоду. Нагрузка Joomla на сервер возросла, примерно, на 104%, при этом, по разным тестам, скорость загрузки сайта ухудшилась, примерно, на 10-20% (да ещё и проблемы с отображением стилей появились). Учитывая всё это и стоимость ОЗУ для Memcache было принято решение отказаться от этой затеи. Хотя для такого решения хватило и фактора падения скорости. То есть, данный отчёт полезен в ситуации типа: «Установили новый компонент – смотрим нагрузку, учитывая посещаемость и тестируя скорость». Делаем выводы о его влиянии на скорость и нагрузку.

Отчёт «Нагрузка на сайт»
Отчёт «Нагрузка на сайт»

Отчёты «Нагрузка по URL» и «Нагрузка по Страницам» (рисунок ниже) могут дать подсказку, какие страницы сайта больше всего потребляют процессорного времени (с учётом количества запросов). Зная это можно посмотреть, какие расширения участвуют в генерации «тяжёлых» страниц и попытаться что-то с этим сделать.

Отчёты «Нагрузка по URL»
Отчёты «Нагрузка по URL»
Отчёты «Нагрузка по Страницам»
Отчёты «Нагрузка по Страницам»

В принципе, данный отчёт (рисунок ниже) аналогичен отчёту «Нагрузка на сайт», но относится только к базе данных. Например, так можно судить о нагрузке нового компонента Joomla на базу данных. К сожалению, только косвенно. Когда мой сайт был на VPS, то там был установлен New Relic. Так вот благодаря очень-очень подробной информации я смог сразу определить, какой компонент (и даже какая именно опция этого компонента) больше всего нагружает базу данных. Та как там была статистика по каждой отдельной таблице базы данных. В моём случае это был компонент глоссария (SEO Glossary). Вернее, нагрузку создавала одна опция – опция автоматической вставки ссылки в материал Joomla на термины, которые есть в глоссарии. Отключив её, мне не пришлось избавляться от этого компонента, так как нагрузка на базу данных, с его стороны, фактически исчезла.

Отчёт «Нагрузка на MySQL сервер»
Отчёт «Нагрузка на MySQL сервер»

Отчёт «Медленные запросы» (рисунок ниже). Для каждого запроса выводится подробная информация о том, как он обрабатывался сервером баз данных и какие индексы использовались. К счастью, таких запросов у меня нет и более подробную информацию пока дать не могу.

Отчёт «Медленные запросы»
Отчёт «Медленные запросы»

 

После отключения\удаления ненужных расширений стоит поискать опции оставшихся расширений, которые создают нагрузку Joomla на сервер или замедляют сайт. Это ещё более сложная и по времени затратная процедура. Проводится она аналогично вышеописанной с поиском ненужных расширений.

 

Можно пойти ещё дальше и поискать замену используемым расширениям. А это ещё дольше, сложнее и дороже. Такое я делал только для своих собственных проектов. Возможно, Вам может понадобиться переделать половину сайта. Сама процедура выбора – длительный процесс, а потом ещё настройка и тестирование, причём, несколько итераций и в течение нескольких дней.

Использование кеша браузера Joomla и другие рекомендации

Удалите код JavaScript и CSS, блокирующий отображение верхней части страницы. Оптимизируйте загрузку видимого контента. Сократите HTML. Сократите JavaScript. Сократите CSS.

Помимо вышеописанного (с отключением\удалением лишних расширений), для реализации данных рекомендаций можно воспользоваться специальным плагином JCH Optimize Pro. Там есть соответствующие опции. Применение этого или любого другого аналогичного расширения может повлечь за собой негативные последствия в виде нарушения работоспособности и\или отображения сайта. Настройка подобного расширения может быть длительным итерационным процессом, но это того стоит.

Также, в качестве инструментов, позволяющих реализовать рекомендации Google Page Speed Insights, можно использовать инструменты\настройки хостинга\сервера или поискать соответствующие расширения Joomla.

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

Почему так может происходить? Joomla, как и любая готовая CMS, написана не под конкретные текущие требования именно Вашего проекта, а является универсальным, готовым программным обеспечением для создания разных сайтов. То же самое относится к её расширениям. Так вот советы Google типа: «Удалите код JavaScript и CSS, блокирующий отображение верхней части страницы», «Оптимизируйте загрузку видимого контента», «Сократите HTML», «Сократите JavaScript», «Сократите CSS» и т.д., по-хорошему, требуют рефакторинга кода (его переработки). По-хорошему, из кода нужно убрать абсолютно всё лишнее, что не нужно для текущих задач Вашего конкретного сайта. А это требует от специалиста высокой квалификации и много времени, как следствие – дорого. Также это, наверняка, лишит Вас всех преимуществ применения готовой CMS. Вы уже не сможете, так же легко, как и ранее, устанавливать дополнительные расширения, обновлять ядро CMS и т.д. По сути у Вас будет самописная CMS. Или даже хуже. Смесь самописной CMS и готовой. Для дальнейшей поддержки сайта – это «ад».

Что же делает JCH Optimize Pro и ему подобные расширения? Они «на лету» делают некий «рефакторинг» генерируемых страниц без изменения исходного кода CMS и её расширений. А это дополнительная нагрузка на сервер и ухудшение времени генерации страницы. Без кэша подобные процессы могут только навредить.

Плюс, не всегда удаётся настроить JCH Optimize Pro и ему подобные расширения на выполнение всех рекомендаций Google Page Speed Insights без ущерба для функциональности и\или внешнего вида сайта. На мой взгляд, если никак нельзя устранить такой конфликт, то лучше отказаться от выполнения подобной рекомендации.

 

Оптимизируйте изображения.

Ознакомьтесь с этими рекомендациями, а в качестве инструмента сжатия без потерь рекомендую File Optimizer. В его настройках, на вкладке PNG, можете включить опцию Allow lossy optimizations (лучше для сжатия степени сжатия, но хуже по времени сжатия). Учтите, что сжатие изображений в File Optimizer может происходить очень долго (особенно PNG изображения с большой высотой), но сжимает хорошо. Сравнение программ есть в статье «Обзор инструментов для сжатия изображений».

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

А ещё, я ни разу не встречал побочных эффектов от сжатия изображений.

 

Включите сжатие.

Сжатие передаваемой, между браузером и сервером, информации (HTML, CSS и т.д.) обладает теми же преимуществами, что и сжатие изображений. Его можно активировать в настройках Joomla (Система ­– Общие настройки – Сервер – Gzip-сжатие страниц). Это также можно включить (или как у меня на хостинге, включено по умолчанию) в настройках сервера\хостинга. Можно настроить в файле «.htaccess». Подробнее об этом файле и разных его настройках можно прочесть в статье «Попытка номер раз создать почти идеальный htaccess».

Это реализуется достаточно быстро, просто и не вызывает проблем.

 

Используйте кеш браузера.

Речь идёт о кэшировании всех «тяжёлых» статических файлов на стороне клиента. Это могут быть изображения, CSS и HTML-файлы, видео аудио и т.д. Это можно настроить, например, в файле «.htaccess». Подробнее об этом файле и разных его настройках можно прочесть в статье «Попытка номер раз создать почти идеальный htaccess». Также это можно настроить на сервере\хостинге или при помощи Speed Cache, JCH Optimize и т.д. Также в Joomla есть плагин «Система - Кэш». Но стоит подумать над тем, какие типы файлов и на сколько нужно кэшировать. Так как закэшированные на стороне клиента файлы не обновляются в момент их изменения на сервере. Это может приводить к отображению устаревшей «версии сайта» или контента. Кстати говоря, в Speed Cache эта проблема решена. Если файл был закэширван на стороне клиента, а после этого обновлён на сервере, то при следующем заходе на сайт Speed Cache сообщит браузеру клиента о том, что файл нужно загрузить повторно.

Отмечу, что кэш браузера Joomla может существенно увеличить скорость загрузки сайта, уменьшить трафик и нагрузку на сервер. Плюс, если страница со всем её содержимым закэширована у клиента в браузере, то он сможет ею пользоваться даже без подключения к интернету.

 

Не используйте переадресацию с целевой страницы.

Нужно избегать переадресаций с одного URL на другой. Более одной переадресации – это плохо. Речь идёт о 300-х редиректах (301, 302 и т.д.). С этим можно бороться только «организационными» мерами. Искать и сокращать цепочки переадресаций в файле «.htaccess», компоненте «Перенаправление» (com_redirect) Joomla или сторонних расширениях. Такие цепочки переадресаций могли возникать в результате многократных смен структуры URL-адреса, переноса содержимого станицы с одного URL на другой (смена принадлежности товара в интернет-магазине из одной категории в другую) и т.д.

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

 

Буду рад, если какие-то советы Вам пригодятся и помогут ускорить свой сайт или сократить время ответа сервера Joomla.

 

Полезные ссылки: