Плагин кеширования W3 Total Cash и его быстрая настройка. Установка и настройка плагина W3 Total Cache. Мастер-класс от Романа Теличко

Здравствуйте, друзья!

Долго я не писал. И сегодня постараюсь выдать статью, которая перекроет несколько таких, которые я мог бы написать за все упущенное время.

В последнее время я был озадачен целью оптимизировать свой сайт под максимальную скорость загрузки. Казалось бы, что я уже и так все сделал. Но, проанализировать свой ресурс сервисом Google PageSpeed Insights, оказалось, что еще есть над чем работать.

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

И тут я узнал о плагине W3 Total Cache, который автоматическим образом может сделать те задачи, которые придется выполнять вручную либо же вообще не удастся. Я установил данное решение и удалось прибавить еще скорости сайту + увеличить оценку в глазах сервиса Google PageSpeed Insights. Конечно это не все 100%, но может у вас получится это сделать. Плагин вполне может помочь в этом.

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

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

Преимущества плагина W3 Total Cache

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

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

Различные CMS (движки - системы управления контентом) являются динамическими сайтами. Состоят из PHP кода и постоянно генерируют запросы. В некоторых случаях от этих запросов можно избавиться, установив один из плагинов кэширования, тем самым заставить движок показывать посетителям уже готовые страницы из кэша. Это значительно ускоряет скорость загрузки сайта, что является очень важным фактором ранжирования поисковых систем. Google так точно уделяет данному фактору много внимания и в свое время четко это обнародовал.

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

Одним из преимуществ W3 total cache является его функционал, который помимо стандартного кэширования позволяет произвести оптимизацию всех требуемых функций под максимальную скорость загрузки. И сделать это без стороннего вмешательства в файлы сайта, что придется делать без самого плагина. Это конечно же упрощает задачу новичкам, но в то же время и довольно усложняет, так как разобраться в настройках будет, я бы сказал, очень сложно. Тот факт, что нет русификации, как например в Hyper cache, огорчает.

Что же же это за функционал?

1. Во-первых, можно производить оптимизацию html, CSS и javascript файлов, которая включает в себя минимизацию и объединение всевозможных различных файлов в один. Таким образом можно значительно сократить скорость загрузки сайта + сделать код сайта более легким;
2. Во-вторых, можно включать кэширование браузера на стороне клиента, кэширование запросов к базе данных, gzip сжатие и другие функции, которые требуют вмешательства в файлы сайта.

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

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

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

Теперь мы переходим к настройкам, которых достаточно много.

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

Приступим.

После установки и активации плагина, появится новый пункт в админ-панели сайта.

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

• Purge from cache - удаляет из кэша ту страницу, на которой сейчас находимся;
• Empty all caches - очистить весь кэш сайта;
• Empty page cache - очистить кэш страниц;
• Empty minify cache 0 очистить кэш элементов, которые были минимизированы (скрипты, стили, html код);
• Empty database cache - очистить кэш sql запросов к базе данных;
• Empty object cache - очистить объект кэша.

Итак, начнем с самого первого пункта настроек плагина (dashboard) и дойдем до последнего.

Пункт настроек Dashboard

Как и в любом другом плагине или программе на компьютере, на данной приборной (функциональной) панели можно видеть различную информацию о плагине и о его работе.

В данном случае мы видим несколько блоков, на которых можем:

1. Смотреть прайс на подключение других возможностей плагина (платная поддержка);
2. Поддержать плагин различными способами;
3. Подключить плагин к работе совместно с системой хранения файлов MaxCDN, чтобы сделать загрузку более быстрой;
4. Смотреть данные о скорости работы сайта;
5. Отслеживать статистику о скорости работы сайта по данным сервиса Google Page Speed.

1 - варианты платной поддержки; 2 - поддержать плагин различными способами; 3 - подключить плагин к работе с MaxCDN; 4 - смотреть статистику производительности сайта; 5 - подключение сервиса Google pagespeed для просмотра производительности

Также на вкладке Dashboard можно управлять очисткой кэша, как всего сайта целиком со всеми его элементами (файлами стилей, скриптами и т.д.), так и кэш по отдельности.

Также можно смотреть информацию об установленных модулях плагина и о его совместимости (кнопка compatibility check).

Что касается первого пункта, то он простой. На нем мы пока делать ничего не будем. Двинемся к основным настройкам, где уже можно настраивать работу плагина под наши нужды.

General Settings (основные настройки)

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

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

Блок General

• Toggle all caching types on or off (at once) - данный чек-бокс служит переключателем между активным и неактивным состоянием всех чек-боксов за каждый тип кэширования. Если необходимо включить все типы кэша, тогда ставим галочку и сохраняем настройки (Save all settings). Так же само и отключаются все типы кэша в пункте "General settings" - стоит снять чек-бокс и сохранить настройки. Я не рекомендую включать данную настройку, так как мы используем не все;
• Preview mode - режим предварительного просмотра работы плагина. Если вы хотите сначала протестировать работу плагина, чтобы никто (кроме администратора) не мог видеть результаты его работы, то активируйте данный режим, нажав на кнопку "Enable". Если же вы хотите отдать работу плагина на всеобщее обозрение, тогда отключите данный режим (отключен по умолчанию).

Блок Page Cache

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

Так как основная функция плагина W3TC - кэширование, то функцию обязательно включаем (чек-бокс "Enable").

• Page cache method - метод кэширования. По умолчанию стоит вариант "Disk: Enhanced", который подразумевает, что вы используете виртуальный хостинг. Данный вариант помечен, как лучший, поэтому его и используем.

Также вы можете выбрать вариант "Disk: Basic", если у вас недорогой слабый хостинг. Если заметили, что после выбора рекомендуемого варианта (Enhanced) сайт стал работать заметно медленней или какие-то функции тормозят, то установите вариант Basic.

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

Блок Minify

В данном блоке мы можем минимизировать файлы CSS, Javascript и html.

Настройку конечно же включаем, активировав чек-бокс "Enable" напротив пункта "Minify".

• Minify mode - выбираем режим минимизации. По молчанию стоит вариант "Auto", который подразумевает, что вся минимизация файлов будет происходить в автоматическом режиме. Лучше данный вариант и оставить, если он работает нормально. В моем же случае имеются скрипты, которые подгружаются с других сервисов и, когда они минимизируются данным плагином, то происходят конфликты из-за чего перестают работать некоторые функции. Поэтому, как видите, я выбрал ручной вариант минимизации "Manual", который мы настроим чуть далее в пункте настроек плагина "Minify";
• Minify cache method - выбираем метод кэширования для данной функции. Оставляем вариант по умолчанию "Disk";
• HTML minifier, JS minifier, CSS minifier - данные пункты отвечают за выбор способа минимизации. Варианты по умолчанию хорошо справляются со своей задачей. Но, если вы видите, что какие-то функции работаю не так, например скрипт перестал работать или стили поехали, то попробуйте изменить способ минимизации к соответствующим файлам. Я оставил все по умолчанию.

