Создание быстрых и оптимизированных сайтов на WordPress

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

Оптимизация сайтов на WordPress

Изложенные в этой статье советы помогут создать быстрые и оптимизированные WordPress-сайты.

1. Переход на другой хостинг не всегда помогает исправить проблему

Возникшие проблемы с исходным кодом или совместимостью плагинов никак не связаны с хостингом.

Проблемы с кодом не устранятся волшебным образом.

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

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

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

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

Если вы не хотите использовать промежуточную среду, можно разрабатывать локально, используя LAMP или LEMP. Эти наборы предназначены для Linux, (Apache / Nginx), MySQL и PHP.

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

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

Стек LEMP

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

3. Вы не разработчик? Тогда не редактируйте код

Одна из распространенных причин, по которым WordPress- сайты дают сбой–изменения PHP-кода из редактора в разделе "Внешний вид" непрофессионалами.

Редактирование кода в редакторе WordPress

Также рекомендуется разместить следующий код в файле wp-config.php. Он удаляет параметры edit_themes, edit_plugins и edit_files для всех пользователей. Это помешает злоумышленникам взломать сайт через код.

define('DISALLOW_FILE_EDIT',true);

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

define('DISALLOW_FILE_MODS',true);

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

Старайтесь выбирать авторитетных разработчиков при поиске плагинов и заранее просматривать рейтинги и обзоры. Ознакомьтесь с историей разработчика. Учитывая, что в репозитории WordPress более 50 000 плагинов, это может быть непростой задачей, поэтому проведите все необходимые исследования заранее.

Поиск плагина в репозитории WordPress.

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

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

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

Многие разработчики включают в свои темы дополнительные плагины, такие как Revolution Slider или Visual Composer. Проблема заключается в том, что когда обнаруживаются уязвимости, пользователю остается ждать обновления темы. Хотя баг может быть исправлен уже на следующий день. Это делает большое количество сайтов крайне уязвимыми для хакеров.

5. Отслеживайте административные вызовы AJAX

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

Активное использование admin-ajax.php

Если вы используете сторонние плагины, которые применяют в своей работе admin-ajax.php, убедитесь, что они делают это правильно. Можно просмотреть действия POST HTTP- запросов и на основании имени быстро определить, какой плагин может выполнять их.

Также нужно провести сравнение различия в производительности admin-ajax.php и API-интерфейса WordPress REST.

6. Разумно используйте нетворкинг

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

Я добавил три объявления Google AdSense размером 300 на 250 пикселей в версию сайта для разработки, на котором была установлена тема twenty sixteen, и протестировал скорость до и после.
До Adsense:

• Первый просмотр: время загрузки 1,372 секунды.
• Повторный просмотр: время загрузки 1,013 секунды.

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

Разбивка контента до добавления Google AdSense

После Adsense:

• Первый просмотр: время загрузки 4.103 секунды.
• Повторный просмотр: время загрузки 3,712 секунды.

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

Контент после добавления Google AdSense

Добавив три рекламных объявления от Google AdSense, я получил 6 дополнительных подключений. WordPress- сайт с рекламными объявлениями стал в 2,7 раза медленнее. Это связано с дополнительным временем поиска DNS-серверов и масштабным использованием JavaScript на странице. А представьте, что может произойти, когда крупные сайты вставляют 10 рекламных объявлений на одну веб-страницу.

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

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

Большое количество загружаемых ресурсов из-за рекламной сети

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

Время транзакций на сервере приложений

В качестве другого примера можно привести сайт Huffington Post. Если вы посмотрите его тест скорости, то увидите огромное количество HTTP- запросов к рекламным сетям. Этот график показывает, что я увидел в тесте скорости. Время загрузки этого сайта составляло более 13 секунд!

• Первый просмотр: время загрузки 15,908 секунд / 221 HTTP-запрос.
• Повторный просмотр: время загрузки 13.957 секунд / 66 HTTP-запросов.

