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

Я собрал список плохих web-решений, а также рекомендаций о том, чего делать на вашем сайте не стоит. Список основывается на тысячах часов общения с клиентами, а также поддержки и устранения неполадок, с которыми я сталкиваюсь ежедневно. Что-то из предложенного будет достаточно примитивным, а какие-то вопросы будут более продвинутого уровня. Многое из описанного может отделять успешный сайт на WordPress от провального. Ведь, несмотря на то, что выбор правильного web-хостинга очень важен, вы должны уделять достаточно времени оптимизации сайта на WordPress, чтобы он был успешным.

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

1. Смена хостинга — не всегда решение проблемы
2. Работающие сайты не предназначены для разработки
3. Не разработчик? - Не лезь в код
4. Не экономьте на темах и плагинах
5. Контролируйте AJAX-запросы
6. Будьте аккуратны при работе с рекламными сетями и внешними сервисами
7. Чрезмерная оптимизация может нанести вред производительности
8. Популярные проблемы с производительностью легко диагностировать
9. Изменение ядра WordPress, это плохо
10. Обеспечьте совместимость с PHP 7 и HHVM до переноса сайта
11. Крупные сайты должны заниматься оптимизацией баз данных
12. Действительно ли вам необходима универсальная тема?
13. Лог ошибок - ваш друг
14. Google здесь не просто так
15. 123456 больше не допускается
16. Скрипты не всегда должны загружаться по всему сайту

1. Смена хостинга — не всегда решение проблемы

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

Администрируемый хостинг предоставит вам столько поддержки и помощи, сколько сможет, но не будет заниматься отладкой кода или плагинов. Написание хорошего кода на PHP, создание и редактирование функционала плагинов и тем, правка интеграции, а также наполнение сайта содержимым - не зона ответственности web-хостинга. Этим может заняться опытный разработчик, который вникнет в работу сайта, изучит проблему и решит её.

2. Работающие сайты не предназначены для разработки

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

Если вы не хотите использовать такие решения, вы можете воспользоваться локальной разработкой и тестированием, используя то, что некоторые называют LAMP или LEMP -стеком. Они предназначены для работы с Linux, Apache/Nginx, MySQL и PHP. А такие инструменты, как WAMP и MAMP упростят и ускорят сборку сервера для локальной разработки.

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

Чтобы избежать таких проблем, я рекомендую воспользоваться такими инструментами, как DesktopServer и Local, которые созданы исключительно для ускорения вашего рабочего процесса при локальной работе с WordPress. Они включают в себя упрощенные способы передачи данных рабочему сайту, а также имеют дополнительные функции, такие как работа с WP-CLI и встроенная поддержка режима мультисайтов. Поддержка мультисайтов сама по себе может быть бесценной, поскольку работа с большими локальными копиями WordPress иногда может быть довольно сложной.

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

3. Не разработчик? - Не лезь в код

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



Рекомендация для администраторов: поместите следующий код в файл wp-config.php с заменой edit_themes, edit_plugins, и edit_files привелегий для всех пользователей. Это помешает пользователям уронить сайт посредством редактирования кода.

define('DISALLOW_FILE_EDIT', true);

Также, отключите возможность редактирования файлов темы или установки плагинов для пользователей. Для этого поместите следующий код в файл wp-config.php.

define('DISALLOW_FILE_MODS', true);

Учтите, вышеприведенные команды также отключат редактор файлов для тем и плагинов. Больше информации в WordPress Codex.

4. Не экономьте на темах и плагинах

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

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



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

Ожидание обновлений установленных плагинов - это огромная проблема для пользователей WordPress, которые покупают решения в сторонних каталогах, вроде ThemeForest. Многие разработчики тем встраивают в них дополнительные плагины, такие как Revolution Slider или Visual Composer. Дело тут в том, что при обнаружении уязвимостей во встроенном плагине, пользователю приходится ждать обновления от разработчика темы, хотя сам плагин мог быть исправлен буквально сразу же. Это делает многие сайты очень уязвимыми для хакеров.

5. Контролируйте AJAX-запросы

Следите за тем, как используются AJAX-запросы на сайте, а также за плагинами, использующими AJAX. Например, API WordPress Heartbeat использует /wp-admin/admin-ajax.php для обращения к AJAX через браузер. Многие из этих обращений лишние. Особенно частое использование этого файла происходит при всплесках трафика и загрузке процессора. Это может существенно замедлить ваш сайт. Это чем-то похоже на запуск DDoS-атаки против себя самого.



Если есть сторонние плагины, использующие admin-ajax.php, убедитесь в том, что они взаимодействуют с ним правильно. Вы без труда можете отслеживать HTTP POST-запросы и, на основе имени, определять, каким плагином они вызваны. Например, тот, что обнаружил я, get_shares_count, оказался популярным плагином для взаимодействия с социальными сетями, который перегружал admin-ajax.php. На сайте с высоким трафиком, перегрузка выросла бы многократно.

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

6. Будьте аккуратны при работе с рекламными сетями и внешними сервисами

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

Вот краткое сравнение того, как рекламные сети могут повлиять на ваш сайт на WordPress.

Параметры тестирования: на тестовый ресурс я добавил три объявления из Google AdSense, размером 300x250. На сайте установлена тема по умолчанию - Twenty Sixteen. Я замерил скорость загрузки до установке AdSense, и после.

До AdSense (результаты тестирования)

• Первая загрузка: 1,372 с.
• Повторная загрузка: 1,013 с.

Разбивка содержимого по соединениям:

После AdSense (результаты тестирования)

• Первая загрузка: 4,103 с.
• Повторная загрузка: 3,712 с.

Разбивка содержимого по соединениям:



Просто установив 3 объявления Google AdSense, мы добавили 6 дополнительных подключений. Сайт на WordPress c рекламными объявлениями в 2,7 раза медленнее, чем без них. В основном это связано с дополнительным временем поиска DNS и использованием JavaScript на странице. Все это должно создать у вас картину происходящего на крупных сайтах, вставляющих 10 объявлений на одну страницу. Независимо от того, насколько быстрый хостинг вы используете, он не будет исправлять задержки от сторонних рекламных подключений.

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



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



Другим хорошим примером является сайт Huffington Post. Если вы проведете тест скорости загрузки, вы увидите огромное число HTTP-запросов к рекламным сетям. Быстрый тест показал скорость загрузки свыше 13 секунд!

• Первая загрузка: 15,908 с. | 221 HTTP-запрос
• Повторная загрузка: 13,957 с. | 66 HTTP-запросов

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

Пример асинхронного JavaScript:

src="example.js" async

Пример отложенного JavaScript:

src="example.js" defer

У Патрика Секстона есть другой метод отсрочки JavaScript. WordPress версии 4.1 и выше, имеет фильтр, с помощью которого вы можете легко добавить атрибуты async или defer к своим скриптам.

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

7. Чрезмерная оптимизация может нанести вред производительности

В Интернете есть тысячи статей, дающих “советы” о том, как ускорить и оптимизировать сайт на WordPress. Но нет ничего хуже, чем когда пользователи чрезмерно оптимизируют свои сайты. Да, это происходит гораздо чаще, чем вы думаете. Владельцам сайтов WordPress часто кажется, что добавив чего-то, он удвоит скорость загрузки.

Ниже я перечислил несколько проблем, с которыми встречаюсь регулярно:

Попытка закэшировать кэш

В отличии от типичных VPS или обычных серверов, многие хостинги WordPress имеют собственное кеширование, которое выполняется на уровне сервера (например, Redis или Memcache). Многие провайдеры запрещают использование кэширующих плагинов, потому что их использование может вызвать все типы проблем, но чаще всего, 502 Bad Gateway. Попытка “закэшировать кэш”, как я это называю, никогда не является хорошей идеей.

