Константин Ковшенин: «Когда каждый пятый сайт в мире работает на WordPress, сложно не иметь претензий от пользователей»
Недавно редакция AIN.UA столкнулась с проблемами в работе сайта. Страницы загружались медленно, несколько дней подряд сайт «падал». Украинские специалисты по серверам (к которым мы обращались после поисков на рынке) рекомендовали нам отказаться от «кривого» WordPress и скорее скрывали симптомы, чем устраняли проблему. После долгих поисков нам удалось познакомиться и успешно посотрудничать с программистом Константином Ковшениным, который специализируется на этой CMS. Более того — он принимает участие в ее разработке, развитии и популяризации. Мы не смогли не воспользоваться случаем и задали ему несколько вопросов про WordPress.
Большинство админов регулярно рассказывают нам, что WordPress — «кривая и тормознутая» CMS, которую нужно сменить на «нормальную». Часто сталкиваешься с таким? Какие аргументы «за» приводишь?
Часто. Конечно, WordPress не является идеальным продуктом и ему безусловно есть куда расти, но на сегодняшний день WordPress — это почти 20% всех сайтов в мире. С такой популярностью сложно не иметь претензий со стороны пользователей и разработчиков.
Важно также учитывать, что WordPress обладает гибкой системой так называемых «хуков» и широким API, что позволяет разработчикам творить с самим движком практически всё что угодно, в том числе его «кривить и тормозить». Ведь большинство проблем с WordPress случаются именно из-за некачественно написанных плагинов (расширений) и тем.
Можешь в общих словах рассказать, что ты сделал с нашим сайтом? И что вообще нужно делать и куда смотреть, когда сайт на WordPress начинает работать со странностями?
Основной причиной сбоев и тормозов WordPress являются, конечно же, плагины, поэтому к их выбору нужно относиться очень серьёзно, особенно когда речь идёт о средних и крупных проектах. Две недели назад главная страница сайта открывалась за 600 запросов в базу данных, при этом свежая и пустая установка WordPress делает это всего за 20-30. Пришлось отказаться от каких-то плагинов, а некоторые — подправить.
Так же для проектов с таким уровнем посещаемости немаловажным является правильное кэширование: поставить первый попавшийся плагин и забыть об этом, к сожалению, уже не сработает. Здесь нужен комплексный подход: кэширование байт-кода PHP, объектов в WordPress, страниц, запросов в базу данных. Подробнее об этом вы можете прочитать в моей статье «Основы кэширования в WordPress» и послушать в докладе с WordCamp Russia 2013.
Не стоит забывать и о настройке самих серверов: правильный подбор и настройка программных пакетов, грамотное распределение ресурсов между веб-сервером, обработчиками PHP, MySQL, хранилищами кэша и прочее. Также нужно научиться измерять результат, для чего есть масса бесплатных утилит, например ab и munin.
Если вы столкнулись со странностями при работе в WordPress или если он вдруг стал работать медленно, первым делом стоит смотреть в сторону плагинов. Отключите все плагины и включайте их по очереди, это поможет быстро выявить причину, и не забывайте, что причиной может быть и ваша активная тема. Если возможности ставить подобные эксперименты на живом сайте нет (например, если вы не хотите пугать ваших посетителей сменив тему на стандартную), то придётся работать непосредственно с кодом. Здесь вам помогут плагины серии Debug Bar, логи веб-сервера, PHP и MySQL, и внешние утилиты как Xdebug.
Ты говоришь, что нужно быть осторожными с плагинами. А как вообще понять, какой хороший, а от какого больше вреда? Например, нам ты посоветовал забыть навсегда про PHP-Exec, который в целом довольно популярный, т.е. рейтинг — не показатель?
Я думаю, это приходит с опытом и здесь важно учитывать много различных факторов. Количество скачиваний и рейтинги — это, конечно, хорошо, но они мало чего говорят о качестве, скорости и правильности исходного кода плагина.
Если говорить о самых частых проблемах, то стоит отметить неправильное использования HTTP API в WordPress, например напрямую через cURL, или без транзитного кэширования результата; неправильную работу с AJAX в WordPress, когда HTTP запрос приходит напрямую в файл плагина, а не admin-ajax.php; циклы с запросом на все записи, чтобы например посчитать количество «лайков» для каждой из них; неправильное использование планировщика задач в WordPress.
Эти проблемы не имеют никаких последствий для сайтов с небольшим количеством записей и с относительно низкой посещаемостью, поэтому люди ими пользуются, ставят высокие рейтинги и советуют друзьям, это нормально. Но как только увеличиваются посещаемость и объём данных, все эти проблемы всплывают наружу.
Плагин PHP-Exec довольно популярен, и он отлично подойдёт большинству пользователей WordPress. Им ведь не важно, что все сниппеты хранятся в базе данных, их загрузка происходит при каждом посещении для исполнения в статьях и виджетах, и что подобные сниппеты априори не могут быть закэшированы на уровне байт-кода. Альтернатива здесь довольно простая — создать специальные виджеты или шорткоды для исполнения требуемого кода в виде отдельного плагина для WordPress.
Заранее знать все проблемы со всеми плагинами невозможно — их ведь почти 30,000! Но грамотному специалисту не составит особого труда проанализировать код плагина и понять его слабые места.
Что можешь посоветовать тем, кто решил развивать свои проекты на WordPress, чтобы как можно меньше сталкиваться со сбоями и тормозами?
Три простых правила: Обновляйтесь вовремя и всегда. Не пользуйтесь дешёвым хостингом где «всё включено» за 5 копеек в год, хороший хостинг — это как хороший бензин для вашего автомобиля. Не пользуйтесь сомнительными темами и плагинами и старайтесь не ставить эксперименты на живом сайте.
В последнее время появляется все больше хостингов «заточенных под WordPress». Что это значит? Стоит ли вообще с ними связываться?
По этому поводу я общался со многими хостинг-провайдерами как в России, так и за рубежом. Большинство в подобные слова ничего не закладывают, кроме возможности установить WordPress из панели управления хостингом, чем сегодня уже никого не удивишь. То есть на сегодняшний день это не более чем маркетинг.
Но есть и приятные исключения в области хостинга для WordPress, например, компания WP Engine — их инфраструктура целиком построена под WordPress. Они написали свои собственные модули для работы с объектным кэшем и кэшированием страниц в WordPress. Они автоматически проверяют файлы на вредоносный код при их загрузке. Они автоматически обновляют ваш сайт до последней, самой стабильной версии WordPress. Их служба технической поддержки никогда не скажет вам «это проблема в WordPress» — они всегда помогут разобраться, ведь они специалисты в этой области и даже сами участвуют в разработке и развитии проекта WordPress.
Подобные наработки есть у компаний DreamHost (которые недавно запустили платформу DreamPress), ZippyKid, Page.ly, и, если я не ошибаюсь, то в скором времени мы увидим нечто подобное от Bluehost (которые принимают активное участие в разработке ядра WordPress) и MediaTemple.
В Рунете, к сожалению, подобных компаний пока нет.
Стоит так же отметить проект WordPress.com VIP — это хостинг для крупных сайтов от компании Automattic. WordPress.com VIP построен на инфраструктуре сети WordPress.com, которая на сегодняшний день насчитывает более 50 миллионов сайтов. Цены на подобный хостинг начинаются от $4000 в месяц, а среди клиентов — такие крупные брэнды как TechCrunch, CNN, Time, NBC, Samsung, METRO.
А какой самый популярный русскоязычный сайт из работающих на WordPress?
Сложно сказать, так как WordPress в России пока не настолько популярен. Из последних крупных сайтов с которыми сталкивался пожалуй стоит выделить Блог Лаборатории Касперского, журнал Лайфхакер и портал Mail.ru API.
Расскажи, как вообще устроен «Мир WordPress»? Это бесплатная и очень популярная CMS. Кому она принадлежит и как они зарабатывают?
WordPress — это проект с открытым исходным кодом, он бесплатный и распространяется под свободной лицензией GNU GPL. Торговая марка WordPress принадлежит некоммерческому фонду WordPress Foundation в США, поэтому о заработке здесь речи быть не может.
В разработке и развитии WordPress может участвовать любой желающий, например, в версии 3.6 приняло участие более 200 дизайнеров и разработчиков. Большинство таких участников — волонтёры, но есть и те, чьё время оплачивает коммерческая компания. Хорошими примерами являются Audrey Capital, 10up, WooThemes, Bluehost, DreamHost, и, конечно же, Automattic.
Вокруг WordPress также проходят некоммерческие мероприятия при поддержки фонда. Они называются WordCamp, и в 2012 году более 60 таких конференций прошло по всему миру, а в августе 2013 года состоялся первый WordCamp в России.
А чем непосредственно ты занимаешься?
Последние два года я работаю программистом в упомянутой выше компании Automattic. Нас уже почти 200 человек и мы очень быстро растём. Я работаю в команде под названием Dot Org — мы помогаем развивать сам WordPress и ряд некоммерческих ресурсов вокруг него, в том числе WordPress.tv, WordCamp.org и сайт WordPress.org. В своё свободное время я разрабатываю бесплатные темы и плагины, а также веду онлайн журнал о WordPress — WP Magazine.
Связаться с Константином можно в Twitter и через электронную почту. Если у вас есть дополнительные вопросы по WordPress, можете задавать их в комментариях. Он постарается на них ответить.
Комментарии | 40
«Это бесплатная и очень популярная CMS. Кому она принадлежит и как они зарабатывают?» С вопроса выпал. Такая клева статья и будто удар в челюсть.
Ну хорошо, что вы знали, например, кому принадлежит тот же VIP WordPress, но, поверьте, это знают далеко не все. И какие там схемы между организацией и коммерческими разработчиками
На самом деле вопрос очень важный, ведь многие до сих пор путают разницу между WordPress.com и WordPress.org, а это далеко не одно и то же. Так же мало кто знает, что фонд WordPress не имеет права вести коммерческую деятельность, и что «лицензия GPL» это не пустые слова.
Совсем недавно столкнулся со статьёй «WordPress получил $50M инвестиций от Tiger Global» — глубочайшее заблуждение, ведь фонд WordPress ни копейки от них не получил, а вот компания Automattic действительно продала часть своих акций инвестиционной группе.
Я просто оставлю это здесь:
Какая разница между WordPress.com и WordPress.org?
http://wpcafe.org/tutorials/kakaya-raznitsa-mezhdu-wordpress-com-i-wordpress-org/
Почему WordPress бесплатен, кто его оплачивает и в чем подвох?
http://wpcafe.org/tutorials/pochemu-wordpress-besplaten-kto-ego-oplachivaet-i-v-chem-podvoh/
WPcafe.org в вашей статье вы пишите: «WordPress.com — бесплатная площадка, которая полностью управляется сообществом разработчиков движка»
WordPress.com не управляется никаким сообществом. Площадка принадлежит и управляется коммерческой компанией Automattic уже более 8 лет. Вот видите, даже онлайн журналы про WordPress часто не до конца понимают разницу 🙂
Вы правы, немедленно внесем правки! Спасибо! 🙂
Господа, тут маленькое непонимание про разницу я в курсе. Меня зацепило, то что в такое серьезной статье допускается такая очевидная, для меня по крайней мере ошибка. WordPress в первую очередь не бесплатная, а свободная система. Бесплатно свободная.
Согласен, тем не менее для большинства пользователей WordPress это не имеет значения. Им наплевать на их права и обязанности, ровно так же как и на лицензионное соглашение при установке iTunes 🙂
А что вы хотели чтобы админы сделали с вордпрес ? Вам правильно указали, что причина в самом вордпресе . И вы правильно нашли грамотного разработчика. Деколетте отказывали в помощи оптимизации вордпреса ?
Мы не хотели что-то делать с WOrdpress. Мы хотели решить проблему с тем, что сервер, например, падал или медленно работал. Но нам говорили — меняйте CMS, хотя в сервере тоже кучу всего в итоге было перенастроено
В «самом WordPress» причины небыло, его мы оставили без изменений, а вот все программные пакеты на сервере пришлось перенастроить.
Вообще
не только сервер, плагины… Весь контент (видео, картинки, файлы) должен
лежать на CDN, кеш запросов к базе данных, кеш http сервера (подключить к
примеру Varnish, или генерить страницы html). В общем оч много вариантов
оптимизации, если влом уходить с WordPress. А сколько всего можно переписать в
самой CMS 😀
«Украинские
специалисты по серверам рекомендовали нам отказаться от «кривого»
WordPress» какие специалисты, а? ))) все спецы работают на внешний рынок, остальное
просто — конторы по разработке сайтов-визиток.
Отличное интервью!
Практически все проблемы в WP либо из-за использования неоптимизированных и кривых плагинов, либо из-за кривой темы. Настройки хостинга или VPS тоже влияют, но уже не так сильно, как обилие кривого кода в клиентских плюшках.
Константин и Артур, спасибо, прекрасное интервью.
У меня вот такой вопрос — от каких еще плагинов из «топовых», кроме PHP-Exec, Вы бы посоветовали отказаться?
Хороший вопрос! В голову приходит NextGEN Gallery, User Avatar, многие плагины для создания XML карт сайта, многие плагины реализующие мобильную версию сайта, большинство плагинов со словом «Security» в их имени, большинство плагинов для резервного копирования, и так же стоит опасаться плагинов, которые выводят что-либо в случайном порядке, например 5 случайных комментариев и т.д. И это далеко не полный список.
Вообще отказываться от всего вовсе не обязательно, важнее понимать проблемы того или иного плагина. Например, если у нас на сайте огромная посещаемость, а комментариев всего, скажем 50.000, то запрос на случайные комментарии не такой уж и «тормозной», хоть он и повлечёт за собой полный скан таблицы и filesort, и не будет закэширован на уровне MySQL из-за сортировки RAND().
Если же мы работаем с миллионом комментариев, подход нужен совсем другой, например запланированная асинхронная задача для выбора тысячи комментариев случайным образом и кэширование результата на определённое время. Этот кэш уже можно использовать для выбора 5 случайных комментариев (из 1000) на самом сайте.
Здравствуйте! Подскажите, пожалуйста, существует ли плагин Word Press для сжатия всех изображений на странице в зависимости от его реально отображаемого размера на странице? Как в MS Word и Power Point, например. У меня проблема с такими страницами, они весят более 18 мб http://dreammadetravel.ru/asia/sri_lanka/ . Заранее спасибо за ответ.
Мария, спасибо за вопрос! Здесь два разных подхода, которые часто используются вместе: уменьшение размера изображений, и их оптимизация. Уменьшение помогает избавиться от 18-мегабайтовых изображений и это может сделать сам WordPress, в зависимости от вашей темы (её максимальная ширина, размер миниатюр и т.д.) и в зависимости от настроек размеров в разделе медиа.
Если вы сменили тему, (т.е. если размер миниатюр и ширина изменились), то WordPress попытается самостоятельно подобрать наиболее подходящий размер из имеющихся, и очень часто использует именно оригинал. Вы можете «перегенерировать» требуемые размеры с помощью плагина Regenerate Thumbnails.
К сожалению этот плагин не поможет вам, если оригиналы изображений у вас вставлены непосредственно в содержимое записей и страниц. Вам нужно уменьшать размеры «на лету». Для этого есть хороший сервис Photon в плагине Jetpack, который не только уменьшит размеры изображений, но и оптимизирует их и выдавать будет с CDN серверов сети WordPress.com, что существенно уменьшит трафик передаваемый через ваш хостинг сервис.
Для оптимизации (без потери качества) изображений я советую рассмотреть утилиты optipng, pngcrush, jpegtran, а так же сервис от Yahoo Smush.it, для которого есть даже плагин WordPress, но учтите, что этот плагин немного замедлит работу медиатеки, поскольку каждое загружаемое изображение будет проходить через сторонние сервисы.
Спасибо за подробный ответ!
Константин все правильно советует, я бы добавил только:
1. Альтернатива Smush.it — EWWW Image Optimizer
2. Imsanity — очень полезный плагин, который уменьшает большие изображения при загрузке. Чаще всего проблема с гигантскими фото из-за того, что обычные пользователи не задумываются о том, какого размера фотографии они загружают. И часто это — полноразмерные JPG прямо из камеры, размером 5×4тыс пикселей и более. На сайтах такие фото никому не нужны, если это не фотобанк. Настраиваете данный плагин на предельные размеры фото и дальше можете заливать любые картинки, если ее размеры будут превышать лимит — плагин уменьшит картинку, удалит оригинал, а дальше — как обычно.
Все про рунет, про Україну ні слова…
А что про Украину? Специалист из Москвы же
Да и в Украине вообще посещаемых блогов очень и очень мало
Статья классная, спасибо))
И шо внатуре при использовании PHP-Exec + Кеш плагин типа WP Super Cache с использование .htaccess редиректов код вставок PHP исполняется при каждом запросе стараницы?
При выдаче из кэша страниц — нет, запросов дополнительных не будет. Ровно так же как и запросов в БД MySQL, запросов на кэш объектов и т.д., поскольку результат уже сохранён в кэше и выдаётся на уровне advanced-cache.php, который исполняется ещё до загрузки тем и каких-либо плагинов.
А в случае с WP Super Cache, который настраивается на прямой доступ к .html или .gz файлам, интерпретатор PHP и вовсе запускаться не будет, т.е. выдача будет происходить напрямую через веб-сервер.
Ну вот, значит PHP-Exec на полностью закешированых сайта юзать можно и без проблем 🙂
Совершенно верно. Можно то же самое сказать про любой плагин, который замедляет загрузку любой страницы на 20 секунд — ставим перед ним кэширование страниц, и проблем как не бывало 😉
Действительно кэширование страниц спасает от многих подобных вещей, но важно учитывать, что страницы далеко не всегда выдаются из кэша. Ведь у кэша любой страницы есть свой срок жизни, а так же ряд факторов, которые могут в любой момент сбросить кэш той или иной страницы, например публикация нового комментария, внесение изменений в статью, визит авторизованного пользователя, дополнительные GET параметры при запросе, или сервер Memcached решил удалить кэш определённой страницы, чтобы освободить память под другую — такое случается гораздо чаще чем мы думаем.
Прятаться за кэшированием страниц можно, но до поры до времени. Например в сети WordPress.com авторизованным пользователям вообще никогда не выдаются страницы из кэша, а пользователей там более 50 миллионов.
Кстати, а зачем именно так? Даже у кеш-плагинов такая настройка по дифолту. Из-за HTTPS сессий или почему кеш не подходит для залогиненых пользователей?
Причины могут быть разные, но полагаю основная в том, что пользователи, которые выполнили вход, могут видеть содержимое отличное от того, что показывается остальным. Например приветствие по имени, аватара в правом верхнем углу, ссылки «редактировать запись» или «одобрить комментарий» в статьях и т.д, и поскольку эта версия содержимого только для одного конкретного пользователя (а не для большой аудитории), кэшировать её особого смысла нет.
Ну так кеш же можно отключать/сбрасывать только для тех старниц которые редактировались во время сесссии 🙂 Хотя если работает группа редакторов, то без кеша наверное надежнее…
> Две недели назад главная страница сайта открывалась за 600 запросов в
базу данных, при этом свежая и пустая установка WordPress делает это
всего за 20-30.
И сколько SQL-запросов осталось после рефакторинга?
Около 80 для главной страницы.
Константин, вы упомянули несколько хостеров, которые занимаются поддержкой сайтов на WordPress (WP Engine, DreamHost, ZippyKid, Page.ly). Если ли у них какие-то преимущества (или наоборот — недостатки) перед обычным VPS на качественном хостинге вроде Linode или DigitalOcean? Проще говоря — есть ли смысл покупать VPS и настраивать его под WordPress (настроить nginx и подружить его с W3TC, подключить CDN и т.д.) или лучше воспользоваться готовым решением?
Александр, основные преимущества это возможность использовать готовую инфраструктуру, и конечно же поддержка, если вы в ней нуждаетесь. Инфраструктура наверное здесь важнее, ведь большинство подобных сервисов это не типичный shared-хостинг или VPS. Например WordPress.com VIP это более 2000 серверов в 3-х дата-центрах в 3-х разных городах, воссоздать такое самостоятельно — задача не простая.
Недостаток это конечно же цена, а некоторые ещё и дополнительные ограничения устанавливают, например запрет на определённые плагины, ревью всего кода перед каждым deploy и т.д.
Иными словами, если у вас есть время, знания и ресурсы на создание и содержание своей собственной инфраструктуры (начиная с одного единственного сервера), то безусловно вам стоит взять всё в свои руки — VPS или аренда выделенных серверов. Если же вам некогда или не хочется об этом даже думать — вам подойдёт «managed» WordPress хостинг.
Честно говоря, цена не такая уж и высокая — 20-30 уе, что вполне сравнимо с VPS. Если честно, то я раньше знал только про WP Engine и даже видел несколько относительно популярных в США сайтов, которые им пользуются (с точки зрения пользователя всё работает быстро). Но оказывается специализированных предложений намного больше — благодарю, что рассказали, тем более что у самого сейчас возникла проблемы смены хостера для проекта. Пожалуй даже в ближайшее время попробую протестировать.
На WP Engine или Page.ly за $30 вы получите до 25,000 визитов в месяц. За эти же $30 вы можете взять хороший VPS с 1-2 гб памяти, способный выдержать все 500,000 а то и больше, а с WP Engine это уже $250+.
Вообще сравнивать такой хостинг не совсем честно, ведь за те же $30 на WP Engine, ваш сайт будет находится на нескольких серверах в нескольких дата-центрах, с распределением нагрузки, со stage-сервером и с деплоем с помощью Git, со сканированием кода на уязвимость, и даже SLA. Плюс служба поддержки, которая знает WordPress от и до. А в случае с VPS вы за $30 получаете одну пустую машинку и службу поддержки, которая может по вашему запросу её перезагрузить 🙂
Относительно хостеров для WordPress…
Как Вы считаете является ли сервис Hostenko http://goo.gl/KGgLY9 специализированным для WordPress или это просто маркетинговый ход?
Вопрос к Константину Ковшенину:
А как насчёт скорости работы WP в сравненении с «самодельными CMS»?
Даже без плагинов, с небольшим кольчеством постов и посетителей, WordPress многократно проигрывает в скорости работы, особенно в админке (где сохранение поста может занять 10-20сек).
Установка плагинов кеширование помагает, но только для front-end.
А покупать «продвинутый хостинг» на WP-engine для небольшого проекта не по карману.
Выступлю заместителем Капитана Очевидность:
1. Любая универсальная CMS проигрывает по скорости специализированным решениям под конкретную задачу («самодельным»). Особенно при высоких нагрузках. Если, конечно, самодельщик не адски криворук.
2. Чтобы выкрутиться — не вкладывать слишком много в разработку с нуля, не впадать в зависимость от одного разработчика и получить сравнимую с хардкодом скорость — используют CMF. Вроде SilverStripe. Впрочем, в качестве такого фреймворка можно и WP использовать.
3. Что-то слишком тормозно и для WP — недавно знакомым посадил два сайтика на дешёвый хостинг, таких задержек там нет.
> сохранение поста может занять 10-20сек
Если у вас сохранение записи занимает 10 секунд, то у вас что-то совсем не так. Свежая установка WordPress без плагинов и со стандартной темой не занимает более 1 секунды для публикации записей.
Откуда задержка в 10 секунд надо разбираться, первое что приходит в голову это неправильно настроенный планировщик задач, который возможно пытается выполнить запрос на внешний ресурс (например для проверки на обновления) а доступ к внешним ресурсам заблокирован. Советую прогнать эту «задержку» через Xdebug и посмотреть где конкретно она происходит. Возможно вы просто стали жертвой дешёвого хостинга.
> А как насчёт скорости работы WP в сравненении с «самодельными CMS»?
Если эта самодельная CMS умеет хотя бы 5% того, что умеет WordPress, возможно она и покажется вам быстрее, но в случае с самодельными CMS я бы в первую очередь задался вопросом безопасности, а не скорости.
> Установка плагинов кеширование помагает, но только для front-end.
Не забывайте, что кэширование бывает разное, например кэширование байт-кода PHP и кэширование объектов WordPress ускоряют в первую очередь панель администрирования WordPress.
Маркетинг, ровно так же как их сёстры UM.la и DruHost.