PWA: transformando seu site em app instalável sem loja
Durante anos, ter um "app" significou uma escolha cara: contratar desenvolvimento nativo para iOS e Android, manter duas bases de código separadas, e submeter cada atualização à aprovação das lojas. Para muitos produtos, isso é esforço demais para o retorno. E se o seu site pudesse ser instalado na tela inicial do celular, funcionar offline e enviar notificações, sem nenhuma loja no meio do caminho? É exatamente isso que um PWA (Progressive Web App) entrega.
Um PWA é um site que usa recursos modernos do navegador para se comportar como um aplicativo. Ele mora na web, é acessado por uma URL e indexado pelo Google como qualquer página, mas pode ser instalado, aberto em tela cheia e usado mesmo sem conexão. Este guia explica as peças que tornam isso possível, como funcionam e quando um PWA é a decisão certa.
O que define um Progressive Web App
Três atributos, resumidos pela própria comunidade web, capturam a essência de um PWA:
- Capaz (capable): consegue fazer coisas que antes eram exclusivas de apps nativos, como acesso offline, notificações push e integração com o sistema.
- Confiável (reliable): carrega instantaneamente e funciona mesmo em conexão ruim ou inexistente, nunca mostrando a temida tela de dinossauro do navegador.
- Instalável (installable): pode ser adicionado à tela inicial do celular ou à área de trabalho, abrindo em janela própria, sem a barra de endereço do navegador.
A palavra "progressive" é importante: o site funciona para todo mundo, e os recursos avançados são adicionados como camada extra para quem tem um navegador compatível. Ninguém fica de fora, os capazes ganham mais.
As peças fundamentais
Um PWA se apoia em algumas tecnologias de navegador que trabalham juntas. Vamos por partes.
O web app manifest
O manifest é um arquivo JSON que descreve como o app deve se comportar quando instalado: nome, ícones, cores, orientação e a URL inicial. É ele que faz o navegador oferecer a instalação e que define a aparência do ícone na tela inicial.
{
"name": "Minha Loja",
"short_name": "Loja",
"start_url": "/",
"display": "standalone",
"background_color": "#FFFFFF",
"theme_color": "#1E5AF0",
"icons": [
{ "src": "/icons/192.png", "sizes": "192x192", "type": "image/png" },
{ "src": "/icons/512.png", "sizes": "512x512", "type": "image/png" }
]
}
O display: "standalone" é o que remove a interface do navegador, dando ao PWA a aparência de um app de verdade.
O service worker
O service worker é o coração de um PWA. Trata-se de um script que roda em segundo plano, separado da página, e funciona como um proxy entre o app e a rede. É ele que intercepta requisições, decide o que servir do cache e o que buscar online, e é o que viabiliza o funcionamento offline e as notificações push.
Um service worker tem um ciclo de vida próprio (instalação, ativação e controle das páginas) e opera sobre estratégias de cache. As mais comuns:
| Estratégia | Como funciona | Melhor para |
|---|---|---|
| Cache first | Serve do cache; só vai à rede se faltar | Assets estáticos (CSS, fontes, ícones) |
| Network first | Tenta a rede; cai no cache se falhar | Conteúdo que muda com frequência |
| Stale-while-revalidate | Serve do cache e atualiza em segundo plano | Equilíbrio entre velocidade e frescor |
Um registro mínimo, com cache dos arquivos essenciais na instalação:
// registro na página
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('/sw.js');
}
// dentro de sw.js: cache first para o "casco" do app
const CACHE = 'app-v1';
const ESSENCIAIS = ['/', '/styles.css', '/app.js', '/offline.html'];
self.addEventListener('install', (e) => {
e.waitUntil(caches.open(CACHE).then((c) => c.addAll(ESSENCIAIS)));
});
self.addEventListener('fetch', (e) => {
e.respondWith(
caches.match(e.request).then((hit) => hit || fetch(e.request))
);
});
Um detalhe não negociável: service workers só funcionam sobre HTTPS (com exceção de localhost para desenvolvimento). Segurança aqui é pré-requisito, não opcional.
Funcionamento offline e o modelo app shell
O padrão clássico de PWA é o app shell: separar o "casco" da aplicação (o HTML, CSS e JavaScript da estrutura, cabeçalho, navegação) do conteúdo que muda. O casco é cacheado no primeiro acesso e servido instantaneamente nas visitas seguintes, enquanto o conteúdo dinâmico é buscado por cima. O resultado é uma sensação de app instantâneo, mesmo em redes lentas.
Para o modo offline, a estratégia é decidir, por tipo de recurso, o que fica disponível sem rede. Uma página de fallback amigável para conteúdo ainda não cacheado é muito melhor do que um erro de conexão cru.
Notificações push e recursos de sistema
Além do offline, os PWAs acessam capacidades que antes eram exclusivas do nativo:
- Notificações push: reengajam o usuário mesmo com o app fechado, via service worker, desde que ele consinta.
- Sincronização em segundo plano: permite enfileirar ações feitas offline (como enviar um formulário) e completá-las quando a conexão voltar.
- Acesso a hardware: câmera, geolocalização, e em muitos casos sensores, tudo pela API do navegador.
Vale um aviso honesto sobre suporte: a cobertura de recursos varia entre plataformas. O Android costuma oferecer o conjunto mais completo, enquanto o iOS historicamente foi mais restritivo em pontos como push (que evoluiu, mas com particularidades). Projetar de forma progressiva, sem depender de um recurso que pode faltar, é o que mantém o PWA robusto em todo lugar.
PWA x app nativo: quando escolher cada um
A pergunta prática não é "PWA é melhor que nativo?", e sim "qual resolve o meu problema com menos custo?". Uma comparação direta:
| Critério | PWA | App nativo |
|---|---|---|
| Distribuição | Por URL, sem loja | App Store e Google Play |
| Custo de desenvolvimento | Uma base de código web | Uma por plataforma (ou cross-platform) |
| Atualização | Instantânea, no servidor | Sujeita à aprovação da loja |
| Descoberta | Indexável no Google | Busca dentro da loja |
| Acesso a hardware | Bom, com limites por plataforma | Completo |
| Performance de ponta | Muito boa para a maioria | Melhor para casos extremos (games 3D) |
O PWA brilha quando você quer alcance, atualização rápida, custo controlado e uma experiência mobile de alta qualidade sem manter três times. O nativo continua imbatível para produtos que dependem de acesso profundo ao hardware ou de performance gráfica extrema. Para a enorme maioria dos sites de produto, e-commerces e ferramentas, o PWA cobre muito bem.
Como começar sem reescrever tudo
A beleza do PWA é que ele é incremental. Um site existente pode virar um PWA em etapas:
- Garanta HTTPS em todo o site, pré-requisito de tudo.
- Adicione o web app manifest com nome, ícones e cores, habilitando a instalação.
- Registre um service worker simples, começando por cachear os assets estáticos.
- Defina estratégias de cache por tipo de recurso e uma página offline de fallback.
- Evolua com push e sync conforme o produto realmente precisar, sem adicionar complexidade cedo demais.
Cada passo entrega valor sozinho, então não há um "big bang" arriscado. Mede-se o progresso, inclusive, com auditorias que verificam os critérios de PWA de forma objetiva.
Um app sem o atrito da loja
O PWA desfaz a velha falsa escolha entre "site" e "app". Você mantém tudo o que a web tem de bom (uma URL, indexação, atualização instantânea, uma base de código) e ganha o que antes só o nativo oferecia (instalação, offline, notificações, cara de aplicativo). Para muitos produtos, é o melhor retorno sobre investimento em mobile que existe hoje, sem a fricção e o custo de manter aplicativos separados em duas lojas.
Na ConstructorTI, projetamos e implementamos PWAs performáticos e confiáveis: manifest e ícones corretos, service workers com estratégia de cache pensada, funcionamento offline de verdade e engajamento por push, tudo construído sobre uma base web rápida e indexável. Se você quer oferecer uma experiência de app aos seus usuários sem o custo do desenvolvimento nativo, fale com o nosso time e saia da conversa com um plano claro para transformar o seu site em um app instalável.