Yoda

Этого всего мало - потому как если посмотреть в лог запросов на странице, то можно удивиться и увидеть, что cart->getProducts инцииализируется не один раз, а на странице оформления бывает и по 4! Индексы помогают до определенного количества, а после 100-150 позиций без оптимизации самого класса cart не обойтись!

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

Продолжаю делиться соображениями про хостинг-шмостинг. Сразу маленький дисклаймер. Облачные хостинг, serverless технологии, дедики, кластера и иную кибениматику попрошу в комментариях не поднимать, так как всё же информация адресована широкой аудитории, а не любителям полемики ради полемики. Итак. Площадку для сайта, если нивелировать фактор цены (об этом в самом конце), стоит выбирать по следующим характеристикам: быстродействие, качество саппорта, надежность и стабильность. Еще несколько лет назад фраза - собственный сервер звучала как что-то из разряда фантастики. Где-то в этом мире существовали грамотные linux-волшебники, которые могли прописать какие-то конфиги и скрипты, стоил такой волшебник $30-100 в час и найти просто так его было нереально. Соответственно была проблема с администрированием и поддержкой системы. Да и разница в цене получалась достаточно неприятной. С появлением ISP5 95% задач которые требовали привлечения дорогого админа отпали сами собой. Начиная с банального развертывания виртуал-хоста и почтовых ящиков, заканчивая автообновлением let's encrypt сертификатов, отличной системы бекапов и жонглированием версиями PHP. Вот ща должен прибежать Вурдалак @stickpro и завести свою журавлиную песню про "панели - зло", только чистый линукс. Но это песни для избранных, и простому обывателю собственно говоря они ни к чему. Все сказки от одминов-линуксоидов идут от того, что многие сисадмины с минимальными навыками развертывания LAMP-стека остались без клиентов. Ну и да, я знаю, что в ISP куча глюков, что там что-то может не работать, какие-то не те версии пакетов. Устаревшие пакеты и бла бла бла. Но. Глюки проявляются в сотой доли процента ситуаций и как правило связаны со сторонним ПО, а что касается устаревших системных пакетов, то тут я считаю что это больше плюс - так как они все-таки стабильны. А явные свежие уязвимости очень быстро и оперативно исправляются разработчиками. Ну и цена вопроса - работы сисадмина по настройке полноценного WEB-стека с почтой, бекапами сертификатами и минимальными модами безопасности - это ну никак не 4 евро в месяц! Кроме того появились хостеры, специализирующиеся именно на виртуальных серверах, в отличии от того же рег ру, бегета, таймвеба или ukraine, основной бизнес которых до сих пор это шаред или виртуальный хостинг. В чем же разница и зачем все это нужно. Если приводить аналогии с реальной жизнью - это приблизительно как автобус и личный автомобиль. Производительность. Благодаря тому что, вы получаете выделенные изолированные ресурсы, благодаря виртуализации, используя VPS? в теории, если хостер не жадный вы сразу получаете большую скорость работы магазинов. Тут опять же надо сделать небольшое отступление. Если хостер предлагает XEN или OpenVZ виртуализацию - это говорит о том, что они или жадные, или тупые, или пытаются втулить вам впс на древнем морально устаревшем железе. Так что только KVM! Стабильность. Ваши ресурсы - только ваши, вы можете легко отмониторить нагрузку и в случае нехватки их моментально докупить. И даже если вы получите пиковую нагрузку ваш магазин будет сразу доступен как она спадет и скорее всего будет как-то работать пусть и медленно, а не как на некоторых хостингах, которые вас могут блокировать внезапно до момента устранения источника нагрузки. Это очень важный фактор для сео, так как поисковики видя ваш лежачий магазин, моментально вас убирают из выдачи. Потом попробуй туда вернись! Разумное отсутствие ограничений на ресурсы и скрытых вымогательств. Я не просто так написал разумное. Так как ограничения есть всегда, но вам не надо докупать память мемкеш, выделенный айпи, редис для сессий, ждать пока там в очереди планировщик отработает восстановление бекапов соседей и выполнит ваш через 20-30 минут, упираться в ограничение по количеству доменов, inodes, ssl сертификатов, баз данных, почтовых ящиков, количество отправленных в день писем. Полный доступ под капот через SSH или та самая консоль. Ну да, ну да. Я ж писал что админы не нужны, но иногда бывают нужны). Да и в целом где-то половина людей с которыми я сталкиваюсь имеют базовые навыки работы в консоли. Зачем это надо? Ну тут на ум приходят например быстрые операции переноса проектов через rsync, установка расширений типа cwebp или jpegoptim или сервисов мониторинга типа htop, mytop. Ну а возможность полноценно использовать Nginx+php-fpm без apache с неограниченным доступом к конфигам nginx и php-fpm- это просто счастье (на самом деле эта функция доступна напрямую из панели управления). Если даже какие-то поставщики виртуального хостинга предоставляют ssh доступ, он как правило сильно ограничен и никто вам не даст править nginx.conf. А апач в наше время - это зло, так как съедает от 50 до 300-400 мс производительности. Безопасность. Для меня безопасность любого проекта начинается с бекапов. Ну они как минимум должны быть хоть какие-то. В данной ситуации есть важный нюанс, бекапы с VPS вы можете сделать хоть на узел в Антарктиде в два клика (если вы используете ISP) , шаред-хостеры если же и хранят их, то в соседней стойке, сгорает датацентр, сгорают все ваши данные или преращают их хранение вместе с закончившейся оплатой. С серванта же вы настраиваете их в Hetzner storage за 3 евро в месяц или на google drive или в dropbox и спите спокойно. Бекапы должны быть физически удаленные на приличное расстояние всегда! Также, изолированность ресурсов нам играет на руку. Возьмем к примеру ukraine.com.ua у них общий админвпс для всех. засветился ваш пароль-логин в базу, и все полный доступ ко всему, на впс же мы можем выключить, phpmyadmin, переименовать, закрыть под пароль, да что угодно, равно как и поменять порт ssh, удалить ftp демон. Да все что угодно, в целом базовыми операциями очень быстро сервер приводится в бронебойное состояние, даже если у вас наглухо дырявый магазин. Крооме того, очень часто на виртуальном хостинге рядом с магазином торчит еще несколько штук мертвых проектов на worpress жумле и тд. И все это под одним аккаунтом. Взломали старый WP, получили доступ в боевой магазин. На VPS, мы спокойно под каждый проект создаем своего владельца, со своими ftp-пользователями, и даже если вам чпокнут один проект и зальют шелл, все остальные окажутся недоступными для зловредов. Выделенный айпи. Ну да, ну да, его можно купить и на шареде, но на VPS он сразу есть, в итоге мы можем и почту настроить на отправку без спама, как для уведомлений так и для рассылок (на шаред-хостинге один айпи на всех, и у вас там как правило будут ограничения на количество писем, а также большая вероятность, что кто-то из соседей попал в блек-листы), и для поисковиков полезно. Наверное, я много упустил, да и за один раз не расскажешь всего. Однако, базово рассказать в чем разница и зачем нужен VPS, вкратце получилось. Если резюмировать, то виртуальный хостинг подходит в современных реалиях только для небольших стартапов без трафика и большого количества товаров, в случае же если вы перевалили за 300 уникальных хостов в день, стоит шевелится в сторону переезда на VPS. И вот тут мы возвращаемся к разнице стоимости и трудностям администрирования. В целом на сегодня приличный VPSможно арендовать за 15-20 долларов в месяц. Это треть зарплаты приходящей уборщицы, или 10 банок хорошего пива. Но кроме этого в большинстве случаев - это залог стабильных бизнес-процессов и спокойного сна, а это бесценно. Я считаю, что это безапелляционный аргумент. Можно конечно рассказать, про то, что за счет прироста в скорости у вас улучшится индексация, вырастет трафик, увеличится конверсия, но это избыточно. Просто даже если вы за год ни разу не будете простаивать из-за лежащего магазина, разницу в стоимости вы уже получите в виде не упущенной прибыли. А что касаемо саппорта и подержки, то топ 5 хостеров в выдаче гугла с названием vps в домене, в целом осуществляют достаточную и даже избыточную поддержку. Ну и опять повторюсь ISP5 и примитивное гугление закрывает 95% вопросов, которые раньше делали задорого волосатые сисадмины! Подписываемся, ставим лайки, комменитруем!

