Progressivas web hoje não são mais o futuro, são o presente chato
A gente precisa ajustar esse papo desde já: Progressiva não é tecnologia mágica que transforma seu site medícro em aplicativo nativo. É uma camada de compatibilidade que, se implementada direito, te dá cache local, instalação e notificações. Se implementada errado — o que é a maioria dos casos — você gasta três dias e não tem nada no final.
Como avaliar qual as melhores progressivas para seu projeto
O primeiro erro que eu vejo todo mundo cometendo é olhar para o catálogo de apps antes de olhar para o cenário técnico do próprio site. Você precisa mapear três coisas antes de escolher qualquer coisa: o framework que sustenta seu frontend, a infraestrutura de backend atual e, acima de tudo, quais comportamentos offline são realmente necessários. Não adianta querer que uma loja inteira funcione sem internet se o pagamento depende de gateway em tempo real. Isso é ficção. Um dos cenários que eu lidei recentemente foi com um cliente que tinha uma aplicação React rodando sobre Next.js com SSR híbrido. O problema é que o service worker tentava interceptar requisições de API que precisavam ser dinâmicas. A solução foi criar duas rotas separadas: uma com stale-while-revalidate para os dados estáticos e outra com cache-first estrito só para assets. O serviço de push parou de gerar erros 500 e a taxa de retenção subiu de 12% para 34% em seis semanas. Nada de revolucionário. Apenas o básico bem feito.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Aqui vai algo que poucos mencionam: a maioria dos desenvolvedores foca obsessivamente no manifest.json e esquece que a experiência real começa no momento em que o usuário desinstala e reinstala o app. Se você não tiver um sistema de ID persistente no banco de dados ligado ao token do push, a pessoa perde todo o histórico de notificações e o engajamento cai. Eu vi isso acontecer em duas oportunidades. A correção foi implementar UUIDs sincronizados entre o frontend e o backend antes de ativar qualquer notificação push. Agora, falando abertamente dos problemas: progressive web apps têm limitações sérias em iOS. O Safari não permite notificações push nativas. Ele não suporta background fetch. A instalação via prompt padrão também é restrita. Se seu público-alvo é majoritariamente iOS, você está basicamente gastando dinheiro com um site que tem um botão ridículo de "adicionar à tela inicial". Nesse caso, vale mais a pena considerar uma solução híbrida com React Native ou até aceitar que o PWA não é a resposta correta.
Outro ponto que ninguém quer ouvir: a complexidade de manutenção cresce exponencialmente. Um service worker mal configurado pode cachear versões antigas do seu código por dias. Já tive um caso onde a equipe de QA passou duas semanas debugando um bug que na verdade era um cache obsoleto do SW. A solução foi usar strategy cache-first com no nome do arquivo e invalidar manualmente sempre que um deploy era feito. Leva mais tempo no início, mas evita dor de cabeça depois.
O que realmente importa na hora de escolher
O Lighthouse é uma ferramenta útil mas enganosa. Um score de 100 não significa que seu app progressivo funciona bem. Ele mede Performance, Acessibilidade, Best Practices e SEO. Não mede se o service worker funciona no modo avião ou se as notificações chegam quando o app está em segundo plano. Para isso você precisa testar manualmente, em dispositivos reais, nos cenários que seus usuários realmente enfrentam. Se você precisa de uma recomendação concreta, o caminho mais seguro começa com um site já bem estruturado, com HTTPS ativo, componentes renderizados em servidor ou estático, e assets versionados. Qualquer um desses requisitos ausente é um risco de projeto falhar. Não existe receita de bolo. Mas posso garantir que a abordagem mais simples costuma funcionar melhor do que tentativas ambiciosas de replicar funcionalidades nativas.