После всех проделанных изменений не забываем сохранить настройки.

Блок Database Cache

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

• Database Cache - включаем кэширование запросов к базе данных, активировав чек-бокс "Enable";
• Database cache method - по аналогии с предыдущими методами кэширования оставляем вариант по умолчанию (Disk).

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

Данную функцию я не активировал, так как она не поможет ускорить сайт, если используется виртуальный хостинг (shared server). Если же вы используете выделенный сервер, тогда включите.

Касаемо метода кэширования, то ставим тот же самый "Disk".

Блок Browser Cache

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

Обязательно включаем данную настройку.

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

Это достаточно просто проверить. Можно воспользоваться все тем же сервисом Google PageSpeed Insights . Вводим адрес сайта на странице сервера и смотрим результат проверки.

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

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

Если же покажет тот же самый результат, то на вашем хостинге, скорей всего, уже установлен какой-то заголовок для включения кэша браузера, который не распознается Google PageSpeed Insights и который вы не можете перезаписать, так как конфигурация установлена у самого хостера. Чтобы убедиться в том, что кэш браузера включен на вашем хостинге, советую обратиться в службу поддержки. Я так и сделал и оказалось, что кэширование у меня работает с помощью заголовка eTag, который сервис от гугла не распознает.

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

Будьте с данной настройкой внимательны. Сделайте так, как я описал выше.

1. Проверяем сайт;
2. Если кэш браузера отключен, тогда включаем его в плагине;
3. Если после повторной проверки сервис все равно ругается и изменений вообще никаких нет, то обращаемся к поддержке хостинга, чтобы узнать, включено ли кэширование в браузере на стороне клиента. Если включено, то данную настройку можно не включать и показания сервиса Google PageSpeed Insights относительно этого пункта можем игнорировать. Если же нет, тогда просим включить вашего хостера кэш браузера, так как это одна из важнейших настроек для оптимизации скорости сайта.

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

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

Блок CDN

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

Если же все таки решились на этот шаг, тогда активируем чек-бокс "Enable" и выбираем предпочтительную для себя CDN. Рекомендую MaxCDN и Amazon S3.

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

Блок Monitoring

Можно включить мониторинг производительности сайта с системой New relic. Но тогда придется создать аккаунт в ней и получить ключ API, который следует ввести в данном блоке настроек плагина.

Блок Licensing

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

Блок Miscellaneous (разное)

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

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

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

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

Блок Debug (отладка)

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

Вот как это выглядит в исходном коде.

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

Блок Import/Export Settings

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

Также можно сбросить все настройки W3 total cache в исходное состояние, которое доступно сразу после установки и активации плагина.

1. Импорт настроек из файла конфигураций;
2. Экспорт настроек в файл конфигураций;
3. Сброс настроек в исходное состояние.

Основные настройки мы рассмотрели. Переходим к следующему пункту.

Page Cache (кэш страницы)

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

Блок General

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

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

Блок Cache preload

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

Все чек-боксы включаем.

• Automatically prime the page cache - автоматически создавать кэш страницы;
• Preload the post cache upon publish events - предварительная загрузка страницы в кэщ сразу после момента ее публикации.
• Update interval - интервал времени, один раз в который создается новая партия кэшированных страниц. Значение выставляем в секундах. Значение 604800 - одна неделя. Можете выставить более маленький интервал. Тут экспериментируйте и следите за нагрузкой своего сайта на хостинг. Сейчас я поставил стандартное значение в 900 секунд;
• Pages per interval - количество страниц, которое будет кэшироваться в заданный ранее интервал времени. Я ничего не менял. По умолчанию стоит 10;
• Sitemap URL - указываем путь к XML карте сайта. Из данной карты будут определяться приоритеты для разных типов страниц и в соответствии с ними будет происходить кэширование.

Блок Purge policy: Page cache

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

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

В данном пункте все довольно просто и можно ничего не менять. Вот мои настройки.

Блок Advanced (продвинутый)

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

Но все же я применил некоторые функции, что вам сейчас и объясню.

Первая настройка у меня не включается, поэтому включить ее я и не смог. Этого делать и не нужно, т.к. в описании к опции написано, что может увеличить время отклика сайта. А нам это ни к чему.

• Compatibility mode - режим совместимости. Разработчики говорят, что включив эту опцию производительность сайта может упасть примерно на 20%, но взамен мы получим более высокую совместимость работы плагина с большинством хостинг провайдеров. Рекомендую включить данную настройку, что я и сделал;
• Charset - настройка решает проблему с возможными проблемами в кодировке уже закэшированных страниц. Я включил;
• Garbage collection interval - интервал очистки мусора (кэша, срок действия которого вышел). По умолчанию стоит значения 3600 секунд (1 час). То есть каждый час будет производится очистка того кэша, у которого истек срок действия его хранения. Кэш удалится и начнется создание нового. Для занятых сайтов (где мало места на хостинге, но много страниц, то есть в перспективе много кэша) рекомендуются небольшие значения. Я поставил значение 1го дня (86400 секунд) и пока все работает хорошо.

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

• Accepted query strings - указываем строки с запросами и URL, на которых будут производиться данные запросы будут всегда кэшироваться;
• Rejected user agents - вписываем те пользовательские агенты, которым никогда не будут даваться кэшированные страницы (агенты - по сути это те устройства, с которых сидит пользователь, например Apple 5 iphone);
• Never cache pages that use the specified cookies - никогда не использовать кэш для страниц, которые используют специфические куки;
• Never cache the following pages - никогда не кэшировать следующие страницы. Указываем те страницы, которые никогда не нужно заносить в кэш;
• Cache exception list - список исключений кэша. Сюда указываем те страницы/директории, которые нужно кэшировать даже, если они добавлены в пункт ранее "Never cache the following pages";
• Specify page headers - указываем заголовки страниц, отдаваемые сервером, которые также стоит кэшировать.

Minify (минимизация)

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

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

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

Блок General

