Pull to refresh

Comments 37

>> 1. Используем хороший хостинг (а лучше впс купить, тем более в последнее время появились очень дешевые тарифы)
>> 3. Оптимизируем код, оптимизируем скрипты, оптимизируем изображения.

Мне одному кажется, что это не советы по оптимизации именно WP?

>> 2. Отключаем неиспользуемые плагины, по возможности заменяем их кодами.

А чем «плагин» — не «код»?:)

Вообще, пост какой-то странный. Первая часть лично мне показалась интереснее.
Описаные «секреты» — это какие-то такие простые вещи, которые писать на Хабре смысла нет.
В голосование нужно добавить пункт «Никому».
Надо наградить принявших участие в конкурсе. Другие то не написали — только за смелость уже можно дать приз. Конечно нужно делать скидку на то, что уровень читателей может быть разным. Принимайте участие в конкурсах, пишите крутые статьи и побеждайте! К тому же можно дать совет по оптимизации в комментариях, и если он будет хорошим — получите 300 рублей на счет Infobox Jelastic.
Может быть никто не писал Вам потому что никому не интересен приз?
Авторам статей, которые мы выберем для публикации (связанные с сервисами Infobox и InfoboxCloud), мы пополняем счет на серьезную сумму в облачном хостинге Infobox Jelastic (поддерживается PHP, Java, Python, Ruby, SQL, NoSQL базы и многое другое в 1 клик с автоскейлингом без необходимости администрирования ОС и первоначальной настройки программных стеков). Подробности по email: trukhinyuri@infoboxcloud.com. Ключевое — качественный контент, полезный для пользователей и еще не рассмотренный нами.
А зачем столько ссылок на сайт в каждом ответе?
У гиперссылок есть преимущество перед простым текстом: если не надо — можно не нажимать, а если надо — удобно быстро перейти на страницу или написать письмо. Просто для удобства.
Вероятно, подразумевается выполнение определенного кода в functions.php вместо обертки этого кода в плагин. Это немного быстрее, т.к. на инициализацию плагинов тратятся хоть и небольшие, но все же, ресурсы сервера.
Ничего подобного. Один и тот же код в плагине или в functions.php выполняется с одной и той же скоростью. Разница только в том, когда он будет выполнен. Код в плагине выполняется раньше, чем код в functions.php, что имеет свои положительные стороны. В остальном, как раз хорошая и правильная практика — выносить функционал в плагины. Инициализация плагинов отнимает время только если это комплексные плагины со своими библиотеками, лоадерами и т.д. Но тут без вариантов — такой код вы и при желании в functions.php не засунете.
Хороший совет. За хорошие советы комментаторам даем по 300 рублей на облачный хостинг Jelastic:) Зарегистрируйтесь на infobox.ru/hosting/cloud/ и пришлите логин на trukhinyuri@infoboxcloud.com. После окончания пробной версии пополним вам счет.
Битва не на шутку =)
Советы хорошие, но вот отключение проверки обновлений довольно спорная штука на мой взгляд. Постоянно мониторить новости с критических багах в WP и следить за релизами сэкономив пару мегабайт памяти на отключении автоматической проверки думаю не лучшая идея.
100% так, отключение обновлений опасно. Поэтому курсивом дописали об этом под рекомендацией.
Можно установить такие плагины как:
1) DB Cache Reloaded Fix — кэширование запросов к БД
2) WP Minify — сжатие css/js

