Каковы лучшие методы предотвращения устаревших CSS и JavaScript

Question

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

Я работаю со средой Spring 2.5 MVC и уже использую API Google для предоставления прототипов и скриптов. Я также планирую использовать Amazon S3 и новое предложение Cloudfront, чтобы минимизировать задержки в сети.

Answer 1

Я добавляю в запрос параметр с номером ревизии, например:

<script type="text/javascript" src="/path/to/script.js?ver=456"></script>

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

Answer 2

Как и @ eran-galperin, я использую параметр в ссылке на файл JS, но я включаю сгенерированную сервером ссылку на дату последнего изменения файла. @ stein-g-strindhaug предлагает такой подход. Это будет выглядеть примерно так:

<script type="text/javascript" src="/path/to/script.js?1347486578"></script>

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

Например, в PHP мой скрипт для создания этого кода выглядит так:

function cachePreventCode($filename) {
    if (!file_exists($filename))
        return "";
    $mtime = filemtime($filename);
    return $mtime;
}

Итак, когда ваш PHP-файл содержит ссылку на CSS-файл, он может выглядеть следующим образом:

<link rel="stylesheet" type="text/css" href="main.css?<?= cachePreventCode("main.css") ?>" />

... который создаст ...

<link rel="stylesheet" type="text/css" href="main.css?1347489244" />

Answer 3

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

Однако, что касается производительности и повторения Тодд B упоминание о скорости вращения по имени файла, пожалуйста, проверьте работу Стива Соудерса для получения дополнительной информации по теме:

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

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

http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/

Answer 4

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

Я бы порекомендовал публиковать ваши файлы, используя временную отметку и / или версию, встроенную в URL, поэтому вместо:

/ media / js / my.js, в итоге вы получите:

/ media / js / v12 / my.js или что-то подобное.

Вы можете автоматизировать управление версиями / отметками времени с помощью любого инструмента.

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

Одна вещь, на которую следует обращать внимание при использовании JS или CSS, - когда вы включаете в них зависимые URL-адреса (фоновые изображения и т. Д.), Вам необходимо убедиться, что метка времени / версия JS / CSS изменяется, если ресурс внутри (а перепишите их, но это возможно с очень простым регулярным выражением и манифестом ресурса).

Независимо от того, что вы делаете, убедитесь, что вы не бросаете?

Answer 5

Используйте запрос conditional get с заголовком If-Modified-Since

Answer 6

Если вы используете MAVEN, вы можете использовать это, ДОБАВИТЬ на вас pom.xml:

<properties>
   <maven.build.timestamp.format>yyyyMMddHHmm</maven.build.timestamp.format>
   <timestamp>${maven.build.timestamp}</timestamp>
</properties>

С этим вы можете получить доступ к $ {timestamp}. Как этот образец:

<script type="text/javascript" src="/js/myScript.js?t=${timestamp}"></script>

Answer 7

Если вы получите «время изменения» файла в качестве метки времени, он будет кэшироваться до тех пор, пока файл не будет изменен. Просто используйте вспомогательную функцию (или как она называется в других средах), чтобы добавить теги script / css / image, которые получают метку времени из файла. В Unix-подобных системах (которые чаще всего используются) вы можете просто touch файлы, чтобы заставить измененное время измениться при необходимости.

Ruby on Rails использует эту стратегию в производственном режиме (по умолчанию я верю) и использует обычную метку времени в режиме разработки (чтобы быть уверенным, что что-то не кэшируется).