Existe um motivo para não usar o armazenamento local HTML5 para conteúdo

Em muitos sites estáticos, o tamanho total do conteúdo de texto real das 20 páginas mais populares chegaria a menos de 100kb.

Eu imaginaria que seria possível aproveitar o armazenamento local HTML5 para baixar o conteúdo via AJAX do servidor em um único arquivo, salvá-lo no armazenamento local e usá-lo com uma estrutura JS orientada a dados, como angularJS. Na verdade, você pode estar baixando ainda mais conteúdo silenciosamente em segundo plano. Isso pode resultar em uma experiência do usuário muito rápida e responsiva.

Apesar disso, eu não vi nenhum site funcionando dessa maneira. Existe uma razão que me falta que tornaria essa uma má idéia?

javascript angularjs local-storage

— Matthew Dolman
fonte

Não se esqueça de fazer o SEO funcionar. E você realmente precisa reinventar o cache do navegador?

— usar o seguinte comando

Você esquece que muito disso é feito pelo navegador. Um bom motivo para não fazer isso seria: e se você precisasse atualizar um desses recursos?

— Neil

É uma péssima idéia, porque é muito mais fácil fornecer os cabeçalhos de captura corretos para suas solicitações GET e permitir que os navegadores façam o trabalho pesado.

— Esben Skov Pedersen

@ jfriend00, sim, eu queria saber sobre SEO também. Acredito que o rastreador do Google possa lidar com algum javascript básico, mas isso provavelmente estaria além do escopo de seus rastreadores.

— Matthew Dolman

@ Neil, suponho que você possa ter o tempo limite de expiração incorporado, dependendo do recurso. Como eu mencionei no post eu estava pensando mais sobre sites estáticos que não seriam submetidos a alterações de curto TimeSpan

— Matthew Dolman

Eu acho que a resposta curta para sua pergunta é que a razão pela qual você não está vendo muita coisa acontecer como o que você descreve é que o armazenamento local em HTML5 não está de acordo com a tarefa, e até os últimos dois anos faltam apenas algo nos últimos dois anos sendo especificado que forneceria uma solução melhor.

Sobre o armazenamento local HTML5 especificamente: Possui uma condição de corrida e alguns outros problemas que impedem que seja adequado para uso na produção de qualquer aplicativo em que você deseja garantir que não haja corrupção de dados e em que deseja armazenar mais do que apenas strings .

Esses problemas no armazenamento local podem ser corrigidos, mas a realidade é que nenhum dos fornecedores de mecanismo de navegador neste momento tem interesse em afundar mais recursos em suas implementações de armazenamento local. Eles preferem que os desenvolvedores da Web usem alternativas ao armazenamento local.

De qualquer forma, para o caso de uso que você descreve, felizmente existem realmente soluções mais robustas em andamento. O ponto principal daqui para frente será o Service Worker - e, no contexto desta pergunta, o Service Worker Cache e o CacheStorage fazem interface especificamente.

O IndexedDB também é a solução de nível de produção que o tempo de execução da Web agora possui para o caso geral de armazenamento robusto de dados no cliente, com implementações eficientes e com mais controle sobre os tipos de dados armazenados e como eles são armazenados.

— sideshowbarker
fonte

"local storage is in no way up to the task"- SIM que é acima para a tarefa. você pode despejar qualquer resposta vinda do servidor e, para aplicativos simples, você não vai riscar o 5MBlimite. não foi feito para isso, mas ainda assim, pode ser usado com muito sucesso para armazenar em cache as respostas do servidor.

— vsync 14/10