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

Maxim Dounin mdounin на mdounin.ru
Вт Апр 28 00:08:52 UTC 2020


Hello!

On Mon, Apr 27, 2020 at 04:29:44PM -0400, gz wrote:

> > > Maxim Dounin Wrote:
> > > -------------------------------------------------------
> > > > > В HTML страницы бэкендом выдаются элементы <link rel="preload">
> > с
> > > > указанием
> > > > > на ресурсы для предзагрузки.
> > > > > Хотелось бы перейти с предзагрузки на http2_push указанных
> > ресурсов.
> > > > 
> > > > А вы пробовали тестировать, что вы получите на выходе?
> > > 
> > > Практически не проверял, но здравый смысл подсказывает, что даже в
> > рамках
> > > HTTP2 проталкивание ресурсов в первом запросе позволит сэкономить
> > минимум
> > > один запрос на получение ресурсов, объявленных в <link
> > rel="preload">.
> > 
> > Здравый смысл тут подсказывает неправильно. Поскольку сервер не 
> > знает, какие ресурсы уже есть у клиента, а каких ещё нет, он шлёт 
> > push'ы всегда, и тем самым расходует как канал, так и лишние 
> > ресурсы на сервере. Соответственно результат будет зависеть от 
> > того, насколько польза от push'а (сэкономленный 1 rtt при запросе 
> > дополнительных ресурсов у тех клиентов, у которых этих ресурсов 
> > нет) больше или меньше тех проблем, которые push добавляет всем 
> > остальным клиентам.
> 
> Востребованные ресурсы из push-кэша переходят в основной и будут
> использованы для следующих страниц.
> Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся в
> кэше.
> В крайнем случае несложно пометить клиента стандартным способом через
> cookie.

Проблема в том, что даже отказ от push-ресурсов - это нагрузка как 
на сервер, так и на канал.  И статистика как бы говорит нам, что в 
среднем эти накладные расходы - больше, чем польза.

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

> > > > Имеющиеся исследования про эффективность HTTP/2 push позволяют
> > предолжить,
> > > 
> > > > что результат скорее всего будет хуже, чем то, что у вас есть 
> > > > сейчас.
> > > 
> > > Я встречал обратные исследования.
> > > https://dexecure.com/blog/http2-push-vs-http-preload/
> > 
> > По ссылке нет исследований, там только общие соображения.  
> > Исследования выглядят как-то так:
> > 
> >
> https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf
> 
> Не совсем понимаю какие выводы делают авторы.
> 
> Предлагают работать над приоритезацией (которая и так корректная, и
> регулируется preload'ом), использовать экспериментальный QUIC, поддержики
> которого толком нет.

Авторы ясно и однозначно показывают, что server push - в среднем 
вредит, и в большинстве случаев лишь способ выстрелить себе в 
ногу.  И предлагают работать над другими технологиями, 
потенциально более полезными.

Тут важно понимать, что речь идёт про взгляд разработчиков 
браузера, и рассказывалось это всё на HTTP working group, то есть 
в рамках встречи людей, занимающихся разработкой протокола.

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

> > > Плюс у push шире поддерживается.
> > 
> > Я бы не был столь категоричен. 
> 
> Нет никакой категоричности:
> https://caniuse.com/#search=rel%20preload — 84%
> https://caniuse.com/#feat=http2 — 94%
> 
> Не совсем корректное сравнение точно preload vs push, тем не менее.

Ну вот это сравнение - говорит о минимальной разнице, и при этом 
мы не знаем, сколько в том http2 поддержики push'а, и не знаем, 
сколько глюков там, где она таки есть.

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

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

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

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


Подробная информация о списке рассылки nginx-ru