Главная » Создание сайта на Wordpress, раскрутка сайта, поисковое продвижение и сопровождение

W3 Total Cache — установка и настройка плагина кэширования для WordPress

W3 Total Cache установка и настройка

Я уже написал немало статей про оптимизацию скорости работы сайта. Среди них были статьи про то, как сжать HMTL код, сократить CSS-стили и закодировать JavaScript, для уменьшения его объема. Кроме этого были статьи и про оптимизацию размера изображений. Но инструмент Google Page Speed упорно не хотел выдавать максимальные баллы по скорости загрузки страницы и методично жаловался на то, что необходимо Сократить время ответа сервера. Именно для решения данного вопроса и был установлен плагин кэширования W3 Total Cache.

Плагины кэширования для ускорения скорости генерации страницы

Хотелось бы сразу сказать, что на данном сайте используется плагин WP Super Cache. Выбор этого плагина будет объяснен чуть позже. Кроме этих двух плагинов, есть еще как минимум два довольно известных, каждый из которых довольно часто становится машиной для драг рейсинга, чтобы выяснить, какой же из плагинов наиболее производительный. Лично я работой W3 Total Cache очень доволен, но до этого мы доберемся, а пока что коротко о том, что делают эти плагины. Плагины кэширования, как и следует из названия, кэшируют страницу вашего сайта и сохраняют его на жестком диске вашего хостинга. В чем же выигрыш от такой процедуры. Так как наш любимый WordPress полностью сидит на считывании всех данных с базы SQL, а на фронтэнде большинства серверов установлен могущий, но довольно медлительный Apache, то время, которое необходимо чтобы построилась целая HTML страница, для построения которой необходимо послать немало десятков запросов в SQL, оказывается довольно существенным. Это время ответа сервера, время генерации страницы. Ну для справки, Page Speed настроен таким образом, что при превышение скорости ответа сервера в 200 мс, будет возмущенно ругаться на Ваш. А если это так, то возможно это грозит некоторым проседанием в поисковой выдаче, так как скорость загрузки страницы так же является одним из факторов ранжирования.

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

Установка и настройка плагина W3 Total Cache

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

Для установки W3 Total Cache на WordPress необходимо либо самому скачать плагин с официального сайта WordPress, после чего перенести в папку plugins, либо воспользоваться стандартным поисковиком плагинов в админке Вашего WordPress, где найти плагин W3 Total Cache и нажать кнопку Установить. После этого необходимо выставить права доступа 777(это полные права доступа для абсолютно всех) для папок wp-content и wp-content/uploads. Зачем ему понадобилась вторая папка я не смог понять, так как ничего там и не появилось, но не это не суть, так убрать эти права доступа можно сразу же после того, как вы активируете этот плагин. Лично я не убирал права доступа до окончания первичной настройки, так как плагин подарил мне немалые проблемы.

После активации плагина лезем в меню Performance и далее открываем раздел General Settings. Тут будут перечислены множество различных возможностей данного плагина, нужные из которых вы можете настроить и немного настроить. Вот краткий список всех возможностей:

  • Само кэширование страницы
  • Минификация(html, css и js). То что можно сделать вручную, может сделать и данный плагин.
  • Кэширование запросов к Базе Данных.
  • Object Cache — не вникал что такое.
  • Browser Cache — кэширование браузером определенных файлов — то что настраивается несколькими строчками в .htaccess в случае с сервером Apache.
  • CDN — распаралеливание загрузки изображений с разных доменов. Так как по спецификациям http браузер может параллельно загружать только два объекта с одного домена, то раскидывание многих файлов и изображений по различным поддоменам и специальным сайтам, может увеличить скорость загрузки страницы.
  • И прочая бурда.

Для каждого из приведенных и неприведенных здесь возможностей плагина имеется собственная вкладка, для более детальной настройки. Я же скажу пару слов только про вкладку Page Cache — кэширование страниц сайта. В первом блоке General данной вкладки вы можете указать какие страницы и для каких пользователей включить кэширование. Думаю тут разберетесь сами, ведь чисто логически можно понять, что кэшировать страницу 404 не имеет никакого резона.

Следующая функция Cache Preload — это то, что мне особенно нравится в W3 Total Cache. Данная функция основываясь на данных файла sitemap.xml создает кэш заданного количества страниц через каждый заданный промежуток времени. Благодаря этому, ваш сайт полностью окажется в кэше через какое-то время(зависит от размера вашего сайта). В отличии от WP Super Cache, который так же предлагает такую функцию, она здесь действительно работает. Так как Super Cache при нескольких попытках заставить его закэшировать весь сайт(было испробовано на двух различных сайтах), только делал вид, что занят работой. На деле же кэш вообще не пополнялся.

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

Последний пункт называется Advanced и особо интересен он тем, что в нем можно настроить время жизни кэша, которое по умолчанию, если не ошибаюсь, установлено на уровне 5-10 минут, не помню уже. А еще он интересен тем, что первый же пункт, который судя по всему включает все это дело, не активен. Но все же потыкайтесь в пункт под названием Garbage collection interval и проверьте что будет, если из другого браузера(в режиме инкогнито будет еще лучше) зайти на закэшированную минут 10-15 назад страницу, после чего поглядеть комментарий в конце кода страницы с указанием время создания кэша. Если время обновилось и стало равным времени вашего посещения, то увы, плагин либо косячный, либо хочет деньги за свои услуги.

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

