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

Я таковой статистикой не располагаю.
Но предполагаю, что клиенту отказаться от push'а проще, чем сделать дополнительный запрос к ресурсу.

> Что будет конкретно в вашем случае - зависит, безусловно, от
> конкретной нагрузки и от того, насколько "в крайнем случае
> несложно" вам будет избежать лишних push'ей. Но, повторюсь, в
> среднем - будет хуже, потому что "в крайнем случае" никто не
> заморачивается. Именно поэтому я начал с вопроса пробовали ли вы
> тестировать, что получится. Подозреваю, что от банального
> перекладывания существующих <link rel="preload"> в push'ы -
> станет только хуже.

Да, я понял Вашу точку зрения.
Да, узкого эксперимента я не проводил.

> https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf
> >
> > Не совсем понимаю какие выводы делают авторы.
> >
> > Предлагают работать над приоритезацией (которая и так корректная, и
> > регулируется preload'ом), использовать экспериментальный QUIC,
> поддержики
> > которого толком нет.
>
> Авторы ясно и однозначно показывают, что server push - в среднем
> вредит, и в большинстве случаев лишь способ выстрелить себе в
> ногу. И предлагают работать над другими технологиями,
> потенциально более полезными.
>
> Тут важно понимать, что речь идёт про взгляд разработчиков
> браузера, и рассказывалось это всё на HTTP working group, то есть
> в рамках встречи людей, занимающихся разработкой протокола.

Из Ваших соображений и трактовке вышеприведённого исследования складывается впечатление, что даже разработчики протокола не донца понимают зачем push нужен.
При том, что не только они описали его в протоколе, но и сторонние разработчики реализовали поддержку push'а клиентах и нескольких серверах.

> (Ну и да, про приоритезацию - смешно. Нет, это не про preload,
> это, как я понимаю, про приоритеты в рамках HTTP/2. Там самолёт с
> бассейном и джакузи запроектирован в рамках стандарта, корректности
> ждать не приходится.)

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

> > Я прекрасно понимаю, что push — не панацея, и хотел попробовать на
> практике
> > проталкивание критических ресурсов, которые в любом случае
> приоритетны и
> > будут загружены для отрисовки.
>
> Именно с этого я и начал: попробуйте на практике на отдельных
> страницах, без попыток вытаскивать версии ресурсов через SSI и вот
> этого всего. Получите статистику, сравните.
>
> Сейчас же вы пришли и убеждаете разработчиков, что вам надо,
> потому что оно точно будет лучше, но тестировать вы ничего не
> тестировали и не хотите.

Где именно и кого я в чём-то убеждал и убеждал в том, что мне нужно?
Я задал вопрос о планах.

А учитывая, что использовать саму директиву http2_push затруднительно — один ресурс за раз, невозможность использования в if — и предвидя рекомендацию использовать http2_push_preload, я рассказал о том, в какую сторону пошёл и что уже попробовал сделать своими силами, и о том, какие возможности могли бы помочь в решении задачи.

> Так это не работает. Придёте со
> стастикой, явно показывающей плюсы - мы задумаемся над тем, как
> облегчить вам жизнь в конфигурации с SSI. Пока же из статистике
> есть вот только ссылка выше, из которой явно следует, что делать
> что-либо для лучше поддержки HTTP/2 push - в среднем бессмысленно.

То, о чём я рассказываю и есть эксперимент.
Проще внедрить это на dev- или даже production-версии сайта, чем готовить узкие эксперименты из двух страниц.
В случае pdocution'а можно прогнозировать значимое изменение в статистике загрузки страниц, в том числе по данным браузеров — в той же Метрике, Google Console или PageSpeed Insights.

Простой эксперимент, конечно, имеет право на жизнь, но это пара страниц и несколько доступных браузеров и инструментов.