Т.е. сайт очень большой формирование кэша занимает очень много времени от 6 до 9 секунд. Как минимум отключите кеширование карты ресурсов. Время генерации кеша не особенно снизится, но сам кеш контекста процентов на 50-70% уменьшится. Это системная настройка cache_alias_map.

Смотрите в сторону Closure::bindTo. Навесьте плагин на событие OnMODXInit (судя по всему это событие появилось только в MODX-2.3+) и расширяйте объект $modx. Но это скользкая дорожка. Правильней написать свой класс-сервис и добавить его в ExstensionPackages с указанием названия сервиса и имени класса, и юзать типа $modx->MyService->MyMethod().

Они понятно, что все не кешируемые. А вот это не понятно. А зачем их делать не кешируемыми? С рандомными еще понятно, но остальные-то выборки почему не кешируемые? В чем профит?

У меня только один вопрос: а почему не использовать getdata-процессоры? Как раз для таких задач они же и были написаны.

Именно это и делает метод getIterator Не совсем. Во-первых, не fetchAll() используется, fetch(), так как на каждую итерацию идет выборка только одной строки из БД. Во-вторых, getIterator получая очередную строчку данных, набивает ее в конечный объект. А формируя запрос и выполняя fetch() самостоятельно, мы просто оперируем полученными данными. Это во многие разы снижает потребление ресурсов.

то выгоднее не использовать getCollection, а выбрать через fetchAll(PDO::FETCH_ASSOC) В большинстве случаев да. TV можно выбрать вторым запросом, используя уже полученный массив, к нему же и присоединить результаты. Можно и сразу запрос сформировать, используя leftJoin(). Просто сколько будет нужных TVшек, столько и джоинов выполнять, указывая в условии ID-шник добавляемой ТВшки.