Мы создаем приложение с помощью CRA (версия WebPack от Facebook с разумными настройками по умолчанию).
Это означает, что наши скрипты красиво упакованы в bundle.hash.js, что означает, что мы можем реализовать долгосрочные заголовки кэша для этих файлов (в отличие от index.html).
Теперь это прекрасно работает для всего в экосистеме CRA, но у нас есть некоторые файлы, которые могут измениться после переиздания, а некоторые - нет.
Здесь у нас есть 2 варианта:
Для тех элементов, которые мы можем - Установить кратковременный кеш, т.е. 8 дней для этих файлов - Установить долгосрочный кеш и использовать запрос на очистку кеша param (например, SHA1 текущей git ревизии)
Теперь в моем тестировании я заметил, что Chrome иногда игнорирует все это, даже с правильным типом заголовков кэша. Довольно часто он выполняет 200 OK (from Disk) вместо фактического запуска запроса к серверу, который затем возвращает новую версию или 301 not modified.
Так что я думаю сделать еще один шаг вперед.
Я контролирую каждый вызов файла в сценариях, я просто не контролирую, как определенные активы копируются в окончательную сборку.
Итак, я придумал это nginx совпадение местоположения:
location ~* (\/(?:[^/]+\/)+)([^\.]+)\.([^\.]+)\.([^\.]+) {
add_header Cache-control: no-cache;
try_files $uri /$1/$2.$4 =404;
}
Давайте предположим каталог с именем assets, и там у нас есть mypicture.jpg и bundle.a1b2c3.js.
Вызов bundle.a1b2c3.js будет просто работать, так как это просто $uri
Мы изменяем интерфейс так, что при запросе mypicture.jpg он фактически запрашивает mypicture.q1r2s3.jpg.
В случае совпадения местоположения mypicture.hash.jpg просто возвращает файл на диск, но это позволяет нам устанавливать заголовки долгосрочного кэширования для этих файлов.
В следующий раз, когда мы переиздадим, ха sh изменится, что приведет к однократному удару по серверу, который вытянет новую (возможно, неизменную) версию.
Итак, существуют следующие ограничения: * У нас абсолютно не может быть устаревшего ресурса, поэтому попадание файла, загружающегося время от времени, в порядке. * У нас не может быть обращений каждый день, когда браузер запрашивает проверку ETag.
Этот подход лучше, чем добавление параметра запроса? Или я что-то здесь упускаю, что позволило бы Chrome вести себя лучше?