Проблемы с W3 Total Cache

Начнем наверное с того, что я опишу конфигурацию сервера, на котором стоит сайт под управлением W3 Total Cache и к которому был присобачен данный плагин. Это VPS под управлением ОС CentOS 6,5, где бэкэндом установлен тягучий Apache, а на фронтэнде уютно разместился быстрый и юркий Nginx. Кроме этого установлен eAccelerator, для кэширования запросов в БД, что в купе с не с самыми кривыми руками позволяет иметь необходимость только в первой и самой важной функции плагина W3 Total Cache. Отсюда хотелось бы сразу отрезать комментарии и высказывания по поводу того, что, возможно, W3 Total Cache работает в чем то хуже других аналогичных плагинов, так данный плагин(именно W3 Total Cache) может похвастаться полной совместимостью с Nginx, в то время как все остальные плагины добавят свои коды в файл .htaccess и с явным недоумением будут ждать, пока администратор перепишет эти реврайты на понятном для Nginx языке. Последнее, надо сказать, мне не удалось. Точнее мне не удалось найти рабочие реврайты, которые заставили бы дружить Super Cache и Nginx. Возможно он и к лучшему, так как сейчас я бы с радостью сменил Super Cache на данном блоге на W3 Total Cache. Но, в семье не без уродов, да и W3TC не такой уж и безобидный. Этим абзацем я заканчиваю монолог о том, что необходимо делать с сервером Nginx для кэширования страниц сайта.(Всегда рад услышать другие методы кэширования).

Итак, проблем в процессе знакомства W3 Total Cache с Nginx`ом, да и тем более с Apache ни у кого не должно возникнуть, а потому перейдем к решению проблемы с невозможностью сменить время жизни кэша, а так же с тем, что W3 Total Cache полностью отказывается слушать все внесенные настройки, такие как запрет на кэширование страниц с запросами(страницы поиска) и запрет на кэширование для пользователей. Если с последними двумя я так и не разобрался, хоть и добрался до ручной правки файла конфигурации(кстати, находится по адресу wp-content/w3tc-config/master.php), то с первым удалось совладать. Хотел бы сказать, что изменение внесенные в админке этого плагина, как правило, сохраняются в этом файле, но лучше перепроверить, благо каждая переменная имеет говорящее название. Из всех переменных меня заинтересовала переменная pgcache.late_init(скорее всего от Late initialization — тот самый пункт, который не активен), которой я сразу же выставил значение true, а так же параметр pgcache.cache.nginx_handle_xml, после выставления которому значения true, плагин наконец-то начал слушать то число, которое введено в поле про максимальное время жизни кэша. Проверка показала, что после данных изменений, на озвученном выше сервере, время жизни кэша действительно стала совпадать с указанным пользователем значением.

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

Вспомнив про мобильную версию сайта хотелось бы сказать, что плагин умеет кэшировать и данную версию, причем отдельно, что не может не радовать. Для этого необходимо перейти во вкладку User Agent Groups и поставить две галочки напротив пунктов Enable. В каждом из пунктов вы можете добавить свою юзер-агенты для каких-то новых устройств. Кэш мобильной версии сохраняется в той же папке страницы, что и кэш основной версии. Отличие только в добавлении постификсов high и low(так называют группы по умолчанию). Вы, кстати, можете добавить и свои группы. Единственный минус с мобильной версией состоит в том, что плагин не умеет самолично создавать кэш мобильной версии сайта, что означает что это будут делать только ваши пользователи(или Вы).

Следующей проблемой с W3 Total Cache стала то, что на данном сайте сразу после активации данного плагина и активации функции кэширования, весь сайт погряз в кракозябрах, что говорит о проблемах  W3 Total Cache с кодировкой. На сайте используется кодировка UTF-8 и даже в настройках плагина мелькает эти символы. Однако как активация пункта Disable UTF-8 blog charset support, так и его деактивация, не принесла никаких плодов. Далее в недрах Интернета была найдена подсказка, что нужно добавить строку AddDefaultCharset UTF-8 в начало файла .htaccess, но и данный способ на смог помощь. А так как дальнейшие поиски не привели ни к чему стоящему и был установлен WP Super Cache(который по первому взгляду, не лишен некоторых вышеописанных проблем, но об этом возможно позже).

Кодировка W3 Total Cache, дружба W3 Total Cache с Nginx, мобильная версия сайта… Ну, вроде ничего не упустил из того, чего понабрался во время знакомства с этим инструментом, который, надо сказать, со своим делом справляется весьма неплохо. Если страницы вышеозвученного сайта, судя по статистике от Pingdom.com, грузились от 1-2 секунд, то сейчас этот показатель для закэшированной страницы составляет 0,5-0,7 секунд. Если же обратиться к Page Speed от уважаемого Google, то можно напороться только на предупреждения о том, что ресурсы, скрипты и прочий хлам которых загружаясь вместе с данной страницей, являются единственным отрицательным моментом в безупречной технической оптимизации сайта. И интересно то, что гугл ругается на скрипт JQuery, который загружается из репозитория … да, именно, с репозитория гугла. Им бы самим заняться этим вопросом.

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

 

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

Ваш комментарий появится после модерации.