Оптимизация темы (шаблона) WordPress для снижения его нагрузки на сервер хостинга, плагин WP Tuner и число запросов к БД. Миллион посетителей на WordPress против сервера

Привет, привет. Зачастую блоггеры и веб-мастера сталкиваются с такой проблемой, что рано или поздно их проекты начинают жутко тормозить. Значительно повышается нагрузка на CPU хостинга, а народные методы вовсе не помогает в решении. И сегодня мне хотелось бы рассказать Вам о том, что делать если тормозит сайт на WordPress и как в этом случае снизить нагрузку на сервер.

В большинстве случаев, значительные подвисания и тормоза сайта начинаются абсолютно нежданно, в связи с чем естественно начинается паника. В состоянии страха блоггеры начинают «ковырять» свой сайт, пытаясь спасти его от этой неприятной проблемы. Но чаще всего такие «спасания» заканчиваются плачевно, вплоть до сноса сайта, без возможности восстановления.

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

Буквально пару дней назад ко мне обратился один блоггер и инфобизнесмен, которого многие прекрасно знают — Дмитрий Зверев , с просьбой посмотреть сильные подвисания его блога. Естественно я согласен, это ведь моя работа, тем более почему бы не помочь хорошему человеку? 🙂

Так вот, Дмитрий скинул мне все данные от сайта и хостинга, и я приступил к анализированию. Представьте, средняя скорость загрузки сайта составляла аж целых 13 секунд.

Жесть, не правда ли? Да что тут говорить, помимо такой «скорости», и доступность сайта хромала, порой сайт открывался через раз. Одним словом он катастрофически зависал и отказывался полноценно работать. А самое интересное заключалось в том, что при авторизации в админ-панели проблем становилось ещё больше!

Это вызвало у меня ещё больше интереса, потому что я никогда не ранее не сталкивался с подобным! «Ну что ж, попробуем, чем тяжелее — тем интереснее» — подумал я, и приступил к работе.

В первую очередь я начал анализировать активированные и смотреть какие из них больше всего нагружают сайт. Анализ я производил через плагин под названием P3. Если кому-то интересно узнать про него подробнее — подписывайтесь на обновления блога. Я обязательно напишу об этом в одной из следующих статей.

Таким образом я обнаружил 2 плагина, которые грузили блог значительнее остальных, это LeadPages и NextGEN Gallery. Но после их отключения и очистки кэша абсолютно ничего не изменилось. И тогда началось самое интересное. Я начал копать всё глубже и глубже, дабы выискать истинную причину сего безобразия 🙂

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

И вот, спустя два дня, и множества попыток, в том числе и абсолютно бесполезных, скорость стала следующей:

И помимо этого, прекратились постоянные сбои в работоспособности и хостеры перестали жаловаться на повышенную нагрузку CPU. Ура! К чему стремился, то и получил — миссия выполнена.

Но что именно я делал и как мне удалось одержать победу? Давайте по порядку.

Снижение нагрузки на сервер

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

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

2. Зачастую тормоза появляются из-за скрипта под название WP-Cron . Данный скрипт, встроенный в WordPress отвечает за планирование задач. К примеру, размещение статей по времени, автоматическая чистка корзины, создание резервной копии с помощью плагина и т.д.

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

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

Так вот, для отключения WP-Cron существует несколько способов. Дело в том, что какой-то из них (как было в моем случае) может не заработать, а другой вполне.

1 способ. Переходим в корень Вашего сайта по Ftp, например через FileZilla, и открываете там файл под названием wp-config.php и добавляем новую строчку:
Define(‘DISABLE_WP_CRON’, true);
Желательно добавить её после строки:
Define(‘WPLANG’, ‘ru_RU’);
После чего сохраняете файл и радуетесь, скрипт должен отключиться.

Но если этого не произошло, то необходимо воспользоваться следующим вариантов.

2 способ. Опять же, в корне сайта необходимо открыть файл под название wp-cron.php , найти строчку:
Ignore_user_abort(true);
и закомментировать её (отключить) с помощью двух слэшов. На выходе должно получиться вот так:
//ignore_user_abort(true);
Сохраняем файл и cron отключается.

3. Далее, необходимо включить zlib компрессию , которая позволяет значительно ускорить сайт за счет обработки и сжатия php кода. В первую очередь Вам необходимо написать хостеру и узнать включен ли у Вас функция zlib или же нет. Если подключена — отлично, если же нет — просим включить. После чего переходим в файл header.php и в самый самый верх вставляем следующий код:

Сохраняем файл и ощущаем значительный прирост в скорости.

4. После чего очень важно оптимизировать БД с помощью плагина . Переходим в админ-панель, открываем вкладку «Плагины» — «Добавить плагин» и в поиске вбиваем «WP-Optimize», нажимаем Enter и устанавливаем первый плагин.

Теперь наша база данных оптимизирована, а это ещё один плюсик в сторону ускорения сайта.

5. Теперь наша задача защитить блог от Ddos-атак , т.к. именно такие атаки зачастую и становятся причиной «сноса мозгов» сайта. Для этого, во-первых, я рекомендую установить плагин под названием iThemes Security, про его настройку я расскажу в следующей статье, а во-вторых, важно использовать блокировку подозрительных посетителей с помощью .htaccess .

Я не буду сейчас объяснять как выискивать таких подозрительных и вредоносных , потому что это тема отдельной статьи, а поделюсь с Вами списком IP-адресов, которые я сумел собрать за некоторое время. Именно их и нужно будет заблокировать.

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

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

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

Для начала вам нужно будет получить доступ по FTP к файлам вашей темы оформления. Они находятся в папке:

/wp-content/themes/название_вашей_темы_оформления

Начнем с уже упомянутого выше — HEADER . Думаю, что с Файлзилой вы уже знакомы и доступ по ФТП к хосту для вас не в новинку. Если нет, то вверху есть окно поиска и достаточно будет ввести туда слово «файлзила» или «нотепад», чтобы получить самую полную информацию по этим двум архиполезным программам.

В HEADER реализовано достаточно много обращений к базе данных, которые спокойно можно заменить на статичные данные или же вообще удалить. В самом верху вы, наверняка, увидите следующий участок кода:

; charset=" />

Нет, удалять его, конечно же, не надо, но вот немного видоизменить, убрав не нужные обращения к БД, можно:

Ну вот, два запроса в минус — пустячок, а приятно. Дальше — больше. Что еще можно заменить или удалить в HEADER? Давайте перечислим:

Удалить строку с информацией о номере установленной версии WordPress . Она не несет никакой полезной нагрузки и, более того, является опасной, т.к. некоторые варианты взлома применимы только к определенным версиям, а из этой строки как раз очень удобно узнавать текущую версию вашего движка. Выглядит эта строка обычно так: " />
Заменить URL до вашего файла таблицы стилей CSS в вашей текущей теме оформления на статический. В коде это строка: " type="text/css" media="screen" />

WP Tuner устанавливается на WordPress стандартным способом, а именно:

распакуйте архив, используя ftp-менеджер подключитесь к вашему блогу и загрузите папку wptuner в папку с плагинами wp-content/plugins/ на сервере хостинга
войдите в админку и выберете вкладку «Плагины»- «Inactive»
найдите строку с плагином WP Tuner и активируйте его

