Прекратить кеширование файлов с помощью Java

Кажется, вам нужно использовать

registry.addResourceHandler("/js/**")
            .addResourceLocations("/js/")

вместо

registry.addResourceHandler()

в зависимости от расположения файла login.js

Кроме того, измените 1 секунду на 30 секунд, чтобы дать Spring передышку :)

Попробуйте это в методе сопоставления запросов вашего класса контроллера: -

@RequestMapping("/test")
public ModelAndView preventCache(HttpServletResponse response){
    response.setHeader("Expires", "Tue, 01 Jan 2001 00:00:01 GMT");
    response.setHeader("Last-Modified", new Date().toString());
    response.setHeader("Cache-Control", "no-store, no-cache, must-revalidate, max-age=0, post-check=0, pre-check=0");
    response.setHeader("Pragma", "no-cache");
    return new ModelAndView("viewName");
}

Добавить заголовок Expires или Cache-Control

тег: сервер

У этого правила есть два аспекта:

• Для статических компонентов: реализуйте политику «Никогда не истекает», задав далеко future Expires заголовок
• Для динамических компонентов: используйте соответствующий заголовок Cache-Control для помочь браузеру с условными запросами

Дизайн веб-страниц становится все богаче и богаче, а это означает, что на странице появляется больше скриптов, таблиц стилей, изображений и Flash. Первому посетителю вашей страницы, возможно, придется сделать несколько HTTP-запросов, но с помощью заголовка Expires вы сделаете эти компоненты кэшируемыми. Это позволяет избежать ненужных HTTP-запросов при последующих просмотрах страницы. Заголовки Expires чаще всего используются с изображениями, но их следует использовать во всех компонентах, включая скрипты, таблицы стилей и компоненты Flash.

Браузеры (и прокси) используют кеш, чтобы уменьшить количество и размер HTTP-запросов, что ускоряет загрузку веб-страниц. Веб-сервер использует заголовок Expires в HTTP-ответе, чтобы сообщить клиенту, как долго компонент можно кэшировать. Это заголовок Expires в далеком будущем, сообщающий браузеру, что этот ответ не будет устаревшим до 15 апреля 2010 года.

  Expires: Thu, 15 Apr 2010 20:00:00 GMT

Если ваш сервер Apache, используйте директиву ExpiresDefault, чтобы установить дату истечения срока действия относительно текущей даты. Этот пример директивы ExpiresDefault устанавливает дату истечения срока действия через 10 лет с момента запроса.

  ExpiresDefault "access plus 10 years"

Имейте в виду, что если вы используете заголовок Expires из далекого будущего, вы должны изменять имя файла компонента всякий раз, когда компонент изменяется. В Yahoo! мы часто делаем этот шаг частью процесса сборки: номер версии встроен в имя файла компонента, например yahoo_2.0.6.js.

Использование заголовка Expires в далеком будущем влияет на просмотры страниц только после того, как пользователь уже посетил ваш сайт. Это не влияет на количество HTTP-запросов, когда пользователь посещает ваш сайт впервые, а кеш браузера пуст. Следовательно, влияние этого улучшения производительности зависит от того, как часто пользователи обращаются к вашим страницам с загруженным кешем. («Заполненный кеш» уже содержит все компоненты страницы.) Мы измерили это в Yahoo! и обнаружил, что количество просмотров страниц с заполненным кешем составляет 75-85%. Используя заголовок Expires в далеком будущем, вы увеличиваете количество компонентов, которые кэшируются браузером и повторно используются при последующих просмотрах страницы, без отправки ни одного байта через Интернет-соединение пользователя.

Используйте кеширование браузера

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

Обзор

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

Рекомендации

Каждый ресурс должен указывать явную политику кэширования, которая отвечает на следующие вопросы: можно ли кэшировать ресурс и кем, на какой срок и, если применимо, как его можно эффективно перепроверить по истечении срока действия политики кэширования. Когда сервер возвращает ответ, он должен предоставить заголовки Cache-Control и ETag:

• Cache-Control определяет, как и как долго индивидуальный ответ могут кэшироваться браузером и другими промежуточными кешами. Учить подробнее см. кэширование с помощью Cache-Control.
• ETag предоставляет токен повторной валидации, который автоматически отправляется браузер, чтобы проверить, изменился ли ресурс с момента последнего был запрошен. Чтобы узнать больше, см. Проверка кешированных ответов с помощью ETags.

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

• Определение оптимальной политики Cache-Control
• Аннулирование и обновление кешированных ответов
• Контрольный список кеширования

Мы рекомендуем минимальное время кеширования в одну неделю и предпочтительно до одного года для статических ресурсов или ресурсов, которые меняются нечасто. Если вам нужен точный контроль над тем, когда ресурсы становятся недействительными, мы рекомендуем использовать методику снятия отпечатков URL или управления версиями - см. Ссылку «Аннулирование и обновление кешированных ответов» выше.