Всем привет! В очередной раз показываю плод свего творчества http://www.ynafani.com.ua/.
Для ускорения его работы приняты следующие меры
(возможно про какие-то я забыл):
Boost. Поставил модуль + crawler. Ничего особо не настраивал. Скопировал нужное в htaccess и все. Вроде бы работает. Файлы в папке cache создает.
Filecache + Entitycache. Тоже поставил, включил забыл.
Advagg. Из набора модулей включил лишь AdvAgg Compress CSS и AdvAgg Compress Javascript. В настройках выставил компрессию всего через YUI.
Внутренние настройки производительности.
Минимальное время жизни кэша — 3 часа
Время жизни кэша страниц - нет.
Объединение и сжатие CSS+JS.
Во вьюхах везде где только можно в настройках кеширования поставил Результат запроса и Обработанный вывод — 6 часов.
Как считаете:
1) Работает быстро и есть ли смысл ускорять?
2) Эти модули не конфликтуют друг с другом?
3) Еще можно что-то для ускорения сделать?
Комментарии
1. Не быстро, смысл есть.
2. Конфликтуют. Блок корзины не обновляется.
3. Разумеется.
Я вообще говоря хз что посоветовать. Интернет магазин - это не сайт для анонимов, без сессии не обойдёшься, а сессия убивает кучу механизмов кэширования друпала. Надо смотреть в сторону Authcache, я думаю.
Корзина понял.
Дальнейшие комментарии принимаются.
Смысл Authcache - кешировать страницы для авторизированных пользователей? Если да как-то не особо интересует. На сайт под своим логином заходят единицы.
Entitycache имеет смысл юзать с Memcache или Redis, о чем, собственно, и написано на странице модуля:
На антимонгольском
Смысл Authcache - не кэшировать части страницы, уникальные для пользователя, и не важно, авторизован он, или нет. Например корзину, или токены форм.
По рейтингу Google он набирает 9 из 100 баллов. Но в целом на выделенном канале работает быстро. Ни разу не видел сайтов на Drupal с таким низким показателем.
А мне показало 89 мобильные и 90 десктоп.
Ссылку на рейтинг Гугл дайте пожалуйста.
https://developers.google.com/speed/pagespeed/insights/ вы имеете ввиду это? Да бывают просадки.
https://www.drupal.org/project/display_cache
У меня такой результат в аудите хрома. Надо поучится у вас SEO )))
Ничего не делал, а СЕО до 90 за день упало. Странный аудит какой-то. Ок, я по возможности учту его требования.
Да действительно в ходе определенных операций верстка чуть поехала но на скорость не думаю что это влияет.
По моим ощущениям тест производительности очень сильно зависит от скорости каналов связи и маршрутов. Вообще любые результаты тестов скорости они не на 100% объективные.
Если надо без особых заморочек "ускорить" сайт, с относительно небольшой посещаемостью (чуть пониже новостного портала с 100000 поситителями в месяц) - redis, отличное решение.
Поставил и забыл.
Проверял на "коленке" (в devtools chrome), после сброса кэша, загрузка какого нибудь навороченого вьюса второй раз (в первый он попадает в кэш) быстрее раз в 5-8..
Но для redis нужна свободная оперативнакя память, ибо его суть: хранилище кэша в виде ключ-значение в оперативной памяти..
Из-за этого и ощутимый прирост производительности.
Т.е. скорее всего нужен впс с достаточным кол-вом оперативы, а в идеале на SSD c достаточно большим свопом (файл подкачки)
Кое что подправил в от теребований аудита Хрома.
Результаты "в синтетике " повысились.
Больше всего волнует это:
и это:
Как-то можно исправить эти 2 пункта?
Может еще что -то можно исправить "малой кровью" ? Полный отчет https://c.radikal.ru/c27/1805/86/17d7e8ba1394.jpg