Добиться более плавной анимации помог комплекс следующих действий:

1. Точное указание property у transition (т.е. вместо "transition: all" указываем конкретное свойство с которым производится анимация).
2. Использование при JS манипуляции с классами не classList, а className. Переход на это решение позволил добиться реального прогресса в плавности анимации. В частности, это решение подсказал VK, там используется такая же схема. Метод className входит в DOM Core (level 2), имеет практически полную совместимость со всеми браузерами, а также более эффективно обрабатывается браузерными движками с минимальными задержками.

Как оказалось, в этой проблеме было целых 2 нюанса:

- первый заключался в адресе обращения к wss (спасибо Дмитрий Беляев)
- второй в том, что необходимо было убрать из настроек подключения "requestCert: true" (спасибо @andreyma со stackoverflow).

В итоге пришел к решению на уровне логики приложения. В основной базе постоянно содержится 0.5-1 млн наиболее свежих записей, а остальные выносятся в архивную. Скрипт-архиватор раз в сутки переносит старые записи в архив. Первоначально пользователям выдаются только наиболее свежие данные из основной базы (99% запросов), а если их недостаточно, то производится поиск в архивной.

P.S. В дополнение, если пользователь начал листать ленту - сделал вывод не 10, а 50 записей. При скроллинге клиент 1 раз выдает данные из запроса, а остальные 4 пакета помещает в массив и выдает по мере необходимости. Когда данные клиента заканчиваются, делается новый запрос. Сразу 50 не вывожу, чтобы не тормозить браузер (там много графики). Что-то подобное встречается в vk и ряде других крупных сайтов.

P.P.S. Итоговое решение на уровне MySQL получилось следующим. Провел вручную тестирование с выборками на основе жестко прописанного (use index) простого или составного индекса. Наилучшим по производительности оказалось использование составного индекса (например, (type, update)), использование которого жестко прописано в коде приложения в зависимости от конкретного типа выборки (по-умолчанию, в ряде случает MySQL выбирает не самый производительный индекс). Удивило расхождение данных, выдаваемых EXPLAIN с реальными показателями производительности. Так, простой индекс (EXPLAIN показывает rows 10) работал в сотни раз медленнее составного с rows в несколько млн. записей.

P.P.P.S. В общем, проблема была в неправильном выборе движком MySQL индекса по которому проводился поиск (в некоторых случаях использовался только простой индекс, когда лучше было использовать составной, а в некоторых поиск проводился сразу по 2-м индексам с объединением результатов). При прописывании USE INDEX вручную (на каждый конкретный случай) производительность многократно возросла.