Отправьте пару рассылок в неделю хотя бы на 10к заказчиков через яндекс или мейл ру - узнаете!

ну да ну да... Так же говорят про красивых женщин прыщавые малолетки - фу она какая... Дает только за больше деньги!

Представьте ситуацию, у вас шоссе в 6 полос упирается в однополосный тоннель, вы хоть на жигулях, хоть на мерседесе попадете в пробку. Так что тут сравнение не совсем корректное. Ну и если у вас реально столько фото, не занимайтесь фантастикой. https://www.hetzner.de/dedicated-rootserver/ax41-nvme 34 евро + 4 евро панель + 8 евро стораж под бекапы. Если платите с нормальной визы - никаких проблем с хетцнером, а если спрятаться под клаудфларе, которым уже можно пользоваться спокойно. так как ркн перестал лютовать, то про все проблемы ваши можно забыть. Вы сейчас скажете - ой жеж, дорого. Но тут надо понимать две вещи, во первых норм сервер сразу улучшает индексацию и это отражается на продажах. За последний год таких уже несколько примеров @Vorodisa, вот не даст соврать. А второй момент - спокойный сон. Один раз настроили и забыли. Если же таки вам хочется жесткого секса в извращенной форме с Amazon Bucket - смотрите в сторону s3fs. https://cloud.netapp.com/blog/amazon-s3-as-a-file-system Как то так... upd: Крайне не рекомендовал бы маунтить удаленное хранилище для фото, так как хочешь не хочешь есть какое-то время на пинг. А у нас модель image сканирует каждый раз файловую систему на наличие кеша картинок. Поэтому получите приличные тормоза. Но допустим если у вас узлы в подсети хетцнера, где пинг 2-3 мс между хельсингки и гамбургом и канал как звезда Зейнаб - то тут вопросов нет!

