Главная
Аппаратные решения
Как уменьшить нагрузку на сервер и ускорить WordPress с помощью Memcached. Ускоряем работу WordPress снижаем нагрузку на сервер

Как уменьшить нагрузку на сервер и ускорить WordPress с помощью Memcached. Ускоряем работу WordPress снижаем нагрузку на сервер

21.06.2019

Мой сервер, который и будет героем последующего повествования - это обычный арендованный у FirstDedic сервер среднего класса с процессором DualCore Xeon E3110 3.00Ghz. Оперативной памяти было установлено 4 Гб, жесткий диск 500 Гб. На сервере был установлен nginx 1.01 в качестве frontend, и apache 2 в качестве backend, с запуском скриптов в режиме CGI.

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

И вот, в один прекрасный «Женский день», утром, приходит SMS от сервиса мониторинга сайтов, что сервер недоступен. Естественно, от такой новости мгновенно просыпаюсь, и пробую пинговать сервер. Пинг присутствовал, но очень вялый. Соединение по SSH установить невозможно, потому что все ресурсы сервера отданы неизвестному процессу, или процессам.

Соединившись по KVM, я отправил сервер в перезагрузку, и сразу после загрузки соединился по SSH. В процессах, я увидел страшную картину: запущено около 1000 процессов php от имени автора блога, кроме того, Load averages больше сотни. Очень страшный показатель, который показывает, сколько приходится ожидать процессу своей очереди на порцию ресурсов.

Естественно, времени мне хватило только чтобы это увидеть, запустив команду top. Уже через минуту сервер перестал отвечать на запросы, и пришлось его вновь перезагрузить, и сразу после перезагрузки выключить apache. Теперь я гарантированно получил сервер, который не израсходует все ресурсы. Начал проводить анализ, я вывел число открытых соединений командой netstat и ужаснулся. Было более 10000 установленных соединений с nginx. Это значит, что за последнюю минуту было 10 тысяч попыток зайти на сайт клиента – хорошая нагрузка.

Попытавшись порыться в настройках WordPress, естественно с согласия клиента, Я обнаружил, что был активирован плагин для кэширования WP Super Cache, который я выключил, потому что при выполнении самую большую нагрузку на файловую систему давал именно он. Выключив плагин, сайт стал выполнять очень много запросов в базу данных – неудивительно. Поэтому первым делом я включил систему кэширования запросов в MySQL, так как нагрузку давала всего одна страница, на которую и было множество переходов. После включения кэширования запросов, база данных вздохнула свободнее, но не настолько, насколько хотелось бы, притом, что основную нагрузку теперь давал сам Wordpress.

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

Proxy_cache_path /path/to/cache levels=1:2 keys_zone=wpblog:10m max_size=10m;
В нужную нам секцию server прописываем:

Proxy_cache_valid 200 3m; proxy_cache wpblog; proxy_pass http://127.0.0.1:8080;

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

