Обновление синтаксиса кэшированных данных CSS

Возможно ли заставить браузер обновить кешированный CSS?

Это не так просто, как каждый запрос. У нас есть сайт с устойчивым CSS на некоторое время.

Теперь нам нужно сделать некоторые основные обновления для CSS; однако браузеры, которые кэшировали CSS, не получат новый CSS в течение нескольких дней, вызывая проблемы с обработкой.

Есть ли способ принудительно обновить CSS или мы лучше просто выбираем URL-адреса, специфичные для версии?

Ответ 1

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

Что мы пытаемся выполнить?

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

Наблюдаемое поведение кэширования

Отслеживание различных перестановок может быть немного запутанным, поэтому я создал следующую таблицу. Эти наблюдения были получены путем запроса запросов от Chrome к IIS и наблюдения реакции/поведения в консоли разработчика.

Во всех случаях новый URL-адрес приведет к HTTP 200. Важно то, что происходит с последующими запросами.

+---------------------+--------------------+-------------------------+
|        Type         |   Cache Headers    |     Observed Result     |
+---------------------+--------------------+-------------------------+
| Static filename     | Expiration +1 Year | Taken from cache        |
| Static filename     | Expire immediately | Never caches            |
| Static filename     | None               | HTTP 304 (not modified) |
|                     |                    |                         |
| Static query string | Expiration +1 Year | HTTP 304 (not modified) |
| Static query string | Expire immediately | HTTP 304 (not modified) |
| Static query string | None               | HTTP 304 (not modified) |
|                     |                    |                         |
| Random query string | Expiration +1 Year | Never caches            |
| Random query string | Expire immediately | Never caches            |
| Random query string | None               | Never caches            |
+---------------------+--------------------+-------------------------+

Однако помните, что браузеры и веб-серверы не всегда ведут себя так, как мы ожидаем. Известный пример: в 2012 году мобильный Safari начал кэшировать POST-запросы. Разработчикам не понравилось.

Строка запроса

^{Примеры в синтаксисе ASP.NET MVC Razor, но применимы практически на любом языке обработки сервера.}

... поскольку в некоторых приложениях традиционно используются GET и HEADs с URL запросов (те, которые содержат "?" в части rel_path) для выполнения операции со значительными побочными эффектами, кэши НЕ ДОЛЖНЫ лечить ответы на такие URI, как свежие, если сервер не предоставляет явный Время истечения. Это означает, что ответы HTTP/1.0 серверы для таких URI НЕ ДОЛЖНЫ быть взяты из кеша.

Добавление случайного параметра в конец URL-адреса CSS, включенного в ваш HTML, заставит новый запрос, и сервер должен ответить HTTP 200 (не 304, даже если он не был изменен).

<link href="[email protected]" />

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

Если вы поддерживаете только несколько URL-адресов, вы можете вручную изменить их, чтобы они содержали номер сборки или дату:

@{
    var assembly = Assembly.GetEntryAssembly();
    var name = assembly.GetName();
    var version = name.Version;
}

<link href="[email protected]" />

Это приведет к новому запросу в первый раз, когда пользовательский агент столкнется с URL-адресом, но последующие запросы будут в основном возвращать 304s. Это все еще вызывает запрос, но по крайней мере весь файл не обслуживается.

Изменение пути

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

Этот ответ показывает несколько простых и элегантных опций для платформ, отличных от Microsoft.

Разработчики Microsoft могут использовать HTTP-модуль, который перехватывает все запросы для данного типа файлов или может использовать комманду маршрутов/контроллеров MVC для подачи правильного файла (я этого не видел, но считаю это возможно).

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

TL;DR

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

Ответ 2

Я думаю, что переименование CSS файла - гораздо лучшая идея. Это может не устраивать все приложения, но это гарантирует, что пользователь загрузит только один файл CSS. Добавление случайной строки в конец обеспечит их загрузку каждый раз. То же самое можно сказать о методе javascript и методах apache выше. Иногда простой ответ может быть наиболее эффективным.

Другое решение:

<FilesMatch "\.(js|css)$">
    Header set Cache-Control "max-age=86400, public"
</FilesMatch>

Это ограничивает максимальный возраст кэш-памяти до 1 дня или 86400 секунд.

Ответ 3

Ю. мог бы сделать это в apache...

<FilesMatch "\.(html|htm|js|css)$">
FileETag None
<IfModule mod_headers.c>
Header unset ETag
Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"
Header set Pragma "no-cache"
Header set Expires "Wed, 11 Jan 1984 05:00:00 GMT"
</IfModule>
</FilesMatch>