Лучший плагин кеширования WordPress — W3 Total Cache

W3 Total Cache - плагин кеширования WordPress Привет, друзья. Вчера совершенно случайно узнал, что Google выпустили плагин для WordPress, который реализует lazy-load загрузку изображений (но разговор не об этом, хотя про lazy-load я еще расскажу дальше). Я сразу установил этот плагин и решил посмотреть, как это влияет на оценку скорости в PageSpeed Insights, и обратил внимание на целую пачку замечаний и рекомендаций, из-за которых оценка скорости оставалась низкой (около 70).

С момента появления моего блога я использовал плагин кеширования WP Super Cache, который меня полностью устраивал…до вчерашнего дня. Не смотря на свою изначальную неповоротливость, WordPress начинает быстро работать после включения кеширования (это и решал плагин WP Super Cache), но со временем поисковики выдвигают все новые требования, и вот у меня появились следующие проблемы:

  • Устраните ресурсы, блокирующие отображение,
  • Используйте современные форматы изображений,
  • Удалите неиспользуемый код CSS,
  • Настройте показ всего текста во время загрузки веб-шрифтов,
  • Минимизируйте работу в основном потоке,
  • Сократите время выполнения кода JavaScript,
  • Отложите загрузку скрытых изображений,
  • Задайте правила эффективного использования кеша для статических объектов,
  • Уменьшите размер кода CSS,
  • Уменьшите размер кода JavaScript,
  • Включите сжатие текста.

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

В процессе поиска я наткнулся на классную статью на Хабре, где ребята подробно разобрали вопрос оптимизации скорости загрузки сайта на WordPress, а главное, представили большую итоговую таблицу с оценками:

Плагин или связка плагиновRoleИТОГServer CacheClient CacheOptimizeManage
LiteSpeed Cache + Hyper Cache Extended + Autoptimize + Speed Up – Browser Caching (Bundle)Full96%98%71%100%100%
BreezeFull93%95%71%97%75%
WordPress Cache and CDN Plugin + Autoptimize (Bundle)Full90%98%100%83%75%
Autoptimize + Cache Enabler + Speed Up – Browser Caching (Bundle)Full88%98%71%83%100%
W3 Total CacheFull84%55%100%100%100%
WordPress Cache and CDN PluginFull82%98%100%67%75%
LiteSpeed Cache + WP Fastest Cache (Bundle)Full79%50%71%100%100%
WP RocketFull76%50%71%95%100%
WP Speed of LightFull70%50%71%83%100%
Yasakani CacheFull64%98%0%53%75%
Hummingbird Page Speed OptimizationOptimize53%48%71%50%100%
WP Fastest CacheFull52%50%71%47%100%
Cache EnablerServer Cache48%95%0%20%100%
LiteSpeed CacheOptimize47%2%71%70%100%
AutoptimizeOptimize44%2%36%73%100%
Powered CacheFull44%50%71%30%100%
Hyper CacheServer Cache43%95%0%10%100%
Hyper Cache ExtendedServer Cache43%95%0%10%100%
Simple CacheServer Cache43%95%0%10%100%
Super Static CacheServer Cache43%95%0%10%100%
WP Super CacheServer Cache43%95%0%10%100%
Fast Velocity MinifyOptimize36%2%0%65%100%
WP Performance Score BoosterClient cache31%23%71%30%0%
Speed Booster PackOptimize27%0%0%52%50%
Comet CacheFull27%25%0%30%100%
Speed Up – Browser CachingClient cache23%0%71%30%0%
Gator CacheServer Cache20%48%0%0%100%
CachifyFull16%25%0%10%50%
Cache-ControlClient cache3%0%29%0%0%

