<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">ср, 29 апр. 2020 г. в 22:26, gz <<a href="mailto:nginx-forum@forum.nginx.org">nginx-forum@forum.nginx.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> > Востребованные ресурсы из push-кэша переходят в основной и будут<br>
> > использованы для следующих страниц.<br>
> > Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся<br>
> в<br>
> > кэше.<br>
> > В крайнем случае несложно пометить клиента стандартным способом<br>
> через<br>
> > cookie.<br>
> <br>
> Проблема в том, что даже отказ от push-ресурсов - это нагрузка как <br>
> на сервер, так и на канал.  И статистика как бы говорит нам, что в <br>
> среднем эти накладные расходы - больше, чем польза.<br>
<br>
Я таковой статистикой не располагаю.<br>
Но предполагаю, что клиенту отказаться от push'а проще, чем сделать<br>
дополнительный запрос к ресурсу.<br>
<br>
> Что будет конкретно в вашем случае - зависит, безусловно, от <br>
> конкретной нагрузки и от того, насколько "в крайнем случае <br>
> несложно" вам будет избежать лишних push'ей.  Но, повторюсь, в <br>
> среднем - будет хуже, потому что "в крайнем случае" никто не <br>
> заморачивается.  Именно поэтому я начал с вопроса пробовали ли вы <br>
> тестировать, что получится.  Подозреваю, что от банального <br>
> перекладывания существующих <link rel="preload"> в push'ы - <br>
> станет только хуже.<br>
<br>
Да, я понял Вашу точку зрения.<br>
Да, узкого эксперимента я не проводил.<br>
<br>
><br>
<a href="https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf" rel="noreferrer" target="_blank">https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf</a><br>
> > <br>
> > Не совсем понимаю какие выводы делают авторы.<br>
> > <br>
> > Предлагают работать над приоритезацией (которая и так корректная, и<br>
> > регулируется preload'ом), использовать экспериментальный QUIC,<br>
> поддержики<br>
> > которого толком нет.<br>
> <br>
> Авторы ясно и однозначно показывают, что server push - в среднем <br>
> вредит, и в большинстве случаев лишь способ выстрелить себе в <br>
> ногу.  И предлагают работать над другими технологиями, <br>
> потенциально более полезными.<br>
> <br>
> Тут важно понимать, что речь идёт про взгляд разработчиков <br>
> браузера, и рассказывалось это всё на HTTP working group, то есть <br>
> в рамках встречи людей, занимающихся разработкой протокола.<br>
<br>
Из Ваших соображений и трактовке вышеприведённого исследования складывается<br>
впечатление, что даже разработчики протокола не донца понимают зачем push<br>
нужен.<br>
При том, что не только они описали его в протоколе, но и сторонние<br>
разработчики реализовали поддержку push'а клиентах и нескольких серверах.<br>
<br>
> (Ну и да, про приоритезацию - смешно.  Нет, это не про preload, <br>
> это, как я понимаю, про приоритеты в рамках HTTP/2.  Там самолёт с <br>
> бассейном и джакузи запроектирован в рамках стандарта, корректности <br>
> ждать не приходится.)<br>
<br>
Я о текущей примитивной приоретизации.<br>
Сомневаюсь, что когда-нибудь появятся инстументы точного управления ею,<br>
браузеры всё равно будут вынуждены использовать указания как рекомендацию.<br>
<br>
> > Я прекрасно понимаю, что push — не панацея, и хотел попробовать на<br>
> практике<br>
> > проталкивание критических ресурсов, которые в любом случае<br>
> приоритетны и<br>
> > будут загружены для отрисовки.<br>
> <br>
> Именно с этого я и начал: попробуйте на практике на отдельных <br>
> страницах, без попыток вытаскивать версии ресурсов через SSI и вот <br>
> этого всего.  Получите статистику, сравните.<br>
> <br>
> Сейчас же вы пришли и убеждаете разработчиков, что вам надо, <br>
> потому что оно точно будет лучше, но тестировать вы ничего не <br>
> тестировали и не хотите. <br>
<br>
Где именно и кого я в чём-то убеждал и убеждал в том, что мне нужно?<br>
Я задал вопрос о планах.<br>
<br>
А учитывая, что использовать саму директиву http2_push затруднительно — один<br>
ресурс за раз, невозможность использования в if — и предвидя рекомендацию<br>
использовать http2_push_preload, я рассказал о том, в какую сторону пошёл и<br>
что уже попробовал сделать своими силами, и о том, какие возможности могли<br>
бы помочь в решении задачи.<br>
<br>
> Так это не работает.  Придёте со <br>
> стастикой, явно показывающей плюсы - мы задумаемся над тем, как <br>
> облегчить вам жизнь в конфигурации с SSI.  Пока же из статистике <br>
> есть вот только ссылка выше, из которой явно следует, что делать <br>
> что-либо для лучше поддержки HTTP/2 push - в среднем бессмысленно.<br>
<br>
То, о чём я рассказываю и есть эксперимент.<br>
Проще внедрить это на dev- или даже production-версии сайта, чем готовить<br>
узкие эксперименты из двух страниц.<br></blockquote><div><br></div><div>у вас же должны быть логи по html страницам и по css-файлам. посмотрите на них.</div><div>если</div><div><br></div><div>а) у вас хорошее кеширование (т.е. ноль 304-х)</div><div>б) количество ответов css соответствует количеству отданных html страниц</div><div><br></div><div>то, вероятно, в вашем случае будет профит от того, что сделаете push на css</div><div>ну и наоборот, если css отдается меньше, или отдается столько же, но много 304-х,</div><div>то выигрыш будет отрицательный<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
В случае pdocution'а можно прогнозировать значимое изменение в статистике<br>
загрузки страниц, в том числе по данным браузеров — в той же Метрике, Google<br>
Console или PageSpeed Insights.<br>
<br>
Простой эксперимент, конечно, имеет право на жизнь, но это пара страниц и<br>
несколько доступных браузеров и инструментов.<br>
<br>
Posted at Nginx Forum: <a href="https://forum.nginx.org/read.php?21,287846,287886#msg-287886" rel="noreferrer" target="_blank">https://forum.nginx.org/read.php?21,287846,287886#msg-287886</a><br>
<br>
_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a></blockquote></div></div>