Если при установке плагина WP Tuner у вас возникли какие-либо затруднения, то можете обратиться к материалам статьи, про решение возможных проблем с установкой плагинов. Теперь можно зайти в админку и ознакомиться с настройками этого расширения (из левого меню выбрать Параметры -> WP Tuner.

Собственно, настроек у WP Tuner не так уж и много, к тому же для того, чтобы данный плагин начал показывать количество запросов к БД при загрузке страницы, вообще ничего менять не надо. Нужно просто зайти на блог, но при этом нужно, чтобы вы были под логином администратора, и открыть какую-либо страницу.

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

Обычные посетители блога, естественно, этого безобразия, внесенного WP Tuner, видеть не будут, только администратор, т.е. вы.

Но посмотреть число запросов к базе в WordPress можно и не прибегая к услугам плагинов . Для этого нужно получить доступ к файлам вашего блога по FTP и открыть на редактирование, например, файл:

/wp-content/themes/название_вашей_темы_оформления/footer.php

и где-нибудь в его содержимое нужно вставить следующую конструкцию (место вставки будет определять область вывода числа запросов к БД в футере):

queries in seconds.

В результате после загрузки страницы, в самом низу (в области подвала), вы увидите, сколько при этом было сделано обращений к БД:

Удачи вам! До скорых встреч на страницах блога сайт

посмотреть еще ролики можно перейдя на

Вам может быть интересно

Пропало левое меню в админке WordPress после обновления
Создаем для блога на WordPress кнопки добавления в социальные сети и закладки (без плагинов и скриптов)
Снижение потребляемой в WordPress памяти при создании страниц - плагин WPLANG Lite для подмены файла локализации Смайлики в WordPress - какие коды смайлов вставлять, а так же плагин Qip Smiles (красивые смайлики для комментариев) Как автоматически добавить атрибут Alt в теги Img вашего блога на WordPress (там, где их нет)
Hyper Cache - включаем плагин кэширования в Вордпресс для оптимизации WP блога и снижения его нагрузки на сервер хостинга

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

Такой поворот событий для меня не был неожиданностью и возможную причину знал заранее. После запроса логов у хостера догадки подтвердились. Ко всем сайтам на аккаунте подбирались пароли к админке WordPress.

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

Брутфорс – это и есть подбор пароля и логина путем перебора множества вариантов. В результате таких манипуляций растет количество запросов и увеличивается нагрузка.

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

Как уменьшить нагрузку на сервер с WordPress?

Самые вкусные файлы для взломщиков wp-login.php и wp-config.php. Для уменьшения нагрузки на сервер им необходимо уделить особое внимание, а для защиты админки следует присмотреться к следующим способам.

Первый способ. Закрыть полный доступ к wp-login.php для всех IP адресов, кроме вашего. Для защиты достаточно внести изменения в файл.htaccess. То есть доступ к админке будет разрешен только вам, у остальных будет выкидываться ошибка.

Этот очень простой способ для меня не самый удобный. Дело в том, что при подключении к интернету мне дается новый IP и для входа в админку сайта требуется сначала зайти в админку хостинга, внести мой новый IP в.htaccess и только потом перейти на блог.

Второй способ. Спрятать файл wp-login.php. Этот способ оказался для меня идеальным.

1. Переименовываем название файла wp-login.php в, например, 45jkdsf234.php . Искать файл нужно в корне сайта, корректировать либо через админку хостинга либо через .

2. Заменяем все встречающиеся слова wp-login.php на переименованные, в моем примере на 45jkdsf234.php . Изменения нужно внести в старый файл wp-login.php , который сейчас называется 45jkdsf234.php и в wp-includes/general-template.php .

Теперь вход в админку будет осуществляться не по адресу ваш-сайт/wp-login.php , а по адресу ваш-сайт/45jkdsf234.php .

3. Добавить в.htaccess перед # END WordPress такой код:

В результате у меня получился такой.htaccess:

Третий способ . Использовать плагин Login LockDown, который предотвращает попытки подбора пароля. Установка плагина банальная, поставил и забыл. По умолчанию имеется 3 попытки войти в админку в течение 5 минут, при неудачных попытках происходит блокировка по IP на 1 час.

Мне очень не хотелось ставить Login LockDown, обычно я подбираю пароль к админке раза с 5-го. Но что сделаешь, придется тренировать память, лучше так, чем постоянные взломы.

Вот так выглядит график нагрузки до и после подбора пароля:

Период взлома отчетливо виден по резким скачкам графика.

Что не помешает сделать вебмастеру для снижения нагрузки WordPress на сервер

По максимуму обезопасить админку позволит следование базовым правилам по соблюдению безопасности:

На админку стоит поставить сложный пароль;
Поменять логин admin на другое название;
В FTP-клиентах не хранить пароли и логины;
Регулярно делать back up файлов вордпресс и базы данных mysql. Про создание автоматической резервной копии базы .

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

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

На самое сладкое видео с заманчивым названием.

Почти все мои сайты работают на самописных движках, но до недавнего времени один из них все еще сидел на столь распространенном сейчас wordpress. Дело в том, что изначально wordpress был установлен из-за удобства освоения админки человеком ведущим этот сайт (не мной). Но после выхода линейки версий 2.8 я понял, что это уже не дело…

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

Я испробовал на локали большинство готовых блоговых движков и пришел к неутешительному выводу:
ни один из них (!) даже при наличии импорта из wordpress, не мог предоставить той же структуры ЧПУ (и уж тем более в автоматическом, интуитивном режиме), а это значит при переходе -> 301 редирект и непонятно какая реакция со стороны ПС в плане существующих позиций.

В итоге получилось как всегда: посмотрел сорцы wordpress, импортнул данные из существующей БД, написал небольшое подобие CMS.

Нагрузка: на MySQL снизилась в среднем в 10 раз, на проц — в 2 раза. Думается мне, что здесь есть еще где развернуться в плане оптимизации, но согласитесь даже это уже показательный результат!

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

15 Комментариев

1
Мысли хорошие, но они есть у всех. Хотелось бы прочитать вазможное решение проблем с разгрузкой БД изменяя параметры движка
2
Основное направление в существенной оптимизации wordpress - кеширование на стороне сервера. Почитать это вы, я думаю, сможете в других многочисленных блогах. У меня же сейчас нет ни одного сайта, построенного на wordpress, и соответственно я не могу описать решение проблем с оптимизацией.
3
Всегда в сети говорили, что ВП лёгкий, и я верил, хоть и использую по жизни Drupal. Потом в сентябре у меня появился заказчик, с желанием «Съехать с этого глючного ВП нах на друпал». Оказалось следующее:
1. Сайт крутился на VPS 500Mhz и 384 рамы
2. Посещаемость около 1000 хитов в сутки.
3. Включены все мыслимые и немыслимые кеши.
Вся эта система стабильно раз в сутки падала, в остальное время безбожно тормозила. Начался суровый и кропотливый процесс переезда на друпал, в итоге:
1. Все материалы перетянули.
2. Где урлы устраивали, оставили их, где не устраивали, сделали новые урлы, на старые 301 редирект.
3. Переехали абсолютно без потерь. С той же функциональностью, а в некоторых местах даже больше.
Сейчас загрузка сервера по процессору в самые жесткие моменты, когда приходит Гоша и Яша не превышает 30 процентов, с отключенным кешированием.
Так что, подумайте о друпале, не так он хренов, как все говорят.
Вот пациент - surlaterre.ru
4
Ничего против Друпала не имею, хорошая система. Основная моя претензия - в современных движках нет простой системы переезда с другой CMS с сохранением старой системы ЧПУ.
5
Если взять тот же переезд с ВП, то существующий модуль переносит вместе с ВП-шными урлами, но я переносил своим модулем, у меня несколько иначе было всё
6
Если тот или другой модуль сумеет перенести любой вид адреса, который можно создать с помощью стандартных средств Wordpress - честь и хвала ему, +1 к друпалу, но когда я искал подобное среди движков ничего не нашел или находил, но реализовано было далеко не все.
7
В общем могу сказать: «Ничего не переносимого нет», если тема интересна, то велком в аську/почту/скайп. Контакты на моём сайте
8
Не знаю как у вас был настроен WordPress, сервак и кеши. Но у меня на обслуживании стоят сайты на WP у которых на виртуалках посещалка 4000 в сутки и ни каких проблем. Есть сайты с посещалкой на 10 000 в стуки, но на приватах. Там нагрузка не превышает 10% в пиках. Так что WP рулит еще как!
9
Я сейчас осваиваю MovableType. Эта CMS несмотря на необычность (используется perl, генерит статические html), очень легкая и достаточно функциональная. Быстрее WP в разы.
10
MovableType хорош, но информации на русском о нем все же мало.
11
Я лично вообще не могу разобраться какая там эта нагрузка. У меня крупных проектов WP ни когда не было и проверить я это сам не могу. А где бы я ни почитал, дак ни чего не поймешь одни говорят wp-рулит, другие говорят что фигня движок. А вообще какая все таки нагрузка и и какую wp может выдержать я ни где не встречал. Остается один вопрос почему тогда wp по зоне ru находится на лидирующих позициях?Может из-за своей простоты?

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

нам приходят на помощь дополнительные инструменты под названием плагины - рабочие лошадки, помощники в работе наших блогов. Что бы мы без них делали? Чтобы улучшить и ускорить загрузку блога, установим простенькие плагины для для оптимизации и ускорения загрузки блога. В сегодняшней статье установим плагин для чистки территории блога WP -Optimize. Как устанавливать плагины,

Плагины для оптимизации wordpress
1 - WP-Optimize помогает оптимизировать базу данных и таблицы сайта. Это обязательно - необходимый плагин.
Функции WP - Optimize:

Конкретно чистит наш ресурс от всяческого мусора.
Оптимизирует - сжимает базу данных блога и таблицы.
Удаляет все резервные копии записей, когда мы ставим статью на блог и по несколько раз редактируем один и тот же пост, также весь опубликованный контент.
Удаляет спам комментарии.
Не конфликтует с другими плагинами.
Просто и стандартно устанавливается на блог.
Входим в админку
Плагины
Добавить новый
В поисковой строке вписываем название WP-Optimize
Устанавливаем
Активируем

Далее еще проще: В меню слева ищем по названию WP-Optimize, заходим в настройки, видим фото людей, которые отблагодарили лайком.
Жмем лайк Нравится - отправляем на Фейсбук, лайк не отправите, плагин будет молчать и работать не начнет. Как немой и глухой ничего не слышит, так и этот плагин будет бездействовать. Со мной такая история

приключилась при установке, пока я не догадалась отправить лайк. Пока вы не отправите благодарность разработчикам плагина, плагин работать не будет. Закон Вселенной: для того, чтобы что - то получить, вначале нужно самому что - то дать. Другая аксиома: не сделав добра, не жди обратного. Далее смотрим такой скриншот

Обратите внимание на выделенное красным, посмотрите напротив на количество килобайтов, опуститесь в самый низ - здесь общая сумма мусора в Kb.
Перед тем, как чистить блог, зайдите в комментарии, вполне вероятно, что пара - тройка хороших комментов попала в спам: бывает, что дедушка

Акисмет переусердствовал - он же надежный охранник блога от спамщиков, загнал несколько комментариев для подстраховки в спам - папку. Отрабатывает свой хлеб. :)
А теперь можно чистить. Ставим во всех пунктах чебоксы - птички и жмем слово PROCESS.

