Comments 34
Cache-control: max age=100000000
Expires: 2050-10-10и удаления `E-tag/Last-Modified` — чтобы браузеры и не думали за 304 обращаться
В конце 2050 года все ваши сайты резко замедлятся...
Веб разработчики которые начинают заниматься оптимизацией статических ресурсов обязательно на это натыкались при тщательной отладке.
Хром как раз это и пофиксил.
Вообще, раньше было лучше: сначала загружалась страничка, её уже можно было читать, а уже потом подгружались картинки и стили.
Это воовсе непонятно, html страничка же загружается в самом начале, а уже потом на ней начинают навешиватсья скрипты и стили.
Браузер отправляет запросы изображений стилей и скриптов до полной загрузки страницы(html). Я на бесплатном мобильном инете когда сидел наблюдал аналогичную картину. Сделал скрипт который скрывает изображения до полной загрузки страницы.
А мне нравится appcache. Обновление страницы и её контента проверяется одним запросом. И сайт может работать из кеша даже оффлайн. Жаль что ему установили статус нерекомендуемый но пока он всё ещё работает.
Перезагрузка страницы не поможет, тогда переустанавливать браузер? (сарказм)
Вообще должен догрузить при обновлении страницы. А вот с ошибками только проверкой хеша можно бороться.
Просто нажать "Hard reload"
Загрузку не полностью браузерам пора бы научиться определять самим. А обновление должно быть заботой не пользователя, а разработчика. И решается проблема просто: новая версия файла должна иметь другое имя.
А что если в ответ по первому запросу к странице выдавать полный список версий ресурсов с этой страницы или просто устаревших ресурсов. Браузер смотрит что протухло, и грузит только устаревшие версии. Что-то в духе:
Cache-outdated: main.css, image.png, script.js
Или такое уже есть в симпсонах стандарте?
Я вот так себе это фантазирую(на примере nginx+php):
первый запрос: php генерирует страницу, выдает ее nginx-у, тот отдает клиенту, затем смотрит в содержимое, ищет все ресурсы, приписывает какой-то тег странице со списком ресурсов и их версий(или временем изменения), затем сохраняет страницу в свой кэш.
последующие запросы: nginx берет страницу из кэша, отдает клиенту. Клиент смотрит этот тэг, видит, что страница имеет следующие ресурсы A.ver123, B.ver35, Z.ver5. Смотри в свой кэш, находит эти ресурсы, если совпадают, то сразу же по ним возвращает 304 и рендерит страницу. Если же есть расхождения, то делает запросы только по ним.
Возможно это хорошо только для кэшируемых страниц.
А зачем?
Проблема в предложенном подходе с immutable — только одна: невозможность смены содержимого ресурса без смены его имени. Но это проблема организационная. И решение её давно придумано — называть ресурсы по хэшу их содержимого.
А ваша идея создаёт технические проблемы которые кому-то придется постоянно решать.
Appcache же.
- За место имён ресурсов используем хеш
- Отсылаем хедер с ними
Cache-Control: immutable
index.html
<!DOCTYPE HTML>
<html manifest="cache.appcache">
<body>
…
</body>
</html>cache.appcache:
CACHE MANIFEST
/cf298295d05da05257c0cb7ce8af7dcc8ef95e35.css
/2d408aaa5a340d732402a346a7f915ed8a3d8a04.js
/cbb33e652dd64ca308905a138dec165c4619ae32.pngВ результате браузер должен запросить только новые файлы.
Да, точно, оно самое. Спасибо.
Надеюсь вы шутите :) Во-первых он deprecated, ибо теперь service workers. Во-вторых в рамках обсуждаемого вопроса, это как из пушки по воробьям. Там у этого AppCache (который вообще для offline приложений) столько нюансов…
Не смотря на deprecated AppCache всё ещё работает. Service Worker пока ещё
на эксперементальной стадии.
Этот сценарий успешно реализуется в рамках текущего HTTP и именно он еще больше улучшается с введением immutable. Никакого Cache-outdated не нужно.
На самом деле там все просто. Версия кодируется в имени файла, получившемуся ресурсу выставляется "вечное" кеширование. И не обязательно это делать в рантайме — такие инструменты как webpack умеют добавлять хеш содержимого в имя бандла, из-за чего версионирование получается автоматически еще на стадии сборки проекта. В крайнем случае можно в качестве версии брать хеш текущего коммита в git. Дельта-обновлений не получится — но при не очень частых обновлениях никто лишнего трафика не заметит.
Странно, вроде бы фичу первым внедрил Firefox, а преподносится всё так, словно за неё надо благодарить Chrome… Ох уж эти маркетологижурналистыАлизар…
Представьте себе на секунду, что мы бы говорили не про 'http', а про 'world wide git'. Страница — набор коммитов. Браузер может делать либо нормальный pull (без истории), либо скачивать только те коммиты, которые устарели.
Файлы идентифицируются по хешу, т.е. устаревание файла определяется по смене хеша, на который ссылаются.
Говорю это по наблюдению за браузером, когда pull для проекта проходит быстрее, чем открытие его страницы на гитхабе.
IPFS — это одноранговая распределенная файловая система, которая соединяет все вычислительные устройства единой системой файлов. В некотором смысле IPFS схожа со всемирной паутиной. IPFS можно представить как единый BitTorrent-рой, обменивающийся файлами единого Git-репозитория. Иными словами, IPFS обеспечивает контентно адресуемую модель блочного хранилища. с контентно адресуемыми гиперссылками и высокую пропускную способность. Это формирует обобщенный древовидный направленный граф. IPFS сочетает в себе распределенную хэш-таблицу, децентрализованный обмен блоками, а также самосертифицирующееся пространство имён. При этом IPFS не имеет точек отказа, и узлы не обязаны доверять друг другу.
Улучшения Chrome и Firefox ускорили перезагрузку страниц на 28-50%