Recursos e dados

Um Progressive Web App é um site. Todos os recursos dele são os mesmos da Web, mas com novas ferramentas para que eles carreguem rapidamente quando estiverem on-line e disponíveis off-line.

Componentes do app

O desenvolvimento de um aplicativo geralmente envolve vários ativos e recursos, desde a lógica e o código (compilados ou não) até os elementos da interface do usuário, como designs de tela, imagens, logotipos e fontes.

Um Progressive Web App é um site, então todos os recursos dele são os mesmos que na Web:

HTML para o conteúdo e a renderização inicial da página.
JavaScript para lógica, incluindo a capacidade de executar módulos WebAssembly (código compilado) e renderizar gráficos 2D e 3D otimizados por hardware.
CSS para layout, estilo e animações.
Imagens em formatos da Web, como PNG, JPEG, WebP e SVG.
Vídeos em formatos da Web, como MPEG-4 e WebM.
Fontes da Web.
Dados em JSON ou outros formatos.

Por padrão, os sites fazem o download de recursos pela rede, começando com HTML e seguindo para o restante dos recursos.

Gerenciar esses recursos para que eles sejam carregados rapidamente e estejam disponíveis off-line tem sido um desafio para a Web. Atualmente, os PWAs usam recursos anteriormente associados apenas a apps específicos da plataforma.

Apps específicos da plataforma x PWA

Ao instalar um app específico da plataforma, você normalmente faz o download de um pacote que inclui todos os recursos do app: código, imagens, fontes, vídeos etc. Portanto, todos esses recursos estão disponíveis no armazenamento do dispositivo, mesmo quando o app está off-line.

Já no site clássico, ela precisa de uma conexão de rede para fazer o download dos recursos quando necessário. Se você estiver off-line, vai encontrar um erro do navegador, já que não há recursos no lado do cliente.

A abordagem com PWA aprimora a experiência tradicional da Web disponibilizando alguns ou todos os recursos no lado do cliente, como acontece com apps específicos da plataforma. Portanto, quando você abre um PWA, a renderização inicial pode ser tão instantânea quanto um app de plataforma porque os recursos ficam disponíveis sem acessar a rede.

Caches e armazenamento

Desde o início da Web, os desenvolvedores não tinham controle total sobre como um recurso é armazenado em cache. O navegador é responsável pelo cache HTTP e pode ou não armazenar em cache e exibir recursos com base em políticas diferentes. Outras opções de armazenamento, como Web Storage e IndexedDB, foram criadas para salvar dados e objetos simples.

Os PWAs não precisam depender dessas políticas sozinhos para seu conteúdo. Em vez disso, temos soluções hoje para ter mais controle sobre quando e como armazenar recursos em cache e quando e como fornecê-los localmente: a API Cache Storage. A Web tem algumas soluções de armazenamento do lado do cliente disponíveis:

Armazenamento da Web: inclui localStorage e sessionStorage. Essas APIs armazenam pares simples de strings de chave-valor. O armazenamento Web é limitado e tem uma API síncrona, por isso, evite fazer isso sempre que possível.
IndexedDB: um banco de dados baseado em objeto (No-SQL) com uma API assíncrona que é bom para o desempenho na Web. O IndexedDB pode armazenar dados estruturados e binários do lado do cliente. Normalmente, é o que você usará para armazenar dados, como os dados obtidos ou enviados como uma solicitação de API. Também é útil salvar os dados no local imediatamente e depois sincronizá-los com o servidor. A API IndexedDB é usada para interagir com o banco de dados.
Armazenamento em cache: uma coleção de pares de solicitação e resposta HTTP que podem ser usados para armazenar e recuperar recursos (com os cabeçalhos HTTP) exatamente como eles são entregues pelo servidor. A API Cache Storage permite armazenar, recuperar, atualizar e excluir solicitações de rede, por exemplo, para seus recursos, mesmo off-line.

A necessidade de service workers

Um PWA pode armazenar recursos no armazenamento em cache e no IndexedDB, mas como podemos usar esses recursos para oferecer uma experiência rápida e off-line aos seus usuários. A resposta? Service workers.

Com um service worker, é possível veicular recursos sem acessar a rede, enviar notificações para um usuário, adicionar um selo ao ícone do PWA, atualizar conteúdo em segundo plano e até mesmo fazer todo o PWA funcionar off-line. Saiba mais sobre service workers no próximo capítulo.

