Использовать кеширование браузера в IIS (проблема с страницами в версии Google)

Есть несколько вопросов об использовании кеширования браузера, но я не нашел ничего полезного в том, как это сделать в приложении ASP.NET. Google Pagespeed говорит, что это самая большая проблема производительности. Пока что я сделал это в своем web.config:

Прокомментированный код работает. Я могу установить заголовок expire для определенного времени в будущем, но я не смог установить cacheControlMaxAge, чтобы установить, сколько дней с этого времени будет кэшироваться статический контент. Это не работает. Мои вопросы:

Как я могу это сделать? Я знаю, что можно установить кеширование только для конкретной папки, которая будет хорошим решением, но она не работает. Приложение размещено на Windows Server 2012, в IIS8, пул приложений настроен на классический.

После того, как я установил этот код в веб-конфигурации, я получил strpeed из 72 (раньше было 71). 50 файлов не были кэшированы. (Теперь 49) Мне было интересно, почему, и я просто понял, что один файл был фактически кэширован (файл svg). К сожалению, файл png и jpg не был. Это мой web.config

EDIT: Если я установил точную дату истечения срока действия, кеширование работает, но не для jpg, gif.... только для png

EDIT2: Если я установил cacheControlCustom="public", как здесь:

работает кеширование, но еще не для jpegs и gif; он работает только для svgs и pngs.

Ответы

Ответ 1

Большинство проблем кэширования браузера можно разрешить, просмотрев заголовки ответов (это можно сделать в инструментах разработчика Google Chrome).

Теперь в разделе clientCache вашего файла web.config следует установить максимальное кэширование вывода, как показано на рисунке ниже, для параметра max-age - 86400, которое составляет 1 день в секундах.

Вот фрагмент web.config для этой настройки.

<clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="1.00:00:00" />

Теперь отлично, заголовок ответа имеет свойство max-age, заданное в заголовке Cache-Control. Поэтому браузер должен кэшировать содержимое. Ну, это в основном верно, но для некоторых браузеров требуется установить еще один флаг. В частности, флаг public установлен для заголовка управления кэшем. Это можно легко добавить с помощью атрибута cacheControlCustom в web.config. Вот пример.

<clientCache cacheControlCustom="public" cacheControlMode="UseMaxAge" cacheControlMaxAge="1.00:00:00" />

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

Теперь, как вы можете видеть из изображения выше, мы теперь имеем значение public, max-age=86400. Поэтому у нашего браузера есть все необходимое для кэширования ресурсов. Теперь изучение заголовков и вкладки сети google chrome поможет нам.

Вот первый запрос к файлу. Обратите внимание, что файл не кэшируется...

Теперь вернемся к этой странице ( ПРИМЕЧАНИЕ: не обновляйте страницу, мы поговорим об этом через секунду). Теперь вы увидите ответ, возвращающийся из кеша (по кругу).

Теперь, что произойдет, если я обновляю страницу с помощью F5 или используя функцию обновления браузера. Подождите, куда пошел (from cache).

Хорошо в Google Chrome (не уверен в других браузерах) с помощью кнопки обновления будет перезагружать статические ресурсы независимо от заголовка кеша (вставьте пояснение здесь, пожалуйста). Это означает, что ресурсы были повторно восстановлены, а максимальный заголовок заголовка отправлен.

Теперь, после объяснения выше, обязательно проверьте , как отслеживать заголовки кеша.

Обновление

На основании ваших комментариев, которые вы указали, у вас есть общий обработчик (IHttpHandler) с именем Image.ashx с типом контента image/jpg. Теперь вы можете ожидать, что поведение по умолчанию будет кэшировать этот обработчик. Однако IIS видит расширение .ashx (правильно) как динамическое script и не подлежит кешированию без явной установки заголовков кеша в самом коде.

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

context.Response.ContentType = "image/jpg";

context.Response.Cache.SetMaxAge(TimeSpan.FromDays(1));
context.Response.Cache.SetCacheability(HttpCacheability.Public);
context.Response.Cache.SetSlidingExpiration(true);

context.Response.TransmitFile(context.Server.MapPath("~/out.jpg"));

