Os blocos de construção dos aplicativos da Web progressivos

Os aplicativos da Web podem substituir todas as funções de aplicativos e sites nativos de uma só vez. Eles estão vindo cada vez mais à tona nos dias de hoje, mas ainda não há pessoas suficientes familiarizadas com eles ou adotando-os.

Neste artigo, você poderá encontrar alguns prós e contras sobre como fazer um aplicativo da web progressivo, bem como recursos para pesquisas adicionais. Também abordarei os vários componentes e problemas de suporte relacionados aos aplicativos da web. Embora nem todo navegador seja amigável para eles, ainda existem algumas razões convincentes para aprender mais sobre essa tecnologia.

O que torna um aplicativo da Web progressivo?

Um aplicativo da Web progressivo é um termo abrangente para determinadas tecnologias que se unem para produzir uma experiência semelhante a um aplicativo na Web. Para simplificar, vou me referir a eles simplesmente como aplicativos da web a partir de agora.

Um aplicativo da Web ideal é uma página da Web que possui os melhores aspectos da Web e dos aplicativos nativos. Deve ser rápido e rápido para interagir, caber na janela de visualização do dispositivo, permanecer utilizável offline e poder ter um ícone na tela inicial.

Ao mesmo tempo, não deve sacrificar as coisas que tornam a web excelente, como a capacidade de vincular profundamente ao aplicativo e usar URLs para permitir o compartilhamento de conteúdo. Assim como a web, ela deve funcionar bem em todas as plataformas e não se concentrar apenas em dispositivos móveis. Ele deve se comportar tão bem em um computador desktop quanto em outros fatores de forma, para não corrermos o risco de ter outra era de sites m.example.com sem resposta.

Os aplicativos da web progressivos não são novos. Os navegadores móveis têm a capacidade de marcar um site na tela inicial do seu telefone desde 2011 (2013 no Chrome Android), com metatags na head determinando a aparência da página da Web instalada. O Financial Times usa um aplicativo da web para entrega de conteúdo digital em dispositivos móveis desde 2012.

A mudança para um aplicativo da web permitiu que o Financial Times usasse o mesmo aplicativo para enviar entre plataformas em um único canal de distribuição. Quando eu trabalhava para o Financial Times, com uma única compilação, pudemos oferecer suporte ao seguinte:

• iOS,
• Android (4.4+) Chrome,
• Android mais antigo (por meio de um wrapper),
• Windows 8,
• Amora,
• Firefox OS.

Isso realmente alcança “construir uma vez, implantar em qualquer lugar”.

“Mas não está em uma App Store”

Existem algumas boas razões pelas quais complementar um aplicativo nativo com um site ainda é uma prática padrão para a maioria das grandes empresas. Entre eles estão as preocupações com o suporte ao navegador e o fato de que a maioria dos usuários está acostumada a usar aplicativos nativos. Abordarei essas questões com mais detalhes posteriormente. Uma dessas preocupações é como o aplicativo obterá exposição se não estiver em uma loja de aplicativos.

Eu diria que estar em uma loja de aplicativos não tem grande vantagem porque foi demonstrado que, se você não estiver no top 0,1% dos aplicativos na loja de aplicativos, você não está obtendo benefícios significativos por estar lá.

Os usuários tendem a encontrar seus aplicativos encontrando primeiro seu site. Se o seu site for um aplicativo da Web, eles já estão no destino.

Um dos pontos fortes de um aplicativo da web é que ele permite que você melhore o engajamento reduzindo o número de cliques necessários para reengajar o usuário entre o acesso ao seu site e o engajamento com seu aplicativo.

Ao fazer com que o usuário “instale” seu aplicativo da Web adicionando-o à tela inicial, ele poderá continuar interagindo com seu site. Quando eles fecham o navegador da web, o telefone mostra onde o aplicativo da web está instalado, trazendo você de volta ao conhecimento deles.

Histórico e Clima Atual

Os aplicativos da Web modernos são baseados em uma nova tecnologia chamada service workers. Service workers são proxies programáveis ​​que ficam entre a guia do usuário e a Internet mais ampla. Eles interceptam e reescrevem ou fabricam solicitações de rede para permitir armazenamento em cache muito granular e suporte offline.

Desde as origens do aplicativo da web em 2011, que permitiu que os sites fossem marcados na tela inicial, vários desenvolvimentos ocorreram para estabelecer mais bases para a criação de aplicativos da web progressivos.

O Chrome 38 introduziu o manifesto do aplicativo Web, que é um arquivo JSON que descreve a configuração do seu aplicativo Web. Isso nos permitiu remover a configuração do head .

No Chrome 40 (dezembro de 2014), os service workers começaram a ser implementados no Firefox e no Chrome. Até agora, a Apple optou por não implementar esse recurso no Safari no momento em que este artigo foi escrito, mas o está “em consideração”. A função do service worker é simplificar o processo de colocar um aplicativo offline; ele também estabelece as bases para futuros recursos semelhantes a aplicativos, como notificações push e sincronização em segundo plano.

Os aplicativos que foram criados com base nos novos service workers e no manifesto do aplicativo Web ficaram conhecidos como aplicativos Web progressivos.

Um aplicativo da Web progressivo não é o mesmo que a especificação. Na verdade, começou como uma definição do que um aplicativo da web deveria ser na era dos service workers, dada a nova tecnologia que está sendo incorporada aos navegadores. Especificamente, o Chrome usa essa definição para acionar um prompt de instalação no navegador quando várias condições são atendidas. As condições são que o aplicativo da web:

• tem um service worker (requer HTTPS);
• tem um arquivo de manifesto do aplicativo web (com pelo menos configuração mínima e com display: "standalone" );
• teve duas visitas distintas.

Nesse caso, “progressivo” significa que quanto mais recursos o navegador suportar, mais semelhante a um aplicativo poderá ser a experiência.

O prompt para instalar o aplicativo da Web é exibido atualmente em condições variadas no Opera, Chrome e no navegador Samsung.

A Apple indicou interesse em aplicativos da Web progressivos para iOS, mas no momento da redação ainda depende de metatags para configuração de aplicativos da Web e do cache do aplicativo (AppCache) para uso offline.

Em que ponto um site se torna um aplicativo da Web?

Sabemos como é um site e como é um aplicativo, mas em que ponto um site se torna um aplicativo da web? Não há uma métrica definitiva sobre o que torna algo um aplicativo da Web em vez de um site.

Aqui entraremos em mais detalhes sobre as características de um aplicativo da web.

Um aplicativo da Web progressivo deve exibir certas propriedades semelhantes a aplicativos…

• Responsivo
  Preenchendo perfeitamente a tela, esses sites são voltados principalmente para telefones e tablets e devem responder à infinidade de tamanhos de tela. Eles também devem funcionar apenas como sites de desktop. O design responsivo tem sido uma parte importante da construção de sites há muitos anos. A Smashing Magazine tem ótimos artigos sobre isso.
• Off-line primeiro
  O aplicativo deve ser capaz de iniciar offline e ainda exibir informações úteis.
• Compatível com toque
  A interface deve ser projetada para toque, com interação por gestos. A interação do usuário deve ser ágil e ágil, sem atrasos entre um toque e uma resposta.
• Metadados do aplicativo
  O aplicativo deve fornecer metadados para informar ao navegador como ele deve ficar quando instalado, para que você obtenha um belo ícone de alta resolução na tela inicial e uma tela inicial em algumas plataformas.
• Notificações via push
  O aplicativo pode receber notificações quando o aplicativo não está em execução (se aplicável).

… Mas deve manter certas propriedades semelhantes à Web

