И все таки Autoptimize…

И все таки плагин Autoptimize сослужил мне плохую службу, несмотря на  лестные отзывы о нем. Теперь я с определенной степенью уверенности могу сказать, что проблемы, связанные с очень длительной загрузкой страниц сайта и работы в админке были обусловлены с недостатками именно этого плагина.

И ничто другое –  ни постоянное “нашествие” ботов, никакие другие плагины, установленные на моих сайтах, ни медленные запросы к базе данных и связанные в связи с этим временные, но высокие нагрузки на CPU сервера,  ни подобранные темы к блогам не могли так сильно препятствовать загрузке страниц. Причина крылась в другом…

Почему я деактивировал плагин Autoptimize

Подозрение постоянно падало на плагин Autoptimize и вот почему. Дело в том, что познакомился я с этим плагином на одном из сайтов, где автор подробно рассказал о назначении плагина и  принципах его работы. Плагин понадобился мне после того, как ПС Google все настойчивее стала требовать и пояснять свои требования с помощью сервиса PageSpeed Insights: скорость загрузки и рекомендуемые меры по устранению проблем – сжатия файлов и скриптов… А еще удобство для просмотра сайта на мобильных устройствах. Ну, кто из вебмастеров сейчас не знаком уже с этими рекомендациями в Вебмастере Гугла?

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

Нет, я ничего плохого про этот плагин сказать не могу и, возможно, проблему с его “содействием” можно было решить совершив некоторые действия. Каждый вебмастер, как оказалось, столкнувшись с проблемой после установки этого плагина, решает проблемы по разному – так как проблемы тоже бывают разные. Кто-то заменив тему сайта на более простую,  решает проблему. Кто-то после того, как “упал” счетчик Я. Метрики, добавил в настройках в исключения запись в специальном окне. Кто-то, заметив, что если не чистить кэш – то кэшированные стили и JS в скором времени съедают много места. Решил проблему так: “настроил на сервере VPS крон очистки папки кэша Autoptimize и тем избавился от проблем”.

Сам автор изученной статьи, после не длительного его использования, все же удалил плагин.  Не сразу, но после того как обнаружил, что в работе плагина есть проблемы, в обновлении статьи добавил  “его [плагин] пришлось удалить, потому что он создает лишние загрузки. Например, если у вас есть динамичный скрипт на странице, то плагин будет создавать сборную копию скриптов для каждого измененного скрипта. В итоге получается чуть ли не отдельный огромный js файл для каждой страницы. Можно с этим бороться исключениями динамических скриптов в настройках плагина, но это муторно… Буду искать другой подобный плагин. Вам рекомендую поставить этот плагин, и по прошествии пары дней, зайти в настройки и посмотреть сколько там файлов в кэше, если мало, то все отлично, если много (100+), то рекомендую его удалить”.

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

Не мудрствуя лукаво, я решил уже окончательно отключить плагин Autoptimize. Сначала сделал это на одном из пары моих сайтов на движке WordPress. Проблема осталась. Отключение плагина на обоих доменах принесло удачу: страницы стали грузиться нормально. При этом нагрузка на CPU в сравнении с предыдущими днями и неделями, не претерпела особых изменений. По прежнему наблюдаются всплески превышения мягкого лимита.

Картинки наглядно показали, что кратковременное превышение мягкого лимита нагрузки на CPU вовсе не являются причиной огромных затруднений работы с сайтом. Причина выяснилась: во всем “виноват” плагин  Autoptimize.

Не выясняя “глубинных” причин торможения работы моих сайтов из-за плагина Autoptimize,  теперь я просто его удалил. Благо, есть другие подобные плагины. Сейчас по совету одного из комментаторов, установил плагин Better WordPress Minify и тестирую его. Пока все проходит удачно.