• Rewrite URL structure - данная опция у меня активна по умолчанию. Так ее и оставил. Отвечает за перезапись структуры URl адресов для CSS и Js файлов;
• Disable minify for logged in users - деактивировать минимизацию для залогиненных пользователей. Если активируете данную настройку, то для вас, как администратора (вошедшего пользователя сайта в свой аккаунт), минимизация не будет применяться. А вот для остальных посетителей минимизация работать будет. Тут ставим на ваше усмотрение, но я не включал;
• Minify error notification - уведомление об ошибках минимизации. Если вы хотите, чтобы вас плагин уведомлял об ошибках при минимизации, то в выпадающем списке справа выберите способ уведомлений. Существует 3 способа уведомлений: в админке (admin notification), на почту (email notification) и последний комбинированный вариант.

Блок минимизации HTML и XML

Напротив пункта " HTML minify settings" выставляем те параметры, в соответствии с которыми будет происходить минимизация HTML и XML на странице сайта.

• Enable - включаем минимизацию;
• Inline CSS minification - минимизировать CSS так, чтобы все было выстроено компактно в одну строку. Удаляются пробелы и отступы в тех местах, где их можно убрать. Таким образом код становится очень компактным без лишнего пустого места, что уменьшает его размер;
• Inline JS minification - тоже самое, только для JS элементов (скриптов) на странице сайта;
• Don"t minify feeds - не минизировать фид каналы. Я их минимизировал бы, поэтому опцию не активировал;
• Line break removal - удалить разрывы строк в коде. Когда мы удалим все отступы и пустые места в HTML коде посредством 2й и 3й настроек, то код уже будет компактный, но могут быть переносы строк. Чтобы убрать эти переносы мы активируем последнюю настройку и код станет в одну строку. В браузере Google chrome вы не увидите одну строку в исходном коде страницы, а просто будет показан слитный код. Чтобы убедиться в наличии кода в одной строке проверьте исходный код в браузере Mozilla Firefox - он отображает так, как все есть на самом деле.

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

По умолчанию в данное поле добавлены первые 2 исключения, которые часто находятся в коде в таком виде, что делает из них комментарии. Я также добавил 3й вариант - noindex. У меня в шаблоне достаточного много мест закрыто данным тегом. Но закрывал я их не в стандартном виде (), а в валидном варианте (<--noindex-->). Такой валидный вариант воспринимается, как комментарий в коде\

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

Блок минимизации JS (Javascript, скриптов)

Как и с минимизацией кода страницы в целом мы можем настроить и минимизацию скриптов в отдельности. Чтобы включить ее, активируем чек-бокс "Enable".

В блоке настроек "Operations in areas" мы можем выбрать 2 вариант оптимизации скриптов:

1. Либо их полная минимизация (minify);
2. Либо только объединение (combine only).

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

Далее мы удаляем все комментарии из скриптов (Preserved comment removal) и переносы строк (Line break removal), чтобы скрипт выстроился в одну строку. Эти 2 опции не работают при варианте только с объединением скриптов (combine only).

Довольно интересным пунктом настроек в минимизации является опция " JS file management", которая позволяет управлять расположением скриптов в различных шаблонах файлов темы оформления.

Что я имею ввиду. Например, имеется мой текущий шаблон. В нем имеются шаблоны файлов, отвечающие за каждый тип страницы (рубрики, главная, статья и так далее). И, зная путь к файлу определенного скрипта, мы можем назначить ему свое расположение на каждом типе страниц. Это очень удобно, так как большинство скриптов можно разместить только на каком-то одном типе страниц, например только на странице статей. Вот получается, что эти скрипты нужно подгружать только в статьях. Зачем же их нужно грузить на других типах страниц? Правильно, незачем.

Как пользоваться этой опцией? Сперва мы выбираем шаблон, с которым мы будем работать, и жмем на кнопку "Add script".

Появится поле для ввода адреса к файлу скриптов (1), для выбора шаблона вывода определенного типа страниц (2) и для выбора места размещения (3).

При выборе области размещения скрипта мы можем выбрать 3 варианта его локации:

1. В секции шапки сайта (секция head). В данной области я рекомендую размещать только те скрипты, которые не работают в нижней области сайта (перед закрывающим тегом body);
2. После открывающего тега body;
3. Перед закрывающим тегом body. Именно это вариант я и рекомендую использовать, чтобы скрипты загружались в самую последнюю область.

Таких скриптов мы можем добавить очень много. Нажав еще один раз на кнопку "Add a script", появится еще одно поле для добавления нового скрипта. Таким образом мы можем сделать так, что на каждом типе страниц будут грузиться только те скрипты, которые там нужны. В итоге скорость загрузки будет увеличена. Настройка очень интересна и ей стоит воспользоваться, если на сайт добавлено много разнообразных скриптов, которые на каждой странице выполняют свою функцию.

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

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

Не забываем пользоваться кнопкой "Verify URL" для проверки правильности адреса к файлу скриптов.

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

Минимизация CSS файлов стилей

Тут все то же, что и в предыдущем блоке настроек, связанном с минимизацией скриптов. Делаем все точно так же. Единственное, что не могу вам ничего сказать про опцию "@import handling". Не разобрался я с тем, на что она влияет. Ее и не трогал. Вы поступите так же.

В остальном же ставим так, как на скриншоте ниже.

Настройки аналогичны блоку продвинутых опций в пункте настроек плагина "Page cache", который мы рассмотрели ранее. Только он немного сжат.

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

Остальные поля касаются исключений.

• Never minify the following pages - никогда не минимизировать следующие страницы;
• Never minify the following JS files - никогда не минимизировать следующие js файлы. Данным полем рекомендую пользоваться в том случае, если после минимизации скриптов у вас происходят конфликты. Возможно, что минимизация какого-то скрипта приводит к конфликтам и из-за этого все скрипты перестают работать. Для этого определяем проблемный скрипт и заносим его в исключения;
• Never minify the following CSS files - никогда не минимизировать следующие CSS файлы;
• Rejected user agents - указываем пользовательские агенты, которые никогда не будут получают минимизированные данные.

Database Cache (кэш базы данных)

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

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

Просто активируем кэширование запросов к базе данных в пункте "General setttings" настроек плагина и изымаем эффект.

Object Cache (кэширование объектов)

Как говорилось ранее, то данная функция не будет увеличивать скорость загрузки сайта, если он размещен на обычном виртуальном хостинге. Так как это именно мой случай, то ее я не активировал в самом начале в пункте "General settings".

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

Browser Cache (кэш бразуера)

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

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

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

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

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

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

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

Я выбрал функцию "Set expires header", так как она является наиболее распространенной. Тоже самое можно сказать и про первый заголовок в списке этих пунктов. Его также можно выбирать.

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

Enable HTTP (gzip) compression - также важная настройка, которая опять же по умолчанию на большинстве хостингов активна. Она сжимает все данные и помещает их в архив сжатого формата gzip. Браузеры могут распознавать содержимое такого формата. Таким образом клиент не грузит всю информацию в полном размере, а только в сжатом, что значительно сокращает время загрузки страницы.

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

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

