Как справиться с проблемой Leverage Browser Caching в WordPress

Как справиться с проблемой Leverage Browser Caching в WordPress

Если вы когда-либо проверяли свой сайт в Google PageSpeed Insights или в Pingdom, то вы, скорее всего, видели большое желтое предупреждение Leverage Browser Caching. И, скорее всего, именно по этой причине вы читаете данный пост. Сегодня мы посмотрим на то, что значит это предупреждение, с чем оно связано, а также как поступить в данной ситуации.

brcac

Что означает предупреждение Leverage Browser Caching?

Предупреждение Leverage Browser Caching, как видно из скриншота, связано с вашим кэшем браузера. Каждый раз, когда вы посещаете сайт, браузер загружает ресурсы, такие как HTML, CSS, JS и изображения в локальный кэш браузера. Таким образом, браузеру не придется всякий раз получать их при каждой загрузке страницы. Предупреждение появляется в том случае, если ваш веб-сервер или сторонний сервер не имеет корректных HTTP-заголовков кэша. Либо заголовки могут существовать, но время жизни кэша слишком мало.

cons1

Вы могли также видеть это предупреждение в новом тесте скорости сайта «think with Google», который основан на Google PageSpeed Insights. Этот инструмент является маркетинговым, однако сегодня многие клиенты проверяют в нем свои сайты и передают найденные ошибки веб-мастерам. В итоге разработчики и дизайнеры WordPress вынуждены быстро исправлять это, чтобы успокоить своих клиентов.

gst

Устраняем предупреждение Leverage Browser Caching в WordPress

Пользователи WordPress чаще всего сталкиваются с предупреждением Leverage Browser Caching по следующим причинам. Первая и самая распространенная причина – веб-сервер некорректно сконфигурирован. Вторая причина (достаточно ироничная) – предупреждение вызывает скрипт Google Analytics. Третья причина – предупреждение вызывают сторонние скрипты. Давайте посмотрим, что делать в каждой из ситуаций.

1. Предупреждение Leverage Browser Caching на сервере

Первая и самая распространенная причина появления Leverage Browser Caching – ваш веб-сервер не имеет соответствующих заголовков. На скриншоте ниже представлен Google PageSpeed Insights, где можно узнать причину появления предупреждения – expiration not specified. Вообще, есть два метода кэширования: заголовки Cache-Control и заголовки Expires. Заголовок Cache-Control включает кэширование на стороне клиента и задает максимальный срок жизни ресурса (max-age), в то время как заголовок Expires используется для определения момента, когда ресурс больше не является валидным.

brc1

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

Важно! Редактирование вашего конфига Nginx или файла .htaccess Apache может привести к поломке сайта при некорректных действиях. Если вы не уверены в своих навыках, обратитесь к своему веб-хостингу или разработчикам.

Добавление Cache-Control заголовков в Nginx

Вы можете добавить заголовки Cache-Control в Nginx, задав в конфиге следующий блок в разделе server:

location ~* .(js|css|png|jpg|jpeg|gif|ico)$ { expires 2d; add_header Cache-Control "public, no-transform"; }

Добавление Expires заголовков в Nginx

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

location ~* .(jpg|jpeg|gif|png)$ { expires 365d; }  location ~* .(pdf|css|html|js|swf)$ { expires 2d; }

Добавление Cache-Control заголовков в Apache

Вы можете добавить заголовки Cache-Control в Apache с помощью следующего кода в файле .htaccess:

<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$"> Header set Cache-Control "max-age=84600, public"

Добавление Expires заголовков в Apache

Вы можете добавить заголовки Expires в Apache с помощью следующего кода в файле .htaccess:

## EXPIRES HEADER CACHING ## <IfModule mod_expires.c> ExpiresActive On ExpiresByType image/jpg "access 1 year" ExpiresByType image/jpeg "access 1 year" ExpiresByType image/gif "access 1 year" ExpiresByType image/png "access 1 year" ExpiresByType text/css "access 1 month" ExpiresByType application/pdf "access 1 month" ExpiresByType application/javascript "access 1 month" ExpiresByType application/x-javascript "access 1 month" ExpiresByType application/x-shockwave-flash "access 1 month" ExpiresByType image/x-icon "access 1 year" ExpiresDefault "access 2 days" </IfModule> ## EXPIRES HEADER CACHING ##

Просмотреть установленные заголовки можно с помощью сетевой панели Chrome DevTools. Также можно просто пропустить WordPress сайт заново через Google PageSpeed Insights, чтобы убедиться, что предупреждения пропали:

caching-headers-wordpress

2. Leverage Browser Caching и Google Analytics

Вторая популярная причина появления Leverage Browser Caching – Google Analytics. Это выглядит ироничным, поскольку предупреждение вызывает скрипт от Google. Проблема заключается в том, что они установили малое время кэширования для своего ресурса (2 часа), что видно из скриншота. Скорее всего, сделано это было для того, чтобы все изменения и доработки скрипта максимально быстро передавались пользователям. Однако есть способ обхода этого – размещение скрипта Google Analytics на своем собственном сервере. Стоит помнить о том, что этот способ не поддерживается Google.

cf1

Есть великолепный плагин под названием Complete Analytics Optimization Suite, который был создан Daan van den Bergh. Этот плагин позволяет размещать Google Analytics локально на WordPress-сайте.

loc

Вы можете скачать Complete Analytics Optimization Suite из каталога плагинов WordPress. Плагин позволяет вам размещать JavaScript-файл Google Analytics (analytics.js) локально и поддерживать его актуальность с помощью wp_cron(). Другие возможности включают в себя: скрытие IP-адресов ваших посетителей, задание скорректированного показателя отказов, а также размещение скрипта в хэдере или футере.

Дополнительные преимущества от локального размещения скрипта аналитики – вы можете снизить количество внешних HTTP-запросов к Google с 2 до 1; также вы получаете полный контроль над кэшированием файлов. Соответственно, вы можете использовать заголовки кэша, как это было показано выше.

Просто установите плагин, введите ваш Google Analytics Tracking ID, после чего плагин добавит необходимый код отслеживания для Google Analytics на сайт WordPress, скачает и сохранит файл analytics.js на вашем сервере, а также будет поддерживать его в актуальном виде с помощью планировщика wp_cron(). Мы рекомендуем выполнять загрузку в футере. Примечание: плагин не будет работать с другими плагинами для Google Analytics.

local-analytics-settings

3. Другие сторонние скрипты

Если вы ведете свой бизнес с помощью WordPress-сайта, то, скорее всего, у вас имеются дополнительные сторонние скрипты для отслеживания конверсией, выполнения A/B тестов и т.д. К ним могут относиться скрипты для Twitter, CrazyEgg, Hotjar и т.д. К несчастью, вы не можете хранить эти скрипты локально, т.е. вы не можете управлять кэшированием сторонних ресурсов. Однако для некоторых небольших сайтов и блогов есть возможность избавиться от предупреждения Leverage Browser Caching, если следовать рекомендациям, приведенным выше.

scrbr

Заключение

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

Источник: kinsta.com

Сохранено из oddstyle.ru

Добавить комментарий

%d такие блоггеры, как: