В чем смысл?
Уже существует хорошо отработанная методика, называемая кэшированием на стороне клиента. Что дает в этом случае локальное хранилище HTML5, чего не хватает кешированию?
У вас может быть какое-то странное приложение, которое должно динамически загружать куски кода JavaScript, чтобы вы не могли эффективно использовать кеш, но это крайне редкий случай.
Также будьте в курсе другого. Браузеры имеют определенные политики для кэширования, и большинство браузеров хорошо справляются с управлением кэшем (удаляя только старый контент и т. Д.). Реализуя свой домашний кеш, вы не позволяете браузерам правильно управлять им. Мало того, что он может быть подвергнут критике сам по себе, но он также причинит вам боль рано или поздно. Пример: когда пользователи веб-приложения сообщают об ошибках, вы часто отвечаете, прося их очистить кеш. Я не уверен, что вы спросите в вашем случае, так как очистка кэша никогда не решит проблемы с вашим веб-приложением.
В ответ на ваше первое редактирование (ваше второе редактирование не по теме):
Я знаю, кеш браузера, еще будет проверка доступа к заголовку
Кажется, вам не хватает понимания кеширования браузера. Вот почему важно сначала понять, как это работает, прежде чем приступить к реализации собственного механизма домашнего кэширования . Изобретайте свое собственное колесо только тогда, когда вы достаточно хорошо понимаете существующие колеса и имеете вескую причину не использовать их. Смотрите пункт 1 моего ответа на вопрос «Изобретая колесо и НЕ сожалея об этом» .
При предоставлении некоторых данных через HTTP вы можете указать несколько заголовков, связанных с кешем:
Last-Modified
указывает, когда содержимое было изменено,
Expires
указывает, когда браузер должен запросить сервер, изменился ли контент .
Эти два заголовка позволяют браузеру:
- Избегайте загрузки контента снова и снова. Если
Last-Modified
задано значение за последний месяц, а контент уже был загружен сегодня несколькими часами ранее, нет необходимости загружать его снова.
- Избегайте запросов на дату последнего изменения файла. Если
Expires
из объекта кэша является 5 мая - й , 2014, вы не должны выдавать любой запрос GET ни в 2011, ни в 2012 или 2013 году, так как вы знаете , что кэш уточненный.
Второй важен для CDN. Когда Google передает JQuery посетителю Stack Overflow или cdn.sstatic.net
обслуживает изображения или таблицы стилей, используемые Stack Overflow, они не хотят, чтобы браузеры каждый раз запрашивали новую версию. Вместо этого они обслуживают эти файлы один раз, устанавливают дату окончания срока действия достаточно долго, и это все.
Вот, например, скриншот того, что происходит, когда я захожу на домашнюю страницу Stack Overflow:
Есть 15 файлов для обслуживания. Но где все эти 304 Not Modified
ответы? У вас есть только три запроса контента, которые изменились. Для всего остального, браузер использует кэшированную версию, не обращаясь ни к какому серверу .
В заключение, вам действительно нужно дважды подумать, прежде чем реализовывать свой собственный механизм кэширования, и особенно найти хороший сценарий, где это может быть полезно . Как я сказал в начале своего ответа, я могу найти только один: где вы обслуживаете куски JavaScript, чтобы использовать их через OMG eval()
. Но в этом случае я почти уверен, что есть лучшие подходы:
- Более эффективно использовать стандартные методы кэширования или
- Проще поддерживать.