На Mac это Shift+Command+R, или удержание Shift при нажатии кнопки перезагрузки (в отличие от Command+R или обычного клика для регулярного обновления).
Подробнее:
Для Shift+Command+R, кэш просто игнорируется и ресурсы запрашиваются так, как будто кэша не существует.
Для Command+R, Chrome будет выдавать If-Modified-Since или Etag запросов к веб-серверу, даже для вещей, которые на самом деле кэшируются_. Для большинства, если не для всех, содержимое, которое сервер должен ответить 304 Not Modified. Это справедливо для большинства, если не для всех современных браузеров.
Единственный способ заставить полагаться на кэш (без запроса браузером даже возможных изменений), кажется, это щелчок по ссылке на веб-странице, или переход по ссылке в закладке, или переход в строку URL-адреса и нажатие на Return там (Command+L, Return).
Однако: давняя известная проблема в Chrome, Chrome Forced Refresh не игнорирует кэш (а более свежая Reload/Refresh не обновляет ), или, возможно, на самом деле функция в WebKit, Динамически вставленные подресурсы не перепроверяются даже при перезагрузке содержащего документа , делает Chrome нечистым ВСЕ связанные кэши при использовании вышеописанных методов. Разработчик Chromium объясняет :
Вкладка “Сеть” инструментов разработчика показывает водопад всех ресурсов при их загрузке. С правой стороны расположены две вертикальные линии… одна из них навешена на надпись “Load event fired” (Загрузка события произведена). Любая загрузка после этой точки официально не является частью страницы (страница может продолжать выдавать запросы в течение нескольких часов) […], поэтому она НЕ будет “обновлена” с любой комбинацией f5. Это по дизайну.
[…]. ]
Кэширование [любого ресурса, до и после строки “Load event fired”] определяется HTTP-заголовками ответа, а не временем выдачи запроса.
Также обратите внимание на твиттер @ChromiumDev :
Отключаемый кэш Chrome DevTools делает дисковый кэш недействительным (отлично подходит для разработки!), но… только в то время, когда видны devtools.
