Улучшения в подсистеме кэширования Internet Explorer 9

http://blogs.msdn.com/b/ie/archive/2010/07/14/caching-improvements-in-internet-explorer-9.aspx
  • Перевод
image
Сеть играет ключевую роль в общей производительности веб-браузера. Лучшим способом увеличить производительность работы с сетью является уменьшение объема трафика передаваемого по сети с помощью HTTP-сжатия и использования кэширования в браузере.

Мы проделали огромное количество улучшений в том как Internet Explorer 9 кэширует данные, для того чтобы увеличить использование ресурсов из кэша. Этот пост описывает эти улучшения, которые уже доступны в третьей версии IE9 Platform Preview, которая была выпущена в прошлом месяце.

Суть кэширования


Давайте начнем с быстрого описания того, как работает кэширование в браузерах. На самом высоком уровне браузеры выполняют два типа запросов HTTP(S) – условные запросы и безусловные запросы.

Безусловные запросы создаются когда браузер не имеет кэшированной копии ресурса. В этом случае, ожидается, что сервер вернет ресурс с ответом HTTP/200 OK. Если заголовки ответа отдельно этого не запрещают, клиент может кэшировать контент и использовать его в будущем.

Если в дальнейшем браузеру нужен ресурс, который есть в локальном кэше, то заголовки ресурса проверяются на то, остается ли ресурс актуальным. Если закэшированная копия актуальная, то запросов к ресурсу в сети не будет произведено и клиент просто использует копию из кэша.

Если закэшированный ресурс устарел (старше, чем заголовок max-age или позднее даты Expires), то клиент сделает условный запрос на сервер, чтобы определить актуален ли ранее закэшированный ресурс и может ли он быть использован. Условный запрос содержит заголовки If-Modified-Since и/или If-None-Match, которые показывают серверу какая именно версия контента уже есть на клиенте. Сервер может определить что клиентская версия все еще актуальна вернув пустой ответ с заголовком HTTP/304 Not Modified или может указать клиенту о том, что его версия устарела, вернув ответ с заголовком HTTP/200 OK и новым содержимым.

Очевидно, что условные запросы приводят к лучшей производительности по сравнению с безусловными запросами (поскольку серверу не нужно пересылать ресурс, если на клиенте уже есть актуальная версия), однако лучшая производительность достигается когда клиент знает какая версия в его кэше актуальна и условная перевалидация не производится вовсе.

Заголовки с экстремально большими значениями периода жизни


Хотя RFC2616 рекомендует серверам ограничивать продолжительность жизни контента одним годом, некоторые серверы указывают директивы Cache-Control со значительно большим периодом. До IE9 Internet Explorer признавал устаревшими все ресурсы, период жизни (значение Cache-Control: max-age) которых был больше 2147483648 (2^31) секунд, примерно 68 лет.

В девятой версии IE мы принимаем любое установленное значение max-age вплоть до 2^63, хотя внутри уменьшаем его до 2^31 секунд.

Улучшения параметра Vary


Заголовок ответа HTTP/1.1 Vary позволяет серверу указать, что актуальный закэшированный ресурс может использоваться без перевалидации только, если указанные в Vary заголовки совпадают с заголовками запроса.

Например, это позволяет серверу возвратить контент на английском с заголовком Vary: Accept-Language. Если пользователь позднее сменит в своем браузере значение Accept-Language с en-US на ja-JP, то ранее кэшированный контент не будет использован, поскольку заголовок Accept-Language больше не совпадает с тем значением, которое было сохранено при кэшировании ресурса на английском.

В IE9 мы улучшили поддержку ключевых сценариев использования Vary. Так, IE9 больше не требует серверной перевалидации для ответов, которые содержат директивы Vary: Accept-Encoding и Vary: Host.

Мы можем безопасно поддерживать эти две директивы по следующим причинам:
  1. все запросы явно зависят от Host, потому что хост – это компонент URL запроса;
  2. IE всегда распаковывает HTTP-ответы в кэш, что делает Vary: Accept-Encoding избыточным.
Как и IE6 и выше, IE9 так же игнорирует директиву Vary: User-Agent.

Если ответ содержит директиву Vary, которая указывает заголовок или комбинации заголовков отличных от Accept-Encoding, Host или User-Agent, тогда Internet Explorer будет продолжать кэшировать ответ, если ответ содержит заголовок ETAG. Тем не менее, такой ответ будет помечен как устаревший и будет произведен условный HTTP-запрос перед его использованием для того, чтобы определить актуальность кэшированной копии.

Кэширование редиректов


IE9 теперь поддерживает кэширование ответов с HTTP-редиректом, как это описывается в RFC2616. Ответы с перманентным редиректом (со статусом 301) будут кэшироваться до тех пор пока они не содержат заголовки запрещающие это (например, Cache-Control: no-cache) и те запросы, которые имеют статус временный редирект (302 или 207) тоже будут кэшироваться, если заголовки позволят это (например, Cache-Control: max-age=120).

Несмотря на значительные улучшения в производительности, веб-приложения, которые неверно сконфигурированы могут не работать так, как ожидается после этих улучшений. Например, мы обнаружили несколько общедоступных сайтов, которые используют шаблоны похожие на следующие:

> GET / HTTP/1.1

< 301 Redirect to /SetCookie.asp


> GET /SetCookie.asp HTTP/1.1

< 301 Redirect to /


Здесь, цель сайта установить cookie с помощью вспомогательной страницы, если оно не установлено. Проблема в том, что сервер выбрал 301 для этой задачи и 301 – кэшируется. Как следствие, IE будет просто осуществлять редиректы на стороне клиента без обращения к серверу пока пользователю это не надоест и он не закроет браузер. Учтите, что этот бесконечный цикл будет и в том случае, если cookie запрещены в браузере пользователя.

Если ваш сайт создает редиректы, вы должны убедиться что они сконфигурированы так, чтобы избежать зацикливания и проверить что специфические редиректы (например, для установки cookie) помечены как некэшируемые.

Улучшения в кэшировании HTTPS


Несколько месяцев назад я упоминал, что IE не будет повторно использовать ранее закэшированные ресурсы полученные через HTTPS, пока по крайне мере одно защищенное соединение не будет установлено для текущего процесса. Это может привести к тому, что ранее сохраненные ресурсы будут проигнорированы, что приведет к безусловным сетевым запросам для контента, хотя тот уже есть в кэше.

В IE9 необязательные кросс-хостовые запросы HTTPS теперь будут условными, так что сервер может просто вернуть ответ HTTP/304 Not Modified для неизменного контента. Хотя остается необходимость в запросе, может быть достигнуто значительное увеличение производительности поскольку серверу не потребуется передавать ресурс для клиента.

Оптимизация функций Вперед/Назад


В IE9 мы сделали ряд улучшений для того, чтобы кнопки “Вперед” и “Назад” приводили к быстрой загрузке.

RFC2616 специально указывает на то, что механизм вперед/назад браузеров не должен быть субъектом кэширования:
Механизмы истории и кэширования – это разные механизмы. На практике, механизмы истории не должны пытаться показывать текущее состояние ресурса. Наоборот, механизмы истории должны показывать именно то, что пользователь видел во время когда посещал ресурс.

По умолчанию, время истечения актуальности ресурса не должно иметь значения для механизмов истории. Если сущность остается в хранилище, механизм истории должен отобразить ее, даже если сущность просрочена, пока пользователь специально не сконфигурирует агент для обновления просроченных документов.

В предыдущих версиях IE, когда пользователь переходил вперед или назад, IE проверял обновление ресурсов, если они были посланы с директивой кэша must-revallidate и в зависимости от некоторых других параметров того, как ресурс был получен. В IE9 используется флаг INTERNET_FLAG_FWD_BACK и IE не будет проверять актуальность кэшированных ресурсов когда пользователь переходит по “вперед/назад”.

Как результат этой оптимизации, Internet Explorer 9 может осуществлять значительно меньше условных HTTP-запросов во время работы функций вперед/назад. Например, в следующей таблице показано увеличение производительности по сравнению с предыдущим поведением:

- IE8
IE9
Улучшение
Навигация “вперед/назад”
Число запросов:

21

Байтов передано:

12,475

Байтов получено:

216,580
Число запросов:

1

Байтов передано:

325

Байтов получено:

144,617
Число запросов:

-20 (-95%)

Байтов передано:

-12,150 (-97.4%)

Байтов получено:

-71,963 (-33.3%)

После того как я рассказал про то, что мы игнорируем директивы кэширования во время навигации вперед/назад, внимательные читатели могут спросить почему IE9 все таки производит один запрос, когда пользователь нажимает кнопку “назад”. Причина в том, что IE не отправляет в кэш ни один запрещенный для кэширования ресурс. Запрещенные для кэширования ресурсы доставляются с директивой Cache-Control: no-cache или со значением даты Expires в прошлом или когда дата Expires не позже, чем значение заголовка Date. По этой причине, браузеру приходится перезагрузить такие ресурсы когда пользователь переходит “вперед/назад”. Для увеличения производительности и создания возможности загрузки ресурса в кэш при навигации вперед/назад, просто замените Cache-Control: no-cache на Cache-Control: max-age=0, в таком случае перевалидация будет происходить во всех случаях кроме навигации вперед/назад.

В отличии от других улучшений, которые мы описали, улучшение в работе “вперед/назад” нельзя наблюдать в превью-версии Internet Explorer 9 Platform Preview, поскольку в ней нет кнопок “впере/назад”.

Улучшения в эвристике кэширования


Согласно рекомендациям веб-разработчики должны указывать явно время истечения актуальности их ресурса для того, чтобы браузеры могли использовать ресурсы повторно без необходимости делать условные HTTP-запросы перевалидации на сервер. Тем не менее, множество сайтов доставляют контент без информации об истечении срока актуальности, оставляя на усмотрение браузера заботу о актуальности ресурса.

IE позволяет пользователям конфигурировать что должно произойти с контентом, который получен без информации об истечении срока актуальности. В настройках Tools > Internet Options > Browsing history > Settings вы можете обнаружить четыре опции:

image

Эти опции предлагают следующее поведение:

Every time I visit the webpage
Ресурсы без явной информации о времени актуальности помечаются как устаревшие и будут перевалидированы с сервером перед каждым использованием
Every time I start Internet Explorer
Любой ресурс без явной информации о времени актуальности проводит валидацию с сервером по крайней мере один раз за сессию (и каждые 12 часов в этой сессии)
Automatically (Default)
IE будет использовать механизм эвристики для определения актуальности
Never
Любой кэшированный ресурс будет помечен как актуальный и не будет перевалидирован

Эти опции контролируют поведение браузер только тогда, когда контент получен без информации о периоде актуальности. Если контент указан с явным правилом (например, Cache-Control: max-age=3600 или Cache-Control: no-cache), то браузер будет использовать эти правила сервера и указанные опции не будут иметь эффекта.

В предыдущих версиях IE, автоматическая эвристика была простой и влияла только на кэшированные изображения, но в IE9 проведены улучшения в эвристике согласно RFC2616:
Если ответ содержит значение Last-Modified, то эвристическое значение времени актуальности должно быть не больше интервала с этого значения времени. Типичным значением должно являться 10% от этого интервала.

Если IE9 получает ресурс, который может быть кэширован без установленного значения срока актуальности, эвристическое значение срока актуальности вычисляется следующим образом:

max-age = (DownloadTime — LastModified) * 0.1

Если заголовок Last-Modified отсутствует в ответе сервера, тогда IE применит поведение перевалидации “Once per browser session” (один раз за сессию).

Как результат улучшения эвристического кэширования, IE9 может производить меньшее число условных HTTP-запросов при перезагрузке большей части страниц. Например, в следующей таблице показано улучшение полученное при посещении обычной статьи на популярном сайте:

- IE8
IE9
Улучшение
Повторное посещение в новой сессии браузера (PLT2) Число запросов:

42

Байтов передано:

26050

Байтов получено:

220681
Число запросов:

2

Байтов передано:

1134

Байтов получено:

145217
Число запросов:

-40 (-95.3%)

Байтов передано:

-24916 (-95.6%)

Байтов получено:

-75464 (-34.2%)

Инспектор кэширования в Fiddler покажет вам когда ответ теряет актуальность, основываясь на заголовках ответа. Например, ниже то, что вы увидите в ответе, который содержит ETAG и заголовок Last-Modified, но не содержит информации о периоде актуальности:

image

Прочие улучшения в работе с сетью


В этом посте я перечислил улучшения в коде кэширования Internet Explorer, которые помогают убедится в самом лучшем использовании сети веб-сайтами. Конечно, веб-разработчики должны продолжать следовать рекомендациям и указывать поведение для кэширования с помощью заголовков Expires и Cache-Control, но даже если сайты не делают этого они все равно будут загружаться значительно быстрее в IE9.