Pronto para o modo off-line

Os usuários esperam que seu aplicativo ofereça uma experiência rápida e sempre pronta. Isso significa que o app precisa funcionar off-line.

Ficar pronto para o modo off-line não significa que todos os seus conteúdos ou serviços precisam estar disponíveis sem uma conexão de rede. No entanto, ter pelo menos uma experiência básica quando o usuário está off-line, como uma página que pede para você se conectar à Internet para continuar, proporciona uma melhor experiência do usuário, mantendo-o dentro da experiência do aplicativo em vez de um erro genérico do navegador. Em alguns navegadores, esse é um recurso necessário para passar nos critérios de instalação do PWA. Exibir a interface de usuário do PWA, junto com o conteúdo armazenado em cache, é melhor. Permitir que os usuários continuem usando todo o PWA e sincronizando mudanças do servidor quando eles voltarem a ficar on-line é o padrão ideal para trabalhar off-line.

Para disponibilizar o app off-line, você precisará armazenar em cache os recursos necessários para sua experiência off-line e fazer com que o service worker os disponibilize mais tarde. Adicione os ativos off-line ao seu cache antes de precisar deles. Esse é um caso específico em que não é possível armazená-las em cache quando solicitado.

Abordagens de cache usadas com frequência

No PWA, você é responsável por todas as decisões. Escolha a melhor abordagem para armazenar recursos em cache ou instalar de acordo com suas necessidades. Estas são algumas decisões a serem tomadas:

Pré-armazenamento em cache: escolha os recursos que você gostaria de instalar no primeiro carregamento. Eles devem incluir o HTML e os recursos mínimos para renderizar o app. Ao usar o pré-cache, lembre-se de que você está usando o espaço e a rede do dispositivo. Seja consciente e responsável ao fazer o download de recursos e armazená-los em cache.
Cache conforme necessário: usado para adicionar recursos ao cache quando solicitados. Normalmente, são recursos que podem mudar independentemente da versão do app, como imagens ou conteúdo. Consulte a seção Armazenamento em cache para diferentes estratégias de armazenamento em cache conforme necessário.
APIs e serviços da Web: as chamadas de API podem ser armazenadas em cache ou, em vez de armazenar as respostas da API em cache, é possível armazenar os dados delas no IndexedDB.

Atualizando recursos

No modelo padrão para apps instalados no catálogo, os desenvolvedores publicam um novo pacote quando precisam atualizar o app. Os usuários precisam fazer o download de todo o pacote novamente, mesmo que a maioria dos recursos não tenha mudado. Com os PWAs, usando as abordagens da seção acima, você decide como e quando atualizar os recursos. Confira abaixo as opções de atualização dos recursos:

Atualização completa: nesse caso, sempre que você fizer uma alteração no aplicativo, mesmo que seja uma pequena, o código fará o download de todos os recursos novamente no cache.
Atualização parcial: nessa abordagem, você cria um método para definir quais recursos foram atualizados e atualiza somente esses, com ou sem a intervenção do usuário.
Atualização contínua: com essa técnica, seus recursos são verificados e atualizados automaticamente a cada uso do PWA, individualmente

Tamanho e tempo de vida útil

Normalmente, apps específicos da plataforma não lidam com limites de tamanho. Na instalação, os apps podem ter gigabytes ou mais. A instalação poderá ser permitida se o dispositivo estiver na capacidade máxima. Além disso, enquanto o app estiver instalado, ele vai usar a quantidade total de armazenamento, independentemente de você usá-lo ou não. O armazenamento é processado de forma diferente para PWAs. O navegador armazenará seus recursos com base nas políticas que você definir na lógica do PWA.

Os limites de tamanho dependem do navegador. Ele não é tão flexível quanto os aplicativos de plataformas específicas, mas normalmente é bom o suficiente para a maioria dos aplicativos da Web. Confira as limitações específicas de cada navegador neste artigo.

Os navegadores podem remover recursos com base na pressão de armazenamento ou após algumas semanas de inatividade, se o usuário estiver usando seu PWA. Em algumas plataformas, se o usuário instalar seu PWA, a remoção não vai acontecer. Quando disponível, o código pode solicitar armazenamento persistente por uma API para evitar essa remoção.