• Progressivo
  A capacidade de instalação do aplicativo é um aprimoramento progressivo. É vital que o aplicativo ainda funcione como um site normal, especialmente em plataformas que ainda não suportam instalação ou service workers.
• HTTPS na web aberta
  O aplicativo não deve ser bloqueado para nenhum navegador ou loja de aplicativos. Ele deve ser capaz de ter links diretos e fornecer métodos para compartilhar o URL atual.

Colocando seu site off-line

Colocar seu site offline traz algumas vantagens importantes.

Primeiro, ele ainda funcionará quando o usuário estiver em uma conexão de rede instável.

Além disso, o tempo desde a abertura do aplicativo até o uso do aplicativo é bastante reduzido se o aplicativo não depender da rede. Isso proporciona ao usuário uma ótima experiência. Um aplicativo da Web cuidadosamente otimizado pode iniciar mais rápido do que um nativo se o navegador tiver sido usado recentemente.

Existem dois métodos para fazer um site funcionar offline:

• Método antigo e quebrado
  O suporte para iniciar seu site offline existe há anos na forma de AppCache. O AppCache tem algumas falhas sérias, no entanto, e até foi preterido da especificação. É difícil trabalhar com ele e, se configurado incorretamente, pode danificar permanentemente seu site. Ainda assim, é a única maneira de fazer offline no iOS, pelo menos até que a Apple faça um movimento para apoiar os trabalhadores de serviços.
• Nova gostosura
  Também são eficazes os service workers, que atualmente são suportados no Chrome, Firefox e Opera e chegarão muito em breve ao Edge. A equipe do WebKit da Apple marcou "em consideração".

Os service workers são como outros web workers, pois são executados em um thread separado, mas não estão vinculados a nenhuma guia específica. Eles recebem um escopo de URL quando são criados e podem interceptar e reescrever qualquer solicitação nesse escopo. Se o seu service worker estiver em https://example.com/my-site/sw.js , ele poderá interceptar todas as solicitações feitas para /my-site/ ou inferior, mas não poderá interceptar solicitações para o https://example.com/ raiz https://example.com/ .

Como eles não estão vinculados a nenhuma guia, eles podem ser trazidos à vida em segundo plano para lidar com notificações push ou sincronização em segundo plano. Não menos importante, é impossível quebrar seu site permanentemente com eles porque eles serão atualizados automaticamente quando um novo script de service worker for detectado.

Uma boa diretriz é que, se você estiver criando um novo site do zero, comece com um service worker. No entanto, se o seu site já funciona offline com o AppCache, você pode usar a ferramenta sw-appcache-behavior para gerar um service worker a partir disso, pois em breve poderemos chegar ao ponto em que alguns navegadores aceitarão apenas service workers e outros apenas AppCache.

Como o AppCache está sendo preterido, não o discutirei mais neste artigo.

Configurando um Service Worker

(Além disso, consulte “Configurando um Service Worker” para obter instruções mais detalhadas.)

Como um service worker é um tipo especial de web worker compartilhado, ele é executado em um encadeamento separado para sua página principal. Isso significa que ele é compartilhado por todas as páginas da Web no mesmo caminho que o service worker. Por exemplo, um service worker localizado em /my-page/sw.js poderia afetar /my-page/index.html e my-page/images/header.jpg , mas não /index.html .

Os service workers podem interceptar e reescrever ou falsificar todas as solicitações de rede feitas na página, incluindo aquelas feitas para data:// URLs!

Esse poder permite fornecer respostas em cache para que as páginas funcionem quando não há conexão de dados. Ainda assim, é flexível o suficiente para permitir muitos casos de uso possíveis.

Só é permitido em contextos seguros (ou seja, HTTPS) porque é muito poderoso. Isso impede que terceiros substituam permanentemente seu site usando um service worker injetado de um ponto de acesso Wi-Fi infectado ou malicioso.

