Т.е. не хватает знаний сделать правильный кастом, но хватает знаний сделать все, что нужно полностью с нуля.... ну ну.. :)
Не знаю чего вам там забанили, но репозиторий на githab "мастхев" в таких проектах. (Уже если каким то чудом вы реально там забанены - есть и аналоги). Это важно и для распространения, и для разработки особенно публичных решений.
Скрипт очень сырой. Он не дожидается загрузки картинок как следствие не гарантирует их подхватывание. В прочем сомнительный функционал сгребать все картинки со страницы. протестировать удалось только убрав из фильтра некоторые условия.
Зачем вы включили в него стили (те что отвечают за дизайн точно не стоит втаскивать внутрь скрипта), и саму верстку - не легче ли создавать скриптом ее, что б не было необходимости потом искать в DOM и навешивать обработчики. Крутящийся прогресс при каждой смене картинки - сомнительное решение. Зачем оно ведь картинки в данном случае уже загружены. Опять же: достаточно стандартное решение, что на старнице отображаются маленькие превью, а при открытии уже их полноразмерные варианты..... ну и в общем по мелочи не хватает некоторого функционала, который популярен в подобных скриптах.
И не только на странице. Есть у меня проект, там фоном идет обмен с несколькими внешними сервисами. Все три обмена готовые сторонние решения (и не дешевые). Но глядя на их реализацию (опять же вопрос алгоритмов) хочется кого то прибить...... Там такое ощущение, что люди сделали решение для каталога (вот как раз как выше говорили "до 1000 товаров" и с парой заказов в месяц) и им все ок.... И вот эти процессы идущие фоном на серваке - способны этот сервак загасить полностью
На проектах где высокий RPS (конечно если позволяет ситуация) вполне резонно в узких местах уходить от "типового поведения". Не скажу зв ВП, но в Битриксе это вполне нормально реализуемо. (у меня есть проект где бываю моменты когда приходит более 150К пользователей активных, при чем не размазано на все сутки, а именно норовят все разом). Ну, а далее все так: и алгоритмы и структура БД (Включая денормализацию), кеширование и т.д и т.п.
Инфоблоки прекрасно работают на 1000 :) и даже значительно больше. Т.е. при грамотном кешировании это не особо проблема. Например (из проектов на моем обслуживании) каталог порядка 150к товаров и примерно столько же торговых предложений, нормально работает, хотелось бы быстрее, но проблема скорее в шаблоне и его универсальности (в дополнение к самому битриксу). Второй пример (где напрягает уже именно кухня Битрикс - там чуть меньше товаров, но вот свойств несколько тысяч - исторически так сложилось. Но там ускорили переводом фронта на node.js.
Как итог, конечно же при необходимости "ускорения" урезать "универсальность" вполне себе путь и, полагаю, для любого проекта (где есть универсальность). Но опять же у каждого проекта свои возможности и варианты. Где то надо часть таблиц в отдельную БД вытащить, где то часть функционала вырезать в отдельный сервис и т.д. и т.п.
Пожалуй я для себя, как для пользователя, "заметил" один недостаток: домен с дефисом "сложнее" набирать на мобильном - приходится переключить в какой то момент клавиатуру на знаки :)