В таких случаях важно оптимизировать скрипты и обеспечить их загрузку наиболее оптимальным способом. Можно использовать async или defer, чтобы предотвратить блокировку отображения веб-страницы.

Пример JavaScriptсasync:

src="example.js"async

Пример JavaScriptсdefer:

src="example.js"defer

Есть другой популярный метод отсрочки JavaScript. В WordPress версии 4.1 и выше есть фильтр, в котором можно легко добавить к своим скриптам атрибутa sync или defer.

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

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

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

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

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

Плохая оптимизация, которая усугубляет ситуацию

Такие плагины, как WP Rocket и Cache Enabler, великолепны. Но они предназначены для серверов, которым требуется дополнительная помощь.

Добавление 2 CDN = в 2 раза выше скорость?

Доказано, что сети доставки контента (CDN) уменьшают время загрузки и задержки, возникающие при обслуживании контента в разных географических регионах.

Одним из самых популярных поставщиков CDN является Cloudflare. С технической точки зрения Cloudflare является прокси-сервисом и немного отличается от традиционного CDN.

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

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

Добавление сразу трех специализированных плагинов не поможет вам достичь этой цели. Есть много проблем с совместимостью, которые появляются при попытке одновременно запустить All In One SEO, Yoast и другие SEO-плагины.

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

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

Оценки производительности Pingdom

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

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

10. Обеспечьте совместимость с PHP 7 / HHVM

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

11. Большие сайты должны оптимизировать базу данных

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

Производительность базы данных

Вы можете преобразовать таблицы БД с помощью нескольких простых действий. Убедитесь, что вы используете MySQL 5.6.4 или выше, и не забудьте создать резервную копию. Запустите команду ALTER, чтобы преобразовать таблицу под InnoDB.

ALTERTABLEwp_commentsENGINE=InnoDB;

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

Переход с MyISAM на InnoDB

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

define('WP_POST_REVISIONS',false);

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

define('WP_POST_REVISIONS',3);

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

DELETEFROMwp_postsWHEREpost_type="revision";

Если вам неудобно выполнять запрос, используйте для этой цели специальные плагины, например, WP-Optimize.

12. Вам действительно нужна многоцелевая тема?

Многие покупают многоцелевую тему, а затем используют только 1% ее функций. При этом большая часть не используемого функционала увеличивает время загрузки.
Я не говорю, что все многоцелевые темы плохие.При правильной настройке они иногда могут работать быстро. Вот пример темы Avada, скорость загрузки которой составляет до 700 миллисекунд.

Оптимизированная многоцелевая тема WordPress

Для обычного пользователя WordPress, если он не используют множество функций, более минималистичная тема - отличный вариант.

13. Журнал ошибок - ваш друг

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

Журнал ошибок - ваш друг

Включение ведения журнала:

define('WP_DEBUG_LOG',true);

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

define('WP_DEBUG_DISPLAY',true);

Дополнительную информацию вы найдете в разделе Кодекса WP_DEBUG.

14. Google вам в помощь

Уделив несколько минут поиску,можно легко решить большинство проблем. Обычно такие вопросы, как «как изменить DNS-сервер GoDaddy» или «как использовать SFTP» - это темы, материалы по которым можно легко найти в Google.

В интернете есть отличные ресурсы, такие как Кодекс WordPress. Не говоря уже о сотнях блогов с руководствами.

15. 123456 более не приемлемо

Практика использования легко угадываемых паролей ставит WordPress- сайт в состояние «всегда в одном шаге от взлома». Хотя локальное хранение паролей в таком инструменте, как KeePass, является одной из самых безопасных тактик. А поощрение пользователей к применению таких сервисов, как LastPass или Passpack, поможет сделать их пароли более сложными. Хэшированный и защищенный пароль, размещенный в облаке, намного безопаснее, чем использование «123456».

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

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

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

Скрипт загружается на всем сайте

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

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

Отключение скриптов на странице

Заключение

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

Вадим Дворниковавтор-переводчик статьи «Creating Better, Faster And More Optimized WordPress Websites»