В поле Role указано, какой спектр задач покрывает плагин или связка для обеспечения качественного кеширования (Full – значит плагин умеет все, что касается кеширования):

  • Server cache (кеш на стороне сервера):
    • Page load time (время загрузки страницы) – один из самых важных параметров. Чем меньше время, тем быстрее клиент получает ответ.
    • Caching method (способ хранения) – максимальное сохранение всех подготовленных объектов HTML, JS, CSS, желательно еще и в сжатом состоянии для экономии времени обработки на сервере и увеличения скорости выдачи результата.
  • Client cache (кеш на стороне клиента):
    • Возможность управлять кешем браузера клиента. При его активации повторный запрос на сервер даже не придет, что благоприятно влияет на его производительность.
  • Optimize (оптимизация):
    • Combine (слияние) – загрузка одного общего JS (или CSS) вместо нескольких.
    • Inline (включение) – содержимое CSS вставляется в HTML, что уменьшает число обращений к серверу.
    • Postpone (отложенная загрузка) – отложенная загрузка JS скриптов, не влияющих на начальное отображение страницы. Важнейшая метрика, влияющая на скорость загрузки страницы пользователю. JS лучше отложить, чем включать напрямую в HTML, т.к. это приведет к существенному увеличению объема HTML.
    • Minify (минификация) – в содержимом HTML, JS и CSS зачастую есть лишние части, такие как пробелы, переносы строк, комментарии. Их лучше убирать, чтобы еще больше снизить размер объектов.
    • Compress (сжатие) – сжатие данных алгоритмом GZip (Deflate) для уменьшения объема передаваемых данных. Т.к. HTML, JS и CSS, по сути, текстовые форматы, то они хорошо сжимаются.
  • Manage (управление):
    • Refresh (обновление) – когда запрашиваемый объект изменился (например, добавилась новая статья), объект в кеше нужно пересоздать, иначе пользователям будет отправляться неактуальная информация. Хорошие плагины настроены на авто обновление кеша при наиболее очевидных событиях. И всегда должна быть возможность сбросить кеш целиком вручную.
    • Exclude (добавление исключений) – иногда нужно исключать некоторые объекты и страницы из кеширования для устранения проблем, необходимо управление этим.

По каждому из этих параметров плагины получали оценки.

В лидерах оказались не отдельные плагины, а связки из 2, 3 и даже 4 дополнений. Хоть я в этом и неплохо разбираюсь, но даже для меня это слишком – взять и с первого подхода все настроить корректно, чтобы получить нужный результат в виде повышения скорости, а не кучи проблем. Я выбрал для себя решение, чтоб «все в одном» и находящееся в топе рейтинга.

Этим решением оказался плагин W3 Total Cache. Я про него слышал ранее, и то, что плагин существует давно и до сих пор активно развивается – весомый аргумент. Очевидное преимущество W3 Total Cache против моего любимого WP Super Cache – он не только обеспечивает кэширование на стороне сервера, но оптимизирует ресурсы и кеширует на стороне клиента (браузера) – короче, это целый фреймворк.

Я решил попробовать: отключил старый плагин и активировал W3 Total Cache.


Настройка W3 Total Cache

Бывают простые и понятные плагины, которые позволяют в несколько кликов все настроить и забыть. Среди просмотренных мною в процессе поиска были и такие, но W3 Total Cache другой. Он не имеет привлекательного интерфейса и выглядит аскетично в духе старых версий WordPress, в нем хренова гора настроек, галочек, селектов – просто глаза разбегаются. Вот уж точно не разобраться с первого подхода, особенно, если вы не искушенный администратор. Но я уже принял вызов и был обязан его победить.

Именно по этой причине я решил подробно рассказать, как правильно настроить плагин W3 Total Cache для WordPress.

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

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

Главный экран W3 Total Cache

Сразу рекомендую проверить совместимость плагина и настроек сервера «Compatibility Check» (слева вверху). Допустимо, если какие-то пункты там будут в статусе «Not installed», по этому поводу всегда можно написать хостеру и попросить установить/активировать расширения. Главное, чтобы зелеными были следующие пункты: zlib extension, Opcode cache, Memcached extension, Memcache extension, а также все пункты (кроме последнего) под заголовком WordPress Resources.

Теперь можно переходить непосредственно к настройкам.

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

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