Также забыли про Memcached.
Увеличение размера SWAP-файла (мне в свое время очень помогло когда БД начала часто падать).
Использование async в js (так быстрее отрисовывается страница, но это больше для удобства пользователя, есть даже плагин wordpress.org/plugins/asynchronous-javascript/).
И вместо картинок можно юзать css иконки. symbolset.com/icons/gizmo
И конечно же если у Вас аудитория не только Россия, Украина, то желательно подключить CDN.
Хороший совет. За хорошие советы комментаторам даем по 300 рублей на облачный хостинг Jelastic:) Зарегистрируйтесь на infobox.ru/hosting/cloud/ и пришлите логин на trukhinyuri@infoboxcloud.com. После окончания пробной версии пополним вам счет.
Хотя и совет очевидный, но 300 рублей на Jelastic получите, тк может кому-то помочь. Зарегистрируйтесь на infobox.ru/hosting/cloud/ и пришлите логин на trukhinyuri@infoboxcloud.com. После окончания пробной версии пополним вам счет.
Седьмой пункт сверху. Удаление define ('WPLANG', 'ru_RU'); отключает локализацию вообще всю.
Создаем урезанный файл перевода, откуда выбрасываем перевод админки, затем заменяем:
define ('WPLANG', 'ru_RU');

на:
if (strpos($_SERVER['REQUEST_URI'], 'wp-admin')) define ('WPLANG', 'ru_RU'); else define ('WPLANG', 'ru_RU_lite');


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

p.s. подробнее — _http://lecactus.ru/2008/11/15/3110/

Начиная с версии 4.0 данная константа не используется и ее наличие или отсутствие погоды не делает. Учитывая, что 4й версии уже пару месяцев, пора почитать Changelog.
Ставим wp-supercache, натравливаем nginx на папку с кэшем:
# Use cached or actual file if they exists, otherwise pass request to WordPress
location / {
        try_files /wp-content/cache/supercache/$http_host/$cache_uri/index.html $uri $uri/ /index.php?$args ;
}    


Первое обращение к странице создаст нам статическую копию в .html (используя php, mysql и т.д.), все последующие обращения будут обрабатываться только nginx'ом (банальная выдача статики)

Метод не подходит, если у вас часто обновляется контент на странице.
Можно вообще избавиться от кеширующего плагина и обойтись только кешированием NGINX:
# Don't cache uris containing the following segments
if ($request_uri ~* "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-[^/]*\.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(_index)?.xml|[a-z0-9_-]+-sitemap([0-9]+)?.xml)") {
        set $no_cache 1;
}   

# Don't use the cache for logged in users or recent commenters
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
        set $no_cache 1;
}
# Pass all .php files onto a php-fpm/php-fcgi server.
location ~ \.php$ {
	try_files $uri =404;
	fastcgi_split_path_info ^(.+\.php)(/.+)$;
	include fastcgi_params;
	fastcgi_index index.php;
	fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
	fastcgi_intercept_errors on;
	fastcgi_pass php;
	fastcgi_cache_bypass $no_cache;
	fastcgi_no_cache $no_cache;
	fastcgi_cache WORDPRESS;
	fastcgi_cache_valid  720m;
}


В данном случае все страницы кешируются на шесть часов (сайт не использует комменты и прочую интерактивность).
Главное ребята отключайте проверку обновлений, и через некоторое время у вас будет оптимальный сайт, с красивым веб-шеллом, дорами разложенными по папочкам или ссылками на разные интересные и не очень сайты.

Чтобы не заморачиваться с мускулем для очистки ревизий, есть отличные плагины типа Revision Control.

В целом советы, эти, являются выжимкой из выдачи гугла или яндекса по запросу оптимизация wordpress, только те, кто их копипастили, не учли, что некоторые статьи уже немного устарели и могут не только не дать положительного эффекта, но еще и навредить.
Если сайт сильно нужный и он один, то можно сильно заморочиться. К примеру плагин для очистки ревизий хоть немного да добавляет тормозов — поэтому ревизии чистим bash-скриптом по крону глубокой ночью. Чуть выше также довольно интересный совет с перекидыванием всей статики на плечи Nginx.