А это вы как считаете? На калькуляторе 12 > 10 ? По такой же логике - два пентиума лучше чем core i9. А если серьезно то теоретически у вас там запросы в базу - бутылочное горло, и скорее всего не сами запросы а их количество. Быстрые процессоры работают существенно быстрее, к тому же у админвпс есть некоторые преимущества перед другими хостерами, а именно сразу предустановленая mariadb 10.3 и поднятые лимиты на ресурсы сервера базы. Поэтому фактически производительность может вырасти на порядок.

Сейчас можно найти множество инструкций и услуг по настройке VPS серверов. Люди публикуют какие-то твики, фичи, секретные конфиги. Которые нифига не работают! Сколько раз я слышал - мы поменяли хостинг на сервер и ничего не произошло. Ну а что должно произойти, если один компьютер поменяли на такой же другой? Ничего. Ну да, там выделенный айпи, якобы изолированные ресурсы (что полное вранье в 99% случаев, так как я еще не видел ни одного VPS провайдера, который бы не оверселлил). Но все же при нынешних ценах на выделенные сервера, любому магазину VPS - мастхев. Наверное стоит про это отдельно написать развернуто в следующий раз. Что же сделать, чтобы увидеть результат? 1 - У вас должно быть достаточно ресурсов, никаких пакетов (одно ядро один гигабайт памяти), можно долго рассказывать почему, но просто поверьте, даже для стабильной работы магазина на 1000 товаров и 1000 посещений в день нужен запас и хотя бы 2 ядра два гига. Если очень кратко, то ваш сервер не только формирует веб-страницы для пользователей, а делает еще много системных операций от бекапов до блокировки подключений левых ботов, на что тоже тратятся ресурсы. Да и генерация одновременно 5-6 страниц магазина в секунду с раздачей статики на каждую страницу - это тоже чуть больше чем 1гигабайт памяти и 1 ядро. Ну и никаких там 10 гигабайт ssd диска 40 гигабайт hdd. Это все жлобство 80 левела. 2 - Ядры выдры. Виртуализация KVM предполагает, что вам доступны виртуальные ядра KVM-ядро, которое вам и продают как базовую единицу, а на каком железе физически базируется это решение - никто вам не расскажет, это может быть реально какой-нибудь бушный celeron, который десять лет назад выкинули на свалку, но его навиртуализировали на пару десятков ядер и продают вам как горячий пирожок. Последние несколько месяцев хостеры наконец-то поняли что пора улучшаться и начали предоставлять быстрые сервера - у хост про - это турбо, у админвпс мощные, у таймвеб 5.5 гГц. Покупаете быстрый сервер и уже сразу видите результат. Ну и NVME тоже решает. 3 - Большинство хостеров продают или дают в нагрузку ISP manager 5. Кто-то его уже предварительно настроил, кто-то нет. Хотите чтобы ваши магазины работали быстро - проверьте чтобы для PHP был включен Opcache и не было жестких ограничений на max_connect_limit в mysql. 4 - Айпи и почта. Вот тут самое интересное. Скорее всего ваш айпи был уже у кого-то в пользовании и его скорее всего всадили в спам листы. Купили впс проверьте айпи через https://www.dnsbl.info/ - вы неприятно удвитесь. Если айпи в блек листе - хорошей отправки-доставки почты вам не видать как своих ушей, придется поработать над делистом из блек-листов! 5 - Почта почта. Попросите сразу хостера сделать PTR или rDNS для вашего айпи с привязкой к домену. Обычно никто этого никогда не делает! Опять же, хотите отправку почты с сервера - без PTR не выйдет. Также, все хостеры как правило выдают сервера в виде vps34234.hoster.com. Сразу меняйте hostname на ваш домен. А еще отключайте ipv6 при отправке в конфиге exim. 6 - Файловая система. И это очень важно. Вот прям очень очень. На сегодня для развертывания виртуальной среды есть уже достаточно зрелые инструменты, их много разных, в подробности нет смысла вдаваться, так как рядовому пользователю сервера в этом нет необходимости. Просто нужно понимать, что одни хостинг-провайдеру используют облачные файловые хранилища, и это сразу плохо, другие же используют физический локальный диск. В случае если хостинг-провайдер vps-сервера позволяет на-лету менять-добавлять размер диска сервера - на 300% там под капотом какой нибудь LVM или ceph, и то и другое замечательные технологии, но они предполагают большой оверхед по ресурсам. Да они позволяют в горячем режиме без остановки сервера делать снепшот виртуальных машин, быстро масштабироваться. Но все эти прекрасные возможности требуют ресурсов, и синхронизация между физическими дисками, так или иначе оказывается бутылочным горлышком. Поэтому я бы однозначно советовал выбирать впс сервера у провайдеров, которые в своей архитектуре используют локальную файловую систему текущего сервера без виртуальных файловых хранилищ. Подписываемся, ставим лайки, комменитруем!

