Александр Маджугин

Никак - стандартный компонент поиска выводит элементы поиска а не элементы инфоблока - не будет там никакого ['PROPERTIES']['NAME']['VALUE']

Варианта два:
1 получать id элементов инфоблока из элементов поиска и подавать их в виде фильтра на вход news.list им уже выводить элементы.
2 в result_modifier.php шаблона компонента поиска, вынимать недостающие данные.

Я бы выбрал второе.

А почему у вас на каждуй вкладку отдельный компонент? Они так сильно разнятся и их невозможно обобщить до однодного?
Но даже в этом случае у вас должен быть один компонент на все вкладки, который будет подключать разный контент как дочерний компонент по имени:

<div class="tab">
        <component
                v-bind:is="activeTabComponent"
                v-model="values"
            ></component>
    </div>

и передавать в этот дочерний компонент в модель, объект куда будет эмиттить свои данные дочерний компонент.
И вот в этом компоненте вкладки расположите свою кнопку.

Делаем обычную сортировку по SORT, а дальше:

1 в шаблоне выводим только элементы с сортировкой меньше 23, остальные вываливаем в виде данных и рендерим на на странице js'ом (тупой вариант: выводить в тег script с невыполняемым type, и оттуда добавлять js'ом в страницу), страницы по набору элементов будут одинаковые, но порядок каждый раз будет разным. Кэш работает.

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

3 Раз в сутки ночью, агентом переписываем эти допсвойства на другие случайные значения.

Итого: кэш работает, видимость случайности есть, причем она при каждом обновлении разная и даже хрен поймешь что страницы часто одинаковы по составу. Объем кэша каталог вырастит - ну у всего есть цена.

UPD:
Про решение с двумя компонентами - да просто во втором компоненте на первой странице скройте 22 элемента первые и все. Естественно страница должна быть больше 22 элементов.
Возможно вы сразу возразите, что тогда посетитель в постраничной выборке не увидит эти 22 элемента, поэтому сразу отвечу - вас это вообще не должно волновать, так как у вас посетитель вообще не увидит почти половину каталога (так на вскидку 40-45%) при случайной выборке + пагинации. Вообще пагинация при настоящей случайной выборке полностью лишена смысла.
Рабочее решение близкое к вашим требованиям я выше привел.
Если хотите избавится в нем от того что часть элементов каталога будет невидна при пагинации - передавайте в свойствах пагинации еще и свойство сортировки случайно выставленное на первой стартовой странице.

Я делаю общий шаблон .default, а в остальных шаблонах в хедере:

<?if(!defined("B_PROLOG_INCLUDED") || B_PROLOG_INCLUDED!==true) die();?>
<?include(S_P_LAYOUT.'/header.php');?>
<div class="page">
	<!-- HEADER :: START-->
	<header class="header">
		<div class="container">
			<div class="header__wrapper">
				<a class="header__logo" href="#"><img src="<?=P_IMAGES?>/logotype.svg" alt=""></a>
				
				<?include(S_P_INCLUDES.'/menu-top.php');?>
				
				<div class="header__links">
					<?include(S_P_INCLUDES.'/menu-links.php');?>
				</div>
				
				<button class="hamburger hamburger--spin" type="button" js-hamburger><span class="hamburger-box"><span class="hamburger-inner"></span></span></button>
			</div>
		</div>
	</header>
	<!-- HEADER :: END-->
	<div class="page__content">
		<?$APPLICATION->ShowPanel()?>

и аналогично в футере:

какой-то отличающийся код
<?include(S_P_LAYOUT.'/footer.php');?>

Соотвественно S_P_LAYOUT - это константа с абсолютным путем к папке шаблона .default

Это вариант номер один (и вобще говоря вы можете вложить так сколько угодно шаблонов).

Второй вариант - использовать общие включаемые области во всех шаблонах.

но эти стили и скрипты нужны для нормальной работы сайта, часть из них часть из них стили и скрипты шаблона сайта, другие это системные JS скрипты которые загружает сам Битрикс.

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

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

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

Для ускорения загрузки страницы pagespeed предлагает использовать атрибут link rel=preload при подключении CSS.

Вообще-то шрифтов.

Пробовал следовать рекомендации pagespeed и подключать CSS стили такой конструкцией

Вы не правильно распарсили рекомендацию.
Если вы хотите добавить предзагрузку стилей вы должны добавить метатег прелойда:

<link rel="preload" href="/local/templates/.default/css/style.min.css">

А не заменить им загрузку стилей.

Eliminate render-blocking resources - здесь сервис рекомендует убрать блокирующие рендеринг страницы ресурсы, в моем случае он почему то таким ресурсом результирующий CSS файл сайта, куда Битрикс объединил CSS файл стилей шаблона сайта, CSS файлы шаблонов компонентов и системные файлы

Что значит "почему-то"? Потому что это блокирующий ресурс. Вынесете стили страницы и хедера в отдельный файл который вставляйте инлайном в html для пользователей заходящих на сайт впервые в head, и подключайте в конце страницы два файла css - этот (да стили будут дважды загружены) и общий.
А для пользователей заходящих повторно, подключайте только файлы, но уже в начале страницы.

Remove unused CSS - здесь сервис указывает системные CSS и стили шаблона сайта как неиспользуемые, почему так происходит, ведь эти файлы используются в проекте?

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

1. Нет ли ошибки?)

Ошибки в чем?

2. Браузер не сможет кэшировать такие картинки?

Дело не в том что не сможет - не будет, поскольку это бессмысленно.
Представим что все эти картинки в dataurl браузер закэшировал... и что? Теперь они магическим образом исчезнут из страницы которую вы передаете браузеру? Нет. Сервер все так же встраивает их в страницу и браузер ее все так же скачивает целиком. А зачем он их тогда кэшировал?

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

Преимущество dataurl - картинки отображаются гораздо раньше так как загружены вместе со страницей или стилями.
Недостаток - они скачиваются всякий раз когда нужно загрузить страницу.

Таким образом хорошо это или плохо зависит от сценария использования вашего сайта.
Если клиент только один раз загрузит страницу с товарами, посмотрит на цены и в ужасе закроет вкладку, то потери и правда будут в районе нескольких процентов. Если несколько раз... ну давайте посчитаем.
Пусть размер страницы 200Кб и на ней еще 2Мб изображений. Тогда в классической ситуации первая загрузка страницы будет ~2200Кб, а все последующие 200Кб. В вашем случае все загрузки будут по 2200Кб.

Таким образом если клиент посещает страницу один раз - разницы нет. Если два - то доп расходы составят 83%, если 4 раза - 215% лишнего трафика сверху.

Но все зависит от повторных просмотров и размеров ваших картинок и отношению этого размера к размеру страницы.

Ну так комплексный компонент и переопределяет.
Наверняка у него есть параметр который отключает такое поведение - поищите.
Но лучше всего не используйте его. Что вообще может заставить использовать комплексные компоненты? Комплексные компоненты зло которого надо избегать всеми доступными способами.

Так сделать нельзя, да и не нужно.

У вас должен быть 1 элемент Услуга в одном ИБ и у него множественное поле привязки к элементам ИБ.
Во втором ИБ вы сделаете нужные вам элементы и привяжете их к Услуге через это поле привязки.

Всё.

Сконвертируйте ее на стороне сайта в mutator.php.
Не нужно одну и ту же задачу выполнять в двух разных местах. Тем более по разные стороны от сети.