Почистили, радуемся генеральной чистоте. Все, что было выделено красным, приобрело синий цвет. Вам сообщают: Полное оставленное свободное место: 33.105 Kb. Не много, не мало, территория чистая. Оптимизация блога прошла успешно.

После чистки плагин деактивируем и один раз в 5 - 7 дней чистим территорию блога.
2. Следующий плагин классический, который не нужно настраивать - по умолчанию он сам знает свои функции от а до я. Для этого постарался автор плагина Макаров, а плагин я нашла на сайте Дмитрия Сидаш sidash.ru/ у которого очень часто прогуливаюсь в поисках интересной и полезной информации. Заходите и вы - многое для себя почерпнете.

SSD Optimize WordPress - данный рабочий инструмент я выделяю из огромной дивизии плагинов полезных, малополезных, не очень полезных, но создающих хорошую нагрузку для сервера и блога. Разгружает от лишнего трафика и несвоевременнных запросов хостинг, на ходу оптимизирует загрузки AJAX библиотек, отключатся ненужные функции, сильно нагружающие систему и в то же время не нарушает работоспособность нашего блога.

Какую пользу имеем от этого плагина:

Отключает проверки обновлений тем, плагинов, движка
Отключает автосохранение редактируемой записи
Включает автоматическую оптимизацию и восстановление Базы данных
Отключает ревизии постов
Отключает генераци метатегов
Подгружает AJAX библиотеки с сайта google, для пользователей
Снижаем нагрузку на сервер благодаря плагину
Семь функций защищают сайт от спама
Запрет в комментариях активных ссылок

Устанавливается аналогично всем плагинам.

Домен не исчез, сайт на месте, но этого плагина нет. Ссылки на разные темы... При нажатии на ссылку автора появляется запись:

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

Появился сайт в сети, даже не знаю - когда, но почему - то сейчас находится в АГС. Ссылка будет здесь неактивной http://makarou.com/ssd-optimize-wordpress-5-0. Как скачать данный плагин: Выделяем ссылку http://makarou.com/ssd-optimize-wordpress-5-0, копируем, вставляем в адресную строку. Но выше цитаты ссылка активная, скачивайте и устанавливайте.