вопрос только насколько этот селектолах совместим с lxml

parsel для css селектора делает преобразование в xpath и дальше им юзается

а если тут вот для начала попробовать подсунуть https://github.com/scrapy/parsel/blob/master/parsel/selector.py

там вроде с html.HTMLParser относительно from lxml import html

а вот про etree непонятно.

Может транслятор можно подсунуть как-то?

еще про ускорение - если у тебя 50 селекторов, попробуй их выставить так, чтобы постепенно отсекать лишние части, т.е. к примеру если ты взял breadcrumbs, и дальше тебе надо брать описание товара справа, то часть дерева с картинками слева, breadcrumbs, футер страницы и меню тебе уже не нужно, ты можешь присвоить условно
breadcrumbs = response.css('blabla')
right_part = response.css('.right_part')
price = right_part.css('.price')

типо так запрос на сайт уже не делается а просто парсиш з уже предыдущего респонса?

ээ, ну обычно там и так реквест новый на каждый чих делать не надо. Это скорее к тому, что парселю не надо по всему стояку  дом-дерева бултыхаться чтобы вытащить одну цену

или ты хочешь сказать, что на каждое поле айтема делаешь новый запрос???

а хотя нет, я например в цикле ж беру один запрос и по нему делаю что надо, тоесть все селекторы были получаеться за один запрос к сайту

да, хотя я не удивлюсь, если это хреновая оптимизация, потому-что я вот сейчас в коде parsel увидел lru_cache,  т.е. оно кеширует запросы какой-то там функции, и если вдруг этот кеш сохраняется между вызовами на верхнем уровне, то эта оптимизация наоборот будет вредна

в scrapy нету кеширования?

есть, я не про это, я про то, что там в коде parsel есть https://docs.python.org/3.3/library/functools.html#functools.lru_cache
но я хз чего он там делает)

И что тебя смущает в lru_cache?

меня ничего, я просто не смотрел для чего именно он там используется, пойду гляну)

Еще не встречал чтоб кэш где-то что-то замедлял

посмотрел, он там только на трансляции из css в xpath используется

ээээ. так я и не говорил, что он что-то замедляет, я всеми руками за него обычно)

"хреновая оптимизация" это я говорил про свое предложение "отсекать" ненужные участки DOM, если вдруг lru_cache и так кеширует условный путь до конечного селектора