Как очистить css кэш

Обновлено: 02.07.2024

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

Я попытался перезапустить nginx, но безуспешно, и я погуглил, но не нашел действительного способа его очистить.

В некоторых статьях говорится, что мы можем просто удалить каталог кеша: var/cache/nginx , но на моем сервере такого каталога нет.

Что мне теперь делать?

24 ответа

У меня была точно такая же проблема - я запускал свой nginx в Virtualbox. У меня не было включено кеширование. Но похоже, что sendfile был установлен на on в nginx.conf , и это было причиной проблемы. @kolbyjack упомянул об этом выше в комментариях.

Когда выключил sendfile - все заработало.

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

В моем случае это был включенный opcache в /etc/php/7.2/fpm/php.ini (Ubuntu):

Установка его на 0 заставила сервер загружать последнюю версию файлов (php).

Я запускаю систему Homestead с Hyper-V, и у меня есть проект laravel, работающий на nginx.

У меня не было кеша в моей папке nginx в / etc /

Когда я посещал свой веб-сайт, я получал старые представления сервера и файлы css.

Что решило это для меня после поиска, потраченного впустую, глядя на мою конфигурацию nginx и пробуя вещи, было использование PHP artisan.

Выполните следующую команду в папке, где установлен artisan [корневой каталог проекта laravel]: php artisan optimize: clear

Эта команда очищает все кеши, и когда я обновил свою веб-страницу, она наконец обновилась со всеми изменениями.

Надеюсь, это поможет таким заблудшим душам, как я :)

Что ж, в общих ситуациях проблем с кешем (кеширование браузера, кеширование прокси, кеширование веб-сервера) вы можете использовать общеизвестное решение проблемы с кешем редко изменяющегося содержимого, такого как файлы CSS или JS - путем добавления параметра URI к их ссылкам:

Не <link rel="stylesheet" type="text/css" href="https://example.com/stacks.css">

Но <link rel="stylesheet" type="text/css" href="https://example.com/stacks.css?v=3b16a418cc4c">

Как и StackOverflow. :)

У меня была похожая проблема:

Настройка системы и проблема: (На виртуальном ящике я использую ubuntu и nginx - обновления веб-страницы PHP не отражают изменений во внешнем файле css). Я разрабатываю веб-сайт на машине с Windows и передаю файлы на nginx через общую папку. Кажется, что nginx не принимает изменения в файл css (обновление любым способом не помогает. Единственное, что сработало - это изменение имени файла css)

Решение: На виртуальной машине найдите общий файл (в моем случае файл css). Откройте с помощью nano и сравните с файлом в общей папке Windows (они кажутся идентичными). На виртуальной машине сохраните общий файл с помощью nano. Все изменения теперь отображаются в браузере. Не уверен, почему это работает, но в моем случае так оно и было.

ОБНОВЛЕНИЕ: после перезагрузки сервера ВМ проблема вернулась. Следуя инструкциям в разделе «Решение», CSS снова стал реагировать на обновления.

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

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

В моем случае, touch этот файл Css, чтобы он выглядел так, как будто ресурсы были изменены (на самом деле touch ничего не делает с файлом, кроме изменения времени последнего изменения), поэтому браузер и nginx будут применять последние ресурсы

Вы можете добавить конфигурацию в nginx.conf следующим образом.

Сверху папка с именем «nginx_cache» динамически создается в / tmp / для хранения кэшированного содержимого.

Если вы хотите очистить кеш от определенных файлов, вы можете использовать директиву proxy_cache_bypass . Вот как ты это делаешь

Теперь, если вы хотите обойти кеш, вы обращаетесь к файлу, передавая параметр nocache

Есть один правильный способ удалить только кеш-файлы, соответствующие любому KEY. Например:

Это удаляет все кеш-файлы, соответствующие КЛЮЧУ "yahoo / *", если в nginx.conf был установлен:

Будьте внимательны, чтобы правильно указать правильный путь.

На моем сервере папка кеша nginx находится по адресу /data/nginx/cache/

Я удалил только это: sudo rm -rf /data/nginx/cache/

Надеюсь, это кому-нибудь поможет.

Для тех, кто пытался удалить файлы кеша nginx, но он либо не работал, либо работал с перерывами, обратите внимание на ваши настройки для open_file_cache. Если это включено и настроено для кеширования файлового дескриптора в течение длительного времени, Nginx может по-прежнему видеть версию кэшированного файла даже после того, как вы удалили его с диска. Мне пришлось уменьшить open_file_cache_valid до 1 с (я не уверен, что это по сути то же самое, что полностью отключить кеш файлов).

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

Если, например, ваше приложение отправляет файл cookie с каждым первым запросом, то сценарий, который запускает proxy_pass_bypass через curl, вероятно, получит этот файл cookie в ответ, а nginx не будет использовать этот ответ для обновления кешированного элемента.