Как видите, сжатие позволило уменьшить размер данных на 74.1%. Данный момент я выделил зеленой рамкой.

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

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

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

User Agent Groups (группа пользовательских агентов)

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

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

Каждая группа имеет свои настройки редиректов.

Рассмотрим на примере стандартной группы, которая создана по умолчанию и имеет приритет "высокий" (hight).

Для активации ставим чек-бокс "Enable".

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

В пункте "Redirect users to" указываем тот домен, на который нужно перекинуть посетителя. Применение разумно в том же случае с мобильной версией сайта. Может быть полная версия сайта на основном домене, а на поддомене размещаться мобильная версия. Тогда в данном поле укажите поддомен и посетителя, зашедшего с одного из указанных пользовательских агентов, перенаправит на мобильную версию сайта.

Referrer Groups

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

Например, пользователь перешел с поисковой системы Google. В данном случае сайт гугла и является реферрером. Для него можно поставить редирект. Аналогично и для других сайтов.

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

Принцип настройки аналогичен предыдущему пункту.

CDN

Данный пункт вам пригодится, если вместе со своим сайтом помимо обычного хостинга вы будете использовать еще и систему доставки контента (CDN).

Суть в том, что такие системы/сервисы позволяют значительно снизить нагрузку с хостинга и выдержать любые объемы трафика без проседания самого сайта. Поэтому, если сайт реально громадный и сильно грузиться, то это реально повод, чтобы задуматься либо о переезде на выделенный сервер, либо подключить одну из систем CDN (например, MaxCDN или Amazon S3).

По традиции настройки разбиты на несколько блоков.

Блок General

Тут выставляем галочки напротив тех типов файлов, которые будут обрабатываться CDN. Я выбрал тут все типы файлов за исключением последнего пункта, так как он отвечает не за тип файлов, а за пропись к ним некого заголовка "canonical". Судя по всему, это похоже на атрибут rel="canonical", который прописывается к главной странице. Но все же по умолчанию данная настройка отключена, поэтому я бы ее не трогал.

Блок Configuration

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

Нажав на кнопку "Add CNAME" снизу поля ввода, вы добавите еще некоторые поля, которые будут отвечать за замену адреса не во всех хостируемых элементах сайта на CDN, а за определенные, например за замену адреса в файлах скриптов, размещенных в секции Head сайта. Аналогично и для скриптов, размещенных перед закрывающим тегом body и так далее. Самое первое поле касается файлов стилей.

Блок Advanced (продвинутые настройки)

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

Добавляются они в формате "*.расширение", например "*.xls". Каждый тип записывается через точку с запятой (;).

• В пункте "Custom file list" указаны директории и размещенные в них типы файлов, которые также стоит хостить на CDN. Тут указаны директории, отличны от папки с темой оформления и папки wp-includes, которые по умолчанию обрабатываются плагином (выделены красными рамками).
• В поле "Rejected user agents" вводим названия пользовательских агентов, которые не должны получать данные с CDN. Будут им выдаваться оригинальные данные с хостинга.
• Пункт "Rejected files" содержит директории с типами файлов, которые не стоит использовать совместно с CDN.

Monitoring (мониторинг)

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

Единственное, что стоит напомнить, так это то, что для активации данной системы мониторинга в ней нужно зарегистрироваться и ввести специальный ключ в соответствующем блоке в пункте "General settings", а также активировать чек-бокс "Enable".

Настройки я не трогал бы.

Extensions (расширения)

В данном пункте мы можем настроить работу плагина с некоторыми расширениями. Я не видел бы смысла в данном пункте, если бы не наличие такого расширения, как "Wordpress seo by yoast".

Активировав его, мы можем настроить работу плагина W3 Total Cache в соответствии с рекомендациями плагина WordPress seo by yoast. Данный пункт и так можно активировать, но учитывая, что у меня и стоит этот плагин, то это более чем актуально.

FAQ (справка)

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

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

Install

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

About

Если вы хотите узнать все возможности плагина, то в данном разделе они описаны в пошаговом списке. Собственно это страница о плагине.

Вот и все, друзья. На этом разбор плагина W3 total cache закончен. Надеюсь, что он вам помог настроить плагин так, как лучше будет вашему сайту.

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

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

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

До скорой.

С уважением, Константин Хмелев!

W3 Total Cache improves the SEO and user experience of your site by increasing website performance, reducing load times via features like content delivery network (CDN) integration and the latest best practices.

The only web host agnostic Web Performance Optimization (WPO) framework for WordPress trusted by millions of publishers, web developers, and web hosts worldwide for more than a decade.

ПРЕИМУЩЕСТВА

• Improvements in search engine result page rankings, especially for mobile-friendly websites and sites that use SSL
• At least 10x improvement in overall site performance (Grade A in WebPagetest or significant Google Page Speed improvements) when fully configured
• Improved conversion rates and «site performance » which affect your site’s rank on Google.com
• «Instant» repeat page views: browser caching
• Optimized progressive render: pages start rendering quickly and can be interacted with more quickly
• Reduced page load time: increased visitor time on site; visitors view more pages
• Improved web server performance; sustain high traffic periods
• Up to 80% bandwidth savings via minify and HTTP compression of HTML, CSS, JavaScript and feeds

ОСНОВНЫЕ ВОЗМОЖНОСТИ

• Compatible with shared hosting, virtual private / dedicated servers and dedicated servers / clusters
• Transparent content delivery network (CDN) management with Media Library, theme files and WordPress itself
• Mobile support: respective caching of pages by referrer or groups of user agents including theme switching for groups of referrers or user agents
• Accelerated Mobile Pages (AMP) support
• Secure Socket Layer (SSL) support
• Caching of (minified and compressed) pages and posts in memory or on disk or on (FSD) CDN (by user agent group)
• Caching of (minified and compressed) CSS and JavaScript in memory, on disk or on CDN
• Caching of feeds (site, categories, tags, comments, search results) in memory or on disk or on CDN
• Caching of search results pages (i.e. URIs with query string variables) in memory or on disk
• Caching of database objects in memory or on disk
• Caching of objects in memory or on disk
• Caching of fragments in memory or on disk
• Minification of posts and pages and feeds
• Minification of inline, embedded or 3rd party JavaScript (with automated updates)
• Minification of inline, embedded or 3rd party CSS (with automated updates)
• Browser caching using cache-control, future expire headers and entity tags (ETag) with «cache-busting»
• JavaScript grouping by template (home page, post page etc) with embed location control
• Non-blocking JavaScript embedding
• Import post attachments directly into the Media Library (and CDN)
• WP-CLI support for cache purging, query string updating and more
• Various security features
• Caching statistics for performance insights
• Extension framework for customization or extensibility e.g. New Relic, Cloudflare, WPML and more
• Reverse proxy integration via Nginx or Varnish

Improve the user experience for your readers without having to change WordPress, your theme, your plugins or how you produce your content.

What users have to say:

Who do I thank for all of this?

It’s quite difficult to recall all of the innovators that have shared their thoughts, code and experiences in the blogosphere over the years, but here are some names to get you started:

• George Schlossnagle
• Daniel Cowgill

Please reach out to all of these people and support their projects if you’re so inclined.

Установка

1. Deactivate and uninstall any other caching plugin you may be using. Pay special attention if you have customized the rewrite rules for fancy permalinks, have previously installed a caching plugin or have any browser caching rules as W3TC will automate management of all best practices. Also make sure wp-content/ and wp-content/uploads/ (temporarily) have 777 permissions before proceeding, e.g. in the terminal: # chmod 777 /var/www/vhosts/domain.com/httpdocs/wp-content/ using your web hosting control panel or your FTP / SSH account.
2. Login as an administrator to your WordPress Admin account. Using the «Add New» menu option under the «Plugins» section of the navigation, you can either search for: w3 total cache or if you’ve downloaded the plugin already, click the «Upload» link, find the .zip file you download and then click «Install Now». Or you can unzip and FTP upload the plugin to your plugins directory (wp-content/plugins/). In either case, when done wp-content/plugins/w3-total-cache/ should exist.
3. Locate and activate the plugin on the «Plugins» page. Page caching will automatically be running in basic mode. Set the permissions of wp-content and wp-content/uploads back to 755, e.g. in the terminal: # chmod 755 /var/www/vhosts/domain.com/httpdocs/wp-content/ .
4. Now click the «Settings» link to proceed to the «General Settings» tab; in most cases, «disk enhanced» mode for page cache is a «good» starting point.
5. The «Compatibility mode» option found in the advanced section of the «Page Cache Settings» tab will enable functionality that optimizes the interoperablity of caching with WordPress, is disabled by default, but highly recommended. Years of testing in hundreds of thousands of installations have helped us learn how to make caching behave well with WordPress. The tradeoff is that disk enhanced page cache performance under load tests will be decreased by ~20% at scale.
6. Recommended: On the «Minify Settings» tab, all of the recommended settings are preset. If auto mode causes issues with your web site’s layout, switch to manual mode and use the help button to simplify discovery of your CSS and JS files and groups. Pay close attention to the method and location of your JS group embeddings. See the plugin’s FAQ for more information on usage.
7. Recommended: On the «Browser Cache» tab, HTTP compression is enabled by default. Make sure to enable other options to suit your goals.
8. Recommended: If you already have a content delivery network (CDN) provider, proceed to the «Content Delivery Network» tab and populate the fields and set your preferences. If you do not use the Media Library, you will need to import your images etc into the default locations. Use the Media Library Import Tool on the «Content Delivery Network» tab to perform this task. If you do not have a CDN provider, you can still improve your site’s performance using the «Self-hosted» method. On your own server, create a subdomain and matching DNS Zone record; e.g. static.domain.com and configure FTP options on the «Content Delivery Network» tab accordingly. Be sure to FTP upload the appropriate files, using the available upload buttons.
9. Optional: On the «Database Cache» tab, the recommended settings are preset. If using a shared hosting account use the «disk» method with caution, the response time of the disk may not be fast enough, so this option is disabled by default. Try object caching instead for shared hosting.
10. Optional: On the «Object Cache» tab, all of the recommended settings are preset. If using a shared hosting account use the «disk» method with caution, the response time of the disk may not be fast enough, so this option is disabled by default. Test this option with and without database cache to ensure that it provides a performance increase.
11. Optional: On the «User Agent Groups» tab, specify any user agents, like mobile phones if a mobile theme is used.

Часто задаваемые вопросы

Why does speed matter?

Search engines like Google, measure and factor in the speed of web sites in their ranking algorithm. When they recommend a site they want to make sure users find what they’re looking for quickly. So in effect you and Google should have the same objective.

Speed is among the most significant success factors web sites face. In fact, your site’s speed directly affects your income (revenue) — it’s a fact. Some high traffic sites conducted research and uncovered the following:

• Google.com: +500 ms (speed decrease) -> -20% traffic loss
• Yahoo.com: +400 ms (speed decrease) -> -5-9% full-page traffic loss (visitor left before the page finished loading)
• Amazon.com: +100 ms (speed decrease) -> -1% sales loss

A thousandth of a second is not a long time, yet the impact is quite significant. Even if you’re not a large company (or just hope to become one), a loss is still a loss. However, there is a solution to this problem, take advantage.

Many of the other consequences of poor performance were discovered more than a decade ago:

• Lower perceived credibility (Fogg et al. 2001)
• Lower perceived quality (Bouch, Kuchinsky, and Bhatti 2000)
• Increased user frustration (Ceaparu et al. 2004)
• Increased blood pressure (Scheirer et al. 2002)
• Reduced flow rates (Novak, Hoffman, and Yung 200)
• Reduced conversion rates (Akamai 2007)
• Increased exit rates (Nielsen 2000)
• Are perceived as less interesting (Ramsay, Barbesi, and Preece 1998)
• Are perceived as less attractive (Skadberg and Kimmel 2004)

Is this plugin server cluster and load balancer friendly?

Yes, built from the ground up with scale and current hosting paradigms in mind.

What is the purpose of the «Media Library Import» tool and how do I use it?

The media library import tool is for old or «messy» WordPress installations that have attachments (images etc in posts or pages) scattered about the web server or «hot linked» to 3rd party sites instead of properly using the media library.

The tool will scan your posts and pages for the cases above and copy them to your media library, update your posts to use the link addresses and produce a .htaccess file containing the list of of permanent redirects, so search engines can find the files in their new location.

You should backup your database before performing this operation.

How do I find the JS and CSS to optimize (minify) them with this plugin?

Use the «Help» button available on the Minify settings tab. Once open, the tool will look for and populate the CSS and JS files used in each template of the site for the active theme. To then add a file to the minify settings, click the checkbox next to that file. The embed location of JS files can also be specified to improve page render performance. Minify settings for all installed themes can be managed from the tool as well by selecting the theme from the drop down menu. Once done configuring minify settings, click the apply and close button, then save settings in the Minify settings tab.

I don’t understand what a CDN has to do with caching, that’s completely different, no?

Technically no, a CDN is a high performance cache that stores static assets (your theme files, media library etc) in various locations throughout the world in order to provide low latency access to them by readers in those regions.

How do I use an Origin Pull (Mirror) CDN?

Login to your CDN providers control panel or account management area. Following any set up steps they provide, create a new «pull zone» or «bucket» for your site’s domain name. If there’s a set up wizard or any troubleshooting tips your provider offers, be sure to review them. In the CDN tab of the plugin, enter the hostname your CDN provider provided in the «replace site’s hostname with» field. You should always do a quick check by opening a test file from the CDN hostname, e.g. http://cdn.domain.com/favicon.ico. Troubleshoot with your CDN provider until this test is successful.

Now go to the General tab and click the checkbox and save the settings to enable CDN functionality and empty the cache for the changes to take effect.

How do I configure Amazon Simple Storage Service (Amazon S3) or Amazon CloudFront as my CDN?

Участники и разработчики

«W3 Total Cache» - проект с открытым исходным кодом. В развитие плагина внесли свой вклад следующие участники:

Участники

Журнал изменений

0.9.7.2

• Fixed fatal error during media file upload with CDN module active
• Fixed removal of empty values, JSON encoded string in attribute, trailing quote at end of tag, and the handling of anchors in HTML minify
• Fixed undefined index warning
• Fixed fatal error when purging CDN using full site delivery

0.9.7.1

• Fixed undefined variable notice
• Fixed «No such file or directory» warning
• Fixed writing to PHP error log rather than WordPress debug log
• Fixed default referrer policy should be «no-referrer-when-downgrade»
• Fixed php_flag error related to browser cache, using ini_set instead
• Fixed CloudFlare IPv6 check undefined offset
• Fixed Undefined constant WP_ROOT
• Fixed frame-ancestors being overwritten by frame-src
• Fixed missing semicolon in nginx configuration
• Fixed HTTP/2 URLs handling for browser cache and CDN modules
• Fixed display of CDN debug information
• Fixed CSS Minification with Google Fonts when included via «Include external files/libraries» and non-latin character-sets are loaded
• Fixed media query string not updating when all caches were purged
• Fixed double slash with ABSPATH if file exists
• Fixed setting max-age and expires header simultaneously
• Fixed SASL detection for PECL Memcached
• Fixed handling of manually entered objects to be purged on CDN
• Fixed query string handling in Nginx
• Improved error handling with Cloudfront
• Improved page cache logging
• Improved multi-tenant support for memory-based caching engines
• Improved CSS minification
• Improved purge behavior for changed media objects when using CDN
• Improved compatibility with sitemap plugins
• Added support for Memcached for Nginx
• Added support for caching webm files
• Added Brotli HTTP compression support
• Added StackPath full site delivery support
• Added wc_session to the list of ignored query stems for improved WooCommerce compatibility

0.9.7

• Fixed minified files not being hosted by CDN when enabled if «host minified files» is disabled
• Fixed warning thrown when purge all was selected (via nigrosimone)
• Fixed undefined offset error in fragment cache
• Fixed MaxCDN test button failure when debug mode is enabled
• Fixed purging of feeds when cache feeds option is enabeld
• Improved handling of errors when full site delivery isn’t set
• Improved nginx.conf to support xml caching
• Improved nginx.conf to support HSTS for static files
• Improved minify’s handling of query strings
• Improved database caching, frequent wp_options no longer flush posts or comments data
• Improved Limelight Networks CDN integration
• Improved FAQ, they’re now hosted in the GitHub public repository
• Improved handling for /
• Added flushing of AMP pages

0.9.5.2

• Fixed security issue by protecting configuration data by adding .php to relevant files
• Fixed security issue with the creation of dot folders that could be abused
• Fixed handling HTTP compression for uncached pages
• Fixed handling of .svgz files
• Added expiration headers to webP images
• Added support for Microsoft Azure’s latest API
• Added ability to cache WP Admin. Recommended setting, is off. (Improved WP Admin performance with object caching enabled)
• Added HTTP/2 Push support for minified files
• Added option management support for wp-cli
• Improved handling of uncompressed minified files
• Improved handling of purging of modified pages / posts
• Improved compatibility with Rackspace Cloud Files
• Improved initial CDN configuration reliability
• Improved reliability of object caching
• Improved PHP 7.0 compatibility
• Improved PHP 4.3 compatibility
• Improved HTTP/2 support
• Improved CSS embed handling
• Improved reliability of object cache, transients now fallback to database
• Improved handling of cached http compressed objects

0.9.5.1

• Fixed missing namespace, which caused issues with other implementations of Google APIs
• Fixed handling Cloudflare zone list being incomplete for users with many zones
• Added extension to support Accelerated Mobile Pages (AMP)
• Added notification for users that are still using PHP 5.2 (end of life in 2011)
• Improved default settings
• Improved compatibility with Yoast SEO sitemap caching
• Improved compatability with Jetpack
• Improved directory handling on IIS
• Improved backwards compatibility for 3rd party implementations against legacy W3TC functions

0.9.5

• Fixed XSS vulnerability
• Fixed issues with dismissing overlays
• Fixed handling of tilde in URLs
• Fixed issue with HTTP compression header when using mfunc calls
• Fixed cache ID issue with minify in network mode
• Fixed rare issue of caching empty document when some PHP errors occur in themes or plugins
• Fixed caching of query strings
• Added support for APCu Opcode Cache
• Added support for Redis
• Added support for Google Drive
• Added support for Amazon S3-compatible stroage services
• Added support for PECL memcached
• Added support for srcset elements
• Added support for Rackspace CDN Origin Pull
• Added support for minification of external fonts
• Added support for WOFF2 font format
• Added support for FTPS (FTP-SSL, S-FTP)
• Added YUI Compressor’s PHP Port of the CSS minifier
• Added Narcissus’ JS minifier
• Added purge of parent page when attachments are added or updated
• Added Highwinds CDN provider
• Added «Validate Timestamps» option for compatible opcode caches functions like apc.stat are enabled
• Added Full Site Delivery for Pro subscribers
• Added HTTP Strict Transport Security (HSTS) support
• Added a sample extension for developers to reference
• Added Rackspace Cloud Files Multi-Region Support
• Added more support for exclusions to database cache
• Added more optionality to minifiers
• Added WPML Performance Extension
• Added use of namespace which creates mininum dependency on version PHP 5.3
• Improved PHP 5.6 compatibility
• Improved PHP 7 compatibility
• Improved performance menu in admin bar, including purging of specific cache engines and more
• Improved SSL interoperability
• Improved reliablity of test buttons
• Improved nomenclature of caching files for higher cache hit rates
• Improved nginx compatibility
• Improved WP CLI support
• Improved Cloudflare compatibility (now using latest APIs), Cloudflare must be re-authorized
• Improved AWS API compatibility (now using latest APIs)
• Improved Rackspace Cloud Files compatibility (now using latest APIs)
• Improved page cache purge for extensions like cloudflare and other reverse proxy use cases
• Improved extension framework functionality
• Improved compatibility of headers like ETag and content encoding
• Improved template fragment caching
• Improved notifications, warnings and errors
• Improved moble user agents detection
• Improved security with nonces and form elements
• Improved security throughout the codebase
• Improved detail of debug messages
• Improved Amazon SNS security (validation)
• Improved minify’s ability to match script tags without type attribute

