ср, 29 апр. 2020 г. в 22:26, gz <nginx-fo...@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