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

Вот как у меня:

Пользователь подписыается на события связанные с объектом $dctList['UUID']:
\CPullWatch::Add($UserID, $dctList['UUID']);

Отправляем уведомление всем пользователям при событии связанным с объектом с индентификатором $list_uuid

\CPullWatch::AddToStack($list_uuid,
				Array(
					'module_id' => 'list',
					'command' => 'exchange',
					'params' => [
							'provocative' => $dctData['head']['UID'],
							'list_uuid'=> $list_uuid
						]
				)
			);

загрузка модуля:

BX.loadScript('/bitrix/js/pull/protobuf/protobuf.js', ()=>{
					BX.loadScript('/bitrix/js/pull/protobuf/model.js', ()=>{
							BX.loadScript('/bitrix/js/rest/client/rest.client.js', ()=>{
									BX.loadScript('/bitrix/js/pull/client/pull.client.js',()=>{APP.bitrixreinit._pullinit()});
								});
						});
				});

Подписка на события в методе _pullinit:

// подписываемся на события P&P
		BX.addCustomEvent("onPullEvent", function(module_id,command,params) {
			
			if (APP.getConfigParam('uid') == params.provocative) {
				//if ('production' != APP.getConfigParam('mode')) console.log('собственное событие пропущено');
				return;
			}
			if ('exchange' == command) {
				APP.exchange({basis: 'pull', context: params});
			}
		});

		BX.addCustomEvent("onPullStatus", function(status) {
			if ('online' != APP.$store.state.status.push_and_pull
					&& 'online' == status) {
				// не онлайн сменился на онлайн
				//let last_sync_time = APP.$store.state.db.sync.last.time.client || 0
				//let now_time = Date.now()/1000
				//if (now_time - last_sync_time < 30) {
				//	
				//} else {
				//	
				//}
				APP.exchange({basis: 'reconnect'});
			}
			APP.$store.commit("updateStatus",{key:'push_and_pull',data:status})
		});
		
		BX.PULL.start();

Никак - стандартный компонент поиска выводит элементы поиска а не элементы инфоблока - не будет там никакого ['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 элемент Услуга в одном ИБ и у него множественное поле привязки к элементам ИБ.
Во втором ИБ вы сделаете нужные вам элементы и привяжете их к Услуге через это поле привязки.

Всё.