это бред, бред и еще сто раз бред. если вы точно уверены, что контент кешируемый, добавляете на него Expire (или max-age, как нравится) и у браузера уже есть копия контента, про которую он точно знает, что она актуальна. в этом случае браузер начинает отрисовывать страницу сразу же.
если вы знаете, что контент неизменяемый, но не отдали Expire, то у браузера есть некая копия контента, про которую он не уверен. Он сделает ЛИШНИЙ запрос (это время) с заголовком If-Modified-Since/If-None-Match и только после этого начнет отрисовывать страницу. и в каком месте здесь "UI responsiveness" ? чем гоняться за ETag-ами, лучше сделать правильный Expire. генерация уникальных имен для CSS делается на стороне приложения. это проработанная тема, если у вас Ruby On Rails, например, вот так http://code.google.com/p/bundle-fu/ да, идея простая - уменьшить количество запросов и сделать уникальный хеш для статических сборок. необязательно вообще всё навешивать на nginx. 8 мая 2013 г., 17:21 пользователь Anatoly Mikhailov <anat...@sonru.com> написал: > > On May 8, 2013, at 11:49 AM, Илья Шипицин <chipits...@gmail.com> wrote: > >> расскажите более подробно про сценарии, когда необходим именно ETag ? >> > > ETag необходим тогда, когда вы точно уверены, что ответ от сервера кэшируем > и нет необходимости генерить его заново, когда ваш бэкэнд уверен в этом > >> по моим наблюдениям большинство браузеров используют >> If-Not-Modified-Since, и небольшая часть - одновременно >> If-Not-Modified-Since и ETag. > > эти вещи не жестко связаны, вы можете использовать либо то, либо другое, > либо оба вместе, наипростейшая схема работы описана здесь > http://www.youtube.com/watch?v=Eq3E6ahEk4k > >> >> с другой стороны, если контент заведомо статический, отдаем его с >> "Cache-Control: max-age=много-много" и избавляемся от 304-х кодов >> почти полностью. > > для статики это лучший вариант, для динамики - на усмотрение > >> >> какой великий смысл в том, чтобы отдать статику, не указав при этом >> длинный Expire (или max-age), чтобы браузер делал лишний запрос "не >> обновилась ли картинка/стиль/скрипт" ? > > никакого, статика вся должна ложиться в браузерный кэш и не привлекать > эвристический анализ > >> >> если вы добиваетесь именно "UI responsiveness", логично вообще >> избавляться от If-None-Match/If-Not-Modified-Since запросов, благо это >> не так сложно. > > это не так, ответ 304 избавляет бразузер от рендеринга, если вы точно уверены, > что ничего нового нет > >> >> 8 мая 2013 г., 16:18 пользователь Anatoly Mikhailov <anat...@sonru.com> >> написал: >>> >>> On May 8, 2013, at 10:34 AM, Maxim Dounin <mdou...@mdounin.ru> wrote: >>> >>>> Hello! >>>> >>>> On Wed, May 08, 2013 at 09:31:32AM +0100, Anatoly Mikhailov wrote: >>>> >>>>> >>>>> On May 8, 2013, at 12:23 AM, Maxim Dounin <mdou...@mdounin.ru> wrote: >>>>> >>>>>> Hello! >>>>>> >>>>>> On Tue, May 07, 2013 at 11:32:07PM +0100, Anatoly Mikhailov wrote: >>>>>> >>>>>>> Меня настораживает интересная закономерность, включая/отключая gzip в >>>>>>> конфигурации Nginx, >>>>>>> ETag заголовок пропадает/появляется соответственно в прокированном >>>>>>> ответе от бэкэнда (Unicorn). >>>>>>> Проще говоря, при gzip off ответ всегда приходит с ETag, все остальные >>>>>>> параметры на это не влияют. >>>>>>> >>>>>>> Бэкнэнд, если слушает порт, то легко убедиться, что он добавляет >>>>>>> заголовок ETag к каждому ответу, >>>>>>> и чтобы проксировать ETag заголовок через upstream приходится выключать >>>>>>> gzip. >>>>>>> Если я правильно понимаю, то сжатый ответ не может содержать некоторые >>>>>>> заголовки? >>>>>> >>>>>> При любых изменениях тела ответа, в том числе - модулем gzip, >>>>>> ETag'и из ответа убираются. Это сделано, т.к. стандарт требует, >>>>>> чтобы strong etags у ответов совпадали тогда и только тогда, когда >>>>>> ответы совпадают до байта. (А если ответы будет не совпадать при >>>>>> одинаковых ETag'ах - это в свою очередь чревато получением >>>>>> неверного суммарного ответа при комбинировании нескольких ответов >>>>>> на range-запросы.) Почитать подробности можно тут (и далее по >>>>>> ссылкам): >>>>>> >>>>>> http://tools.ietf.org/html/rfc2616#section-3.11 >>>>>> >>>>> >>>>> Ага, спасибо, более менее разобрался. Все таки, есть вариант оставлять >>>>> ETag, пришедший от бэкэнда, >>>>> может в сочетании с Last-Modified? >>>> >>>> В чём цель? >>> >>> Цель всегда одна - UI responsiveness, чем быстрее пользователь получит >>> данные (идеально - из браузерного кэша), >>> тем меньше нагрузки будет на рендеринг в браузере и можно отдать пустое >>> тело запроса от бэкэнда (fresh_when/stale в Rack) >>> >>> E-Tag, Last-Modified - весьма удобные инструменты, которые неожиданно >>> перестали работать как раз после Nginx 1.3.3 :) >>> >>>> >>>>> Кстати, до реализации SPDY все было точно так же (ETag не проксировался >>>>> при Gzip)? >>>> >>>> Поддержка entity tags не имеет отношения к spdy, и появилась в >>>> nginx 1.3.3. До этого nginx не знал про заголовок ETag и ничего с >>>> ним не делал. >>>> >>>> -- >>>> Maxim Dounin >>>> http://nginx.org/en/donation.html >>>> >>>> _______________________________________________ >>>> 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 > > _______________________________________________ > 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
