Реально ли использовать локальное хранилище HTML5 для хранения CSS и JavaScript?


22

Идея состоит в том, чтобы использовать локальное хранилище HTML5 для хранения часто используемых CSS и JavaScript.

Например (псевдокод):

var load_from_cdn = true;
если (определить локальное хранилище)  
{
  if (кеш css, js найден)
  {
     загрузить кэш локального хранилища
     load_from_cdn = false;
  }
}
if (load_from_cdn)
{
   document.write ( '<скрипт> ...');
}

Это возможно или реально?

Я знаю, кеш браузера, все еще будет некоторая проверка доступа к заголовку,
я предполагаю, что HTTP-доступ лучше (по моему мнению )

PS: Кажется, что локальное хранилище поддерживает только пару ключ-значение , кто-то может это доказать?
(лучше всего с некоторыми примерами)


1
Википедия, очевидно, попробовала это с большим эффектом: twitter.com/catrope/status/408018210529615872 twitter.com/catrope/status/408018210529615872/photo/1
Дейв

1
это моя идея 2 года назад ... :)
ajreal

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

1
Эта картина вводит в заблуждение. Если вы прокрутите дальше вниз, вы увидите, что огромное падение произошло не потому, что локальное хранилище было лучше, чем кеширование, а скорее ошибка в их настройке кэширования: « Оказалось менее впечатляющим :(. График внутреннего трафика, падение из-за к localStorage, скрывающему ошибку кэширования "- twitter.com/catrope/status/408110382599782400
Джейми Баркер

проверить addyosmani.com/basket.js
xhh

Ответы:


11

Абсолютно нормально использовать локальное хранилище для хранения JS и CSS. Однако локальное хранилище имеет ограничение 5 МБ на домен. Возможно, вам придется пересмотреть эту стратегию.

Для настольных веб-приложений вы можете использовать кеш браузера по умолчанию, чтобы сделать свое дело. Просто установите HTTP-ответ JS & CSS для кэширования. Это просто и легко.

Для мобильного Интернета задержка высока. Таким образом, сокращение HTTP-запросов имеет решающее значение. Таким образом, наличие JS & CSS во внешних URL-адресах является оптимальным. Было бы намного лучше иметь встроенный JS & CSS. Это уменьшает HTTP-запросы, но раздутый контент HTML. И что? Как вы сказали, используйте локальное хранилище!

Когда один браузер посещает сайт в первый раз, JS & CSS помещаются в строку. У JS также есть еще две работы: 1) Хранить JS & CSS в локальном хранилище; 2) Установите cookie, чтобы указать, что JS & CSS находятся в локальном хранилище.

Когда браузер обращается к сайту во второй раз, сервер получает cookie и знает, что в браузере уже есть связанные JS & CSS. Таким образом, рендер HTML имеет встроенный JS для чтения JS & CSS из локального хранилища и вставки в дерево DOM.

Это основная идея создания мобильной версии bing.com. Вам может потребоваться учитывать контроль версий JS & CSS при внедрении его в производство.

Благодарность


Да, довольно близко к тому, о чем я думаю.
ajreal

Google разработал модуль для Page Speed ​​Mod, который делает то же самое. Вот страница, на которой они рассказывают о товарах, плохих вещах и недоразумениях developers.google.com/speed/pagespeed/module/…
такон

проголосовал, но wtf означает «встроенный» в данном случае. «inline» имеет 5 разных значений.
Александр Миллс

1
Это на самом деле увеличено до 10 МБ для настольных компьютеров и 5 МБ для мобильных устройств
Roko C. Buljan

1
Вам не нужно печенье. Вы можете просто прочитать, есть ли у localalstorage ключ / значение, которое вы ищете, плюс вы должны предоставить версию (для очевидных целей аннулирования). Этот прием хорош только после второго доступа к сайту, а также если ресурсы не находятся в кеше (по какой-то причине)
vsync


23

В чем смысл?

Уже существует хорошо отработанная методика, называемая кэшированием на стороне клиента. Что дает в этом случае локальное хранилище 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:

На скриншоте временной шкалы переполнения стека в Chrome показано 15 файлов, 3 из которых запрашиваются, 12 - из кэша напрямую, без запросов к удаленным серверам.

Есть 15 файлов для обслуживания. Но где все эти 304 Not Modifiedответы? У вас есть только три запроса контента, которые изменились. Для всего остального, браузер использует кэшированную версию, не обращаясь ни к какому серверу .


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

  • Более эффективно использовать стандартные методы кэширования или
  • Проще поддерживать.

+1 за это. Это абсолютно бессмысленно. Почти во всех случаях абсолютно. Кэширование с помощью уникального ключа, основанного на хэше, намного лучше.
Шабун

1
Вы не совсем правы в отношении кеша браузера. Жесткое обновление пройдет все проверки кеша браузера.
ajreal

1
Ссылка на не reinventing the wheel and not regretting itработает: '(
Esailija

4
Кэширование Bowser не так просто, как вы думаете, и не является согласованным во всех браузерах. Например, некоторые браузеры случайным образом решают загрузить веб-шрифты (независимо от заголовков - не могу найти статью об этом прямо сейчас, но я думаю, что это был Дэйв Руперт, который обнаружил это). Кроме того, ETAG заставляют браузеры проверять, обновлен ли ресурс ... и иногда вы не можете удалить ETAG (например, Amazon S3) - поэтому, если ваш CSS-файл отправляет заголовок ETAG, он всегда будет проверяться на наличие обновлений (304). все еще полезная нагрузка). Чтобы предотвратить ненужные запросы, требуется пользовательское кэширование.
Райан Уил

7

Локальное кэширование на стороне клиента должно быть более оптимизировано, чем использование локального хранилища HTML5. Просто убедитесь, что ваш javascript и CSS находятся во внешних кэшируемых файлах, и ваша страница должна загружаться намного быстрее через кеш браузера, чем пытаться извлечь их из локального хранилища и выполнить их самостоятельно.

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

Кроме того, вам все равно нужен код на странице для загрузки из локального хранилища HTML5, поэтому просто поместите все ваши JS в один внешний, кэшируемый файл JS.



2

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

Вы всегда можете протестировать кеширование в браузере по сравнению с вашим ручным HTML5-решением. Но я держу пари, что нативное кеширование от него избавится.


2

Использование localStorage быстро (э)! Мой тест показал

  • Загрузка jQuery из CDN: Chrome 268ms , FireFox: 200ms
  • Загрузка jQuery из локального хранилища: Chrome 47ms , FireFox 14ms

Я думаю, сохранение HTTP-запроса уже дает большое преимущество в скорости. Все здесь, похоже, убеждены в обратном, поэтому, пожалуйста, докажите, что я не прав.

Если вы хотите проверить мои результаты, я создал небольшую библиотеку, которая кэширует скрипты в localStorage. Проверьте это на Github https://github.com/webpgr/cached-webpgr.js или просто скопируйте его из приведенного ниже примера.

Полная библиотека:

function _cacheScript(c,d,e){var a=new XMLHttpRequest;a.onreadystatechange=function(){4==a.readyState&&(200==a.status?localStorage.setItem(c,JSON.stringify({content:a.responseText,version:d})):console.warn("error loading "+e))};a.open("GET",e,!0);a.send()}function _loadScript(c,d,e,a){var b=document.createElement("script");b.readyState?b.onreadystatechange=function(){if("loaded"==b.readyState||"complete"==b.readyState)b.onreadystatechange=null,_cacheScript(d,e,c),a&&a()}:b.onload=function(){_cacheScript(d,e,c);a&&a()};b.setAttribute("src",c);document.getElementsByTagName("head")[0].appendChild(b)}function _injectScript(c,d,e,a){var b=document.createElement("script");b.type="text/javascript";c=JSON.parse(c);var f=document.createTextNode(c.content);b.appendChild(f);document.getElementsByTagName("head")[0].appendChild(b);c.version!=e&&localStorage.removeItem(d);a&&a()}function requireScript(c,d,e,a){var b=localStorage.getItem(c);null==b?_loadScript(e,c,d,a):_injectScript(b,c,d,a)};

Звонить в библиотеку

requireScript('jquery', '1.11.2', 'http://ajax.googleapis.com/ajax/libs/jquery/1.11.2/jquery.min.js', function(){
    requireScript('examplejs', '0.0.3', 'example.js');
});

3
Ваши меры не имеют значения. (1) Если пользователь является новым для веб-сайта, у него все равно нет jQuery в локальном хранилище. (2) Если, с другой стороны, пользователь уже посетил ваш веб-сайт, у него есть jQuery в кеше, что означает, что он не будет загружен из CDN. Это также приводит к третьему пункту: (3) локальное хранилище соответствует данному сайту, в то время как jQuery в CDN Google используется многими сайтами, что означает, что пользователь, который посетил, скажем, переполнение стека, но является новым для вашего сайта, выиграл не нужно перезагружать jQuery из CDN, если вы используете ту же версию jQuery.
Арсений Мурзенко

@MainMa Может быть, эта мера не очень хорошая, я вижу это сейчас, но для работы кеша браузера необходимо отправить запрос на сервер, который затем возвращает 304. Этот запрос занимает больше времени, чем непосредственное получение файла из localalstorage. , Поправьте меня если я ошибаюсь.
выберите

@MainMa, пожалуйста, также проверьте комментарии на сайте programmers.stackexchange.com/a/105526/195684. Есть еще проблемы с кешем, такие как сравнение ETAG, которое ускоряет это пользовательское кеширование
выберите
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.