> то выигрыш будет отрицательный

у меня эта фраза вызывает когнитивный диссонанс

On Wed, Apr 29, 2020 at 8:41 PM Илья Шипицин <chipitsine@gmail.com> wrote:

>
>
> ср, 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
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru