sonyps4.ru

Оптимизация WordPress. Нагрузка на сервер и как ее снизить

Из этой статьи вы узнаете как значительно ускорить сайт на WordPress с использованием Memcached.
Пошаговая инструкция

Memcached - система распределенного кэширования памяти
Memcached кэширует данные и объекты прямо в память RAM и сокращает время доступа к внешнему ресурсу (например, вызовы БД или API-вызовы). Это особенно помогает динамическим системам, таким как WordPress или Joomla!, заметно ускоряя время обработки запроса.

Важно: перед началом хотим заметить, что Memcached не имеет встроенных мер безопасности для работы на shared-хостинге! Данная инструкция подходит только для выделенного сервера (VPS).

Установка Memcached

На нашем сервере используется Plesk с CentOS 7.x. Тем не менее, это руководство применимо и к другим системам, однако при выполнении следующих операций нужно использовать утилиты, специфичные для определённых систем (например, apt-get вместо yum). Для того чтобы установить Memcached, в первую очередь следует подключиться к серверу по SSH и использовать командную строку:

# yum install memcached

После завершения установки вводим следующую команду:

# service memcached start

Далее следует установить PECL-версию Memcached для нужной версии PHP. WordPress полностью совместим с PHP 7, поэтому давайте активируем Memcached для последней версии PHP - 7.1. Начнём с установки всех необходимых пакетов для добавления их к нашему кастомному PHP-модую в Plesk:

# yum install make plesk-php71-devel gcc glibc-devel libmemcached-devel zlib-devel

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

/opt/plesk/php/7.1/bin/pecl install memcached

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

# echo "extension=memcached.so" > /opt/plesk/php/7.1/etc/php.d/memcached.ini

И наконец, перечитайте обработчики PHP, чтобы модуль отобразился в информации о PHP в графическом меню Plesk.

# plesk bin php_handler -reread

Теперь Вы можете вызвать страницу phpinfo(), чтобы проверить корректную загрузку модуля Memcached:

Либо используйте командную строку:

# /opt/plesk/php/7.1/bin/php -i | grep "memcached support"

Защитите и контролируйте ваш Memcached

Memcached по умолчанию использует порт 12211.Из соображений безопасности можно перенаправить данный порт на локальную машину.
Добавьте следующую строку в конец файла /etc/sysconfig/memcached и перезагрузите службу Memcached:

OPTIONS="-l 127.0.0.1"

Для мониторинга и получения статистики от Memcached используйте следующие команды:

echo "stats settings" | nc localhost 11211
/usr/bin/memcached-tool localhost:11211

Активируйте Memcached в WordPress

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

Скачайте скрипт с https://github.com/bonny/memcachy и переносите все файлы в директорию /wp-content/.

Если Вы не меняли порт Memcached по умолчанию (11211), Вы можете использовать его напрямую. Если вы изменили его, то в файл wp-config.php, лежащий в корневой директории вашей установки WordPress, следует добавить следующий код:

$memcached_servers = array(array("127.0.0.1", 11211));

Теперь, когда активирован бэкенд, мы установим кэширующий плагин для сохранения и предоставления обработанных страниц через Memcached. Установите плагин Batcache (https://WordPress.org/plugins/batcache/) используя инструкцию по установке:

  1. скачайте и разархивируйте архив;
  2. загрузите файл advancaed-cache.php в директорию /wp-content/;
  3. откройте wp-config.php и добавьте следующую строку:
  4. define("WP_CACHE", true);

    Важно: убедитесь, что Memcached для выбранной версии PHP включён корректно, иначе добавление этой строки вызовет ошибку!

  5. загрузите batcache.php в директорию /wp-content/plugins.

Вот и всё! Теперь можете открыть advanced-cache.php и отрегулировать настройки по вашему усмотрению. Файл batcache.php - это небольшой плагин, который регенерирует кэш на статьях и страницах. Не забудьте активировать плагин в бэкенде на странице плагина!

Проверьте правильность работы Memcached в WordPress

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

Чтобы это сделать, нужно изменить файл advanced-cache.php. Откройте его и найдите строку

var $headers = array();

Замените её на:

var $headers = array("memcached" => "activated");

Откройте инструменты разработчика в своём браузере (F12 для Crhome), выберите вкладку «Network» и перезагрузите страницу несколько раз, чтобы быть уверенным, что страница грузится из кэша, и проверьте ответные заголовки. Если вы видите поле memcached - у уас всё получилось!

Обратите внимание, если вы вошли (залогинились) в административную панель сайта на WordPress, кэширование не будет задействовано и система всегда будет отдавать незакэшированную версию страницы. Каким образом проверить функциональность кэша в этом случае? Разлогиньтесь или откройте новую вкладку браузера в режиме «Инкогнито» и используйте инструменты разработчика в браузере.

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

Проведём стресс-тест вместе с Blitz.io

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

Давайте запустим некоторые тесты на загрузку и производительность с помощью сервиса Blitz.io.
Отметим: для этого стресс-теста использован небольшой сервер с одним CPU и 500Мб памяти.


Стресс-тест без использования Memcached

Результат БЕЗ использования Memcached:

Результат такой же, как у стресс-теста Varnish. Как видите, пришлось прекратить стресс-тест, так как сервер не смог обрабатывать запросы быстрее 5 секунд при 50 одновременных подключённых пользователях. Всего лишь через 15 секунд сервер полностью перестал отвечать на запросы.


Стресс-тест WordPress и включённый Memcached

Как видите, Memcached позволяет сохранять стабильность работы сервера даже под высокой нагрузкой. Маленький тестовый сервер выдержал болше 400 одновременных запросов и дольше 50 секунд без каких-либо ошибок. После 50 секунд и почти 450 одновременных пользователей сервер всё-таки перестал принимать дальнейшие запросы. На более мощной конфигурации эти цифры были бы значительно выше.

Таким образом, использование Memcached - отличная идея для тех, кто хочет большей устойчивости к нагрузке. При помощи этой системы даже можно обезопасить сайт от небольших атак. Для защиты сервера от настоящей ДдоС-атаки (Distributed Denial of Service - атака на отказ в обслуживании) следует использовать сервис CloudFlare, Куратор или аналогичные системы фильтрации.

Заключение: WordPress отлично работает с Memcached

Memcached может значительно улучшить производительность сайта на WordPress и снизить нагрузку на CPU вашего сервера. Он прост в установке и работает «из коробки».

Перевод: Антон Ларгин (Русоникс)
Оригинал.

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

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

Проблема в wp-cron.php

wp-cron.php периодически запускает на сайте различные задачи: проверяет обновления WordPress и установленных плагинов, публикует запланированные посты, рассылает уведомления о новых комментариях и прочих событиях и т.д. Проблемы с wp-cron начинаются зачастую на виртуальных серверах, которые имеют ограничение на количество используемых системных ресурсов. В итоге создается экстремальная нагрузка на сервер.

Определив, что источником нагрузки является wp-cron.php, его можно отключить, добавив в файл wp-config.php строчку:

Define("DISABLE_WP_CRON", true);

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

Wget http://ваш_сайт.ру/wp-cron.php?doing_wp_cron > /dev/null

Проблема в xmlrpc.php

В WordPress есть скрипт xmlrpc.php, он отвечает за вызов удаленных процедур и поддерживает известные API - WordPress API, Blogger API, MetaWeblog API и MovableType API. С помощью этого файла можно удаленно публиковать посты на своем сайте или полностью им управлять, не обязательно через административную панель. И как раз таки частые запросы к XMLRPC могут вызывать чудовищную нагрузку, что очень эксплуатируется на практике.

Если Вы вообще не используете в своей работе XMLRPC (а этого наверняка Вы не делаете), то можно просто удалить из корня своего сайта файл xmlrpc.php. А чтобы боты не грузили 404 страницу, в.htaccess добавляем редирект на microsoft.com (сервера у них хорошие):

Redirect /xmlrpc.php http://www.microsoft.com

Проблема в wp-login.php

wp-login отвечает за авторизацию на сайте WordPress. Слишком частое к нему обращение, например, в целью подобрать пароль администратора, что осуществляется программно, вызывает сильную нагрузку. Избежать нагрузок можно, заменив это стандартное имя. Сделать это можно множеством способов, вот пример с плагином и без плагина.

Защита wp-login.php без плагина

в.htaccess добавляем:

Order Deny,Allow Deny from all

Файл wp-login.php, переименовываем в секретное имя, например cudanelza.php и внутри файла меняем все надписи wp-login.php на cudanelza.php.

Теперь у нас wp-login.php стал cudanelza.php

Защита wp-login.php с помощью плагина Lockdown WP Admin

Плагины - Добавить новый - ищем "Lockdown WP Admin". Ставим, активируем, переходим в настройки. Напротив "Yes, please hide WP Admin from the user when they aren"t logged in" ставим галочку. В разделе WordPress Login URL прописываем новый адрес админки, например, "parapara". Сохраняем настройки. Теперь наша админка доступна по адресу http://сайт.ру/parapara

Проблема в sitemap

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

Вот как выглядят дефолтные (по умолчанию) настройки XML карты сайта в плагине All in One SEO. В XML карту попадают все типы записей, которые там вообще не нужны:

Дефолтные настройки XML карты сайта в плагине All in One SEO

Именно дефолтные настройки XML карты сайта были частой причиной нагрузки на сервер, вызываемой поисковыми ботами и пауками.

Данная проблема решается в несколько этапов:

1. Настройте sitemap.xml таким образом, чтобы сюда попадали исключительно ссылки на страницы/записи вашего сайта

2. В robots.txt пропишите директиву

Crawl-delay: 10

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

3. Блокируйте ненужных Вам роботов. В статье вы найдете действенные методы блокировки ненужных ботов и пауков

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

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

Вконтакте

Оцените материал:

Приветствую всех читателей блога сайт. Рано или поздно перед каждым автором блога на WordPress возникает вопрос - Как снизить нагрузку на сервер? Кто-то задумывается об этом заблаговременно (обладая знаниями), а другие (новички) когда начинают приходить письма «счастья» от хостера. Становится ещё печальнее когда периодически начинает происходить отключение блога за превышение лимитов.

Со мной подобная история произошла в 2010 году. Посещаемость на моём первом блоге наконец-то появилась, медленно и уверенно подрастая. Радоваться долго не пришлось. Вскоре со мной произошло именно то, о чём я описал выше.

Все замечательно, все понравилось, кроме цены - 30 $. Тогда он стоил именно столько.

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

И вот настал день когда я впервые, вместо одного из вордпрессовских плагинов для кеширования, установил MaxCache. В 2013 году делая блог о спутниковом телевидении, я решил использовать для кеширования блога именно его.

Поюзал два дня бесплатную лайт-версию, укрепился во мнении, что иду правильным путём, и приобрёл платную Full-версию.

Теперь, когда я делаю кому-либо блог, или запуская что-то своё, не задумываясь, устанавливаю для кеширования блога MaxCache.

Как видите, и на этом блоге для снижения нагрузки на сервер стоит именно он. На сегодняшний день цена MaxCache составляет 10 $.

Алгоритм работы - как MaxCache снижает нагрузку на сервер

Для наглядности сделал скриншоты с футера главной страницы сайт создаваемой нагрузки на сервер до использования скрипта кеширования, и после подключения MaxCache.

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

Открываете файл footer.php вашей темы, и вставляете следующий код перед закрывающимся тегом .

WordPress: " . round(memory_get_usage()/1024/1024, 2) . "MB " ." | MySQL:" . get_num_queries() . " | "; timer_stop(1); echo "sec

";?>

echo "

WordPress: "

Round (memory_get_usage () / 1024 / 1024 , 2 ) . "MB "

. " | MySQL:" . get_num_queries () . " | " ;

timer_stop (1 ) ;

echo "sec

" ; ?>

Запросов к MySQL Скорость генерации страницы Без скрипта 11.68 MB 31 0,68 С MaxCache 0.82 MB 0 0,00025

Нагрузка на сервер снизилась более чем в 14 раз!

Количество обращений к базе данных при использовании скрипта нулевое!

Скорость генерации страницы увеличилась в 2720 раз!

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

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

Кеш страниц сбрасывается каждые 4-е часа. При желании можно указать собственные настройки.

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

Имеется возможность включения gzip-сжатие трафика. Увеличивает скорость загрузки «тяжёлых» страниц. Включение gzip-сжатия даёт дополнительную нагрузку на сервер. Включать или нет эту функцию нужно принимать решение исходя из наличия лимитов по нагрузке CPU. Перед включением gzip-сжатия нужно уточнить у хостера поддерживается ли эта функция сервером.

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

Результаты для главной страницы получились следующие.

До сжатия вес моей страницы был 23,7 KB, после компрессии 6,5 KB. Экономия составила 72,4%. Как говорится - Без комментариев. Сервис проверки работы gzip-сжатия находится по этому адресу - http://www.whatsmyip.org/http_compression/ .

Также в отдельном файле в настройках скрипта можно задать список страниц с запретом на кеширование. При выходе новой версии скрипта, обновление для всех клиентов бесплатное.

В завершение статьи, хотелось бы подчеркнуть, что мне нравится подход автора скрипта к его продажам. После оплаты MaxCache покупатель получает Lite -версию скрипта. Эта версия с ограниченным функционалом. Отличается она от Full-версии, тем, что кеш не сбрасывается на автомате. То есть урезанная версия работает, практически так же, как и полная. На тестирование автор выделяет две недели времени. Далее, вы или отказываетесь от приобретения, и автор возвращает вам деньги либо отправляете заявку на получение full-версии MaxCache.

Я при покупке этого девайса для снижения нагрузки на сервер попросил выслать мне сразу полную версию, так как давно уже знаком с работой скрипта и доволен его работой. Для блога на WordPress MaxCache идеальное решение.

Вконтакте

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

Итак, для начала давайте разберем принцип работы движка на основе PHP+MySQL.
Когда пользователь обращается к какой-то странице сайта, на сервере (при помощи специального серверного языка или просто PHP) идет обращение к так называемой базе данных, которая содержит в себе всю информацию. Затем нужная информация вытаскивается и формируется статическая HTML страница.

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

Оптимизация блога WordPress при помощи кэширования страниц. Плагин Hyper Cache и его настройка.

Оптимизация WordPress при помощи данного метода состоит в том, что при обращении к страницам сайта, как обычно, генерируется статическая html страница. Разница лишь в том, что она сохраняется в КЭШе. При следующем обращении к этой странице вместо того, чтобы генерироваться заново, она просто берется из КЭШа. Это позволяет значительно уменьшить число запросов к базе данных и как следствие уменьшить нагрузку на сервер.

Итак, первым делом нам нужно скачать и установить плагин Hyper Cache. Для этого переходим на официальный сайт WordPress и скачиваем последнюю версию плагина. Далее копируем файлы в папку \wp-content\plugins\ и активируем плагин через административную панель. Для этого переходим в административную панель — плагины и активируем Hyper Cache.

После установки и активации плагина, переходим к его настройке. Точнее для начала нам нужно активировать кэширование в самом WordPress. Для этого нам придется редактировать файл wp-config.php и вставить в него строку

Define("WP_CACHE", true);

Лучше это делать ближе к концу файла, но не дальше строк

If (!defined("ABSPATH")) define("ABSPATH", dirname(__FILE__) . "/");

Затем нам необходимо соединиться с сервером и выставить права доступа 777 для папки wp-content. В принципе можете поставить эти права на саму папку с КЭШем. После этого переходим в административную панель\параметры\Hyper Cache и активируем его. Затем переходим к самим настройкам кэширования.

  • Время жизни кэшированных страниц – устанавливаете время, которое будет существовать страница в КЭШе. То есть после обращения к статье WordPress кэширует эту страницу и сохраняет ее. От значения, которое вы здесь установите, будет зависеть время существования этой страницы, до ее удаления или обновления. Можете ставить по своему усмотрению. Обычно чем дольше, тем лучше.
  • Автоочистка – данная функция проводит проверку КЭШа на наличие записей с истекшим сроком. Если такие находятся, то они удаляются. Благодаря этому вы можете быть спокойны, что у вас не будет накапливаться мусор, который может весить довольно много, что в свою очередь приведет к уменьшению свободного пространства на диске. Значение можете подбирать индивидуально. Вполне подойдет 1440 минут.
  • Как очищать кэш – ставим значение «Single pages». На мой взгляд, это оптимальный вариант. В этом случае при внесении изменений кэш будет обновляться только для тех страниц, которые были редактированы. Остальные же останутся нетронутыми. При большой посещаемости это имеет смысл, так как если бы каждый раз, когда вы редактировали статью, очищался бы весь кэш, то это бы создало огромную нагрузку на сервер.
  • Не кэшировать домашнюю страницу – можете поставить галочку, если не хотите, чтобы сохранялась главная страница. Данная опция имеет смысл, если у вас очень часто обновляется главная страница вашего блога. В принципе ставим по желанию. Лично у меня эта опция включена.
  • Исключить URI – сюда можно вписать адреса страниц, которые вы хотите исключить с КЭШа.

Это были основные настройки плагина Hyper Cache. Для того, чтобы проверить его работоспособность, заходим на наш сайт как незарегистрированный пользователь и смотрим исходный код страницы. В конце должна присутствовать такая строка.

Если она есть, то плагин работает нормально.

Снижение нагрузки на сервер за счет кэширования запросов к базе данных.

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

Настройки этого плагина очень просты и приводиться не будут. Там все интуитивно понятно. Единственное, что могу предложить, это добавить в footer.php код, который будет выводить информацию о количестве запросов к базе и время загрузки страницы.

Для этого открываем на редактирование файл footer.php и где-то в конце добавляем код

queries in seconds.

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

Естественно можно поиграть со стилями, перевести «queries in» и «seconds», но это по желанию. Лично меня и так все устраивает.

Оптимизация шаблона WordPress

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

Оптимизация header.php

1. Находим код

и меняем его на название своего блога. У меня это

Сайт - создание и продвижение сайтов, блогов, заработок на сайте.

2. Код, отвечающий за вывод описания, заменяем на статический.

3. Строка, отвечающая за вывод кодировки.

; charset=" />

Поскольку мы знаем, что кодировка WordPress UTF8, то можем видоизменить данный код и сделать его таким:

4. Удаляем строку, которая отвечает за вывод информации о вашей версии WordPress.

" />

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

5. Заменяем путь к таблице стилей вашего шаблона на статичный.

" type="text/css" media="screen" />

После модификации будет иметь примерно такой вид:

6. Меняем путь к RSS ленте на статический.

RSS Feed" href="" />

После изменения будет выглядеть вот так:

7. Также можно изменить путь до Pingback (рассылка, которая отправляет сведенья по всем адресам, упомянутым в этой заметке).

" />

Заменяем на

Оптимизация файла footer.php

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

заменяем на свой текст. У меня это

  • «Оптимизация WordPress за счет уменьшения количества обращений к данным »

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

На этом все. Удачи вам и успехов в оптимизации сайтов.

Сейчас я расскажу как мне наконец-то удалось снизить CPU нагрузку от моих сайтов wordpress на хостинге. Длилась эта история 3 месяца. Показатель CPU в моём аккаунте был итак на пределе и вдруг начал совсем зашкаливать.

Сколько я прочитала статей в интернете, и сколько облазила форумов — сама точно не знаю. Что я сделала за это время на своих сайтах.

  • Минимизировала количество плагинов. Особенно надо обратить внимание на тяжёлые плагины со сложными скриптами. Обнаружить таких обжор вы можете при помощи плагина P3 (Plugin Performance Profiler)
  • Уменьшила вес картинок. Количество тоже желательно уменьшить, но как без скриншотов, ведь будет сложно понять о чём идёт речь
  • Поставила плагин кеширования — Hyper Cache
  • Уменьшила нагрузку, которую создают поисковые боты

Но только моим сайтам это не помогало, как слону дробина. Проклятое CPU уже показывало более 40-50 единиц, хотя на моём тарифе допускалось – 30. Мой хостер — webhost1 , меня не беспокоил. Но зато психовала я, тем более, что в один прекрасный день мои сайты автоматически отключились – правда длилось это несколько минут. И пришлось перейти на более дорогой тариф.

А CPU на хостинге стало зашкаливать в некоторые дни даже за 50. Переходить на другой хостинг? Возня неимоверная, тем более что на Вебхосте я уже более 3-х лет. И где гарантия, что там история не повторится или не будет ещё хуже. Оставалось только закрывать сайты или платить нереальную (неокупаемую) цену. Но делать этого не хотелось и пошла я бродить по своей хостинг панели.

И о чудо, метод научного тыка как всегда помог! Зашла я в домены и сравнила PHP сайтов старых и новых. Оказалось, что старые сайты работали на устаревшей версии PHP5.3, а новые на PHP5.6!!! Переключила я своих «старичков» на PHP5.6 и уже третий месяц сплю спокойно. CPU нагрузка на хостинг — стабилизировалась.

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

В Настройках найти PHP, выбрать версию 5.6 нажатием на треугольник. И сохранить. После этого нагрузка на CPU должна снизиться. Только не выбирайте версию 7.0 , иначе у вас могут исчезнуть картинки и тема сайта.

  • Не забывайте чистить базу данных каждую неделю. Плагинами: и .
  • Загружать новые обновлённые версии плагинов и движка Вордпресс. Особенно если у вас не отключены обновления – этого, кстати, делать и не рекомендуется, хотя в сети встречаются статьи с советами отключать обновления. Якобы этот способ сильно снижает нагрузки – снижает, но не более чем на 3-5 единиц! А вот сайты свои вы подвергаете опасности быть взломанными, так как в каждой новой версии движка или плагинов закрываются уязвимости. Поэтому заходите хотя бы раз в неделю на свои сайты и принимайте обновления.

Рада, если смогла вам помочь и перед вами больше не стоит вопрос Как снизить нагрузку на CPU хостинга.



Загрузка...