Помогите с агрессивным кешированием JavaScript

Question

Я столкнулся с проблемой, когда вносил изменения в несколько файлов JavaScript, на которые есть ссылки в файле HTML, но браузер не видит эти изменения. Он сохраняет копию, кэшированную в браузере, хотя веб-сервер имеет более новую версию.

Пока я не заставлю браузер очистить кеш, я увижу изменения.

Это конфигурация веб-сервера? Нужно ли устанавливать файлы JavaScript, чтобы они никогда не кэшировались? Я видел некоторые интересные приемы в Google Web Toolkit , где они фактически создают новое имя файла JavaScript при каждом обновлении. Я полагаю, что это не позволит прокси и браузерам сохранять старые версии файлов JavaScript с одинаковыми именами.

Есть ли где-нибудь список лучших практик?

Answer 1

Мы добавляем номер сборки продукта в конец всего Javascript (и CSS и т. Д.) Следующим образом:

<script src="MyScript.js?4.0.8243">

Браузеры игнорируют все после знака вопроса, но обновления вызывают новый URL, что означает перезагрузку кэша.

Это дает дополнительное преимущество, заключающееся в том, что вы можете устанавливать заголовки HTTP, которые означают «никогда не кэшировать!»

Answer 2

Он сохраняет копию, кэшированную в браузере, хотя веб-сервер имеет более новую версию.

Вероятно, это связано с тем, что установлены заголовки HTTP Expires / Cache-Control.

http://developer.yahoo.com/performance/rules.html#expires

Я писал об этом здесь:

http://www.codinghorror.com/blog/archives/000932.html

По сути, это неплохой совет, но он может вызвать огромные проблемы, если вы ошибетесь. Например, в Microsoft IIS заголовок Expires всегда отключен по умолчанию, возможно, именно по этой причине. Устанавливая заголовок Expires для ресурсов HTTP, вы говорите клиенту никогда не проверять наличие новых версий этого ресурса - по крайней мере, до истечения срока действия заголовка Expires. Когда я говорю никогда, я имею в виду - браузер даже не запрашивает новую версию; он просто будет предполагать, что его кешированная версия хороша, пока клиент не очистит кеш, или кеш не истечет. Yahoo отмечает, что они изменяют имя файла этих ресурсов, когда они нуждаются в обновлении.

Все, что вы действительно экономите здесь, это стоимость клиента, проверяющего сервер на новую версию и возвращающего 304 неизмененного заголовка в общем случае, когда ресурс не изменился. Это не сильно накладные расходы ... если вы не Yahoo. Конечно, если у вас есть набор изображений или сценариев, которые почти никогда не меняются, обязательно используйте клиентское кэширование и включите заголовок Cache-Control. Кэширование имеет решающее значение для производительности браузера; Каждый веб-разработчик должен глубоко понимать, как работает HTTP-кеширование. Но используйте его только хирургическим путем, ограниченным образом для тех конкретных папок или файлов, которые могут принести пользу. Для всего остального риск перевешивает выгоду. Это, конечно, не то, что вы хотите включить в качестве общего по умолчанию для всего вашего сайта ... если только вы не любите менять имена файлов при каждом изменении содержимого.

Answer 3

Я написал сообщение в блоге о том, как мы преодолели эту проблему здесь:

Предотвращение проблем с кэшированием таблиц стилей JavaScript и CSS в ASP.NET

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

Answer 4

@ Джейсон и Даррен

IE6 рассматривает что-либо со строкой запроса как не кэшируемое. Вы должны найти другой способ получить номер версии в URL, например, поддельный каталог:

<script src="/js/version/MyScript.js"/>

и просто удалите этот первый уровень каталога после js на стороне сервера перед выполнением запроса.

РЕДАКТИРОВАТЬ: Извините все; это Squid, а не IE6, который не будет кэшироваться со строкой запроса. Подробнее здесь .

Answer 5

Что бы это ни стоило, я увидел deviantART сайт, довольно большой, обслуживающий их файлы JS как 54504.js. Я только что проверил и вижу, что они теперь служат им как v6core.css? -5855446573 v6core_jc.js? 4150339741 и т. Д.

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

Answer 6

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

Answer 7

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

• Выпуск 1: http://www.foo.com/1/js/foo.js
• Выпуск 2: http://www.foo.com/2/js/foo.js

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

Как только вы это сделаете, вы можете использовать заголовки Expires / Cache-Control, которые позволяют клиенту кэшировать ресурсы JS «навсегда», поскольку путь меняется с каждым выпуском, что, как мне кажется, является тем, к чему @JasonCohen обращался.

Answer 8

@ Даррен. Проблема с кэшированием возникла как в IIS 6, так и в Apache 2. Я не уверен, что правильным решением является изменение заголовков ответа HTTP, а вместо этого использование маршрута переименования, описанного в нескольких ответах здесь.

@ Крис Хороший совет. Я думал, что подход с использованием строки запроса был хорошим, но он звучит так, как будто уникальное имя файла или каталога необходимо для всех случаев.

Answer 9

Ваш веб-сервер отправляет правильные заголовки, чтобы сообщить браузеру, что у него есть новая версия? Я также добавил дату в строку запроса раньше. т.е. myscripts.js? date = 4/14/2008 12:45:03 (будет закодирована только дата)

Answer 10

Я тоже из метода просто переименования вещей. Это никогда не выходит из строя, и это довольно легко сделать.