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

Вс Май 3 21:02:43 UTC 2020

Hello!

On Wed, Apr 29, 2020 at 01:26:27PM -0400, gz wrote:

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

Ссылку на статистику я привёл.  Если вы не располагаете другой - 
вероятно, другой и нет.

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

По ресурсам "получить push" и "сделать дополнительный запрос и 
получить на него ответ" - строго одно и то же.  Разница - только во 
времени, полученный 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'а клиентах и нескольких серверах.

Зачем нужен push - все понимают.  Насколько он при этом полезен 
для интернета в среднем - можно выяснить только практически.  Вот 
есть исследование от команды одного из браузеров, которое говорит, 
что в среднем - вреден.  

Что до "реализовали поддержку push'а", то вот мы - всегда считали, 
что полезность push'а, мягко говоря, преувеличена.  Но, тем не 
менее, вынуждены были реализовать, просто мотому, что пользователи 
читают маркетинговые материалы, рассказывающие о новом красивом 
протоколе HTTP/2 и его замечательных возможностях.  А понимать, 
какие недостатки есть у этих замечательных возможностей - не 
пытаются.

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

Приоритизация в рамках стандарта HTTP/2 - это вполне конкретная 
вещь, и именно она и упоминается в соответствующем докладе.  И с 
ней проблемы, именно потому она там и упоминается.

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

И получили на него ответ.  А равно рекоменацию о том, с чего 
начать, если вы вдруг считаете, что вам, тем не менее, надо.

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

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

Директив http2_push может быть сколько угодно.  Если после 
интерполяции переменных парамером оказалась пустая строка - 
директива не делает ничего.  То есь если хочется push'ить ресурсы 
условно, то это можно сделать элементарно:

    set $push "";
    if ($want_push_css) {
        set $push "/css/main.css";
    }

    http2_push $css;

Аналогично можно push'ить произвольное количество ресурсов, если 
это нужно.  Достаточно написать соответствующий конфиг.

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

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

-- 
Maxim Dounin
http://mdounin.ru/