Плагины, такие, как WP Rocket и Cache Enabler, великолепны, но они разрабатывались для серверов, которым необходима дополнительная помощь в ускорении вашего сайта. Рекомендую почитать подробнее о том, что касается кэширования объектов - популярной серверной формой кэширования, часто используемой сегодня.

2x CDN = 2x скорость загрузки, верно?

CDN действительно могут значительно уменьшить время загрузки контента в разных географических регионах, но только при грамотной настройке. Один из самых популярных сервисов - Cloudflare, технически является прокси-сервером, и немного отличается от обычного поставщика CDN, поскольку вы направляете к нему весь свой DNS, а не только содержимое сайта.

Обычно я вижу, как пользователи подключают Cloudflare, затем добавляют KeyCDN или MaxCDN вдобавок. Это часто происходит из-за того, что они читают чьи-то сообщения в блогах, где видят рекомендации попробовать новые сервисы. Они устанавливают новые сервисы, забывая про уже подключенные, и, хотя эта комбинация может работать при определенных сценариях, чаще всего, все заканчивается беспорядком. В большинстве случаев, стоит использовать либо Cloudflare, либо стороннего поставщика CDN, каждый из которых имеет свои преимущества и недостатки.

Огромное количество SEO-плагинов не обеспечивает более высокую позицию в поисковой выдаче

Вы хотите доминировать в поисковой выдаче, это понятно. Но ведь добавление 3 плагинов для SEO не поможет вам достичь этой цели. На самом деле, есть много проблем с совместимостью, возникающих при использовании All In One SEO, Yoast и других плагинов для SEO одновременно, например, вывод дублирующих метатегов. Установка дополнительных плагинов не гарантирует улучшение вашей поисковой оптимизации.

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

Даже если вы не являетесь продвинутым пользователем WordPress, общие проблемы с производительностью достаточно легко обнаруживать. Продвинутым пользователям я рекомендую пользоваться WebPageTest, поскольку он поддерживает последние протоколы HTTP/2. Для остальных подойдет Pingdom. Простой каскадный анализ покажет вам, есть ли у вас ненужные переадресации, отсутствующие файлы, избыток DNS-запросов или перегрузка сайта через сторонние скрипты или рекламные сети.

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

9. Изменение ядра WordPress, это плохо

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

10. Обеспечьте совместимость с PHP 7 и HHVM до переноса сайта

Известно, что PHP 7 и HHVM очень способствуют повышению производительности сайтов на WordPress. И конечно, всегда приятно использовать новейшее и самое лучшее. Но сначала стоит убедиться, что ваш сайт совместим с этими технологиями. Например, если вы обновляетесь с PHP 5.6 до PHP 7, вы должны протестировать все функции вашего сайта на WordPress в обкаточной среде или локально, чтобы убедиться, что проблем с совместимостью нет. Один устаревший, но очень важный для вас плагин, может не работать с PHP 7, что означает, что вам придется подождать его обновления, прежде чем переходить на более свежие технологические решения.

11. Крупные сайты должны заниматься оптимизацией баз данных

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

Вы можете конвертировать свои таблицы всего в несколько простых действий. Для начала, убедитесь, что вы используете MySQL 5.6.4 или более новую, а также, что вы сделали резервную копию, в качестве меры предосторожности. В этом примере используется таблица wp_comments. Просто запустите команду ALTER, чтобы преобразовать для работы с InnoDB.

ALTER TABLE wp_comments ENGINE=InnoDB;

Если же вы работаете с актуальной версией phpMyAdmin, вы можете открыть нужную таблицу, перейти во вкладку “Операции” и изменить механизм хранения там.



Еще один простой способ оптимизации - это отключение или ограничение количества хранимых исправлений в базе данных. Вы можете добавить в свой wp-config.php следующее, чтобы полностью их отключить.

define('WP_POST_REVISIONS', false );

