i_want_to_know_everything: Максим свое дело знает) Опять же, как я писал в комментарии к ответу Максим Тимофеев при 50к тормозить не должно и на шареде, если он адекватен. На VPS нормальном и подавно. Прелесть ES в том, что это полный off-load нагрузки и по индексации БД, и по поиску-фильтрации, что очень удобно и полезно, особенно в пиковых режимах. Сам по себе поиск идет по АПИ в другом месте, возвращаемый результат - массив ID товаров, которые выводятся одним простым WP_Query с аргументом post__in.
i_want_to_know_everything: по поводу "работают как-то так" - 100% :) По поводу скорости, увы, боюсь что нормального решения нет. Я не пилил в виде плагина, но рефакторил существующие на весьма крупных екоммерсах и делал с нуля когда проекты целиком мы делали. В конечном итоге все сводилось к тому, что Elastic Search - единственное правильное решение для крупного магазина. Но не для шареда, естественно. Впрочем, более-менее крупный магазин и шаред - вещи изначально несовместимые.
i_want_to_know_everything: Ну кроме граблей в виде промежуточных таблиц и своих кастомных SQL-запросов других вариантов на шареде нету. Выборки по таксономиям быстрые, по метаданным - нет, такова архитектура WP, поиск-фильтрация как таковые в нем не для таких задач. Для таких задач есть сторонние решения, в чем с ними проблема? Я не совсем понимаю, почему не подходит ElasticPress + ElasticSearch Cloud. Или вы свой плагин фильтрации пилите, поэтому пытаетесь сделать лучше аналогов?
в БД WordPress все нужные индексы уже есть, а запросы в целом вполне себе норм. По таксономиям все работает шустро, по мета-данным - вот там как раз индексы не особо предусмотрены и их добавление сильно ситуацию не спасет. Другое дело, что даже на шареде при 50к записей тормозить не должно еще, надо все остальное смотреть. И оbject cache таки да, заметно ускорит. Впрочем, не факт что он есть даже на дорогом шареде, или что выделенной памяти хватит, а то будет постоянная гонка за место в стеке, а не нормальный LRU. Вообще, конечно, делать такие сложные фильтры и с такой БД держаться за шаред - имхо какое-то странное решение. Тут по большому счету любая платформа может подтормаживать. Берется нормальный VPS, ставится специализированный Elastic Search и все, вопрос решен.
Георгий: у меня оно в meta и options было. поэтому легко менялось. Что касается attachment_url то да, тут так просто не избавиться. Смотрите библиотеки/плагины для offload-а на сторонние сервера
sim3x: не люблю его и не использую, у меня все fine-tuned. Да и не в этом дело. Зачем мне грузить слайдер, лайтбокс, скроллимейт и еще десяток скриптов + парочку их css на каждой странице, если нужны они только, допустим, на главной? Или валидация форм нужна только на странице контактов. Примеров масса. То же с большими спрайтами. Во-первых, мы сильно увеличивает общий весь страницы и самый первый приход пользователя - отдаем ему тупо все, а там видно будет - пригодится или нет. И если мы грузим это все на каждой странице - получаем как раз замедление рендера - браузер то на каждой странице будет парсить все скрипты и стили, даже этот десяток не используется. В общем, с точки зрения оптимизации это все надо разделять. И вот тут HTTP/2 в помощь. Это один из примеров. Можно углубляться, но смысла нет. Ответ очень прост - если это корпоративный сайтик небольшой или портфолио - все это не важно. Если это high-load и крупный проект - тогда это мегаважно. Собственно из опыта хайлоада все это и выросло у меня в кастомные решения.
sim3x: конкатенация и спрайты. Генерация этого добра хоть и автоматизирована, но тоже время на поддержку этого всего. В моем случае с WP иногда бывает неудобно, особенности платформы. То же касается загрузки скриптов и стилей только там где надо вместо одного бандла. Картинки тоже, вместо одного большого спрайта - ровно то, что нужно на этой странице. И всем этим добром, предоставленным со стороны фронтенда в разобранном виде, а не одной большой соплей, мне на бекенде управлять гораздо комфортнее и быстрее. Фронтендеру проще - он забилдил автоматом сборку и в ус не дует. А мне потом это надо оптимизировать под максимальную производительность. По мелочи, но в сумме какая-то копеечка на каждом проекте. Меньше обезьяньей работы.
sim3x: Да я в курсе. Там, в принципе, в 105 кажется слайде - единственная точная информация из этого спича. Все остальное - синтетические тесты и подгонка под свой маркетинг. Многое не учтено, много сказано с точки зрения CDN а не реальных приложений, и по packet loss там вопросов к их тестам много... В общем, нюансов вагон и тележка. Фастли еще те жуки. В целом, конечно H2 не является волшебной палочкой, да. Но все же, in real world он прекрасно работает и таки действительно заметно и ощутимо ускоряет. А также снимает часть работы с команды, а экономия ресурса - это профит. Особенно в long term.
