Создание быстрых и оптимизированных сайтов на WordPress хостинг. Часть 2

Продолжение первой части.

WordPress хостинг: как правильно оптимизировать сайт

Чрезмерная оптимизация способна нанести большой вред производительности

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

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

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

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

Плагины, такие, как Cache Enabler и WP Rocket, великолепны, однако они создавались для серверов, которым нужна дополнительная помощь в ускорении сайта.

2× CDN = 2× скорость загрузки, правильно?

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

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

Множество SEO-расширений не обеспечивает высокую позицию в поисковой выдаче

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

Обеспечьте совместимость с HHVM и PHP 7 до переноса веб-ресурса

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

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

Большие веб-ресурсы должны заниматься оптимизацией БД

Один из наиболее простых методов замедлить работу крупного сайта на CMS WordPress ‒ не заниматься оптимизацией БД. Простые задачи, как, допустим, очистка следов старых версий CMS 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 разных версий постов. В случае если у вашего хостинга вообще нет внутренней оптимизации, то настройки CMS придется задавать самостоятельно, так как по умолчанию, он будет хранить безлимитное количество исправлений.

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

DELETE FROM wp_posts WHERE post_type = «revision»;

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

Действительно ли вам нужна универсальная тема?

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

Можно приобрести более простую, менее функциональную тему, и таким образом, сэкономить деньги и время, которое, в результате, затрачено будет на ее оптимизацию, так как простая тема будет быстрее непосредственно “из коробки”.

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

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

Лог ошибок ‒ ваш лучший друг

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

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

define ( 'WP_DEBUG_LOG', true );

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

define ( 'WP_DEBUG_DISPLAY', true );

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

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

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

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

123456 более не допускается

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

Одним из наилучших решений является применение KeePass, либо его аналогов. Зашифрованный пароль в облаке гораздо безопаснее, нежели “123456”.

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

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

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

Есть ряд методов это исправить. Первый ‒ применять специальную функцию wp_dequeue_script (), введенную в CMS WordPress 3.1. Она позволяет устранять скрипты из очереди загрузки на сайте.

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

Вывод

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