Или просто измените их количество, хранимое для каждого поста или страницы:

define('WP_POST_REVISIONS', 3);

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

Если на вашем сайте сохранено множество изменений, вы можете запустить этот сценарий в phpMyAdmin, чтобы их удалить:

DELETE FROM wp_posts WHERE post_type = "revision";

Вы также можете воспользоваться плагином WP-Optimize для этих целей.

12. Действительно ли вам необходима универсальная тема?

Существует огромная проблема, которую я наблюдаю в сообществе WordPress. Люди покупают универсальные темы, а используют лишь 1% её функционала или и того меньше. Они смотрят на демо-страницы и видят красивые слайдеры и кастомизированные блоки, которые убеждают их в необходимости приобретения, однако, на самом деле, эти возможности могут никогда им не пригодиться. Можно купить более простую и менее функциональную тему, и тем самым, сэкономить и деньги и время, которое, в итоге, будет затрачено на ее оптимизацию, ведь простая тема будет быстрее прямо “из коробки”.

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



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

13. Лог ошибок - ваш друг

Если вы знаете, как вести себя с файлами WordPress и файлом wp-config.php, журнал ошибок может сослужить вам хорошую службу. Регулярно проверяя его, вы спасете себя от всевозможных головных болей, а также глубже изучите работу WordPress. Мало кто из пользователей заглядывает в лог перед обращением за помощью к техподдержке хостинга. С помощью нескольких простых настроек в wp-config.php, вы сможете включить ведение журнала ошибок, который по умолчанию сохраняется в /wp-content/debug.log.

Включение логирования:

define( 'WP_DEBUG_LOG', true );

Вывод логов на странице:

define( 'WP_DEBUG_DISPLAY', true );

Подробнее в WP_DEBUG codex.

14. Google здесь не просто так

Не бойтесь искать ответы в Google. Интернет полон подсказок и решений. В течение пары минут, вы можете исправить большинство ваших проблем. Ответы на типичные вопросы, вроде “как изменить DNS в GoDaddy” или “как пользоваться sFTP”, легко могут быть найдены в Google.

В Интернете есть крупные ресурсы, посвященные работе с WordPress, такие, как StackExchange и WordPress Codex, не говоря уже о сотнях блогов с обучающими статьями.

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

15. 123456 больше не допускается

SpashData собирает список наиболее часто используемых слитых паролей (более 2 млн.) каждый год. Неудивительно, что в 2015 году самым популярным паролем был “123456” - тот же, что и в 2014 году. Это довольно неприятно для хостингов, так как использование таких паролей держит сайты буквально в шаге от взлома. Одним из лучших решений является использование KeePass или его аналогов. Зашифрованный пароль в облаке всегда намного безопаснее, чем “123456”.

16. Скрипты не всегда должны загружаться по всему сайту

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

Один из таких примеров - популярный плагин Contact Form 7. Как показано ниже, он загружает файлы CSS и JavaScript на домашнюю страницу сайта, хотя там не используется ни одной контактной формы.



Есть несколько способов это исправить. Первый - использовать функцию wp_dequeue_script(), введенную в WordPress 3.1. Она позволяет удалять скрипты из очереди загрузки на вашем сайте. Вот пример использования этой функции с Contact Form 7. Разработчик Contact Form 7 также имеет документацию о том, как использовать JavaScript и CSS только там, где это необходимо.

Второй способ - использовать специальные плагины для WordPress, например, Gonzalez или Plugin Organizer. Ниже приведен пример использования Gonzalez на нашем сайте. Удобное окно настроек позволяет за пару щелчков мыши убрать JavaScript и CSS файлы плагина Contact Form 7 со всех страниц, кроме страницы контактов, тем самым, увеличив скорость загрузки остального сайта.

Заключение

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

Это перевод статьи «Creating Better, Faster And More Optimized WordPress Websites» за авторством Brian Jackson.

https://habrahabr.ru/post/330878/