Comments 11
А что мешает дописывать в URL скриптов и стилей конструкцию вида ?[timestamp] с меткой времени последнего изменения файла, получаемой в момент запроса? При перезагрузке страницы в браузере все изменившиеся ресурсы получают формально новый URL и подтягиваются с сервера. А сервер этот timestamp просто не учитывает.
Трюк что вы описываете просто кеш брейкер т.е. способ инвалидировать кеш. Идея с добавлением хеша или версии от релиза будет лучше работать как кеш, чем постоянный принудительный кешбрейк
А поясните, пожалуйста, подробнее. Похоже, я что-то упускаю. Мне кажется, что получить метку времени файла проще и быстрее, чем хеш или какое-то еще содержимое. При этом метка времени сохраняется на уровне файловой системы автомагически, то есть в такой схеме наименьшее количество точек отказа (способов наплодить баги). Какие преимущества у указанных вами методов?
А как делать import в случае необходимости добавления в URL скриптов и стилей конструкции вида ?[timestamp] ?
import {someFn} from './path/to/file.js';Как раз для этого HTTP-заголовки и используются: ETag/If-None-Match. Можете timestamp через ETag передавать на фронт.
Не могу утверждать что эти методы timestamp vs release hash лучше или хуже, они под разные ситуации. На фронтенде (который статика в виде html+js+css) имеет смысл кешировать статику только от релиза к релизу т.е. в момент сборки сайта\веб-приложения через webpack\vite\rollup\etc.. проставлять некий хеш или просто релизную версию к запросам статики, так в рамках одного релиза ваш клиент может быть закеширован браузером и кеш инвалидируется при изменении версии. В случае если просто подставлять timestamp к каждому запросу статики, мы получим каждый раз свежий response, что далеко не всегда нужно, если мы говорим о стратегии кеширования.
Эта история не относится к импортированию файлов внутри проекта и также слабо вяжется с установкой дополнительных заголовков. Чаще всего статику раздает просто nginx и по умолчанию в конфиге не поддерживает динамические переменные. Так вот чтобы не заниматься прокидыванием переменных\хешей и т.п. в конфиги nginx, обходятся такими уловками на клиенте.
Когда я писал про timestamp при каждом запросе, имел в виду, конечно, не метку времени запроса, а метку времени последнего изменения запрашиваемого файла.
Например, у меня бэкэнд на РНР. Совсем статических страниц нет, поэтому при каждом запросе страницы nginx все равно лезет в РНР. Тот генерирует код страницы и отдает. Ну а раз уж он все равно это делает, то добавить к адресам скриптов и стилей '?'.filemtime($_SERVER['DOCUMENT_ROOT'].$file) недолго. Понятно, что два лишних запроса к файловой системе, но зато точно ничего не сломается.
Впрочем, я уже нашел, что некоторые CDN коряво кешируют запросы с параметрами, так что лучше использовать встраивание уникальной строки (метки времени или хеша) в имя файла или путь к нему. В целом справедливо, потому что сервер не обязан отдавать одинаковый контент на последовательные запросы даже с одинаковыми параметрами. Но то же самое относится и к любому другому контенту, даже к /, например. Поэтому надо внимательно думать над тем, как это будет работать в каждом конкретном случае. Что не меняет самой идеи: файл должен отдаваться всегда один (с последними изменениями), а URL должен меняться при изменении запрашиваемого ресурса.
Если и есть в iPhone какой-нибудь способ удалить через конфигурацию смартфона/приложения данные для отдельного сайта, то мне так и не удалось его найти.
Попробуйте: Settings/Safari/Advanced/Website Data - откроется список сайтов - свайп влево для удаления.
Спасибо, это уже чуть лучше, чем удалять всё для всех :) Не совсем понятно, почему адрес сайта иногда редуцируется до домена второго уровня, иногда - до третьего. При этом у меня для тестовых сайтов используются адреса с уровнем вложенности 4-5. Но это однозначно лучше, чем то, что я делал ранее :)
В Хроме удаление данных для отдельного сайта возможно прямо со страницы:
как-то вы плохо искали: Настройки - Safari - Дополнения - Данные сайтов
Кэширование кода в веб-приложениях