Там просто хостинг, поэтому судя по всему надо настраивать smtp.

Потому что у нас могут быть два языка! И получите дублированный набор.

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

Для общего развития - задайте себе вопрос: что будет если у вас вдруг окажутся три категории с одинаковым названием ?

А еще сразу стоит подумать про escape($category_name)

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

Я же показал количество уникальных генераций страниц. Какие с кешом без кеша. И к чему это "дай"... Прекратите ваши мещанские замашки. Дай - это собрату семак спросите. Или у вокзальных женщин с низкой социальной ответственностью требуйте за пирожок.. ДАЙ! После таких дай, бывает приходит ддос от хейтеров на пару десятков террабайт в день. Спасибо не надо!

Давайте тут не будем светить доменами - я не сайткриатор, чтобы показывать чужие ресурсы без разрешения владельцев. Но если вы считаете что 66 000 страниц пагинации это там не оптимизировано. Ну простите. Мало того на данном проекте вопрос стоит сугубо в горизонтальном масштабировании, если будет желание, можно дробить на бесконечное количество индексов и получать почти линейный прирост в том числе и времени ответа страниц пагинации на 66 тысячах страниц. Все решается, просто всех все устраивает! В целом спасибо за репорт - на момент когда там было 500к ответ и на последней странице был вменяемый.

