Если вы искали в последнее время советы по оптимизации WordPress производительности, то вы определенно встретить различные методы, которые люди рекомендуют. К ним относятся всевозможные механизмы кэширования, такие как обратные прокси, плагины кэширования объектов и кэша, minification CSS, использование спрайтов для изображений и так далее. Все они являются жизнеспособными и эффективными способами, чтобы ускорить производительность сайта WordPress. Однако, будьте осторожны при реализации любого из этих методов, и всегда проверить их влияние на вашем конкретном сайте.
В этой статье мы рассмотрим некоторые из наиболее распространенных проблем с различными ускорителями скорости, с которыми я столкнулся, и поделимся решениями, которые помогут вам решить эти проблемы или найти способы обойти их.
Дальнейшее чтение на SmashingMag:
- Как ускорить ваш сайт WordPress
- Взгляд на современный wordpress сервер астек
- Секреты высокого трафика WordPress блоги
- Ускорение работы базы данных вашего веб-сайта
- Do-It-Yourself Кэширование Методы с WordPress
Возможные проблемы при использовании обратных прокси, таких как лак и Nginx
Я начну с обратных прокси, потому что, при правильном использовании, они могут дать вам самый большой импульс скорости и, при неправильном использовании, может вызвать серьезные проблемы, такие как сделать ваш сайт недоступным или показать неверную информацию не правильным посетителям.
Как работают обратные прокси?
Обратные прокси, такие как Varnish и Nginx, стоят между посетителями и вашим веб-сервером. При запросе на одну из страниц ваш веб-сервер обычно должен выполнять службу PHP, которая делает звонки в базу данных, а затем предоставляет выход страницы и статические ресурсы, необходимые для визуализации страницы. С включенным обратным прокси этот результат кэшируется, и в следующий раз, когда кто-то запрашивает эту страницу, готовый вывод будет доставлен обратным прокси, что намного быстрее и не вызывает нагрузки на ваш сервер.
Это здорово, но для правильной работы кэш должен быть удален каждый раз, когда что-то на странице изменилось. Это где вещи могут пойти неправильно,главным образом потому что WordPress родно не поддерживает обратные proxies и требует дополнительных tweaks для кэша, чтобы быть очищены правильно. Как правило, такие хитрости полагаться на WordPress ‘по умолчанию основные крючки (думаю, их как события), чтобы очистить кэш, когда это необходимо — когда сообщение обновляется, когда комментарий добавляется, когда сообщение создается, и т.д. Однако, если важный крючок пропущен в реализации обратного прокси, который вы используете, то у вас может возникнуть проблема. Кроме того, многочисленные события — те, которые не являются частью WordPress ‘основные крючки, а выполняется через плагины — может изменить содержание на вашем сайте.
Возможные проблемы во время WordPress Обновления
При обновлении WordPress помещает ваш сайт в режим обслуживания, обновляет его файлы, а затем отводит режим обслуживания. Обратный прокси может кэшировать некоторые из ваших страниц в то время как ваш сайт находится в режиме технического обслуживания. Это означает, что если кэш не удален, то эта страница обслуживания будет продолжать обслуживаться посетителям, активно предотвращая их доступ к вашему веб-сайту, даже если он работает на веб-сервере.
При обновлении плагина, WordPress отключает его,удаляет всю папку, а затем добавляет новые файлы. За это время плагин фактически не работает. Если это большой плагин, который добавляет много функциональности, таких как галерея или интернет-магазин, то ваш обратный прокси может кэшировать страницы с ошибками на них, а не фактическое содержание.
При обновлении вручную, легко исправить либо отключить кэш во время обновления или очистить кэш вручную, как только вы будете готовы с обновлением. Однако, когда вы используете родной автоматический обновление WordPress, эти решения не очень практичны. Что хороший обратный прокси должен сделать, а это автоматически очистить кэш на каждом событии обновления. Поскольку оба основных и плагин обновления имеют крючки в ядре, это легко достижимо и должно быть сделано вами (если вы реализуете обратный прокси себя) или ваш хостинг-провайдера (если вы полагаетесь на реализацию хозяина).
Проблемы с интернет-магазин плагинов для WordPress
Независимо от того, какой плагин WordPress вы используете для вашего интернет-магазина, вы должны быть очень, очень осторожны при реализации обратного кэширования прокси.
Например, можно создать прекрасный беспорядок с виджетом корзины, который отображает продукты, которые клиент выбрал для покупки. Если это содержимое кэшируется обратными прокси, то все ваши посетители будут видеть продукты, которые первый клиент выбрал для покупки. Ситуация может стать еще хуже, если страницы, содержащие личную информацию, такие как благодарственные страницы, кэшируются и отображаются неправильно не тому посетителю. Нет необходимости говорить о том, что этого следует избегать любой ценой.
Самый безопасный способ избежать таких проблем, чтобы исключить всю часть электронной коммерции вашего сайта из кэша. Как правило, обратные прокси реализованы хостинговых компаний исключить наиболее распространенные WordPress электронной коммерции плагины из кэша по умолчанию.
Если исключить всю часть электронной коммерции вашего сайта не звучит для вас, как элегантное решение — потому что вы, очевидно, потеряете преимущества скорости — то, теоретически, есть более сложный способ вокруг: с помощью Edge Side Includes (ESI), чтобы указать, что части страниц не следует кэшированы. Теоретически, вы бы просто окружили свой HTML тегами ESI:
<esi:include> Dynamic content <esi:remove>
Затем содержимое между тегами будет динамически извлекаться каждый раз, когда запрашивается эта страница.
К сожалению, реализация ESI с WordPress не является простым на всех, из-за WordPress ‘отсутствие родной поддержки обратного прокси. Таким образом, ESI, как правило, не является жизнеспособным вариантом с хостами, которые поддерживают обратные прокси. Но это стоит рассмотреть, если у вас есть интернет-магазин построен с WordPress, и вы реализуете обратный прокси себя.
Проблемы с рейтингом плагинов
Когда вы используете плагин рейтинга на веб-сайте WordPress, который кэшируется задним числом прокси, есть вероятность, что посетители часто видят неправильный кэшированный рейтинг, а не реальный современный рейтинг. Причина в том, что голос посетителя, учитывая через такой плагин не является частью WordPress ‘по умолчанию крючки и не вызовет кэш чистки.
Как и в случае с вопросами электронной коммерции, можно либо исключить страницы, для получения рейтинга, из кэша, либо реализовать модель ESI для этих страниц, если это возможно.
Проблемы с полностраничными кэшингплавинов
В случае, если ваш хостинг-провайдер не предоставляет вам обратную услугу кэширования прокси, вы можете положиться на один из так называемых полностраничных плагинов кэширования для WordPress. Когда посетитель запрашивает страницу, плагин сохраняет фактический выход HTML в физическом файле на вашем сервере. В следующий раз, когда кто-то запрашивает эту страницу, она будет подана как статический HTML-файл, который намного медленнее, чем обратный прокси, но все же быстрее, чем не кэширование вообще.
К сожалению, из-за метода кэширования используется, все возможные проблемы, которые я объяснил для обратных прокси-прокси справедливо для полностраничных плагинов кэширования, а также некоторые новые.
Будьте осторожны, используя такие кэширования на веб-сайте с большим количеством сообщений или страниц. При создании контента на веб-сайте WordPress автоматически создается больше страниц, чем просто те, над которыми вы работаете непосредственно: страницы категорий, на которые перечисляются все посты в этой категории, страницы тегов, архивы, страницы авторов, страницы для загруженных изображений и т.д. Все это добавить до большого количества URL-адресов, что ваш сайт служит. Теперь представьте, что все эти URL-адреса превращаются в HTML-файлы в какой-то папке (обычно uploads папке) на вашем веб-сервере. Когда тысячи файлов находятся в одном каталоге, даже перечислить эти файлы трудно, и мы говорим о Linux OS здесь. Результатом для большого веб-сайта, как правило, огромное количество файлов, тяжелая нагрузка на вволок на сервере и, в конечном итоге, более медленный веб-сайт и проблемы с хостинг-провайдером.
Существует нет точного числа сообщений, выше которых вы не должны включать этот метод, и это также зависит от конкретного способа плагин хранит кэш — с помощью нескольких папок вместо одного, например, было бы более эффективным, но все еще не может быть достаточно для rea lly большой веб-сайт. Просто имейте в виду, что если вы используете такую технику кэширования и ваш сайт начинает замедляться, то это может быть причиной.
Объект Кэшинг (Memcached) И как его сломать
Кэширование объектов отлично подходит для веб-сайта, который получает много запросов в свою базу данных, и это действительно может ускорить некоторые веб-сайты. Memcached хранит результат наиболее часто выполняемых запросов в базу данных в оперативной памяти сервера и обслуживает кэшированные результаты вместо того, чтобы каждый раз запрашивать сервер MyS’L. К сожалению, в некоторых сценариях, вы могли бы на самом деле уменьшить производительность вашего сайта, и вот почему.
Некоторые плагины WordPress закодированы (плохо) для хранения огромного количества данных в базе данных приложений. Служба Memcached имеет ограниченное количество памяти для кэширования. Представьте себе, что происходит, когда плагин хранит огромные изображения в базе данных. Memcached попытается хранить результат этого запроса в буфере, но исчерпал пространство. Затем он начнет удалять ранее кэшированное содержимое на первой, первой основе. Если результаты запроса достаточно велики, то никакое реальное содержимое не будет кэшировано, поскольку оно будет удалено до отбытия во второй раз. В этом случае ваш веб-сайт фактически замедлится, потому что вы не только не сможете сэкономить эту нагрузку на службу MyS’L, но вы бы добавили еще одну услугу в процессе, который требует своего собственного вычислительного времени.
Если вы обнаружите, что ваш сайт работает медленнее после включения Memcached, то, к сожалению, единственным решением является либо отключить все плагины, которые хранят огромное количество данных в базе данных, либо отключить сам сервис Memcached.
Спрайты: Да, вы можете пойти не так с ними, тоже
Я люблю спрайты для повышения производительности они дают на веб-сайт при правильном использовании. Вот почему, когда мы недавно переработали SiteGround, мы перенесли все элементы навигации и uI и многие другие элементы страницы на спрайты. Наш сайт стал намного быстрее, и мы были вполне довольны результатом. Затем мы продолжали добавлять элементы к изображению спрайта, пока в какой-то момент не заметили проблемы, когда некоторые страницы загружаются на устройства iOS.
Это произошло потому, что мы достигли лимита мобильного Safari на максимальное количество декодированных пикселей, которые могут быть отображены. Этот предел отличается для разных устройств. Вы можете легко генерировать спрайт с большим количеством пикселей,и если он достигнет предела размера, то браузер не будет загружать его, который оставит ваш сайт без всех элементов, содержащихся в этом спрайте. Конечно, вы не хотите, чтобы это произошло.
Хороший человек по имени Уильям Мэлоун создал изящный инструмент, чтобы проверить, правильно ли изображение спрайта будет отображаться на всех устройствах iOS. Введите размеры изображения спрайта в калькуляторе, и ответ появится.
Если ваш спрайт слишком большой, возможное решение состоит в том, чтобы разделить его на два изображения. Если вам нужно сделать это, мой совет состоит в том, чтобы отнести только новейшие элементы к новому изображению; в противном случае вам придется настроить весь код CSS, который использует спрайт, задачу, которую вы хотели бы избежать, если это возможно.
Риски с CSS и Минификация JavaScript
CSS и JavaScript minification является одним из наиболее распространенных методов для ускорения веб-сайта. Как правило, минимация этих файлов влечет за собой удаление всех ненужных символов (новые строки, запятые после окончательного свойства CSS, комментарии и т.д.), тем самым уменьшая размер файлов. Этот метод применяется не только к WordPress, но и к любой странице, которая использует CSS и JavaScript.
Многие инструменты и плагины будут автоматически минимифицировать файлы. Тем не менее, некоторые minify более агрессивно, чем просто удаление пустых символов. Некоторые инструменты будут переставлять селекторы CSS, например, группирование их по свойствам и т.д. В некоторых случаях это может нарушить всю логику файла CSS и превратить ваш сайт в нечто, что просто напоминает оригинал.
Чтобы избежать таких проблем, используйте основные неагрессивные инструменты минификации, которые удаляют только ненужные данные из файлов JavaScript и CSS без переупорядочения свойств. Кроме того, всегда храните копию ваших неиминацифицированных файлов, потому что после минификации они станут практически нечитаемыми, что значительно усложнит дальнейшие изменения. Я использую либо плагин или онлайн FreeFormatter.
Gzip: Не может пойти неправильно здесь, но мы можем сделать это лучше
Включение Gzip для WordPress значительно улучшит скорость загрузки. Gzip сжимает выход страницы и передает его в браузер посетителя, как обычный файл, после чего браузер распаковывается и делает его. Это здорово, потому что время, необходимое браузеру для распаковки архивного контента во много раз меньше времени, необходимого для физический перевод несжатого содержимого с сервера на браузер.
Большинство пользователей 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 сайт не должен остановить вас от экспериментов. Чтобы достичь наилучших результатов, просто следуйте нескольким простым принципам: не меняйте слишком много вещей одновременно, ориентируйте скорость загрузки, используйте постановочные копии, когда это возможно, и проверяйте функциональность веб-сайта после применения каждого нового метода. Поступая таким образом, вы ускорите свой сайт, не нарушая никаких функциональных возможностей или вызывая проблемы для посетителей.
Источник: smashingmagazine.com