Configurar HTTPS hoje em dia pode parecer assustador e caro, mas na verdade nunca foi tão fácil ou barato. Let's Encrypt fornece certificados e scripts SSL gratuitos para você configurar automaticamente seu servidor. Caso você hospede no GitHub, as GitHub Pages são veiculadas automaticamente por HTTPS. As páginas do Tumblr também podem ser configuradas para serem executadas em HTTPS. CloudFlare pode fazer solicitações de proxy para atualizar para HTTPS.

Offline geralmente envolve a escolha de certos métodos de cache para diferentes partes do seu site para permitir que sejam servidos mais rapidamente ou quando não há conexão com a Internet. Discutirei vários métodos de cache abaixo.

Eu uso o Service Worker Toolbox para abstrair a lógica de cache complexa. Essa biblioteca pode ser configurada para lidar com o roteamento fornecendo quatro rotas pré-configuradas, que podem ser configuradas de forma limpa. Ele pode ser importado para seu service worker.

Caso de uso 1: pré-cache

O pré-caching retira as solicitações antes que seu site perceba que elas são necessárias. Isso pode diminuir muito o tempo da primeira pintura porque seu site não precisa analisar /site.css antes de começar a baixar o logotipo do seu site, /images/logo.png .

 toolbox.precache(['/index.html', '/site.css', '/images/logo.png']);

Caso de uso 2: off-line

Permitir que os usuários revisitem seu site quando estiverem offline, no caso mais simples, significa voltar ao cache se o dispositivo estiver offline. Definir um tempo limite aqui é importante porque uma rede instável, roteador mal configurado ou portal cativo pode deixar o usuário esperando indefinidamente.

 toolbox.router.default = toolbox.networkFirst; toolbox.options.networkTimeoutSeconds = 5;

Na realidade, podemos ser um pouco mais inteligentes porque a maioria de seus ativos não mudará com o tempo. Provavelmente, queremos apenas obter o conteúdo o mais rápido possível, seja do cache ou da rede. A linha a seguir informa ao Service Worker Toolbox que todas as solicitações para os caminhos das imagens devem vir do cache, se estiverem disponíveis lá.

 toolbox.router.all('/images/*', toolbox.fastest);

Nesse caso, quando o usuário está autenticando, é importante que não retornemos apenas uma resposta em cache; devemos declarar que as solicitações feitas para /auth/ devem ser somente de rede.

 toolbox.router.post('/auth/*', toolbox.networkOnly);

Aqui estão algumas boas práticas para off-line:

• Os ativos estáticos iniciais devem ser armazenados em pré-cache. Isso os baixa e os armazena em cache quando o service worker é instalado. Isso significa que eles não precisam ser carregados do servidor quando forem necessários.
• Por padrão, as solicitações devem, idealmente, ser provenientes da rede, mas retornar ao cache para que estejam disponíveis offline.
• Um tempo limite de rede relativamente curto significa que as solicitações poderão retornar dados em cache em uma conexão de rede que diz que tem uma conexão de dados, mas nenhuma resposta está sendo retornada.
• Ativos atualizados com pouca frequência, como imagens, devem ser despachados do cache primeiro, depois o navegador também tentará atualizá-los. Se toolbox.cacheOnly for usado, ele também poderá salvar os dados do usuário.

Observação: o cache do navegador e a API de cache são animais diferentes. A API de cache foi ignorada no caso de rede em primeiro lugar ou somente rede. A solicitação ainda pode atingir o cache do navegador porque os cabeçalhos de cache na solicitação dizem que ela ainda é válida. Isso pode resultar no problema de o usuário receber uma mistura de dados em cache e novos. Jake Archibald tem algumas boas sugestões para evitar esse problema.

Depurando seu Service Worker

Se você estiver no Chrome ou Opera, acesse chrome://serviceworker-internals . Isso permitirá que você inspecione, pause e desinstale o script do service worker.

Nas versões recentes do Chrome e do Opera, você pode obter visualizações detalhadas e ferramentas de depuração na guia “Aplicativo” no inspetor.

Desempenho de interação e animação

As pessoas passaram a esperar que a web não tenha as interfaces suavemente animadas que os aplicativos nativos têm. No entanto, o mesmo padrão não é aceitável para aplicativos da web. Os aplicativos da Web devem animar sem problemas, para que nossos usuários não sintam que estamos oferecendo uma experiência degradada e de segunda classe. Temos três objetivos para torná-lo mais rápido:

• Quando o usuário faz algo, o aplicativo também deve fazer algo em 100 milissegundos; caso contrário, o usuário notará um atraso. Isso conta para toques, cliques, arrasta e rola.
• Cada quadro deve renderizar a 60 quadros por segundo consistentes (16 milissegundos por quadro). Mesmo alguns quadros lentos serão óbvios.
• Deve ser rápido em um telefone econômico de três anos rodando em uma rede ruim, não apenas em sua máquina de desenvolvimento brilhante.
• Deve começar rapidamente. Há muito que nos concentramos em manter o envolvimento do usuário, tornando nossos sites visíveis e utilizáveis ​​em menos de 1 a 2 segundos. Quando se trata de aplicativos da Web, o tempo de inicialização é mais importante do que nunca. Se todo o conteúdo de um aplicativo estiver armazenado em cache e o navegador ainda estiver na memória do dispositivo, um aplicativo da Web poderá ser iniciado mais rapidamente do que um aplicativo nativo. Um erro cometido por desenvolvedores de aplicativos nativos e sites é exigir conteúdo em rede para que o produto funcione.
• O aplicativo da web deve ser pequeno para baixar e atualizar: 10 MB de uma loja de aplicativos não parece muito, mas 10 MB sem cache baixados todas as vezes são muito impossíveis de gerenciar para muitos usuários móveis.

De cara, o item mais essencial é este, no head do documento:

 <meta name="viewport" content="width=device-width">

Essa linha garante que não haja um atraso de toque de 300 milissegundos em navegadores de telefone baseados no Chromium ou no Firefox, mas ainda permite que o usuário amplie com os dedos (ótimo para acessibilidade).

Desde que o iOS 8 foi lançado, os cliques são rápidos por padrão, mas podem parecer lentos se o toque for rápido, de acordo com certas heurísticas. Se isso for um problema para você, recomendo usar o FastClick para remover o atraso.

Há também a questão do desempenho da animação. Você provavelmente vai querer muitos elementos bonitos animando dentro e fora, elementos que podem ser arrastados pelo usuário e outras interações adoráveis.

O desempenho na Web pode ser discutido em grande detalhe e é um assunto que me é muito caro, mas não vou entrar em muitos detalhes aqui. Vou falar sobre o que faço para garantir que minhas interações e animações sejam nítidas e suaves.

Pesquise ou pergunte a seus amigos ou familiares por um smartphone antigo. Eu costumo pegar emprestado o Nexus 4 do meu parceiro.

Conecte o telefone ao computador e acesse chrome://inspect/#devices . Isso abrirá uma janela de inspeção, que você pode usar para inspecionar as páginas da Web em execução no telefone. Você pode usar a criação de perfil e visualizar a linha do tempo para encontrar fontes de desempenho insatisfatório e, em seguida, otimizá-las com base em um dispositivo de linha de base real.

Animar certas propriedades CSS é uma das maiores causas de animação instável, conhecida como jank. CSS Triggers é um ótimo recurso para determinar quais propriedades podem ser animadas com segurança sem fazer com que o navegador redesenhe ou refaça o layout da página inteira.

Se escrever animações de alto desempenho é uma tarefa assustadora para você, muitas bibliotecas por aí irão lidar com o trabalho. Um dos meus favoritos é o GreenSock, que pode lidar muito bem com interações de toque, como arrastar itens, e que pode fazer animações e interpolações muito sofisticadas.

