Помощь с агрессивным кэшированием JavaScript

Question

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

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

Это конфигурация веб-сервера?Нужно ли мне запрещать кэширование файлов JavaScript?Я видел несколько интересных техник в Веб-инструментарий Google где они на самом деле создают новый Имя файла 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

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

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

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

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

РЕДАКТИРОВАТЬ:Извините все;именно Squid, а не IE6, не кэширует строку запроса.Больше информации здесь.

Answer 4

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

Как избежать проблем с кэшированием таблиц стилей JavaScript и CSS в ASP.NET

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

Answer 5

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

Answer 6

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

Answer 7

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

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

Answer 8

В каждом выпуске мы просто добавляем монотонно увеличивающееся целое число к корневому пути всех наших статических ресурсов, что заставляет клиент перезагружаться (ранее мы видели нарушение метода строки запроса в 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 9

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

Answer 10

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

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