Увы и ах советы в данном посте не могут быть 100% уникальными т.к., на минуточку, Wordpress самая популярная CMS на планете и изучена вдоль и поперек. Но если вдруг получится хороший пост с выжимкой наиболее полезных советов (и описанием действий вместе с возможными подводными камнями), то не грех будет добавить его в избранное и почитывать иногда. И да, он тоже через некоторе время устареет.
Их не нужно чистить баш скриптом по крону, хоть днем хоть ночью, потому что те кому они не нужны, могут их отключить и очистить всего один раз.
А на счет «выжимки наиболее полезных советов» и «описаний действий», так это не про этот пост :)
Ну вы же пишете что нужно для ревизий поставить плагин который будет их автоматом подчищать, значит хотя бы на какое то время ревизии нужны. Я предложил чистить их по крону как менее затратный вариант =)
Самое интересное что многие кто работают с WP даже и не в курсе что там есть «какие то ревизии» =)

Ну в целом я согласен с вами что данный пост довольно трудно будет определить как кладезь полезной и актуальной информации по оптимизации WP, но какие то полезные фишки все же здесь можно найти.
Я пишу, что этот плагин Revision Control, как можно понять из названия, предназначен для управления ревизиями, умеет включать, отключать, удалять, оставлять определенное количество, что облегчает конечному пользователю всю эту мороку (mysql, bash, консоль и тп) с неизвестными никому ревизиями, но если их назвать редакциями документа, то все становится понятным.
От того что кто-то назовет это ревизией, а кто-то редакцией суть функционала не меняется. Просто говорю что знаю многих людей которые внезапно даже и не догадываются о таком функционале.

Я просто к тому что кому нужны удобства — будут ставить еще один плагин к 100500 уже имеющимся. Лично мне не по нраву когда на сайте набирается даже десяток плагинов тем более что функционал некоторых из них можно заменить bash-скриптом из пары строчек. Так что каждому свое. Хорошо когда у одной задачи есть много вариантов решения.
Про выжимку полностью согласен.
Что до обновлений, то я их везде отключаю полностью, но у меня всем управляет InfiniteWP, это очень удобно.
Как админ в т.ч. хостинга не могу не согласиться — на Ваш сайт очень быстро обратит внимание хостер, после того как вебшеллы откуда-то из wp-content/themes/какая-то_тема_сделанная_Васей_за 10_баксов сделают la ~1000 на виртуалке… и попробуйте потом сменить права с chattr -R +i, если на файлах будет chmod 0000, любезно установленный админом для супербыстрой загрузки Вашего сайта.
а WP кстати недавно научился вообще фоном обновляться. Правда, насчёт плагинов и тем не знаю, не вникал подробно
Кстати, несколько слов о безопасности (пост просто немного не об этом).
— Если не пользуемся XML-RPC — то запрещаем к нему доступ
— /wp-admin хотя бы HTTP Basic Auth'ом прикрыть или HTTP Digest, естественно пароли не совпадающие с паролями от админки
— Вообще адрес самой админки вроде как можно поменять, а забавы ради на /wp-admin повесить заглушку один в один повторяющую форму входа в WP, только вместо авторизации старательно записывать логи по атакующим.
Или вместо 200-го ответа, при ошибке авторизации, делаем 403, и на логи натравливаем fail2ban.
Странно както сравнивать эти советы: первые относяться к вп, но по большей части все эти советы легко находяться в 2-3х статьях из гугла/яндекса. Вторые больше отнояться к общей оптимизации, которая практически не зависит от двжика. ИМХО
Забыли сказать про минификацию JS/CSS. В WP для этого есть хорошие плагины.

Ну и отключение обновлений / экономия одного запроса к БД — это экономия на спичках. По сравнению с кешированием и opcache и избавлением от 404 эффект мизерный. Также можно не запариваться с чисткой от старых постов если не используются плагины с выборками по кастом-полям постов (при использовании кастом-полей индексы не используются, в остальных случаях — используются и скорость почти не зависит от наличия мусора).
Какой именно плагин из ссылки Optimize DB рекомендуете?
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
infobox.ru
Employees
51–100 employees
Registered