В следующих статьях я опишу прочие улучшения, которые мы произвели в сетевом стеке IE9 для еще более быстрой загрузки страниц.
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 32
  • +8
    практике, механизмы истории не должны пытаться показывать текущее состояние ресурса. Наоборот, механизмы истории должны показывать именно то, что пользователь видел во время когда посещал ресурс.
    Выкусите, критики быстрого перехода назад-вперед у Оперы, оказывается все по стандартам :)
    • +1
      Редкий случай, когда я со стандартами не согласен
      • +2
        А я хочу, чтобы у меня был выбор, и, например, с зажатым контролом открывалась страница из кэша, а без него — перезагружалась
        • +1
          Логично :)
          • НЛО прилетело и опубликовало эту надпись здесь
        • +9
          Опера, по-моему, до сих пор с кэшем работает лучше других браузеров.
          Закрытая вкладка восстанавливается из корзины ровно в том месте страницы и в том состоянии, какой она была до закрытия (а не загрузится новая страница, с фокусом в самом начале страницы). То же касается и переходов вперёд-назад. И это мне очень удобно при серфинге.

          Во времена массового диал-апа хорошая работа Оперы с кэшем была даже её стратегическим преимуществом, сейчас же это просто очень удобная фишка. Но другие браузеры до сих пор отстают от неё в этом отношении.
      • –16
        как ты дрявое ведро не латай, лучше оно от этого не станет
        • +5
          Думаю стоит дождаться финальной версии,- вот там и посмотрим на производительность IE9
          • +3
            «Если ваш сайт создает редиректы, вы должны убедиться что они сконфигурированы так, чтобы избежать зацикливания и проверить что специфические редиректы (например, для установки cookie) помечены как некэшируемые.»
            Сначала все подстраивались под IE 6, а теперь будьте добры подстроитесь под IE 9 — вот они последствия запоздалой поддержки стандартов.
            И не прикопаешься ведь :)
            • 0
              Ну, думаю, что их всё так же пошлют далеко и надолго.
              Давно бы майкрософт купили бы мозиллу и… оставили в покое :)
              • +3
                Лучше поздно, чем никогда :) Остальные браузеры подтянутся быстро (я думаю, что большинство их не следований стандартам происходит из-за того, что «все подстраивались под IE 6»).

                Радует, что в MS всё-таки прочитали RFC 2616, огорчает, что, похоже, не целиком — о корректной обработке редиректов не заикаются (в большинстве случаев метод изначального запроса в редиректе должен быть повторён, а не заменён на GET)
              • –17
                Т.е. если движок быстрым сделать (ну кроме рендера через directx, на котором MS собаку съели) ну никак не получается, давайте хотя бы компенсируем это кэшированием?

                Вот вроде бы собрались в IE9 как-то следовать общим тенденциям в мире браузеров. И что? ACID до 100% допилить не могут, css и svg поддерживаются очень изберательно, огромная дыра под названием activex как бы говорит нам «этот браузер сделан, чтобы собирать вируса», но зато (ура!) он кэширует лучше других! Супер! Какой сейчас типичный тариф в развитых странах? 10 мегабит? 40?
                • 0
                  >Какой сейчас типичный тариф в развитых странах? 10 мегабит? 40?

                  По некоторым оценкам в США с интернетом уже хуже, чем в России (видимо потому что нам инфраструктуру относительно недавно пришлось создавать с нуля и устареть она не успела, а им нужно переделывать ту, которая несколько лет назад была ещё современной)
                  • +4
                    движок чего? внезапно, движок js в IE9 быстрее Firefox

                    вы несете некомпетентную чушь, из 23 частей спецификации SVG уже реализовано 20, acid уже 83,
                    чего именно из реализованного в IE9 в части утвержденных стандартов CSS вам не хватает?

                    activex сам по себе не опасен, опасны кривые поделия на нем и он отключается в три клика, а в ie8 так вообще местами запрещен.

                    про тарифы расскажите клиентским оптимизаторам которые до сих пор сжимают js и css и используют еще гору оптимизаций.

                    меньше злобы, не нравится вам ie не используйте, врать только не надо
                    • 0
                      Не путайте сарказм и злобу, пожалуйста :) Кэшрование само по себе — хорошо. Я всего-навсего имел в виду, что у разработчкиов IE полно задач и поважнее. Конкретика? Всегда пожалуйста: CSS, SVG. Фактически, я не соврал ни по одному пункту, уж извините меня :)

                      Вы много видели домохозяек с отключенным activex? А вируса-то в основном ловятся именно там. Для примера посмотрите, как сделан activex для лисы: там его, наоборот, включить — проблема.
                      • –2
                        Сами же пройдите по своей ссылке и увидите что CSS 2.1 поддерживается в IE на уровне остальных браузеров.

                        А CSS 3 еще в разработке, смысл его поддерживать? Встраивают потихоньку.

                        SVG in IE9 Roadmap

                        ACID до 100% допилить не могут

                        А зачем?

                        samples.msdn.microsoft.com/ietestcenter/ вот тут кстати гляньте насчет поддержки стандартов
                        • 0
                          Насчет поддержки чего-либо чем-либо всё же больше доверяю сторонним и нейтральным источникам.

                          html5 тоже в разработке, смысл его поддерживать?

                          «А зачем?» — прелесть что такое. Основной Вопрос Жизни, Вселенной и Интернет Эксплорера.

                          Затем, что ACID был сделан, чтобы выявить неочевидные косяки в реализации dom, css и javascipt. И если косяки лезут в ACID, они же будут лезть у десятков тысяч верстальщиков и кодеров по всему миру.
                          • –1
                            html5 тоже в разработке, смысл его поддерживать?

                            А никто толком и не поддерживает. Кто то больше, кто то меньше, на 100% — никто, потому что этих 100% даже нет еще.

                            косяки в реализации dom, css и javascipt.

                            А еще http, html5 и куча других технологий.
                            ACID3 пройденный на 100% не значит что ни у кого не вылезет косяков
                            ACID3 не пройденный на 100% не значит что у кого то вылезут косяки (например firefox не проходит acid3 на 100% потому что в нем по-умолчанию выключены некоторые возможности html5 и smil).
                            Опять же, ACID3 проверяет селекторы css3, которые, как я уже писал, еще находятся в разработке, поэтому то, что они не полностью поддерживаются — это нормально.

                            Короче говоря, ACID3 — не показатель.
                            • 0
                              Не показатель, что не будет косяков — да.
                              Показатель, насколько разработчикам не пофигу на те косяки, которые есть — тоже да.
                              • –1
                                Я же говорю, даже если не 100% это не факт что есть косяки.
                                Если неполная поддержка css3, неполная поддержка html5 — это все минус баллы, но это не косяки потому что говорить о полной поддержке стандартов, которых еще нет — это немного глупо
                                • +1
                                  Ну здесь как с 802.11n-draft'ом: стандартом он ещё не был, а беспроводная сеть на 50 реальных мегабитах у меня дома уже работала.

                                  Так и тут: стандарт ещё не утвердили, а в других браузерах html5 видео уже играет.
                                  • 0
                                    в других браузерах html5 видео уже играет.

                                    В ie9 тоже уже играет. Пробуйте ietestdrive.com/
                                    • +1
                                      Это же только пример был :)

                                      Смысл в том, что незавершенность утверждения html5 не мешает по всему миру использовать его в приложениях.

                                      Соответственно, разработчикам ie9 стОит уделять ему должное внимание (и их шаги в этом направлении, в принципе, радуют).

                                      Соответственно, ошибки acid3 всё же имеют актуальность (хотя молиться на тест не надо, это ясно).
                    • +2
                      Microsoft пытается выйграть даже в мелочах, чтобы в момент выхода в свет его не задавили Firefox, Chrome и Safari прикрутившие невзначай поддержку GPU.
                      К тому же надо вновь создавать положительное представление о старом браузере.
                      Меня если честно радует направление взятое в Microsoft, чего не хватает так это чтобы они:
                      — повыкидывали все свои старые костыли (com, activex, jscript) и почистили ядро в что-то наподобие minIE.
                      — добавили нормальную поддержку работы с файлами по сети (download, upload, torrent, shared а-ля Unity by Opera)
                      — встроили Silverlight и впаяли автообновление
                      — ну и конечно WPF + MEF for plugins
                      • +3
                        Единственное чего на самом деле не хватает — это обновлений чаще, чем раз в 2+ года.
                        • –1
                          так Silverlight и так приходит с обновлениями
                      • +1
                        Итак. все что я извлек — MS пытается сделать IE9 качественнее чем его предшественники…
                        Чтож — я жду официального релиза и тогда буду сравнивать с firefox, chrome, opera (именно на момент релиза) а то можно говорить как много делается — а обычно на момент релиза все уже не кажется таким уж «ВАУ» (Вспоминаем случаи с OS by MS).
                        • +1
                          Пусть сделают первым делом нормальную систему обновления! А то с такими темпами лет через пять будет уже целый выводок разных номеров ИЕ, и каждый придется отдельно поддерживать.
                          • 0
                            Если оставят возможность, которая присутствует в превью версии, а именно — установку ie9 без удаления предыдущей версии, то будет очень круто. Наконец-то, у многих корпоративных пользователей не будет отмазки типа «в вашем новом браузере наши веб-приложения не работают и мы его не можем использовать», потому что будет присутствовать возможность параллельного использования нескольких версий. Тогда и не будет страха все сломать и будут охотнее обновлять браузер. А система обновления едина — Windows Update.
                            • +1
                              ИМХО проблема не в системе обновления, Windows Update вполне себе позволяет апдейтиться хоть каждый день. Проблема в производственном цикле. Причем тот же MS имеет примеры продуктов с нормальным циклом обновлений, тот же Silverlight, ASP.NET MVC. Есть надежда что и для IE так сделают, не зря же эти декларации про беты каждые два месяца.
                            • 0
                              свято верую в светлое будущее. надеюсь на какие-либо драконовские меры со стороны MS по переводу людей на ie9 с ie6-8 после его выхода.

                              но внутри все равно не понимаю, почему нельзя было сделать сразу по-человечески.

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.