Теперь, просматривая код, мы устанавливаем несколько свойств в свойстве Cache. Чтобы получить желаемый ответ, я установил свойства.

context.Response.Cache.SetMaxAge(TimeSpan.FromDays(1)); сообщает кешу out put для того, чтобы max-age= часть заголовка Cache-Control была 1 день в будущем (86400 секунд).
context.Response.Cache.SetCacheability(HttpCacheability.Public); указывает кешу out put для заголовка Cache-Control на public. Это очень важно, поскольку он указывает браузеру кэшировать объект.
context.Response.Cache.SetSlidingExpiration(true); указывает кэшу вывода, чтобы убедиться, что он правильно настроил часть max-age= заголовка Cache-Control. Без установки скользящего истечения кеширование IIS вне кэша будет игнорировать максимальный возрастный заголовок. Объединение этого результата дает мне этот результат.

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

Теперь в связи с вышеописанным процессом вы также можете установить компонент ETag (см. wiki) заголовков кеша, чтобы браузер может проверить содержимое, которое будет доставлено специальной строкой. Вики заявляет:

ETag - это непрозрачный идентификатор, назначенный веб-сервером для определенного версию ресурса, найденного по URL-адресу. Если содержимое ресурса при этом URL-адрес когда-либо изменен, назначается новый и другой ETag.

Таким образом, это действительно своего рода уникальная идентификация для браузера, чтобы идентифицировать контент, который доставляется в ответ. Предоставляя этот заголовок, браузер следующей перезагрузки отправит по заголовку If-None-Match с ETag из последнего ответа. Мы можем изменить наш обработчик, чтобы обнаружить заголовок If-None-Match и сравнить его с нашим собственным созданным ETag. Теперь нет точной науки для создания ETags, но хорошим правилом является предоставление идентификатора, который, скорее всего, определит только одну сущность. В этом случае мне нравится использовать две строки, объединенные вместе, например.

System.IO.FileInfo file = new System.IO.FileInfo(context.Server.MapPath("~/saveNew.png"));
string eTag = file.Name.GetHashCode().ToString() + file.LastWriteTimeUtc.Ticks.GetHashCode().ToString();

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

Это создаст хэш-код, похожий на 306894467-210133036.

Итак, как мы используем это в нашем обработчике. Ниже приведена новая версия обработчика.

System.IO.FileInfo file = new System.IO.FileInfo(context.Server.MapPath("~/out.png"));
string eTag = file.Name.GetHashCode().ToString() + file.LastWriteTimeUtc.Ticks.GetHashCode().ToString();
var browserETag = context.Request.Headers["If-None-Match"];

context.Response.ClearHeaders();
if(browserETag == eTag)
{
    context.Response.Status = "304 Not Modified";
    context.Response.End();
    return;
}
context.Response.ContentType = "image/jpg";
context.Response.Cache.SetMaxAge(TimeSpan.FromDays(1));
context.Response.Cache.SetCacheability(HttpCacheability.Public);
context.Response.Cache.SetSlidingExpiration(true);
context.Response.Cache.SetETag(eTag);
context.Response.TransmitFile(file.FullName);

Как вы можете видеть, я изменил довольно много обработчика, но вы заметите, что мы генерируем хеш ETag, проверяем входящий заголовок If-None-Match. Если хеш etag и заголовок равны, мы сообщим браузеру, что содержимое не изменилось, возвратив код состояния 304 Not Modified.

Далее был тот же обработчик, за исключением добавления заголовка ETag, вызвав:

context.Response.Cache.SetETag(eTag);

Когда мы запустим это в браузере, мы получим.

Вы увидите на изображении (как я изменил имя файла), что теперь у нас есть все компоненты нашей системы кэширования. ETag доставляется как заголовок, а браузер отправляет заголовок запроса If-None-Match, чтобы наш обработчик мог реагировать соответственно на файл кэша.

Ответ 2

Используйте это. Это работает для меня.

<staticContent>
<clientCache cacheControlMode="UseExpires" httpExpires="Tue,19 Jan 2038 03:14:07 GMT"/>
</staticContent>