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

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

Эта статья содержит каждую тактику, которую я реализовал, чтобы ускорить мой блог на 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 просто установите флажок «Отладка включена», и все готово!

Как только регистрация включена, вы можете нажать на ссылку «logfile», которая укажет вам файл с подробным описанием вашего трафика 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-адресов, которые мы видим, когда ваш сайт вызывает проблемы с загрузкой, являются корпоративными, образовательными и прокси-серверами Gov’t / Military, которые, по-видимому, предварительно выбирают контент, когда кто-то заходит на сайт.

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

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

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

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

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 | wax | wmv | wmx | avi | bmp | класс | 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. Удачи!

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

Вы читали это?

• Как остановить кого-то от плагиата вашего сайта и кражи вашего контента
• Drip Vs ConvertKit Vs AWeber Vs MailChimp – проверено 7-сторонним блогером
• Партнерский магазин Amazon против блогов и электронной коммерции – сравнение 3 онлайн бизнес-моделей
• Отчет о доходах: сколько денег я зарабатываю на ведении блогов и продаж в Интернете и какая бизнес-модель лучше
• Как я заработал более $ 300 тыс. За последние 2 года с автоответчиком по электронной почте

Everything you need to know to start a profitable blog and build an audience

• Find a profitable niche
• Setup a WordPress blog
• Generate traffic to your site

Enter your primary email address below and receive my FREE 6 Day Mini-Course and weekly tips on How To Create A Profitable Blog

Learn How To Start A Profitable Blog

Источник записи: https://mywifequitherjob.com