Мы по-моему, про разные вещи говорим. Моя мысль была делать массированный read-ahead - т.е. что если информации не так много, то клиент может (в бэкграунде, не зависимо от действий пользователя) закачать всё в кэш. Т.е. в твоём дизайне это будет запросить полный список хэштэгов, а потом выкачать всё, что ещё не закэшировано. Можно оптимизировать, использовав сжатие. Просто для небольших магазинчиков заархивированной инфы с гулькин нос (никак не больше мегабайта-двух), а benefit огромен: после того, как всё скачалось, вообще никакого взаимодействия с сервером больше не нужно. Кроме, разве что, очень редких обновлений.

Насчёт двух проходного поиска - надо подумать.

У идеи есть один мега-недостаток - это минимум два round-trip'а на каждый "живой" запрос (когда кэш ещё пуст). Два round-trip'а это два round-trip'а. Конкуренты, делающие один round-trip побьют. Ну и для клиентов с медленным соединением это может hurt their experience.

Во всём остальном идея весьма соблазнительная. Надо ещё подумать. Например, очевидно, что нагрузка на сервер будет меньше. Суммарного трафика будет меньше. Хэши, если их очень компактно пересылать, могут уместиться в один TCP пакет, что есть very, very good.

Кстати, очевидно, ты можешь оптимизировать запросы по категориям, чтобы укладываться в один round-trip: если ты заведёшь id категорий ("категория" это прямой линк на список, с главной страницы), и у каждого "документа" будешь держать список id-шников, к которым он принадлежит, то в этом случае ты можешь, когда юзер кликает на категорию, вместе со строкой запроса пересылать серверу список хэшей, которые у тебя уже есть в кэше на эту категорию. Сервер пусть вернёт сразу все детали, но только для тех items, которых у тебя ещё нет.