Небольшое отступление, которое повлияет на ваши дальнейшие настройки. Я буду рекомендовать выбрать метод кеширования Memcached, вместо Disk. Но есть несколько условий, когда это уместно и выгодно. Разница заключается в том, что при выборе Memcached кеш будет храниться в оперативной памяти сервера, а при Disk – на винчестере. Если у вас выделенный сервер, а на них обычно всегда много оперативки, Memcached оправдан, но, если у вас обычный шаред хостинг (образно говоря, недорогой тарифный план, где выделяется пара гигов оперативки), лучше выбирать Disk, иначе кеш забьет всю память. Если у вас SSD дисковая подсистема, то разницы между хранением на диске или в памяти вы не увидите (я экспериментировал). Итого: если у вас выделенный дорогой сервер – Memcached, если недорогой обычный хостинг – Disk.

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

  • Page Cache: Enable
  • Page Cache Method: Memcached
  • Minify: Enable
  • Minify mode: Auto
  • Minify Cache Method: Memcached
  • HTML minifier: Minify (default)
  • JS minifier: JSMin (default)
  • CSS minifier: Minify (default)
  • Opcode Cache: Opcode: Zend Opcache
  • Validate timestamps: Enable (активируется сами, при выборе предыдущего пункта)
  • Database Cache: Enable
  • Database Cache Method: Memcached
  • Object Cache: Enable
  • Object Cache Method: Memcached
  • Browser Cache: Enable
  • CDN: я не использую CDN, потому данные настройки не активировал. Но если вы будете использовать, ставьте галку «CDN: Enable» и «CDN Type: StackPath (recommended)»
  • Fragment Cache Method: Memcached (хотя это не будет работать без PRO подписки).
  • Здесь все, нажимайте «Save all settings».

Page Cache (Кеш страниц)

Ставим галки для следующих пунктов:

  • Cache posts page
  • Cache feeds: site, categories, tags, comments
  • Cache SSL (HTTPS) requests
  • Cache URIs with query string variables
  • Cache 404 (not found) pages
  • Don't cache pages for logged in users
  • Memcached hostname:port / IP:port: будет заполнено по умолчанию «127.0.0.1:11211», ваша задача нажать на «Test» и на зеленом фоне увидеть «Test passed»
  • Use persistent connection

Отдельно выделю пункт «Rejected user agents». Если вы используете какой-либо плагин, создающий мобильную версию сайта, надо заполнить это поле следующими юзерагентами, иначе у вас закешируется десктопная версия сайта и всем мобильным пользователям будет показываться именно она вместо мобильной:

iPhone
iPod
Android
BB10
BlackBerry
webOS
IEMobile/7.0
IEMobile/9.0
IEMobile/10.0
MSIE 10.0
iPad
PlayBook
Xoom
P160U
SCH-I800
Nexus 7
Touch

Но если у вас шаблон с адаптивной версткой, не заполняйте это поле.

Тут все, нажимайте «Save all settings».


Minify (Минификация HTML, CSS и JS)

Ставим галки для следующих пунктов:

  • Rewrite URL structure
  • HTML minify settings: Enable
    Настройка минификации HTML
  • JS minify settings: Enable
    Настройка минификации JS

    Обратите внимание! После минификации JS-скриптов может что-то сломаться (перестанет работать какая-то функция сайта, например, раскрываться меню, работать всплывающие лайтбоксы или еще что), поэтому после завершения всех настроек, обязательно пробегитесь по разным страницам сайта, нажмите все кнопки, отправьте формы, раскройте меню и т.д. Если что-то не работает, вместо Minify выберите Combine only и уберите галку Preserved comment removal.
  • CSS minify settings: Enable
    Настройка минификации CSS
  • Memcached hostname:port / IP:port: проверьте, появляется сообщение «Test passed» в зеленом поле.
  • Use persistent connection – ставим галку
  • Rejected user agents: данное после надо оставить пустым, даже если вы используете мобильную тему для сайта.
  • Жмем «Save all settings» и переходим к следующему пункту.

Database Cache (Кеширование запросов к базе данных)

  • Don't cache queries for logged in users – ставим галку
  • Memcached hostname:port / IP:port: нажмите Test, чтобы получить « Test passed.» в зеленом поле.
  • Use persistent connection – ставим галку
  • Жмем «Save all settings»

Object Cache (Объектный кеш)

  • Memcached hostname:port / IP:port: нажмите Test, чтобы получить « Test passed.» в зеленом поле.
  • Use persistent connection – ставим галку
  • Enable caching for wp-admin requests – ставим галку
  • Store transients in database – ставим галку
  • Жмем «Save all settings»

Browser Cache (Кеш браузера)

Ставим галки для следующих пунктов:

  • Set Last-Modified header
  • Set expires header ИЛИ Set cache control header – эти пункты нельзя включать одновременно, надо выбрать или первый, или второй. Особой разницы я не заметил в производительности, но все же при выборе Set cache control header сервисы проверки скорости дают чуть больше баллов :)
  • Set entity tag (ETag)
  • Set W3 Total Cache header
  • Enable HTTP (gzip) compression
  • Don't set cookies for static files
  • Rewrite URL structure of objects