В нашем очень скромном проекте вот такие цифры за вчера: 162к генераций страниц за сутки: 2 980 000 товаров всего в магазине 1 390 000 товаров в самой большой категории: Время ответа без каких-бы то ни было кешей в этой категории: 220 уникальных элементов значений фильтра в ней же. И огрооооооомный запас прочности и абсолютная стабильность:

Регулярно я вижу это сообщение. "настройте мне сервер, чтобы у меня работали 100 000 товаров на моем неплохом впс сервере". Ну вроде там как бы логично. Хостер заявляет про классные сервера, а фрилансер, который сделал магазин - говорит иди к йоде - он тебе сделает настройку сервера и все полетит задышит. Так вот друзья. Не бывает настроек сервера, которые позволят мертвому магазину, тащить сотню тысяч товаров на ура.. Потому что максимум, что мы можем сделать на сервере, настроить затюнить опкеш, махнуть файловый кеш на хранилище в памяти (не всегда актуально на быстрых впс с NVME), сделать несколько тюнячек для mysql сервера и воткнуть nginx + php-fpm вместо тупорылого апача (не берем во внимание кастомные решения в виде полного нативного кеширования html средствами Nginx, но это опять же кеширование). Там где у вас есть пару сотен онлайна одновременно, там вот есть настройки сервера. Лимиты, максимальное количество коннектов, воркеры nginx, процесс php-fpm. Но в 99% случаев на магазинах где нет и тысячи живых хостов в день - это высшая ненужная кибениматика. И тут вопрос - йодман, шо за дела. Ты же там делаешь быстрые магазины и гнобишь всех разработчиков кешереов. И тут друзья реально да. Я делаю быстрые магазины и гноблю всех разработчиков кешеров, почему, потому что, магазины, которые попадают в мои заботливые руки, потом работают без кешеров, быстрее чем с ними - это раз. А два, кроме быстрой генерации страниц я умею делать и быстрый поиск, и быструю навигацию по товарам в админке и много чего еще. Но суть не в этом... Друзья, настройка сервера - это последняя линия обороны. Важная - но не первичная! Если вы хотите большой магазин на много товаров, вы должны закрыть вопросы "холодной" генерации страниц. А не закешированных версий, почему, потому что это важно для поисковых систем. Яндекс и Гугл - они ходят туда куда хотят, и если у вас страницы не было в кеше, а генерация у нее 5-8 секунд, они больше к вам не придут и страницу выбросят из индекса. Поэтому, если хотите, чтобы ваш большой магазин проиндексировался - вам надо иметь время ответа до секунды на всех страницах, чтобы поисковики не ходили мимо. Как это сделать? В интернете есть масса советов, типа... используйте индексы, используйте кеширование. Но! У нас в опенкарте, нормализованная структура данных, и не нормализованная структура значений для атрибутов. Первая ситуация ограничивает использование индексов при выборке-подсчете товаров в категориях, вторая при выборке подсчете значений фильтров. Если бы у нас был один язык, один магазин и вместо текстовых значений атрибутов была бы нормализованная индексированная таблица с набором id->value(значение атрибута), просто банальным построением индексов в базе и минимальными правками запросов мы бы получали нулевую нагрузку на выборку данных товаров из категорий. Все эти getProducts getTotalProducts - выполнялись за тысячные секунды. Равно как и подсчет атрибутов. Но нет! У нас опенкарт!. У нас есть писатели фильтров, не будем тыкать пальцем, которые умудряются в кеш укладывать десятки тысяч файлов и одно присутствие таких фильтров - это уже тупняк. Зачастую, тюнинг магазина - это разгребание авгиевых конюшен от модулепейсайтелей, а не тюнинг в привычном понимании. Что же делать? Ну нет однозначного ответа и решения. Никогда нет. Иногда бывает достаточно поменять сервер и проставить банальные индексы. Иногда поменять фильтр на Реально - это единственное решение на всем форуме, от автора, который понимает чем нормализованные данные отличаются от денормализованных, и где и какие структуры надо использовать. Несмотря на то что у меня есть масса вопросов к другим аспектам работы его решения, в целом с точки зрения производительности из коробки - это №1! Если вы думаете что MegaFilterPro, который индексирует якобы ваш каталог, и чего-то там долго думает дает производительность - не верьте. Сам по себе Mega фильтр - шикарная штука, но вот эта их индексация мертвому припарка, так как там идет попытка использваняи фулл-текст индексов, а они немного про другое, чем тот процесс, который пытаются решить с их помощью авторы! Лучше бы сегментацию по категориями сделали в выборках всех атрибутов на категорию! Если у вас нет данных и вы торгуете к примеру автозапчястями и вам нужен быстрый старт с поиском по коду детали - вы можете посмотрреть в сторону бесплатного модуля Sphinx: https://www.opencart.com/index.php?route=marketplace/extension/info&extension_id=18266 Который позволит не только выводить поисковые результаты но и весь каталог из сфинкса а не из базы. Да он не будет совместим с фильтрами и поисковые возможности самого модуля на нуле. Но это решение, которое позволит за несколько десятков долларов за внедрение, поднять практически любое количество товаров в магазине. Но как же так получается у нас запускать магазины на 2-3 миллиона товаров и что вот у них все хорошо. Ну по секрету скажу - что случайно) Так получилось, что первый человек с таким запросом - был мой хороший друг, и мы с ним начали работать в формате - ну а давай попробуем, попробовали так и сяк и эдак, стандартными методами не вышло. Те решения, которые работали на 20-30-100к товаров на миллион уже не работали, а тем более на миллион товаров в одной категории. Нам пришлось очень сильно и глубоко раскурить все загадки сфинкса, который позволяет на сегодня держать 300-500 тысяч генераций страниц в день, которые создают боты, при этом - и это важно, имея 5-кратный запас мошности и это на магазине в 2.5 миллиона товаров. Но после того как мы решили вопросы производительности фронта (категории, товары, фильтр, главная страница), возникли и иные вопросы, а именно: обновление цен, добавление новых товаров, манипуляции с заказами в админке, поиск, и так далее. Да и это получилось решить. При чем, решить таким образом, чтобы не уходить от стандартной структуры таблиц Opencart. И еще раз подчеркну... Все решения - это не настройка сервера. Это создание комплекса. Да у нас быстрый и хорошо настроенный сервер, но у нас еще более быстрый и грамотный код. У нас перестроенные запросы в админских моделях. Нам пришлось вскрывать csv import от ионкуба, для того чтобы оптимизировать глупые запросы автора. И да мы получили результат. Есть еще наверное несколько сотен проектов, которые стали быстрые посредством тех или иных решений и технологий, но я всегда стараюсь приводить в пример реальные достижения а не мелкую текучку.... Ну и с чего начал, на том и закончу - не бывает "настройки сервера" от которой ваш магазин вдруг взлетит! И не бывает модулей, которые вжунь и закроют все вопросы производительности. Бывает долгая кропотливая работа по настройке проектов. А те кто думают по другому - могу дать тестовую базу на пару лямов товаров - покажите мне как вы ее запустите на генерацию полмиллиона страниц в день! Ну и как всегда пари платное - 100 000 рублей!

Возьмите любой storage - амазон, или hetzner, сделайте маунт хранилища в качестве дополнитльно диска в VPS. https://wiki.hetzner.de/index.php/Storage_Boxes/ru Перенесите на него исходники картинок. А кеш картинок оставьте на ssd.

Чем отличается от ? https://www.opencart.com/index.php?route=marketplace/extension/info&extension_id=22039&filter_member=OpenCart Brasil

Да что ж ты будешь делать, опять жаднейший скриатор в топе,и его свита. Ну ошибся человек, реши вопрос не жадничай +100 в карму, +1000 лояльности. Вот реально создается впечатление, что в детстве отрубями кормили и на воде и хлебе держали, оно то многое обьясняет, но к шестидесяти годам, можно уже разум заиметь и не быть таким ЖЛОБОМ!

напиши мне, все решим!

Что мне еще сделать, я понимаю, что кому то зудит, за воровство сеопро и он тут бегает ищет нестыковки, но даже в этом комментарии какой то бред душевнобольного. Сходи мальчик, разберись со своей совестью, а потом будешь приходить и нести свой словесный понос. Особенно это вот умилило: 63% пользователей пользуются хромом. Ой https://gs.statcounter.com/ Расскажи дружок, что еще сделать кому... И как? Пруфов нету!! Сплошная мазня! Теперь кроме сикриатора и чукча решил, что чукча решил!

