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

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

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

10.12.2008 15:53:46
7 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

14
10.12.2008 16:12:39
лучшее решение самое простое :) Спасибо
Mike 9.10.2010 21:42:19
Многие старые прокси будут отказываться кэшировать что-либо с помощью строки запроса. лучше использовать какой-нибудь пакет для работы с этим идентификатором в вашем имени файла. /path/to/script-456.jsнамного лучше. Еще проще работать,/path/to/v456/script.js
Nemesarial 25.02.2019 15:37:50

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

1
10.12.2008 15:58:12

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

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

/media/js/my.js вы в конечном итоге:

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

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

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

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

Независимо от того, что вы делаете, убедитесь, что вы не бросаете? Vblah на конце, так как вы в основном выбрасываете кеширование в окне, когда делаете это (что вызывает сожаление, поскольку это, безусловно, самый простой способ справиться с этим)

1
11.12.2008 09:21:26

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

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

0
10.12.2008 18:12:36

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

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

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

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

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

2
23.05.2017 10:27:51

Как и @ 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" />
4
12.09.2012 22:35:37

Если вы используете 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>
0
14.08.2015 18:44:24