Ниже есть еще 3 блока настроек: CSS & JS, HTML & XML, Media & Other Files и Security Headers – первые три дублируют настройки из главного блока, а настройки безопасности и так в порядке. Так что нажимайте «Save all settings».


Разделы User Agent Groups, Referrer Groups, Cookie Groups можно пропустить, они не пригодятся.

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

Раздел Fragment Cache тоже можно игнорировать, потому что он доступен только по подписке в PRO версии.

Последний раздел, который может нас заинтересовать – Extensions. Например, если вы используете плагин Yoast SEO, можно активировать расширение для совместимости с ним.


Очистить кеш WordPress

Теперь осталось последнее действие, чтобы настройки вступили в силу – удалить весь кеш WordPress вручную и создать новый с актуальными настройками. В верхней менюшке найдите пункт «Purge All Caches» (Очистить весь кеш).

Как очистить кеш WordPress

После очистки кеша все статичные файлы, минификации, объединенные CSS и JS файлы будут удалены и вместо них созданы новые, согласно новым настройкам.


Плагин Native Lazyload от Google

С чего все началось-то – как раз с плагина для lazy-load технологии. Так как W3 Total Cache не имеет такой возможности, чтобы получить еще более высокую оценку, стоит установить плагин Native Lazyload от Google. Зайдите в админке в раздел плагинов, ищете по точному названию и жмите «Установить»:

Плагин Native Lazyload от Google

У плагина даже нет меню настройки, его надо просто активировать, все начнет работать автоматически. Ко всем изображениям на сайте на лету будет добавляться атрибут loading="lazy". Как ни странно, но в Хроме проверить работу этого плагина не получится, там почему-то не работает эта функция, но можете запустить Firefox или даже EDGE, открыть страницу с большим числом картинок и быстро прокручивать, вы увидите, как изображения подгружаются по мере прокрутки.


Измерение скорости работы сайта

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

Проверка ответа сервера в Яндекс Вебмастере

Ссылка на инструмент: https://webmaster.yandex.ru/site/tools/server-response/.

У меня главная страница не такая большая, потому отвечает очень быстро – 52мс.

Проверка ответа сервера в Яндекс Вебмастере

Для больших постов с картинками это время чуть больше, например, для страницы размером 170,54 КБ время ответа сервера составило 90 мс. Если у вас время около 100 мс +\-20%, считайте, что все отлично!

Google PageSpeed Insights

Ссылка на инструмент: https://developers.google.com/speed/pagespeed/insights/.

Собственно, инструмент, которым все измеряют свои писюны. Не дал мне 100 баллов, потому что у меня изображения большего размера, чем они вставлены на сайте (например, исходная картинка размером 500×500 пикселей, а на сайте она вставлена с параметрами width=”250” и height=”250”. Но я делаю это намеренно, чтобы на телефонах и ноутбуках с дисплеями HDPI 4k изображения выглядели качественными и четкими, а не размазанными, для меня это важнее, чем +1 балл в оценках от гугла!)

Оценка скорости сайта по Google PageSpeed Insights

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

Оценка скорости сайта по Google PageSpeed Insights

GTmetrix

Ссылка на инструмент: https://gtmetrix.com/.

Еще один популярный инструмент оценки скорости работы сайта.

Оценка скорости сайта по GTmetrix

Обратите внимание, что в пункте Serve scaled images мне занизили оценку до 11 (вместо 100) по аналогичной причине, что у меня размер изображения в оригинале больше, чем вставленное на сайте (в PageSpeed за это отняли 1 балл). Leverage browser caching понижен за отсутствие кеширования для внешних объектов – это тоже не исправить, потому что в эту категорию попадают все внешние скрипты, например, js-код Метрики и Google Analytics, скрипты соцсетей и прочее.

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

DevTools – Audits – Chrome

Хотел завершить описание инструментов проверки скорости сайта на прошлом пункте, но вспомнил, что в Хроме есть встроенный инструмент оценки, основанный на Google PageSpeed Insights. Чтобы найти его, надо нажать на F12, откроется консоль DevTools, выбираем там последнюю вкладку Audits:

Оценка скорости сайта в Хроме с помощью DevTools

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


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

До связи, друзья.

Ерунда и баянЪ!Зачет! Плюсую!
+1
Подписка на новые посты:

Профессиональный технический аудит и рекомендации по оптимизации вашего сайта.
Тот самый необходимый «фундамент» для успешного продвижения.

15 000 руб.