Дополнение к комментарию от @RGB: Возможно, нижеследующий комментарий от @Yoda не выглядел бы настолько неуместным и его автору не советовали бы научиться читать, если бы он прочел не только заголовки записи, но и ее содержание. Однако ради истории мы его тут сохраним в первозданном виде, чтобы все желающие могли ознакомиться с живым примером того, как можно с важным видом спорить с содержанием записи, практически полностью повторяя ее суть в своих же аргументах. Оригинальный комментарий @Yoda следует ниже: Где пруфы, Билли, или опять в стиле сайткриатора, который ссылатеся на мнение сайткриатора, потому что ему что то приснилось? А теперь развенчиваем мифы: а) Как минимум pagespeed учитывает время генерации контента или ttfb. И чем он меньше, тем больше краулингового бюджета на ресурс. Потому как чем тупее магазин, тем больше гугл вас по его мнению ддосит, тем меньше он заходит и наоборот. А чем чаще гугл приходит на ресурс, тем лучше он его индексирует. А также, вот пруф на то что скорость страницы - это ОФИЦИАЛЬНЫЙ фактор ранжирования! б) Быстрый магазин, на котором не тупят странные скрипты, которые не делает 500 обращений к серверу при загрузке контента - он быстрый и удобный для пользователя. И чем он приятней посетителю, тем лучше поведенческие факторы, которые также являются фактором ранжирования! в) Приводить в пример амазон и розетку - это как рассказывать что у ким кардашьян толстая жопа, 100 миллионам подписчиков на это пофиг. Но если мы берем нишевые микромагазины и говорим о том что надо быть чуть лучше чем конкурены - то скорость работы ресурса - это отличный способ с ними бороться! г) Не забываем, что кроме гугла есть еще яндекс, который с недавних пор ввел свою оценку скорости магазинов, которая по алгоритму оптимизации не сильно отличается от гугла и у яши это тоже ранжирующий фактор! Вобщем не стоит уподобляться определенным персонажам ссылающихся в своих домыслах на свои личные фантазии, а стоит сначала следить за официальной документацией.

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