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

[Илья Шипицин]

вт, 28 апр. 2020 г. в 01:29, gz <nginx-forum на forum.nginx.org>:

> > > Maxim Dounin Wrote:
> > > -------------------------------------------------------
> > > > > В HTML страницы бэкендом выдаются элементы <link rel="preload">
> > с
> > > > указанием
> > > > > на ресурсы для предзагрузки.
> > > > > Хотелось бы перейти с предзагрузки на http2_push указанных
> > ресурсов.
> > > >
> > > > А вы пробовали тестировать, что вы получите на выходе?
> > >
> > > Практически не проверял, но здравый смысл подсказывает, что даже в
> > рамках
> > > HTTP2 проталкивание ресурсов в первом запросе позволит сэкономить
> > минимум
> > > один запрос на получение ресурсов, объявленных в <link
> > rel="preload">.
> >
> > Здравый смысл тут подсказывает неправильно. Поскольку сервер не
> > знает, какие ресурсы уже есть у клиента, а каких ещё нет, он шлёт
> > push'ы всегда, и тем самым расходует как канал, так и лишние
> > ресурсы на сервере. Соответственно результат будет зависеть от
> > того, насколько польза от push'а (сэкономленный 1 rtt при запросе
> > дополнительных ресурсов у тех клиентов, у которых этих ресурсов
> > нет) больше или меньше тех проблем, которые push добавляет всем
> > остальным клиентам.
>
> Востребованные ресурсы из push-кэша переходят в основной и будут
> использованы для следующих страниц.
> Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся в
> кэше.
> В крайнем случае несложно пометить клиента стандартным способом через
> cookie.
>
> > > > Имеющиеся исследования про эффективность 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, поддержики
> которого толком нет.
>
> > > Плюс у push шире поддерживается.
> >
> > Я бы не был столь категоричен.
>
> Нет никакой категоричности:
> https://caniuse.com/#search=rel%20preload — 84%
> https://caniuse.com/#feat=http2 — 94%
>
> Не совсем корректное сравнение точно preload vs push, тем не менее.
>
> Я прекрасно понимаю, что push — не панацея, и хотел попробовать на практике
> проталкивание критических ресурсов, которые в любом случае приоритетны и
> будут загружены для отрисовки.
>

я бы с интересом посмотрел на аналитику, которая привела к такому развитию
событий.
какие метрики вы с приложения снимаете, методика, всё вот это.


>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,287846,287852#msg-287852
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200428/d0fd2f71/attachment.htm>