Комплексный подход к решению поставленных задач: достижение топ-10 и увеличение трафика на сайт. В стоимость уже включены полный технический аудит и оптимизация сайта.

25 000 руб.

У вас недостаточно знаний и нужны ответы на вопросы?
Интересует мнение эксперта или надо проверить подрядчика?
Вы задаете вопрос — я отвечаю!

5 000 руб./час

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

50 000 руб.

Комментарии: 38 Написать комментарий
  1. Dmitry (1 комм.)

    Лучший плагин для кэширования и оптимизации WP — PageSpeed Ninja. W3 Total Cache до него все-таки не дотягивает.

    Ответить
    • АлаичЪ

      А какие есть аргументы в пользу этого мнения?

      Ответить
  2. seoonly.ru (44 комм.)

    ну все)) пошел менять плагин-)

    Ответить
  3. Ruslan Banochkin (4 комм.)

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

    Ответить
  4. Pro-Prodvizenie.ru (2 комм.)

    Измерял скорость сайта по гугл (PageSpeed Insights).

    Морда на стандартных настройках с 71 до 96 прыгнула.

    А внутренние страницы подросли с 86 до 90.

    Ответить
    • АлаичЪ

      Сейчас речь про плагин W3 Total Cache и результаты после его установки? Дай подробности.

      Ответить
  5. Денис Маркевич (4 комм.)

    Скорость сайта прилично подросла, спасибо за советы. После установки Native Lazyload в Firefox изображения вставленные в колонки и галереи не отображаются.

    Ответить
    • АлаичЪ

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

      Ответить
      • Денис Маркевич (4 комм.)

        Изображение в галерее — https://markevich.by/rabochie-momenty/primer-vneseniya-izmenenij-v-proektnuyu-dokumentaciyu.html

        Изображения в колонке — https://markevich.by/obuchenie-proektirovaniyu/slabotochnye-sistemy.html

        В Хроме всё хорошо.

        Ответить
        • АлаичЪ

          Почему-то у тебя к изображениям, которые там вставлены добавляется класс native-lazyload-js-fallback, а для этого класса есть inline-стиль: .no-js .native-lazyload-js-fallback{display:none}

          Соответственно, изображения не отображаются.

          Не знаю, по какой причине это происходит, видимо, как-то связано со способом вставки их в пост.

          Если прописать в файле стилей (дефолтно это style.css файл внутри темы оформления) следующее .native-lazyload-js-fallback{display:none!important} все должно показываться.

          Попробуй.

          Ответить
          • Денис Маркевич (4 комм.)

            Не помогло. Заменил Native Lazyload на a3 Lazy Load. Картинки отображаются во всех браузерах.

            Ответить
            • АлаичЪ

              Это я тупанул, извини, там надо не display:none!important, а display:block!important

              Коммент выше откорректировал.

              Протестируешь?

              Ответить
              • Денис Маркевич (4 комм.)

                Протестировал. Теперь изображения отображаются. Оставил Native Lazyload.

                Ответить
                • АлаичЪ

                  Отлично, спасибо за фидбек!

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

                  Ответить
  6. Aspirant (2 комм.)

    Поменял свой старый Hyper Cache на W3 Total Cache. Разницы практически никакой нет.

    Ответить
    • АлаичЪ

      Судя по описанию Hyper Cache не организует кеш на стороне клиента (кеш браузера).

      Ответить
  7. WebMasterMaksim Максим Миронов (2 комм.)

    Hyper Cache и W3 Total Cache это все ерунда. у меня более 500 сайтов на вордпресс перебирали с командой разные варики, в итоге самое лучшее это сачитание:

    WP Rocket + cdn ( по РФ, НЕ ВСЯКИЕ ЗАБУГОРНЫЕ АНАЛОГИ) + PHP 7.3.4 в режиме FastCGI (Nginx + PHP-FPM) + хоснг ВПС kvm ну параметры расписывать не буду.

    и W3 Total Cache нервно курит в сторонке, скорость в два раз быстрее

    Ответить
    • АлаичЪ

      Спасибо, Максим. Верю. Но тут вот какое дело, скорее всего, у рядовых пользователей не VPS/VDS, соответственно, не факт, что можно выбрать FastCGI (Nginx + PHP-FPM). А CDN через плагин WP Rocket настраивается? Кстати, посоветуй тогда и CDN по РФ?

      Ответить
      • Максим (2 комм.)

        CDN по РФ cdnvideo. НО сейчас много аналогов, все не тестировали еще

        Ответить
  8. Latif (1 комм.)

    Добрый день.

    В зарубеже считается WP-rocket в топе, я тоже придерживаюсь этого мнения, так как перепробывал все.

    Ответить
  9. Алексей (10 комм.)

    Здравствуйте Александр!

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

    Ответить
    • АлаичЪ

      Для WordPress есть плагин для организации интернет-магазина, но я бы не рекомендовал выбирать WP как CMS для ИМ. Для этого есть более удачные решения — Битрикс (платный), CS-Cart (платный), OpenCart (бесплатный) или даже облачные решения типа Insales, NetHouse. Все это будет удачнее, чем WordPress.

      Ответить
      • Алексей (10 комм.)

        А если все таки WordPress с плагином WooCommerce? Или все таки не рекомендуете? Могли бы более развернуто ответить почему не рекомендуете. Заранее спасибо за ответ

        Ответить
        • АлаичЪ

          Ну да, если WP — то WooCommerce (но это безосновательное предположение, основанное только на догадках и слухах, т.к. я никогда сам не делал ИМ на WP).

          Почему не рекомендую? Потому что каждая вещь для своей цели предназначена. Спагетти можно есть ложкой — неудобно, но можно. Носить покупки можно в руках — а в пакете удобнее. Понял, да, к чему я клоню? Есть масса удобных изобретений, созданных не просто так, а для решения определенных задач. Так вот WordPress — для блогов, инфосайтов, и сайтов услуг, а для интернет-магазинов есть специальные решения, которым не нужны костыли и доработки, чтобы сайт стал магазином (доработки и там потребуются, конечно, но есть готовые плагины для этого, а плагин для доработки плагина на WP — это уже слишком).

          Достаточно развернуто?

          Ответить
          • Алексей (10 комм.)

            Более чем)) Спасибо вам Александр!

            Ответить
            • Алексей (10 комм.)

              Александр созрел еще вопрос... могли бы вы рекомендовать хорошего разработчика по OpenCart

              Ответить
              • АлаичЪ

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

                Ответить
  10. Батя (1 комм.)

    Заманался уже, на хостере послали меня на vds перейти а дополнительные расширения на Шаред хостинг не будут ставить сказали они! Вот и закончилась эпопея W3 total cach, и теперь не могу заголовок настроить Last Modified чувствую дело в хостере, на другом без проблем было а здесь такая херь... может подскажите что делать ?? Хостера менять тоже как то не вариант геморойно...

    Ответить
    • АлаичЪ

      Ну, если все же менять хостера, то могу порекомендовать FastVPS — я с ними уже лет 10 работаю. Если переезжать, то они бесплатно все перенесут и настроят.

      А если не переезжать, то Last Modified — не самое критичное, другие настройки гораздо важнее (даже отсутствие memcached не критично, потому что Disk не хуже). В чем еще проблемы есть в текущем раскладе?

      Ответить
  11. Александр (1 комм.)

    W3 Total Cache блокирует вывод рекламы плагином adsplacer. Может подскажите где смотреть. Combine only — не помогает.

    Ответить
    • АлаичЪ

      Имеет смысл на вкладке General Settings попеременно выключать галки для: Page Cache, Minify, Opcode Cache, Database Cache, Object Cache, Browser Cache. И после отключения одной из них плагин должен заработать. Потом уже детальнее разбираться, в каком месте причина.

      PS И стоит написать в форум поддержки плагина, да даже на их сайте wp-r.ru в шапке есть обратная связь и пункт «Проблема в работе плагина». Исправить проблему в их же интересах.

      Ответить
  12. Илья (2 комм.)

    Здравствуйте! Уже несколько лет стоял плагин Hyper cache, но решил снова протестировать новые. Явно за столько времени что-то да и изменилось.

    Вначале тестировал на тестовом сайте одну и ту же страницу с разнообразным контентом. Получилось так:

    ПлагинPingdom
    (сек/запросов/Мбайт)
    GTmetrix
    (сек/запросов/Мбайт)
    Google PageSpeed
    (ПК/Моб)
    Код страницы в html
    (знаков с пробелами)
    Без плагина1.54 / 31 / 1.14.5 / 31 / 1.0881 / 5626955
    Hyper cache1.45 / 30 / 1.13.3 / 31 / 1.0894 / 6426948
    W3 Total Cache0.5 / 17 / 1.12.8 / 17 / 1.07100 / 10021382
    WP Fastest Cache1.1 / 23 / 1.13.7 / 17 / 1.0898 / 7526804
    WP Super Cache0.7 / 30 / 1.13 / 30 / 1.173 / 9727095
    WP Performance Score Booster1.6 / 30 / 1.14.1 / 31 / 1.0861 / 8626924

    W3 Total Cache (есть сложности с удалением – нужно вручную удалять папки, раздувает htacces, после деактивации не сразу активируется; актив/деактивация hyper cache и Total Cache активируется). Так как у меня виртуальный хостинг, то параметр Page Cache Method: Disk Enhanced. Далее настраивал по вашей статье, плюс время хранения кеша увеличил.

    WP Fastest Cache (настройки удобные, но минификация в коде не видна – хоть и включена, раздувает htacces)

    WP Super Cache (самотест: есть ошибки в строении структуры страниц с кешом и без)

    Пока что пользуюсь W3 Total Cache. На днях пришло сообщения с Google Webmaster что проблемы с мобильной версией на паре сайтов (адаптивный шаблон). Посмотрел описание проблемы — блокируется в robots папка плагина W3 Total Cache minify. Добавил ее в исключения (на css и js), сбросил кеш, отправил не перепроверку. Снова пишут, что есть проблемы и уже больше страниц в вебмастере Google отображаются. И главное, вручную прохожу страницы в тесте на мобильность – все хорошо. И так было до того, как отправлял запрос на перепроверку… Не понятно в чем дело.

    По плагинам для Lazy загрузки. Тоже тестировал (Native Lazyload, Lazy Loader, Lazy Load by WP Rocket, Lazy Load 0.6.1 By Mohammad Jangda, Crazy Lazy). Но пока не выбрал. Заметил, что в коде к каждой картинке эти плагины добавляют или base 64 url, которые не открываются при нажатии, или еще плюс добавляют кода к каждой картинке x2 и по паре ссылок.

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

    Ответить
    • АлаичЪ

      Привет, спасибо тебе за такой информативный комментарий! Я там тебе марафет навел, свел все данные в таблицу, чтобы все по красоте было, и наглядно чтобы!

      PS Плагины Lazy Load добавляют свои картинки-заставки, чтобы они показывались в то мгновение, пока нужная картинка грузится, чтобы как-то обозначить наличие изображения.

      Ответить
      • Илья (2 комм.)

        Ух-ты! Так намного все наглядней и красивей! Здорово!

        Чудом увидел ваш ответ, на почту уведомление не приходило.

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

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

        Задумался перенести один англоязычный сайт или на американский сервер где есть панель isp manger (еще не нашел подходящий по цене/отзывам) или настроить cdn на Cloudflare через W3 total cache (есть встроенный плагин совместимости).

        Но не понятны моменты, говорят, что если стоит бесплатный ssl Lets Encrypt от хостинга, то он не будет автоматически продлеваться на домен, если ns записи направлены на ns на Cloudflare. Есть вариант использовать фри сертификат от самого Cloudflare. Подскажите пожалуйста, на позиции негативно не скажется смена сертификата на Cloudflare вместо Lets Encrypt?

        Ответить
        • АлаичЪ

          >> Чудом увидел ваш ответ, на почту уведомление не приходило.

          Может в спам залетело? :(

          >> Что-то у меня плагины Lazy Load на мобильном не срабатывают (при загрузке первого экрана отключал интернет и при дальнейшей прокрутке картинки все равно отображались).

          Может быть, так и должно быть? А то обидно было бы, открывать вкладки, чтобы почитать потом в метро, например, или в самолете, а по факту облом. Надо подробнее прочитать, как это работает.

          >> Но не понятны моменты, говорят, что если стоит бесплатный ssl Lets Encrypt от хостинга, то он не будет автоматически продлеваться на домен, если ns записи направлены на ns на Cloudflare.

          Lets Encrypt он от Lets Encrypt и не от кого другого :) Вопрос в том, стоит ли на хостинге скрипт, который автопродление инициирует. Я с Cloudflare не работал, потому подтвердить или опровергнуть это не могу.

          >> Подскажите пожалуйста, на позиции негативно не скажется смена сертификата на Cloudflare вместо Lets Encrypt?

          Более того, скажу, никто вообще не заметит, что поставщик сертификата изменился. Важно само наличие https, а уж кто его выпустил — не имеет значения, главное, чтобы не самоподписанный был.

          Ответить