> Что вы несёте.
> Речь идёт о том насколько у пользователя сайт тормозит, а не о эффективности XML.

Ну то есть мы не в состоянии задать вопрос, по какой именно причине у пользователя тормозит сайт. До джуна не дотягиваете. Подсказываю -- ответить на этот вопрос поможет профайлинг. И прямо говорю -- 99% тормозов происходят из-за медлительной сети

> И дело вовсе не в том сколько мы тащим, хотя и в этом, а в том в какие моменты времени мы это тащим, кто как и когда это парсит и отрисовывает.

Ага. Отсюда и далее начинаем штудировать, что такое AJAX и REST. Где сильные места и где слабые, что масштабируется и что нет. Даже от джуна требуется понимание этих базовых вещей

Из всех тех вещей, которые вы пока ещё не понимаете, хочу обратить внимание на нагрузку на бэкэнд. Рендеринг на бэкэнде потребляет много ресурсов CPU, что заставляет вас масштабировать сервера. Готовы ли вы лишиться части своей ЗП и пустить её на ненужные сервера, которые будут заниматься промышленным форматированием строк и генерацией HTML?

Вторая вещь, которую вы до сих пор не понимаете -- пользователь посещает сайт один раз или переходит со страницы на страницу? Сколько дублей данных получит пользователь по медленной сети, если отдавать ему отрендеренный HTML?

> Не говоря уже что кеширование для динамики никогда не работает.

Да. По этой же причине кэширование динамически отрендеренных HTML страниц тоже не работает. Поздравляю, вы сами сказали, что несёте бред.

> И я не понял, вы вначале 10к записей пользователю заливаете, а потом уже на страницы разбиваете? Прекращайте это безобразие!

Ничерта вы не поняли. Как именно я сформулировал эту мысль? Прочитайте ещё раз

> Напишите уже на коленке тест простой и сами сравните хоть на 1000 записей с текстом пускай по 100 слов на запись.

Предыдущие 2 пункта абсурдны и ещё 2 пункта демонстрируют отсутствие знаний. Если цитату вырвать из контекста, то к ней претензий нет -- бэк должен прочитать данные из БД и сериализовать их, потом данные надо передать по сети, потом парсинг происходит минимум за O(N) (алгоритмов парсинга JSON не изучал, поэтому точно не скажу)
Только в абсолютном значении разница между 10мкс и 100мкс мало заметна
Ещё забавный момент -- накладные расходы на 1 запись получаются меньшими при большем числе записей
И тут умный человек бы задал совсем другой вопрос -- уверен ли я, что пользователь прочитает все 10к записей. И тут ответ уже нет. Но я как бы ранее говорил, что умолчания настроены таким образом, чтобы пользователю в среднем влетало 100 записей. Только пользователь сам и сознательно может запросить больше -- я его не сдерживаю