Notificações via push

As notificações push são uma ótima maneira de interagir novamente com os usuários. Ao avisar o usuário, você traz seu aplicativo para a frente de sua mente. Eles podem finalizar uma transação inacabada ou receber alertas sobre novos conteúdos relevantes.

Certifique-se de que suas notificações push sejam relevantes para o usuário para os eventos que acontecem naquele momento. Não perca seu tempo com coisas que podem ser feitas depois. O que você está notificando deve exigir a ação deles (responder a alguém ou ir a um evento). Além disso, não envie uma notificação se seu aplicativo da Web estiver visível ou em foco.

Ao interagir, uma notificação deve levar o usuário a uma página que funciona offline. As notificações podem ficar sem ser lidas; eles podem interagir quando o usuário não tiver conexão de rede. O usuário ficará frustrado se sua notificação por push se recusar a funcionar depois que eles tentarem interagir com ela.

A melhor experiência para notificações push libera o usuário de ter que abrir seu aplicativo da web ! “Você tem uma nova mensagem” é inútil e tão irritante quanto um título de isca de cliques. Exibe a mensagem e o remetente.

Os botões de ação na notificação podem fornecer prompts de interação que não necessariamente abrem o navegador (“Curtir esta postagem”, “Responder com sim”, “Responder com não”, “Lembre-me mais tarde”). Estes atendem o usuário em seus termos, mantém-no engajado e minimiza seu investimento de tempo.

Se você enviar spam ao usuário com notificações regulares ou irrelevantes, ele poderá desativar as notificações do seu aplicativo no navegador. Depois disso, será quase impossível engajá-los novamente e você não poderá solicitar permissão facilmente novamente!

Para evitar isso, torne o caminho para o botão “desativar notificação” do seu aplicativo claro e fácil. Depois de resolver os problemas que frustram os usuários, você pode tentar se envolver novamente.

A API Push Notification requer um service worker. Como é possível receber notificações por push quando nenhuma guia do navegador estiver aberta, o service worker manipulará a solicitação de notificação em um encadeamento em segundo plano. Ele pode realizar operações assíncronas, como fazer uma solicitação de busca para sua API antes de exibir a notificação ao usuário.

Para criar uma notificação por push, faça uma solicitação para um endpoint fornecido pelo fabricante do navegador. Para navegadores baseados em Chromium (Opera, Samsung e Chrome), isso seria Firebase Cloud Messaging. Esses navegadores também se comportam um pouco fora das especificações.