Proxy_cache_valid 200 3m; location / { if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-postpass_") { set $do_not_cache 1; } proxy_no_cache $do_not_cache; proxy_cache_bypass $do_not_cache; proxy_cache wpblog; proxy_pass http://127.0.0.1:8080; } location ~* wp\-.*\.php|wp\-admin { proxy_pass http://127.0.0.1:8080; } location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar)$ { root /path/to/static; access_log off; expires max; add_header Last-Modified: $date_gmt; } location ~* \/[^\/]+\/(feed|\.xml)\/? { proxy_pass http://127.0.0.1:8080; }

После этого неудобства в работе полностью компенсируются бесперебойностью.

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

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

Используя этот конфиг могу с уверенностью сказать, что сервер переносит несколько подобных сайтов. Так как мой проект после добавления в Google-Новости стал привлекать много трафика, как собственно и с Яндекс-блогов.

Приветствую всех читателей блога сайт. Рано или поздно перед каждым автором блога на 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 идеальное решение.

Вконтакте

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

Все началось совершенно спонтанно и с каждым днем ответ сервера становился все более долгим. Затем в один прекрасный момент в панели webmaster Yandex, появилось соответствующее критическое уведомление. В котором был указан долгий ответ сервера практически на 40 — 50 страницах сайта. Все по-порядку.

Содержание статьи:

Высокая нагрузка создаваемая WordPress сайтом на серверный процессор CPU — основные симптомы этой проблемы

На моем сайте проблема возникала совершенно спонтанно и в разные временные периоды. Толчком 100% нагрузки на CPU сервера становились переходы между страницами сайта. Примерно на 2-й странице, возникал резкий скачек в работе процессора сервера. Хочется заметить, что в этот момент оперативная память практически не имеет колебаний. А количество процессов совершенно незначительно и не должно так пагубно нагружать серверный процессор.

Основные характерные признаки нагрузки, которые встречаются у многих вебмастеров:

Повышение лимита нагрузки процессора на хостинг-сервере.
WordPress начал создавать недопустимую нагрузку на CPU.
Пиковые значения, жесткая перегрузка процессора на хостинге.
Долгий ответ сервера, варьируемое значение колеблется от 5 до 30 секунд.
Чрезмерная нагрузка происходит спонтанно, в разные временные периоды.
Происходит заторможенность сайта, страницы практически не загружаются или этот процесс проходит очень долго.
Сайт в пиковых пределах крашится.
WP создает долгий ответ сервера, сайт работает не стабильно. В пиковых скачках CPU, оперативная память работает в штатном стабильном режиме.
Количество затронутых и исполняемых процессов в периоды скачков минимальны.
Потоковое пакетное обращение и задействованные соединения на nginx или apache минимальны.
Данная аномалия проходит несколько раз в день, в разные промежутки времени. Заканчивается также быстро, как и началась.

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

Как видите количество задействованных процессов минимально. Оперативная память удерживается в стабильном значении, с учетом открытого браузера и огромного количества страниц. А вот все ядра CPU работают в критической нагрузке, изначально причину понять вообще невозможно.

Какие методы я перепробовал в борьбе с критической нагрузкой на CPU

Самое банальное, я грешил на плагины WP и нехватку памяти. Хотя так по-честному, движок использует всего 16 мб памяти из допустимых 512 мб которые я выделил. Что собственно я пробовал:

Провел полное обновление Debian, затем почистил всю систему.
Удалил 99% сохраненных ревизий баз данных на VestaCp.
Раз двадцать просматривал конфигурационные файлы в VestaCp на наличие ошибок.
Нашел в почтовом сервере Exim большое количество системных логов (полностью удалил).
Проверял сайт на наличие вирусов (отсутствуют).
Делал трассировку до сайта, проверял скорость интернет соединения.
На сайте отключил сохранение ревизий записей, большего на сайте не предпринимал. Сайт оптимизирован под 98% смысл его проверять.

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

В чем собственно заключалась проблема чрезмерной нагрузки WP на CPU, и как я ее решил

Проблема заключалась в ошибке WP Cron (крона). Месяца четыре назад я устанавливал плагин, который запрещает обновляться движку, темам и плагинам. Первым звонком по моим пониманием, были ошибки в серверных логах сайта адресованные wp-cron.php. Ошибка заключалась в выделении памяти на процесс, а точнее нехватки памяти. Когда я вспомнил про эту ситуацию, то сразу обратил внимание.

Что мне помогло:

Я установил плагин WP Crontrol — планировщик задач wp cron. Советую установить его сразу, очень хорошее решение.
После установки, я увидел картину в пиковую нагрузку из примерно 900 идентичных событий, которые как я понимаю касаются изображений.

Самое простое решение обнулить все события wp cron до изначального состояния, делается это в functions.php. Достаточно вставить в самом начале файла под

В результате все 900 событий пропали, сайт начал спокойно работать. Серьезных нагрузок на сервер и долгого ответа больше нет. Единственное от чего мне пришлось избавиться, это от запрета на обновление. После этого все проблемы решились. Вот как выглядят показатели нагрузки на данный момент:

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

Как уменьшить нагрузку сайта на вордпрессе на хостинг и оптимизировать базу данных?

Начал задаваться этим вопросом после того, как служба поддержки хостинга Таймвеб написала мне, что мои сайты (их на этом хостинге размещено 10 штук) оказывают чрезмерную нагрузку на центральные процессы хостинга и на базу данных. Повышенная нагрузка была связана частично с ddos-атакой на один мой сайт, ну и в дополнении с тем, что я размещаю сайты на этом хостинге давно уже (более 1,5 года), а никакие работы по очистке мусора с и по оптимизации баз данных не проводил. А ведь сайт можно в некоторой степени сравнить с компьютером. Если не очищать его от ненужных файлов, кряков и прочей лабуды, то компьютер будет со временем поедать и требовать больше ресурсов, что приведет к замедлениям в его работы, частому зависанию. Поэтому нужно заботливо относиться к своим сайтам и периодически проводить действия по оптимизации их работы.

Как снизить нагрузку вордпресса на хостинг и оптимизировать базу данных (MySQL)?

Я провел небольшие действия (о которых расскажу далее), которые позволили мне в результате существенно уменьшить нагрузку на CPU хостинга. Если говорить обобщенно, то удалось снизить нагрузку на CPU с 30-40 до 0,34 – 0,50, а нагрузка на базу данных уменьшить с 90 до 64-70.

В результате проведенных действий по оптимизации базы данных (MySQL) – ее размер удалось уменьшить с 227 мб до 41 мб. Как видим – удалось добиться существенных показателей. А что для этого было сделано?

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

Для оптимизации базы данных понадобиться установить и активировать плагин — Optimize DB (о том, как устанавливать плагины читать ). Далее идете в раздел «Инструменты» — находите строчку «Optimize DB» и переходите по ней. Теперь для оптимизации базы данных на вашем сайте остается только нажать на кнопку «Optimize Now».

Вот такие простые действия оптимизируют вашу базу данных на вордпрессе (так сказать упорядочивают в ней хаос и раскладывают все по полочкам).Чтобы работа этого плагина в дальнейшем не создавала дополнительную нагрузку – нужно его просто выключить. Для оптимизации базы данных на вордпрессе раз в неделю или раз в месяц заходите в раздел с плагинами, активизируйте плагин Optimize DB и проводите оптимизацию MySQL (это и есть база данных). А после снова отключайте его.

Но я не ограничился для снижения нагрузки на хостинг только работой с плагином Optimize DB. Была проведена существенная работа по борьбе со спамом. Особенно много спама накопилось на нескольких сайтах (в сумме свыше 6 тыс. штук). Говоря про спам – я имею в виду комментарии спамного характера, большое количество которых также нагружает хостинг. Удалил много комментариев ожидающих проверки (точнее, чтобы полностью их удалить – отправлял их первоначально в корзину, а потом корзину очищал), также очищал папку со спамом. В в последнее время мне существенно помогает плагин «Invisible Captcha». Благодаря нему спам мгновенно отправляется в папку со спамом, а оттуда все спамные комментарии можно мгновенно удалить, очистив эту папку.

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

Вот такая была проведена работа над 10 сайтами, которая заняла у меня около 2 часов. Но своего я добился – удалось существенно снизить нагрузку вордпресс на хостинг.

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

В этой статье я хочу рассказать о способах оптимизации блога 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

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

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