Кэширование WordPress: все, что вам нужно знать

Что такое кэширование и почему это важно?

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

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

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

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

Кэширование Слоев

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

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

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

 Кэширование Браузера

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

Когда дело доходит до понимания кэша браузера, вкладка сеть в инструментах разработчика Вашего браузера-ваш друг. Давайте посмотрим на кэш браузера в действии, загрузив в качестве примера сайт SpinupWP. При первой загрузке страницы никакие ресурсы не будут кэшироваться браузером. (Я включил «отключить кэш», чтобы подделать начальную загрузку страницы).

Метрики, которые нас интересуют, — это объем передаваемых данных и общие ресурсы.

1.2 MB / 1.2 MB transferred
2.2 MB / 2.2 MB resources

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

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

• Активы, которые кэшируются браузером, не передаются.
• Такие ресурсы, как HTML, CSS и JS, должны быть сжаты (с помощью Gzip) сервером перед передачей в браузер. Затем они распаковываются браузером перед отображением пользователю.

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

Передаваемые данные упали с 1,2 мб до 118 КБ, что является огромной экономией! Вы также заметите, что показатель нагрузки снизился с 893 мс до 573 МС.

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

Вы можете проверить заголовки ресурса с помощью инструментов разработчика или с помощью команды cURL:

Как правило, cache-control заголовок будет иметь значение max-age=<seconds>, которое будет указывать браузеру кэшировать файл максимум <seconds>на некоторое время и предотвращать его повторную загрузку при последующих запросах. В приведенном выше случае файл будет кэшироваться браузером на срок до 1 года.

Распространенные ошибки с кэшированием браузера

1. аннулирование кэша затруднено. После того как браузер кэшировал актив cache-control: max-age=<seconds>, вы не можете сказать браузеру, чтобы он его откэшировал, по крайней мере, без изменения URL-адреса. Вот почему WordPress добавляет строку запроса версии к поставленным в очередь активам. Например:

2. инструменты тестирования скорости веб-сайта, такие как Pingdom, будут жаловаться на кратковременные заголовки истечения срока действия. Часто эти предупреждения запускаются внешними активами, такими как Google Analytics. Это связано с тем, что внешние службы должны использовать короткое время истечения срока действия, чтобы обеспечить актуальность своих активов из-за трудностей с аннулированием кэша. Со временем истечения срока действия в далеком будущем вам придется обновлять свои сценарии встраивания каждый раз, когда Google Analytics меняет свой код. Фу!

3. заголовки cache-control и expires-это не единственные заголовки, которые браузер использует для определения того, следует ли извлекать ресурс с сервера. Например, как только истечет время, указанное  cache-control: max-age=<seconds>etag в заголовке, будет использоваться заголовок. Он содержит токен проверки (аналогичный хэшу MD5 запрашиваемого ресурса), который сравнивается с токеном ресурса, хранящегося на сервере. Если etag значение одно и то же, ресурс возвращает ответ “304 Not Modified”. Это говорит браузеру, что кэшированный ресурс не изменился и что он должен продлить срок действия, указанный в cache-control: max-age=<seconds>

 Кэширование Страниц

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

Чтобы продемонстрировать, насколько значительное влияние может оказать кэширование страниц, я собираюсь протестировать чистую установку WordPress 5.6.2 с помощью ApacheBench. В этих тестах я использую SpinupWP, чтобы подготовить 8 ГБ, 4 vCPUs DigitalOcean Droplet, настроенный для размещения сайтов WordPress. Некэшированные результаты предназначены для WordPress без настроенного кэширования (кроме PHP OPcache, использующего значения по умолчанию PHP 7.4). Кэшированные результаты имеют включенный кэш страниц SpinupWP в один клик.

Начнем с запросов в секунду (чем выше, тем лучше), что переводится в:

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

Это в 10 раз больше запросов в секунду, что потрясающе! Но высокие запросы в секунду ничего не значат, если эти запросы выполняются медленно. Вот почему важно также измерить среднее время отклика (чем меньше, тем лучше), что приводит нас к:

Это повышает производительность приложений. Для сайтов WordPress это означает, что ваш сайт загружается быстрее.

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

Общие готы с кэшированием страниц

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

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

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

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

 Кэширование Объектов

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

WordPress имеет встроенное кэширование объектов, которое позволяет хранить в памяти такие данные, как запросы к базе данных. Таким образом, несколько вызовов функций, таких как get_posts только приводит к одному запросу базы данных. Однако кэш объектов не является постоянным по умолчанию (то есть он не живет за пределами запроса). К счастью, WordPress может быть интегрирован с постоянным хранилищем данных, таким как Redis, что крайне важно для масштабирования динамических страниц. Объектный кэш находится между PHP и базой данных, что ускоряет время выполнения PHP и снижает нагрузку на базу данных за счет кэширования запросов в памяти. Вы можете увидеть, какое влияние оказывает кэш объектов, установив плагин Query Monitor. Загрузка страницы корзины WooCommerce без включенного кэширования объектов приводит к 32 запросам базы данных:

При включенном кэшировании объектов этот показатель снижается до 2 запросов к базе данных и сокращает время генерации страниц с 0,085 С до 0,053 С.:

Эти тесты были выполнены с использованием PHP 7.3, чистой установки WordPress 5.2.2, WooCommerce 3.6.4 и темы Storefront.

Общие Подводные Камни

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

2. кэш объектов не полностью устраняет зависимость от базы данных, которая часто является самым большим узким местом в WordPress. Это связано с тем, что SQL-запросы для построения индекса post всегда будут выполняться, поскольку результаты не кэшируются.

 Плагины Кэширования WordPress

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

Вот и все ребята

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