Pode-se encontrar os detalhes disso solicitando permissão de notificação por push:

 serviceWorkerRegistration .pushManager .subscribe({ // Required parameter as receiving updates // but not displaying a message is not supported everywhere. userVisibleOnly: true }) .then(function(subscription) { return sendSubscriptionToServer(subscription); })

A assinatura é um objeto que se parece com isso:

 { "endpoint": "https://example.com/some/uuid" }

No exemplo acima, o uuid identifica exclusivamente o navegador que está sendo usado no momento.

Observação: os navegadores baseados em Chromium se comportam de maneira um pouco diferente. Você precisará de um ID de aplicativo do Firebase, que precisa ser inserido no arquivo de manifesto do seu aplicativo da Web (por exemplo, "gcm_sender_id": "90157766285" ).

Além disso, o ponto de extremidade não funcionará no formato fornecido. Seu servidor precisa desmontá-lo um pouco para fazê-lo funcionar. Precisa ser uma solicitação POST , com sua chave de API no head e o uuid no body .

Ao enviar uma notificação por push, é possível enviar dados no corpo da própria notificação por push. Isso é complexo e envolve criptografar o conteúdo na solicitação da API. O pacote web-push para Node.js pode lidar com isso, mas eu não o prefiro.

É possível realizar solicitações assíncronas assim que a notificação for recebida, então eu prefiro enviar uma notificação mínima, conhecida como “cócegas”, para o cliente, e então o service worker fará uma solicitação de busca à minha API para puxar qualquer atualizações recentes.

Observação: o service worker pode ser fechado pelo navegador a qualquer momento. A função event.waitUntil no evento push informa ao service worker para não fechar até que o evento seja concluído.

 self.addEventListener('push', function(event) { event.waitUntil( // Makes API request, returns Promise getMessageDetails() .then(function (details) { self.registration.showNotification( details.title, { body: details.message, icon: '/my-app-logo-192x192.png' }) }) ); });

Você também pode ouvir um clique ou pressionar a interação nos eventos de notificação. Use-os para decidir como responder. Você pode abrir uma nova guia do navegador, focar uma guia existente ou fazer uma solicitação de API. Você também pode optar por fechar a notificação ou mantê-la aberta. Use essa funcionalidade com ações na notificação para criar uma ótima funcionalidade na própria notificação. Isso proporcionará uma ótima experiência, porque o usuário não precisará abrir seu aplicativo todas as vezes.

Não ignore os pontos fortes da web

O ponto final e mais importante é que, em nossa corrida por uma experiência semelhante a um aplicativo, não devemos nos esquecer de permanecer como a web em um aspecto muito importante: URLs.

Os aplicativos da Web instalados geralmente ocultam o shell do navegador. Não há barra de endereço para o usuário compartilhar a URL atual e o usuário não pode salvar a página atual para mais tarde.

Os URLs têm uma vantagem exclusiva da Web: você pode fazer com que as pessoas usem seu aplicativo clicando, em vez de descrever como navegar nele. Mesmo assim, é muito fácil esquecer de expor isso aos usuários. Você poderia escrever o melhor aplicativo do mundo, mas se ninguém puder compartilhá-lo, você terá feito um grande desserviço a si mesmo.

Tudo se resume a isso: forneça maneiras de compartilhar seu aplicativo por meio de botões de compartilhamento ou um botão para expor a URL.

E quanto aos navegadores que não suportam aplicativos da Web progressivos?

Confira O ServiceWorker está pronto? para o status atual do suporte para service workers em navegadores.

Você deve ter notado em tudo isso que mencionei Chrome, Firefox e Edge, mas deixei de fora o Safari. A Apple apresentou os aplicativos da Web ao mundo e demonstrou interesse em aplicativos da Web progressivos, mas ainda não oferece suporte a service workers ou ao manifesto do aplicativo da Web. O que você pode fazer?

É possível criar um site offline para o Safari com AppCache, mas fazer isso é difícil e repleto de casos estranhos que podem quebrar a página ou mantê-la permanentemente desatualizada após o primeiro carregamento.

Em vez disso, crie uma ótima experiência de aplicativo da web. Seu trabalho não será desperdiçado porque a experiência ainda será ótima no Safari, que é um navegador muito bom. Quando os service workers vierem ao Safari, você estará pronto para aproveitá-los.

Finalmente, podemos esperar muitos desenvolvimentos interessantes no mundo dos aplicativos da web, com suporte crescente para as tecnologias por trás deles e novos recursos chegando à plataforma da web, como a API Web Bluetooth para interação com hardware, WebVR para realidade e WebGL 2 para jogos de alta velocidade. Agora é um ótimo momento para explorar as possibilidades dos aplicativos da web e participar da formação do futuro da web.

Links

Outras escritas em aplicativos da Web progressivos

• “Mais um blog sobre o estado e o futuro do Progressive Web App”, Ada Rose Edwards

Links mencionados no artigo

• “A Forma da App Store”, Charles Perry
• Auxiliares de Service Worker, Google, GitHub
• Caixa de ferramentas do trabalhador de serviço, Google, GitHub
• “O atraso de clique de 300 milissegundos e iOS 8”, TJ VanToll
• “Práticas recomendadas de armazenamento em cache e pegadinhas de idade máxima”, Jake Archibald