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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<esi:include> Dynamic content <esi:remove>

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

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

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

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

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

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

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

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

Нужно очень аккуратно использовать такое кэширование на сайте, обладающем многочисленными записями и страницами. Когда вы создаете контент на вашем WordPress-сайте, то обычно создается гораздо больше страниц, чем та, с которой вы фактически работаете: создаются страницы рубрик, которые выводят все записи из заданной категории, страницы меток, архивы, страницы авторов, страницы для загруженных изображений и т.д. Все они добавляют большое количество URL-адресов, обслуживаемых вашим сайтом. Теперь представьте себе, что все эти URL будут преобразованы в HTML-файлы в некоторой папке (обычно в папке uploads) на вашем сервере. Если в одной директории находятся тысячи файлов, то даже вывести их проблематично, и мы говорим здесь о Linux OS. Итоговый результат для крупного сайта – большое количество файлов, тяжелая нагрузка на сервер, связанная с вводом/выводом этих файлов, замедление работы сайта и проблемы с хостинг-провайдером.

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

Кэширование объектов (Memcached)

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

Некоторые WordPress-плагины кодированы (ужасно), чтобы сохранить огромный объем данных в базе данных приложения. Сервис Memcached имеет ограниченный объем памяти для кэширования. Представьте себе, что произойдет, если плагин сохранит огромные изображения в базу данных. Memcached попытается сохранить результат этого запроса в буфер, однако исчерпает доступное пространство. Затем он начнет удалять кэшированный ранее контент на основе метода «первым пришел – первым ушел». Если результаты запроса слишком большие, то в таком случае никакой актуальный контент не будет кэширован, поскольку он будет удален еще до повторной выдачи. В данном случае ваш веб-сайт будет сильно замедляться, поскольку вы не только не снизите нагрузку на MySQL-сервис, но и, напротив, добавите еще один сервис в процесс, который требует своего собственного времени выполнения.

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

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

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

Это произошло, поскольку мы превысили предел мобильного 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-сайта, не должно останавливать вас от экспериментирования. Чтобы добиться лучших результатов, просто следуйте нескольким простым принципам: не меняйте сразу слишком много вещей, тестируйте скорость загрузки, используйте тестовые копии при возможности, а также тестируйте функциональность веб-сайта после применения каждой новой техники. Поступая так, вы сможете поднять скорость работы вашего сайта, не ломая его функциональность и не создавая проблем для посетителей.

Источник: wp.smashingmagazine.com