0.9.4

• Fixed undefined w3tc_button_link
• Fixed support and other form submissions
• Fixed extension enabled key error
• Fixed Test CDN errors
• Fixed trailing slashes in custom wp content path and Minify
• Fixed WP_PLUGIN_DIR not being available when object-cache.php is loaded and W3TC constant not set
• Fixed Minify Auto and restructuring of JS code placement on page
• Fixed remove / replace drop in file on plugins page
• Fixed false positive check for legacy code
• Fixed deprecated wpdb escape
• Fixed Fragment Caching and APC anomalies
• Fixed cached configs causing 500 error on interrupted file writes
• Fixed readfile errors on servers with the functionality disabled
• Fixed false positives for license key verification
• Fixed debug information not printed on cached pages
• Fixed backwards compatibility and flushing and added doing it wrong notification
• Fixed «Prevent caching of objects after settings change»
• Fixed «Use late init» being shown as enabled with Disc:Enhanced
• Fixed missing param in APC cache method declaration
• Fixed user roles property not begin an array
• Fixed adding empty Vary header
• Fixed notice on failed upgrade licencing check
• Fixed Database Cache description text
• Fixed duplicate bb10 agents
• Fixed settings link in Minify Auto notification
• Fixed notice with undefined constant
• Fixed nginx configuration and Referrer, User Groups setting
• Fixed Genesis settings and Suhosin field name limit error
• Fixed Genesis and Fragment Caching (caching categories etc)
• Fixed CDN being enabled when creating NetDNA / MaxCDN pull zone
• Fixed NewRelic related notice in compatibility popup
• Fixed trailing slash issue in filename to url conversion
• Fixed issue with wp in subdirectory and relative minimal manual urls
• Fixed issue with widget styling
• Fixed issue with Purge All button action
• Fixed issue with exporting of settings
• Fixed issue with plugin interferring with preview theme
• Fixed issue with malformed config files
• Added caching of list of posts pages (tags, categories etc) to Genesis extension a long with flush it checkbox
• Added typecasting on expiration time in object cache drop-in
• Added capability check for save options
• Added FeedBurner extension
• Added woff support to Browser Cache
• Added new CloudFlare IPs
• Added support for WordPress defined charset and collate in CDN queue table creation
• Added WordPress SEO by Yoast extension
• Added *.less to CDN theme uploads and MIME
• Added default settings for MaxCDN Pull Zone creation
• Added call to change MaxCDN canonical header setting to match plugin setting
• Added one button default pull zone creation to MaxCDN without refresh
• Added MaxCDN authorization validation
• Added whitelist IPs notification for MaxCDN
• Added support for use of existing zones without refresh
• Added new mime types
• Added support for separate domains for frontend and admin backend
• Added CloudFlare as an extension
• Added nofollow to blogroll links
• Added DEV mode support to PRO version
• Added EDGE MODE functionality
• Improved wrapper functions in plugins.php for plugin / theme authors
• Improved reliability of NetDNA / MaxCDN API calls by using WP HTTP and not cURL
• Improved Fragment Caching debug information
• Improved preview mode, removed query string requirement
• Improved FAQ structure
• Improved empty minify/pgcache cache notification when using CDN
• Improved default settings for MaxCDN zone creation
• Improved CDN queue performance
• Improved blogmap url sanitation
• Improved MaxCDN automatic zone creation process
• Improved license key saving and Pro mode activation on Pro license purchases
• Updated EDGE MODE: Full site mirroring support for MaxCDN
• Updated translations