Тем, у кого другие решения не работают, проверьте, используете ли вы службу DNS, например CloudFlare. В этом случае активируйте «Режим разработки» или используйте инструмент «Очистить кэш».

У нас очень большой кеш nginx (гигабайты), который нам иногда нужно очистить. Я разработал сценарий, который мгновенно очищает кеш (что касается Nginx), а затем удаляет каталог кеша, не ограничивая основное приложение дисковым вводом-выводом.

Переместите папку кеша в новое место (в той же файловой системе!) (Это не нарушит работу каких-либо открытых файловых дескрипторов)
Восстановите исходную папку кэша, пустую
Перезагрузить Nginx ( изящная перезагрузка, где nginx позволяет старым исполнителям завершать выполняющиеся запросы)
Удалить старые кэшированные данные

Вот сценарий, адаптированный для Ubuntu 16.04 LTS, с кешем, расположенным в /mnt/nginx-cache :

И в случае, если это будет полезно, вот конфигурация Nginx, которую мы используем:

В моей установке nginx я обнаружил, что мне нужно перейти к:

В этом каталоге. Если вы знаете путь к вашей установке nginx и можете найти каталог кеша, то это может сработать для вас. Будьте очень осторожны с командой rm -rf , если вы находитесь в неправильном каталоге, вы можете удалить весь жесткий диск.

У меня тоже была эта проблема.

Не удалось найти папку nginx / cache
sendfile был отключен

Я нашел это полезным

Ищи, а если найдешь то удаляй.

Я запускаю очень простой сценарий bash, который выполняет задание за 10 секунд и отправляет мне письмо по завершении.

На этот вопрос есть два ответа.

Один для nginx в качестве обратного кеша
Другой для очистки кеша браузера вводом заголовка (этот)

Вы можете удалить каталог кеша nginx или выполнить поиск в конкретном файле:

И удалите только один файл, чтобы nginx обновил их.

Если вы не настроили зону кеширования через proxy_cache_path , а затем использовали ее (для пример в блоке местоположения), через: proxy_cache ничего не кэшируется.

Однако если вы это сделали, то в соответствии с автор nginx, достаточно просто удалить все файлы из каталога кеша.

Самый простой способ: find /path/to/your/cache -type f -delete

Вы также можете обходить / повторно кешировать файл за файлом, используя

И в качестве бонуса вы можете вернуть этот заголовок, чтобы узнать, получили ли вы его из кеша (вернет «HIT») или с сервера содержимого (вернет «BYPASS»).

Для истечения срока действия / обновления кэшированного файла используйте curl или любой другой клиент для выполнения запроса к кэшированной странице.

Это вернет новую копию элемента, а также заменит то, что находится в кеше.

Кэш или кеш (англ. cache) — ускоряет загрузку страниц.

—Daniil Bazhenov

Платформа CS-Cart кэширует практически всё: скрипты, cтили, шаблоны и т.д.

Если вы внесли изменения, а на странице в браузере ничего не изменилось, то тут одно из двух:

По умолчанию всё кэшируется в папку /var/cache , которая содержит:

templates/ - кэш скомпилированных шаблонов.
registry/ - кэш объекта Registry.
misc/ - кэш статики (css/js) и других данных, которые нужно кэшировать.

При разработке и модификации необходимо очищать кэш.

Автоматическая очистка кэша¶

Вы можете включить автоматическую очистку кэша в панели администратора.

Откройте панель администратора.

Пройдите на страницу «Темы».

Верхнее меню → Дизайн → Темы

Включите «Обновлять кеш автоматически»

Автоматически очищать кеш для измененных файлов (включая измененные напрямую на сервере). Возможно незначительное снижение скорости работы магазина. Рекомендуется отключить после внесения всех изменений в тему.

Ручная очистка кэша в браузере¶

Откройте панель администратора.

Добавьте параметр ?cc в URL.

или так: ваш_домен/admin.php?dispatch=products.manage&cc

Несколько вариантов очистки кэша через параметр в URL:

ct — для очистки миниатюр
ctpl — для очистки шаблонов
cc — для очистки registry и misc.

Ручная очистка кэша на веб-сервере¶

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

Все файлы кэша хранятся в папке: /var/cache

Удалите или переименуйте папку: /var/cache

При первой загрузке страницы в браузере, после очистки кэша, данные снова закэшируются.

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

Приветствую, дорогие друзья! В данной статье я решил рассказать о том, как решить проблему с обновлением скриптов и стилей у пользователей сайта (в частности, заказчика). Пойдем мы с вами двумя путями: сделаем версию для стандартного парсера MODX и для Fenom.

Для того, чтобы обновить кеш браузеров пользователей достаточно в дополнение к файлу передать какой-либо GET-параметр, тогда браузер решит, что файл изменился и загрузит новую версию. Сделать это можно, например, так:

Как видите у нас передан GET-параметр time со значением 3. Конечно, после каждого изменения файла style.css можно изменять значение этого GET-параметра для обновления кеша у пользователей, но, как вы понимаете, это не совсем удобно. Тогда на помощь к нам приходит функция php filemtime(), которая возвращает время последнего изменения файла в формате временной метки Unix (количество секунд, которые прошли с полуночи 1 января 1970 года до настоящего времени). С ее помощью мы можем оптимизировать этот процесс.

Стандартный парсер MODX.

Если вы используете стандартный парсер MODX, то вы можете использовать фильтры ввода и вывода. Для этого, сначала создадим сниппет versions со следующим кодом:

Вы можете использовать, например, ClientConfig или системные настройки, где сможете указать пути до файлов скриптов и стилей. Я сделал это через системные настройки.

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

Или можно передать значение напрямую в сниппет:

В итоге, мы с вами увидим, что в путь с помощью сниппета передался GET-параметр v с датой последнего изменения файла.

Fenom.

С парсером Fenom все проще. Создаем плагин на событие pdoToolsOnFenomInit:

И теперь мы можем применять его прямо к строке:

Все! Теперь мы защитим себя от лишних вопросов и сэкономим свое время при общении с заказчиками.

От автора: в первую очередь производительность браузера повышается за счет кэширования CSS. Проверьте, что ваш сервер отправляет заголовки, которые говорят браузеру хранить CSS файлы определенное время. Это наилучший подход, которым пользуются на большинстве, если не на всех сайтах.

Кэширование очень тесно связано с браузером, и в итоге легче его отключить. Задайте в настройках браузера хранить кэш CSS один год (что не редкость). И вдруг вам понадобилось изменить стили. В таком случае вам нужно подумать, как очистить кэш и заставить браузер перезагрузить CSS. Ниже представлены несколько вариантов по решению этой задачи.

Просто посмотрим на то, как выглядят заголовки для кэширования CSS файлов:

Нам нужны Cache-Control и Expires. Я не эксперт в области конфигурации серверов, обычно я смотрю в H5BP конфиги. Но в нашем случае есть классический способ через Apache/HTAccess:

Практический курс по верстке адаптивного сайта с нуля!

Изучите курс и узнайте, как верстать современные сайты на HTML5 и CSS3

ExpiresByType application / javascript "access plus 1 year"

Запросы

Сейчас браузеры видят URL с какими-либо запросами, как отдельные файлы и просто обновляют их на свежие копии. Большинство CDN поддерживают такую функцию и рекомендуют ее.

Что-то не так? Измените на это:

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

< link rel = "stylesheet" href = "global.css?v= <?php echo $cssVersion ; ?> " >

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

Изменение имени файла

Запросы не всегда срабатывают. Некоторые браузеры не различают разные строки запросов, как разные файлы. А некоторое ПО (Squid) вообще не кэширует файлы по строковым запросам. Steve Souders в своей статье рассказывает, почему не стоит использовать строковые запросы. Похожая техника применяется с изменением имени файла. Как в HTML ниже:

Необходимо программно изменить имя файла, а не просто вбить готовое. Таким образом, файл на самом деле не существует вообще, вам придется написать пару строк кода, чтобы попасть к нужному файлу. Совсем недавно Jeremy Keith открыл эту технику.

Сервер будет игнорировать цифры в именах файлов CSS и JavaScript, однако браузер все же будет считать названия файлами и будет пытаться обновить код. Jeremy Keith пользуется Twig и применяет следующий шаблон:

Уверен, что вы можете представить похожий код на любом backend языке (типа ASP). Можно потренироваться с написанием данного скрипта для обновления переменной.

Отключение кэширование основано на обновлении даты

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

return $ path [ 'dirname' ] . '/' . str_replace ( '.' , $ ver , $ path [ 'basename' ] ) ; < link href = " <? phpautoversion ( '/path/to/theme.css' ) ; ?> " rel = "stylesheet" >

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

ETag’и

Возможно ETag’и покажутся хорошей идеей, так как большинство из них это информация о том, имеются ли уже у браузера копии файлов. Но большинство советчиков в интернете говорят: «отключайте ETag заголовки». Yahoo говорит:

«Вся проблема с ETag’ами в том, что они создаются с помощью атрибутов, которые делают их уникальными для каждого сервера. ETag’и не совпадут, если браузер получил компонент от одного сервера, и тот пытается проверить компонент на другом сервере. Общая проблема сайтов, построенных на кластерных серверах.»

Другая проблема в том, что они просто не эффективны при кэшировании. Для проверки ETag’ов все еще нужно делать сетевые запросы. Это не просто загрузка файлов, которая уменьшает производительность, а также различные задержки на стороне сервера при обработке запросов.

Практический курс по верстке адаптивного сайта с нуля!

Изучите курс и узнайте, как верстать современные сайты на HTML5 и CSS3

И снова я не эксперт в этой тематике, но рекомендуется отключить их в Apache:

Читайте также: