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