PWA: transforme seu site num app instalável

Já falei aqui sobre a diferença entre app nativo e híbrido, e PWA entra como uma terceira opção nessa conversa, ainda mais direta: transformar o próprio site num aplicativo instalável, sem passar por loja de aplicativo nenhuma. Vale entender o que faz isso funcionar de verdade por baixo, porque não é mágica do navegador, são só dois arquivos bem específicos.

O que muda de um site comum pra uma PWA

Um site comum só existe dentro de uma aba do navegador, some da tela assim que a conexão de internet cai, e não tem nenhum ícone próprio no aparelho do usuário. Uma Progressive Web App (PWA) ganha três coisas que aproximam ela de um app nativo: um ícone instalável na tela inicial, a possibilidade de abrir em tela cheia, sem a barra de endereço do navegador aparecendo, e algum nível de funcionamento offline, mesmo sem internet.

Nada disso depende de aprovação de loja nenhuma, nem de escrever o app numa linguagem diferente. É o mesmo HTML, CSS e JavaScript de sempre, só que com dois arquivos a mais dando esse comportamento extra ao navegador.

O manifest: o cartão de identidade do app

O manifest.json é um arquivo simples que descreve como o site deveria se comportar quando instalado:

{
  "name": "Meu Blog",
  "short_name": "Blog",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#7c3aed",
  "icons": [
    { "src": "/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icon-512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

Esse arquivo é referenciado no <head> da página:

<link rel="manifest" href="/manifest.json" />

O display: "standalone" é o que remove a barra de endereço quando o app é aberto pela tela inicial, fazendo ele parecer um aplicativo de verdade, não uma aba de navegador. Os ícones são o que aparece na tela inicial do celular depois que o usuário instala. Sem esse arquivo, o navegador nem oferece a opção de instalar o site.

O service worker: o que permite funcionar offline

O manifest sozinho só cuida da aparência. Quem cuida do comportamento offline é o service worker, um script que roda separado da página, em segundo plano, interceptando as requisições de rede antes delas saírem de verdade:

// sw.js
const CACHE_NAME = "meu-blog-v1";
const ARQUIVOS_ESSENCIAIS = ["/", "/estilos.css", "/app.js"];
 
self.addEventListener("install", (event) => {
  event.waitUntil(
    caches.open(CACHE_NAME).then((cache) => cache.addAll(ARQUIVOS_ESSENCIAIS)),
  );
});
 
self.addEventListener("fetch", (event) => {
  event.respondWith(
    caches.match(event.request).then((respostaCache) => {
      return respostaCache || fetch(event.request);
    }),
  );
});

No evento install, o service worker guarda em cache os arquivos essenciais do site. No evento fetch, toda requisição que a página faz passa primeiro por esse código: se o arquivo pedido já está no cache, ele é devolvido direto dali, sem nem tentar a rede. Se não está, a requisição segue normal pra internet. É esse mecanismo que permite o site abrir mesmo sem conexão, pelo menos pras partes que já foram cacheadas.

O registro do service worker acontece na própria página:

if ("serviceWorker" in navigator) {
  navigator.serviceWorker.register("/sw.js");
}

As limitações reais

PWA não substitui um app nativo em tudo. O acesso a recursos do aparelho é bem mais limitado: notificação push funciona, mas de forma mais restrita que um app nativo; acesso a Bluetooth, NFC ou sensores específicos do hardware costuma não existir ou ser bem mais limitado. No iOS especificamente, o suporte a recursos de PWA historicamente vem mais atrasado e mais restrito do que no Android, o que pesa bastante se boa parte dos usuários usa iPhone.

Cache mal configurado também é uma armadilha comum: se o service worker guarda uma versão antiga de um arquivo e nunca atualiza, o usuário pode ficar preso numa versão desatualizada do site, mesmo depois de você já ter feito deploy de correções. Por isso o nome do cache costuma incluir uma versão (meu-blog-v1, meu-blog-v2), permitindo invalidar o cache antigo quando uma versão nova é publicada.

Quando vale a pena

PWA compensa bem quando o objetivo é dar uma experiência de app instalável sem o custo de manter um app nativo separado (duas bases de código, processo de aprovação de loja, atualização que depende do usuário baixar a versão nova). Funciona bem pra conteúdo que se beneficia de acesso rápido e offline básico, como um blog, uma ferramenta simples ou um catálogo. Pra algo que depende pesado de recurso nativo do aparelho, jogo com performance gráfica alta, ou integração profunda com hardware, um app nativo de verdade continua sendo a escolha certa.

Fechando

PWA não é sobre enganar o usuário fazendo o site parecer um app, é sobre usar dois arquivos, manifest e service worker, pra entregar uma experiência de fato mais próxima de um app: instalável, em tela cheia, funcionando mesmo com conexão instável. O ganho é real pra quem já tem um site funcionando, sem precisar reescrever nada numa tecnologia diferente pra conseguir esse comportamento.