Проблемы, связанные с увеличением производительности WordPress

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

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

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

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

Возможные проблемы при использовании обратных прокси, таких как Varnish и Nginx

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

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

Как работают обратные прокси?

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

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

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

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

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

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

Возможные проблемы при обновлении WordPress

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

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

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

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

Это должен делать хорошо настроенный обратный прокси, а не система автоматической очистки кэша при каждом обновлении.

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

Проблемы с плагинами WordPress для интернет-магазинов

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

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

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

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

Если исключение всего, что касается онлайн торговли, из кэша для вас не подходит - потому что вы, очевидно, теряете преимущество скорости - то, теоретически, есть более сложный способ обойти это ограничение: указать с помощью Edge Side Includes (ESI), какие части ваших страниц не следует кэшировать.

В теории, вы просто могли бы окружить HTML-код этих элементов тегам ESI:

<esi:include> Динамический контент <esi:remove>

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

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

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

Проблемы с плагинами рейтингов

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

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

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

Проблемы с плагинами полного кэширования страниц

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

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

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

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

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

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

Все это добавляет большое количество URL-адресов, которые обслуживает ваш сайт. Теперь представьте, что все эти URL-адреса превращаются в HTML-файлы в какой-нибудь папке (обычно это папка uploads) на веб-сервере. Когда в одной директории размещаются тысячи файлов, даже со списком этих файлов уже трудно работать, мы говорим сейчас об ОС Linux.

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

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

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

Кэширование объектов (Memcached) и проблемы, которые с ним связаны

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

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

Некоторые плагины WordPress настроены (и в этом проблема) для хранения огромного количества данных в базе данных приложения. Сервис Memcached имеет ограниченный объем памяти для кэширования. Представьте себе, что произойдет, если плагин хранит в базе данных огромные изображения.

Memcached попытается сохранить результат этого запроса в буфере, но не будет иметь достаточно свободного места. Затем он начнет удалять ранее сохраненные данные методом first-in, first-out. Если результаты запроса являются достаточно большими, то фактическое содержимое не будет кэшироваться полностью, потому что его часть будет удалена до того, как сервис обработал его второй раз.

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

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

Спрайты: Да, с ними тоже могут возникнуть проблемы

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

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

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

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

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

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

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

Риски, связанные с минимизацией CSS и JavaScript

Минимизация CSS и JavaScript - это еще один из наиболее распространенных способов ускорения веб-сайта. Как правило, минимизация этих файлов влечет за собой удаление всех ненужных символов (переносов строк, точек с запятой в конце свойства CSS, комментариев и т.д.), тем самым уменьшается размер файлов.

Этот метод применяется не только в WordPress, но для любых страниц, использующих CSS и JavaScript.

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

Чтобы избежать подобных проблем, используйте неагрессивные инструменты минимизации, которые удаляют из файлов JavaScript и CSS только ненужные данные, без переназначения свойств.

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

Gzip: здесь особых проблем возникнуть не должно, но мы можем улучшить его

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

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

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

Это хотя и быстро, но не так быстро, как если работать непосредственно с сервера Apache. Все, что вам нужно сделать, это установить mod_deflate (поинтересуйтесь у вашего хостинг-провайдера, доступен ли он - он должен быть доступен, потому что это прописано в большинстве стандартов) и добавить несколько строк в файл .htaccess:

AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript

Заключение

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

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

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