[Temp] Улучшение кэширования в Internet Explorer 9

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

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

Понимание Кэша

Давайте начнем с быстрого повышения квалификации о том, как работает кэширование в браузере. На высоком уровне, веб-браузеры делают два типа запросов по HTTP и HTTPS-условные и безусловные запросы.

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

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

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

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

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

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

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

Например, это позволяет серверу для возврата содержания на английском языке с вариациями: Accept-Language заголовка. Если пользователь в последующем изменитAccept-Language в браузере с EN-US на JA-JP, находящиеся в кэше содержание не будет использоваться повторно, так как заголовок Accept-Language не соответствует заголовку запроса, в то время,как оригинальный английский ответ в кэше.
В InternetExplorer 9, мы расширили поддержку сценариев ключевых вариантов заголовка. В частности, IE9 больше не будет требовать повторного подтверждения сервера для ответов, которые содержат Vary: Accept-Encodingи Vary: Hostdirectives.

Мы можем с уверенностью поддержать эти две директивы, потому что:
Все запросы неявно зависят от Host, потому что хозяином является один из компонентов запроса URL.
IE всегда распаковывает HTTP ответы в кэш-памяти, что делает Vary: Accept-Encoding излишним.

Как IE6 и выше, IE9 будет игнорировать вариации: User-Agent директивы.
Если ответ содержит вариации директивы, которая определяет, помимо заголовка Accept-Encoding, Host, или User-Agent (или любая комбинация из них), то InternetExplorer будет по-прежнему кэшировать ответ, если ответ содержит ETAG заголовок. Вместе с тем, что ответ будет рассматриваться как старый и условный запрос HTTP будет принято к повторному использованию, чтобы определить, действительна ли сохраненная копия.
ПеренаправлениеКэширования
InternetExplorer 9 теперь поддерживает кэширование HTTP перенаправлением ответов, как это описано в RFC 2616. Ответы с постоянными статусами переадресации (301) являются кэшируемыми, если есть заголовки, которые запрещают его (например Cache-Control: no-cache), а также со временной переадресацией статуса (302 или 307), если есть заголовки которые позволяют его (например, Cache-Control: max-age=120).

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

> GET / HTTP/1.1
< 301 Redirect to /SetCookie.asp

> GET /SetCookie.asp HTTP/1.1
< 301 Redirect to /

Целью сайта является определить, если пользователь имеет набор cookie, а если нет, отправьте их на страницу, которая устанавливает cookie. Проблема в том, что сервер выбрал 301 для выполнения этой задачи, а 301 это кэш. Таким образом, IE будет просто перенаправить между этими двумя кэшами на клиента (никогда не обращаются к серверу), пока пользователю не надоест, и он не закроет браузер. Примечательно, что любая версия IE удалит перенаправления цикла в сценарии выше, если у пользователя отключены хранения cookie для данного сайта.

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

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

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

Back/Forwardоптимизации

Для IE9, мы внесли усовершенствования, чтобы нажатие кнопок Back/Forwardприводило к большей производительности.

В RFC2616 конкретно говорится, что браузера Back/Forwardмеханизмов, не подпадают под кэш директивы:
Механизмы истории и кэшей разные. В частности, история
НЕ ДОЛЖНА пытатся показать прозрачноевидение
текущего состояние ресурса. Скорее, историястремится
точно показать, что пользователь увидел в момент, когда ресурс
получен.

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

В предыдущих версиях InternetExplorer, если пользователь перемещаться Back/Forward, IE будет проверять свежесть ресурсов, и подтверждать управление кэшем, а также во многих других обстоятельствах в зависимости от того, как в последнее время ресурс был загружен . В IE9, флаг INTERNET_FLAG_FWD_BACK ведет себя, как описано в MSDN, а IE не будет проверять свежесть кэш ресурса, когда пользователь переходит Back/Forward.

В результате такой оптимизации, InternetExplorer 9 может выполнять намного меньше условий изапросов HTTP при переходеBack/Forward. Например, следующая таблица показывает улучшение при переходеBack к типичной статьи о популярных веб-сайтах:

(табл)

Теперь я уже упоминал, что мы игнорируем директивы кэширования при навигации Back/Forward, так что предупрежденные читатели могут быть удивлены, почему IE9 до сих пор делает один запрос при нажатии Backна этом сайте. Причина в том, что IE не будет делать запись в кэш любого некэшированого ресурса. Некэшированый ресурс 1 поставляться с Cache-Control: no-cacheдирективы или с даты, которая истекает в прошлом или истекает в срок не позднее даты в заголовке. Таким образом, браузер вынужден перезакачать такие ресурсы, когда пользователь перемещается назад и вперед. Повышения производительности и позволяет ресурсу, который можно повторно использовать в Back/Forward навигации, по-прежнему требовать повторного подтверждения для других целей, и просто заменить Cache-Control: no-cachewithCache-Control: max-age=0.

В отличие от других улучшений описанных в этой статье, оптимизацияBack/Forward не видна в PlatformPreview, поскольку она не имеет кнопку "Back".

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

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

InternetExplorer позволяет пользователю настроить, что должно произойти, когда содержание поставляется без истечения информации. Сервис> Свойства обозревателя> Журнал> Настройки, вы увидите четыре варианта:

(табл)

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

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

Если InternetExplorer 9 получает кэшируемый ресурс, который явно не указывает свою актуальность, эвристическая жизнь рассчитывается следующим образом:
max-age = (DownloadTime - LastModified) * 0.1

Если Last-Modified заголовка не было в ответе сервера, то InternetExplorer будет переходить обратно на "Onceperbrowsersession" ревалидацию поведения.

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

(табл)

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

Другие усовершенствования сети

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

В будущейстатье, я расскажу о других усовершенствованиях, которые мы внесли в IE9 для дальнейшего совершенствования страницы загрузки.


Источник: http://blogs.msdn.com/b/ie/archive/2010/07/14/caching-improvements-in-internet-explorer-9.aspx
Перевод: Really Fenix