Re: http2 push — не планируется ли поддержка <link rel="preload"> по аналогии с заголовком Link?

[gz]

> > Востребованные ресурсы из 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.

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

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287846,287886#msg-287886