Как я писала в предыдущей статье, в моей жизни, помимо хакерских нападений на блог, происходит много хорошего и светлого. Рука помощи, протянутая Романом Теличко как будто случайно, а на самом деле неслучайно, – только одно из таких событий (вот ссылка на его сайт http://romantelychko.com — можете познакомиться с тем, чем занимается Роман). Справедливости ради, должна сразу сказать, что не только он один примчался учить меня уму-разуму, как поставить надежную защиту блогу. Но позвольте не смешивать все и всех, потому что сегодня расскажу, какой он дал мне мастер-класс по настройке плагина W3Total Cache и проиллюстрирую его же скриншотами. Невероятно, но в Интернете оказалось очень много людей, которые борются с . Роман — один из них.

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

Если вы давно хотите установить плагин W 3 Total Cache, то эта статья как раз для вас. Как скачать плагин, все знают:

ПЛАГИНЫ – ДОБАВИТЬ НОВЫЙ – ввести в окно поиска W3 TOTAL CACHE – ЗАГРУЗИТЬ — УСТАНОВИТЬ – АКТИВИРОВАТЬ

Но!!! «Единственная проблема в том, что настройка этого плагина часто зависит от возможностей и настроек как сервера, так и вообще сайта, на котором это всё происходит. Помните, что я спросил у Вас в первую очередь? Какие методы кэширования доступны?» (цитата из переписки с Романом). Будем считать это отправной точкой. Данные настройки плагина W3 TOTAL CACHE в описанном случае выполняются при методе кэширования Opcode: Alternative PHP Cache (APC) . Возможные варианты (методы) у себя я увидела, уже установив плагин. И еще один очень важный момент: не давайте странице переводиться на русский , если работаете в браузере Google Chrome. Плагины любят родной язык.

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

01. Меню плагина w 3 cache

В таком порядке и пойдем.

Это общий вид того, что у нас должно получиться после настройки плагина w 3 total cache.

03. Page Cache — w3 total cache

Теперь и в минимизации проставляем те же параметры, что и на изображении.

04. Minify — W3 Total Cache

Дошли до базы данных. Обратите внимание, что время по умолчанию выставлено другое. Ставим свое.

05. Database Cache — W3 Total Cache

Объекты кэширования. Здесь тоже не забываем сверять указанное по умолчанию время и исправляем на свое:

06. Object Cache — W3 Total Cache

Вот и все. Когда все настройки будут выполнены, нужно подняться наверх страницы и включить плагин. Обязательно через просмотр. Сначала нажимаем preview , а только потом, когда в соседней вкладке страница полностью успешно загрузится, deploy . И так после внесения дополнительных изменений в любой блок. Просмотреть — включить! Заодно можете просмотреть код страницы моего блога и своего. Если разницу найдете, напишите в комментарии, пожалуйста. Это я так утонченно хвастаюсь. 🙂

Всем желаю грамотно оптимизированных блогов, высокой степени безопасности в Интернете и побольше хороших людей рядом!

P.S. Пожалуйста, обратите внимание на комментарии. Там обсуждается много нужных нюансов.

А еще предлагаю на минутку отвлечься от серьезных дел и прочитать , которое было мной написано в рамках конкурса, проводимого Devaka (Сергеем Кокшаровым) и биржей Rotapost на стыке 2014 и 2015 годов. 🙂 Приз хочу!!!

Плагин W3 Total Cache делает Ваш сайт или блог реально быстрым, один из лучших плагинов для оптимизации WordPress. Солидные сайты mashable.com, smashingmagazine.com, yoast.com спокойно используют его в своих инструментах. Использование плагина W3 Total Cache на Вашем ресурсе повышает удобство работы вашим пользователям за счет повышения производительности сервера, кэширования каждого элемента, сокращения времени загрузки страниц, выдавая пользователю нужный ему материал буквально молниеносно.

Чтобы ощутить все прелести этого плагина, давайте для начала протестируем существующую ситуацию. Я выбрал один из последних сайтов, который я сделал, добавил приложение в Firefox YSlow Addon for Firefox которое покажет время загрузки сайта, у меня на данный момент оно составляет 8,5 сек – я был в шоке!

Изменим эту ситуацию!

1. Перед установкой плагина Вы должны убедится, что любые другие плагины кэширования полностью удалены, в противном случае плагин W3 Total Cache при активации выдаст ошибку.
2. Если все в порядке устанавливайте плагин (не в курсе как устанавливать плагины в WordPress? — читайте ).
3. Официальная страничка плагина в каталоге WordPress.
4. После того как Вы активируете плагин в панели управления появится новый пункт «Perfomance», нажимая на который мы попадаем на страницу настроек и конфигурации плагина W3 Total Cache.

Настройки и конфигурация W3 Total Cache

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

Вкладка General

Первым делом на странице настроек мы попадаем в раздел основных настроек General. Сразу же отключаем режим просмотра (см. картинку) нажатием на кнопку disable (то есть плагин будет работать в режиме реального времени, а не в режиме просмотра).

Следующая опция в этом списке Page Cache. Эта раздел работает так же как в плагине WP Super Cache – создается кэш для статических страниц, включая эту опцию Вы значительно уменьшите время загрузки, рекомендуется использовать диск Enchanced.

После блока Page Cache идет блок Minify – позволяет минимизировать файлы.css, .js, .html также записи, страницы и RSS. Опции обязательно отметьте как на скриншоте. Принцип действия мимнимизирования заключается в том, что удаляются бесполезные расстояния между тегами кода такое действие ускоряет время загрузки сайта на 10%.

Следующий блок опций Database Cache. Обязательно должен быть разрешен, так как CMS WordPRess полностью работает на базе данных и часто высокие нагрузки запросов к БД являются причиной жесткого замедления сайта + если у Вас большой трафик, то это вообще катастрофа. Включение опции может ускорить Ваш сайт в 100х раз.

Не расслабляемся и двигаемся к блоку Object Cache. Галочка в этом блоке увеличивает производительность динамических сайтов использующих API кэша объектов. Окончательные настройки должны выглядеть как на скриншоте:

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

Следующий этап это CDN (Content Delivery Network), к сожалению плагин поддерживает только платные варианты CDN: MaxCDN, NetDNA, Amazon S3, Rackspace Cloud и Amazon Cloud. Если Вы не знаете что такое CDN или не планируете его использовать, то советую сразу же галочку снять.

Далее идет блок Varnish – еще один замут с кэшированием типа CDN и блок Network Perfomance & Security powered by CloudFlare. Ими можем не пользоваться, убираем галочку с Enable. Эти блоки целесобразно использовать, если Ваш ресурс мега посещаем от 1000 и более посетителей — эти CDN, бесплатны, но если у Вас будет такое количество посетителей на сайте не лишним будет раскошелится на 40$ и подключить систему доставки контена (CDN) MaxCDN — очень хорошая и с поддержкой, об них я чуть попозже напишу отдельную статью.

Блок настроек Miscellaneous галочки ставим как на скриншоте ниже и если у Вас есть Page Speed Online API от Google, что можете его здесь ввести.

В блоке настроек Debug не советуют вообще что-то отмечать галочками, послушно поверим

И последний блок это импорт и экспорт настроек, можно сохранить настройки нажав кнопочку download на компьютер, можно и импортировать уже существующие настройки, в общем ничего сложного

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

Вкладка Page Cache

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

В блоке Advanced мы можем выбрать время жизни странице в кэше, по умолчанию 3600 секунд, можете уменьшить (если Вы постоянно работаете над сайтом) или увеличить если изменения происходят редко. Далее можно задать не посылать кэш страницы Bot’у Google – не рекомендуется. Можем отметить страницы которые мы бы не хотели видеть в кэше. В настройках этого блока желательно придерживаться скриншота.

И последний блок настроек в этой вкладке Purge Policy – более определенный выбор страниц копии которых нужно создать в кэше.

Вкладка Minify

Более подробная минимизация (уменьшение размеров) файлов, в первом блоке настроек отмечаем галочкой перезаписывать структуру URL:

Следом настраиваем блок JS, можно добавить разные файлы скриптов для кэширования добавив их через кнопку «Add a script»

И в последнем блоке Advanced мы можем выбрать через какое время обновлять файлы шаблона

Вкладка Database Cache

Медленно, но уверено, главное до конца доползти. Блок настроек General как на скриншоте:

Блок настроек Advanced можете установить время жизни копии кэша

Вкладка Object Cache

Оставляем все здесь по умолчанию.

Вкладка Browser Cache

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

Так и последним шагом будет нажатие кнопочки «Empty page cache» — нужно очистить кэш, после этого Вы увидите зеленое слово «Enable», которое говорит о том, что плагин успешно функционирует.

Заключение

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

Удачи! Если возникли какие-то вопросы, задавайте их в комментариях.

Часто возникает вопрос: «Какой плагин круче W3 Total Cache или WP Super Cache?». Важно понимать, что все нужно проверять самому, одно скажу точно: «если не использовать CDN в W3 Total Cache и в WP Super Cache, то скорость загрузки примерно одинакова». Выбор за Вами, можете подробнее прочитать о плагине WP Super Cache.