ср, 29 апр. 2020 г. в 22:26, gz <nginx-forum@forum.nginx.org>:

> > > Востребованные ресурсы из push-кэша переходят в основной и будут
> > > использованы для следующих страниц.
> > > Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся
> > в
> > > кэше.
> > > В крайнем случае несложно пометить клиента стандартным способом
> > через
> > > cookie.
> >
> > Проблема в том, что даже отказ от 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'а клиентах и нескольких серверах.
>
> > (Ну и да, про приоритезацию - смешно. Нет, это не про preload,
> > это, как я понимаю, про приоритеты в рамках HTTP/2. Там самолёт с
> > бассейном и джакузи запроектирован в рамках стандарта, корректности
> > ждать не приходится.)
>
> Я о текущей примитивной приоретизации.
> Сомневаюсь, что когда-нибудь появятся инстументы точного управления ею,
> браузеры всё равно будут вынуждены использовать указания как рекомендацию.
>
> > > Я прекрасно понимаю, что push — не панацея, и хотел попробовать на
> > практике
> > > проталкивание критических ресурсов, которые в любом случае
> > приоритетны и
> > > будут загружены для отрисовки.
> >
> > Именно с этого я и начал: попробуйте на практике на отдельных
> > страницах, без попыток вытаскивать версии ресурсов через SSI и вот
> > этого всего. Получите статистику, сравните.
> >
> > Сейчас же вы пришли и убеждаете разработчиков, что вам надо,
> > потому что оно точно будет лучше, но тестировать вы ничего не
> > тестировали и не хотите.
>
> Где именно и кого я в чём-то убеждал и убеждал в том, что мне нужно?
> Я задал вопрос о планах.
>
> А учитывая, что использовать саму директиву http2_push затруднительно —
> один
> ресурс за раз, невозможность использования в if — и предвидя рекомендацию
> использовать http2_push_preload, я рассказал о том, в какую сторону пошёл и
> что уже попробовал сделать своими силами, и о том, какие возможности могли
> бы помочь в решении задачи.
>
> > Так это не работает. Придёте со
> > стастикой, явно показывающей плюсы - мы задумаемся над тем, как
> > облегчить вам жизнь в конфигурации с SSI. Пока же из статистике
> > есть вот только ссылка выше, из которой явно следует, что делать
> > что-либо для лучше поддержки HTTP/2 push - в среднем бессмысленно.
>
> То, о чём я рассказываю и есть эксперимент.
> Проще внедрить это на dev- или даже production-версии сайта, чем готовить
> узкие эксперименты из двух страниц.
>

у вас же должны быть логи по html страницам и по css-файлам. посмотрите на
них.
если

а) у вас хорошее кеширование (т.е. ноль 304-х)
б) количество ответов css соответствует количеству отданных html страниц

то, вероятно, в вашем случае будет профит от того, что сделаете push на css
ну и наоборот, если css отдается меньше, или отдается столько же, но много
304-х,
то выигрыш будет отрицательный



> В случае pdocution'а можно прогнозировать значимое изменение в статистике
> загрузки страниц, в том числе по данным браузеров — в той же Метрике,
> Google
> Console или PageSpeed Insights.
>
> Простой эксперимент, конечно, имеет право на жизнь, но это пара страниц и
> несколько доступных браузеров и инструментов.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,287846,287886#msg-287886
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru