Почему ваш сайт на WordPress такой медленный и удобное руководство по ускорению работы

Я хотел начать этот пост с того, чтобы сообщить вам, что это НЕ очередная общая статья «Как ускорить работу WordPress».

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

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

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

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

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

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

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

Некоторые интересные факты о WordPress

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

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

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

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

Мораль истории? Тот факт, что тест скорости показывает, что ваш блог работает быстро, не обязательно означает, что все в порядке.

Вот несколько забавных фактов о WordPress и плагинах кеширования, таких как WP Super Cache и W3 Total Cache, о которых вам следует знать.

• Ответы WordPress 404 медленные . Каждый раз, когда ваш блог получает доступ к несуществующей странице, ваш бедный сервер должен загрузить WordPress, запустить кучу php-кода, выполнить кучу запросов MySQL, а затем выплюнуть вашу пользовательскую страницу WordPress 404. Это очень ресурсоемкая задача, и кеширование здесь не поможет.
• Ваш плагин кеширования не очень хорошо работает, если в URL-адресе есть параметры GET. Например, я раньше замечал, что мой блог будет медленно сканировать всякий раз, когда я отправляю взрывную рассылку в свой список адресов электронной почты. Теоретически при статическом кэшировании файлов мой сервер должен быть почти непобедимым.

  Но поскольку Aweber вставляет параметры отслеживания в URL-адрес, ни один из моих файлов не кэшируется в суперкэш. В результате WordPress должен создать новый файл кеша (даже если он уже существует), заархивировать его и каждый раз отправлять. Хуже всего то, что эти кешированные файлы используются только один раз, что делает их пустой тратой ресурсов сервера.

• Доступ к мошенникам медленный. Поскольку мошеннический доступ требует загрузки WordPress по умолчанию, плохой бот или краулер, решивший спамить ваш сайт неверными запросами, может довольно легко заблокировать ваш блог.
• Ваш плагин кеширования может иметь ошибку или несовместим с тем, как вы настроили свой блог . Например, в течение 3 лет я думал, что WP Super Cache поступает правильно, пока я не начал смотреть свои журналы и не заметил ошибку в коде. Из-за того, как я все настраивал, у меня была проблема, когда WP Super Cache слишком часто очищал мой кеш.

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

Обнаружение несанкционированного доступа

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

Итак, первый шаг - выяснить, что, черт возьми, происходит. Есть много способов сделать это, но самый простой - использовать режим отладки, который предоставляет плагин WP SuperCache. Что делает этот режим? По сути, каждый раз, когда доступ напрямую обрабатывается WordPress (ресурсоемкий), он будет отображаться в журнале WP Super Cache. Вот как вы включаете этот режим.

На вкладке отладки вашего плагина WP Super Cache просто установите флажок «Отладка включена», и все готово!

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

15:03:46 /?utm_source=fwisp.com supercache dir:
15:03:46 /?utm_source=fwisp.com No wp-cache file exists. Must generate a new one.
15:03:46 /?utm_source=fwisp.com In WP Cache Phase 2
15:03:46 /?utm_source=fwisp.com Setting up WordPress actions
15:03:46 /?utm_source=fwisp.com Supercache caching disabled. Only using wp-cache. Non empty GET request.
15:03:46 /?utm_source=fwisp.com USER AGENT (Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)) rejected. Not Caching

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

Что искать в журналах

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

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

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

Боты забивали мои архивы

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

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

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

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

Когда мы много раз видим проблемы с загрузкой вашего сайта, возникает большое количество обращений для IP-адресов прокси-серверов, и теория состоит в том, что эти прокси кэшируют ваш сайт и переходят по всем этим ссылкам на архив. Многие из IP-адресов, которые мы видим, когда ваш сайт вызывает проблемы с загрузкой, - это корпоративные, образовательные и правительственные / военные прокси-адреса, которые, как представляется, предварительно выбирают контент, когда кто-то обращается к сайту.

Решение: проверьте, есть ли у вас php-оператор «wp_get_archives» в коде заголовка вашего блога, и удалите его. После удаления этого небольшого фрагмента все мои обращения к архиву исчезли.

Боты обращались к несуществующим файлам

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

Решение этой проблемы - отредактировать файл .htaccess (погуглить, если вы не знаете, что это такое) и добавить следующие строки.

RewriteCond% {REQUEST_FILENAME}! -F
RewriteCond% {REQUEST_FILENAME}! -D
RewriteCond% {REQUEST_URI}! (Robots \ .txt | sitemap \ .xml (\. Gz)?)
RewriteCond% {REQUEST_FILENAME} \. (Css | js | html | htm | rtf | rtx | svg
| svgz | txt | xsd | xsl | xml | asf | asx | воск | wmv | wmx | avi | bmp | class | divx | doc
| docx | exe | gif | gz | gzip | ico | jpg | jpeg | jpe | mdb | mid | midi | mov | qt | mp3 |
m4a | mp4 | m4v | mpeg | mpg | mpe | mpp | odb | odc | odf | odg | odp | ods | odt | ogg | pdf
| png | pot | pps | ppt | pptx | ra | ram | rar | swf | tar | tif | tiff | wav | wma | wri |
xla | xls | xlsx | xlt | xlw | zip) $ [NC]
RewriteRule. * - [L]

После того, как эти строки будут вставлены в ваш файл .htaccess, ваш веб-сервер сначала проверит, существует ли файл. В противном случае он выдаст ответ 404 БЕЗ загрузки WordPress.

Боты обращались к несуществующим URL-адресам

Что прискорбно в том, как написан WordPress, так это то, что если есть доступ к статье, которой нет в вашей базе данных, вашему серверу придется загрузить WordPress, выполнить кучу кода PHP и выполнить кучу поисков MySQL перед выдачей 404 ответ.

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

Например, я заметил, что группа ботов заходила на мой сайт по URL-адресу www.mywifequitherjob.com/some-article/www.facebook.com/like.php/… . И каждый раз мой сервер загружал WordPress и выдавал ответ 404.

Поэтому вместо того, чтобы WordPress обрабатывать эти запросы, я добавил следующие строки в свой файл .htaccess

RewriteCond% {REQUEST_FILENAME}! -F
RewriteCond% {REQUEST_FILENAME}! -D
RewriteCond% {REQUEST_URI} www \ .facebook \ .com / plugins [NC]
RewriteRule. * 404.html [L, R = 404]

В приведенных выше строках мой веб-сервер ищет «www.facebook.com/plugins» в URL-адресе и немедленно отправляет ответ 404 без загрузки WordPress. Просматривая свои журналы, вы обнаружите множество несанкционированных доступов, подобных тому, который я описал выше. Напишите правило .htaccess для каждого, и эти обращения больше не будут загружать ваш сервер.

Боты забивали мои ссылки на комментарии

Помните, я говорил вам, что URL-адреса с параметрами GET по-разному обрабатываются вашим плагином кеширования? Я обнаружил, что над моими статьями с набором параметров «ответить на комментарий» было множество ботов.

Когда это происходит (в зависимости от ваших настроек кеширования), загружается wordpress и обслуживается кэшированный / zip-файл, хотя к нему, вероятно, больше никогда не будет доступа. Это пустая трата ресурсов.

Пример взят из моего журнала
12:01:11 /how-to-get-more-facebook-fans-with-a-facebook-reveal-tab-or-fan-gate/?replytocom=5972 No wp-cache file exists. Must generate a new one.
12:01:11 /how-to-get-more-facebook-fans-with-a-facebook-reveal-tab-or-fan-gate/?replytocom=5972 Gzipping buffer.

Решение - перенаправить всех ботов и сканеров с этими параметрами GET на главную страницу статьи. Вот код, который я добавил в свой файл .htaccess.

RewriteCond% {QUERY_STRING} replytocom
RewriteCond% {HTTP_USER_AGENT} ^ (. *) (Bot | crawl | spider | slurp) [NC]
RewriteRule. * Https: //mywifequitherjob.com% {REQUEST_URI}? [L]

Этот код ищет параметр GET «replytocom», а затем удаляет этот параметр из конечного URL-адреса перед предоставлением доступа WordPress.

Сканеры получали доступ к сообщениям без косой черты

Я не уверен, почему это так, но я заметил кучу веб-краулеров, которые, казалось, законно пытались получить доступ к статьям в моем блоге без косой черты в URL-адресе.

Как вы можете знать или не знать, URL-адрес, написанный как http://yourblog.com/article/ , отличается от URL-адреса, написанного как http://yourblog.com/article .

В результате, когда встречается URL без косой черты, WordPress должен вмешаться, запустить кучу PHP-кода и затем выполнить 301 редирект на статью с конечной косой чертой. Чтобы избавиться от изображения WordPress, вы можете просто вставить следующее правило в свой файл .htaccess.

# Добавить косую черту в конце
RewriteCond% {REQUEST_FILENAME}! -F
RewriteCond% {REQUEST_URI}! (. *) / $
RewriteCond% {QUERY_STRING}!. * =. *
RewriteRule ^ (. *) $ 1 / [L, R = 301]

Добавляя косую черту в конце, вы отправляете 301 редирект на правильный URL, прежде чем он попадет на WordPress, что сэкономит ресурсы ЦП.

Я обнаружил ошибку в WP Super Cache

В отличие от большинства людей, мой блог WordPress не установлен в корне моего каталога public_html. Кроме того, первая страница моего блога также не является страницей с моими «сообщениями». Когда ваш блог настроен так же, как и я, в WP Super Cache возникает ошибка, из-за которой все ваши файлы кеша могут быть удалены преждевременно, даже если вы предварительно загрузите кеш.

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

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

Отключить плагины с интенсивным использованием ЦП

Даже если вы выполнили все мои шаги, описанные выше, невозможно отфильтровать все несанкционированные доступы до того, как они достигнут вашего блога WordPress.

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

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

В результате (и это может показаться нелогичным) вы на самом деле не хотите делать что-либо ресурсоемкое для ЦП, например «минимизировать» или «сжимать» ваши страницы на лету. Уменьшение размера и сжатие помогает увеличить пропускную способность за счет использования ЦП.

Меньше всего вам нужно минимизировать и кэшировать мошеннические доступы. Фактически, вам, вероятно, также следует подумать о том, чтобы не уменьшать или не сжимать URL-адреса с параметрами GET.

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

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

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

Мораль истории

Тот факт, что онлайн-тест скорости показывает, что ваш блог работает быстро, на самом деле не имеет большого значения в общем плане.

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

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