Yoda

Тут вот какое дело... Просто перенести в подвал - не выйдет по нескольким причинам. Во первых гуглу это не подойдет, так как он будет все равно ждать первую загрузку контента (это нововведения такие). Во вторых можно порушить работоспособность модулей. И в третьих так или иначе надо перерабатывать всякого рода скрипты, которые добавляются не через $this->document->addScritp('somescript.js'). Та же самая история и со стилями. По нынешним рекомендациям гугла соответствующие стили надо загружать только под соответсвующий vieport и дробить базоый стиль на кучу составляющих. А все вспомогательные стили грузить уже после всей загрузки контента - на выходе тоже можно получить дергания. Так же гуглу не нравится, что мы грузим по очереди несколько десятков ресурсов, а то что уже давно существует HTTP2 и как он работает гугл не в курсе. И вряд ли в ближайшем времени будет в курсе. Также возможно просто обьединение всех стилей и заголовков в один большой файл. Но в таком случае можно забыть про то что бразуеры кешируют статику. Правда для разного типа контента все же будет кеширование, но не на уровне элементов вашей структуры, а на уровне свой стиль/скрипт на каждый роут товар, категорию и тд. Если сильно охота можете попробовать поиграть вот в такие теги: <link rel="alternate stylesheet" href="mystyles.css" onload="this.rel='stylesheet'"> и как то так: <script>function init() { $('a').addClass('ajax'); }</script> <script src="/jquery.js" async onload="init()"></script>

50-500 мс экономии на генерации страницы.

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

Извините, но вы написали глупость. В данном случае в ответе сервера присутсвует warning, который выдает ошибку, которая является десткой болезьню движка, связанную с удалением файлов кешей. В каком месте здесь проблемы с вебсервером? Лечится - просто отключением вывода логов ошибок в настройках магазина.

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

if (ltrim($this->request->server['REQUEST_URI'], '/') == 'sitemap.xml') { $this->request->get['route'] = 'extension/feed/google_sitemap'; return; } Это по моему лишнее. При наличии реврайта в htaccess.

А вот строчку в htaccess не нужно было комментировать. И в seo_pro неплохо было бы добавить вот такое: if (isset($this->request->get['route']) && $this->request->get['route'] == 'extension/feed/google_sitemap') { return; }

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

Права на папки!

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

Где пруфы, вы так много глупостей говорите. У меня есть много пруфов, когда после включения сео-про магазин взлетает в выдаче. А у вас сплошное бла бла бла и байки про каноникал. А ничего страшного, что в движке без сео про может быть пару десятков разных ссылок на один и тот же контент? А ничего страшного, что если у вас 20 000 страниц вы получите 400 000 неуникальных урлов? А ничего страшного, что если бот начнет активно ходить по всем этим ссылкам, пытаясь обнаружить каноникал не хватит никакого краулингового бюджета. Не несите ересь пожалуйста с вашим другом, который пишет ночной код. Или предоставьте не единичные факты с графиками изменения позиций и индексации проектов, где вы внедряете вашу ересь!

1 - включите отображение всех ошибок и посмотрите нет ли их где-то по ходу в html 2 - проверьте включен ли у вас json-php модуль 3 - в контроллере карточки товара сделайте var_dump($product_info['name']); или seo_h1 - посмотрите что у вас приходит из базы. По результатам - отпишите Upd - посмотрите что у вас в поле h1 в базе для этого товара. Если кракозябр нет - где-то в коде движка скорее всего он увас на лету трансфомируется, и скорее всего у вас нэ очэнь руске пыхапэ, и скорее всего где-то есть strtoupper(), который необходимо заменить на mb_strtoupper()

Не работает асинхронная загрузка в случае с opencart - надо использовать rel = preload

Не совсем понял. Но я немного не о том хотел сказать. Так или иначе кроме вагона скриптов тот же мега фильтр генерирует очень много лишних оберток для контента, а объединение его скриптов в один общий - не дают желаемого эффекта. В данном случае если говорить про то как все должно быть в идеале. На фронт должна приходить JSON коллекция, из которой выдергиваться 2-3-5 первых значений параметров, а все остальные подгружаться по кнопке показать еще... 27.ua - пример. И в таком формате необходимо подходить практически ко всему контенту. Все что вторичной надобности отдаем только по пользовательскому событию. Тогда это выходит и в концепции, которую продвигает гугл и действительно быстро. Но в 4500 строк JS кода фильтра, я лезть не готов. Проще написать 300 своих, пусть с ограниченным фукнционалом. Но так как надо.

Расскажите, как вы переверстаете вывод megaFilterPro на скажем так 400-500 значений атрибутов. И при это сохраните метрику аналитикс и facebook внешние скрипты. Именно в том виде, в котором это рекомендовано руководствами по внедрению этих скриптов, а не вот этим всем... "мы сейчас все сохраним локально и поставим время жизни кеша в MAX".

Да я и сам умею, тока не до этого в данный момент.

Насколько мне известно от 2 до 15 тыр берут здешние персонажи. Но из тех кто этим занимается, я бы кроме @spectre ни с кем не связывался по тем или иным причинам.

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

Потому что то что вы нашли - это следствие. А источник уязвимости в другом месте!

От того что вы его удалите ничего не изменится. Через какое то время будет тоже самое.

Права на файлы папки фиксим!

https://stackoverflow.com/questions/5539169/how-do-i-remove-extra-spaces-tabs-and-line-feeds-from-a-sentence-and-substitute

public function set($key,$value) { /* $status = $this->cache->set(CACHE_PREFIX . $key, json_encode($value)); if($status){ $this->cache->setTimeout(CACHE_PREFIX . $key, $this->expire); } return $status; */ $this->cache->setEx(CACHE_PREFIX . $key, $this->expire, json_encode($value)); // sets key → value, with 1h TTL. } Как то так лечится ваша беда.

Не занимайтесь извращенным сексом - возьмите сразу сервер с L7

Самое логичное - не использовать непонятные сборки.