PWA (Progressive Web App) é uma aplicação web que combina service worker, Web App Manifest e HTTPS para entregar experiência de aplicativo: instalação na tela inicial, funcionamento offline e notificações push, tudo a partir da mesma URL, sem passar por loja de aplicativos.
Guarde essa frase. Ela resolve 90% das discussões de reunião sobre o assunto.
Agora o cenário real. A diretoria pediu “uma experiência mais de app” no mobile. Você olha para a fila de desenvolvimento interno, para o orçamento e para o prazo, e percebe que abrir uma frente nativa significa mais seis meses e uma stack paralela para manter. O PWA existe justamente para não te obrigar a esse caminho: ele adiciona capacidades de app sobre o site que você já tem no ar.
Neste guia eu vou direto ao mecanismo: o que roda por baixo, quais critérios o navegador exige, como implementar no WordPress e em quais casos eu simplesmente não recomendo.
Um PWA não é um app nativo disfarçado. Também não é site responsivo com ícone bonito. É uma camada de tecnologias padronizadas do navegador que transforma uma aplicação web comum em algo instalável e resiliente a falhas de rede.
Três peças sustentam isso:
Service worker: um script JavaScript que roda em segundo plano, fora da thread principal, intercepta requisições de rede e controla o cache local. É o que permite carregamento instantâneo em visitas recorrentes, funcionamento offline e recebimento de push.
Web App Manifest: um arquivo JSON que declara nome, ícones em múltiplas resoluções, cor de tema, URL de início e modo de exibição. Sem ele, o navegador não oferece a opção de instalar o site na tela inicial.
HTTPS: contexto seguro obrigatório em toda a origem. Service worker não registra em conexão não criptografada (exceto localhost, para desenvolvimento).
A referência canônica está na documentação de PWA do web.dev e no verbete de Progressive Web Apps na MDN. Se alguém do seu time for implementar, é de lá que sai a especificação atualizada.
O termo foi cunhado em 2015 por Alex Russell, engenheiro do Google, para descrever sites que ganham capacidades de app de forma progressiva, conforme o navegador do usuário suporta. A palavra-chave ali é progressiva: quem está num navegador antigo continua vendo o site funcionar, só não recebe as camadas extras.
A adoção veio por um motivo aritmético. Segundo o Statcounter Global Stats, dispositivos móveis respondem pela maior fatia do tráfego web mundial, à frente de desktop. No Brasil, a concentração em mobile é ainda mais acentuada.
Ou seja: a experiência mobile não é um recorte do seu público. É o seu público.
Os casos públicos ajudam a dimensionar. Pinterest, Twitter Lite e Starbucks reconstruíram suas experiências mobile como PWA e reportaram ganhos de engajamento e de conversão, conforme os estudos de caso publicados no web.dev. O denominador comum desses projetos é interface leve que carrega rápido em rede instável.
Para quem gerencia marketing, o argumento é de fricção. Não há download de centenas de megabytes, não há espera por aprovação de loja, não há release travado numa fila de review. O usuário chega pela URL indexável e, se quiser, instala em um toque.
Entender o papel de cada componente é o que te permite estimar esforço e cobrar prazo com precisão.
Pense num prédio com um porteiro que guarda cópias das encomendas mais pedidas. Quando alguém pede algo que ele já tem na guarita, entrega na hora. Só quando não tem é que ele sobe até o apartamento.
É exatamente isso que o service worker faz. Ele é um proxy programável entre a página e a rede. No primeiro acesso, armazena em cache os recursos essenciais (HTML de shell, CSS, JavaScript crítico, fontes e ícones). Nas visitas seguintes, decide o que serve do cache e o que busca na rede.
Essa decisão segue estratégias declaradas por você: cache-first para assets versionados, network-first para conteúdo que muda, stale-while-revalidate para o meio-termo. Particularmente, eu prefiro stale-while-revalidate em páginas de blog e listagens: o usuário vê algo imediatamente e o conteúdo atualiza em segundo plano.
O service worker também é quem recebe e exibe push notifications, inclusive com a aba fechada.
O manifest (normalmente manifest.json) é a carteira de identidade do PWA. Nele você declara nome curto, nome completo, ícones de 192×192 e 512×512 pixels, cor de tema, cor de fundo, start_url e display.
É esse arquivo que transforma uma aba do navegador em ícone na tela inicial, com splash screen e barra de status na sua cor de marca. Se você quiser descer ao detalhe de cada propriedade, temos um material dedicado sobre Web App Manifest.
Um service worker consegue interceptar todas as requisições de uma origem. Liberar esse poder em conexão aberta seria entregar a chave de casa para ataques man-in-the-middle.
Por isso o navegador só registra service worker em contexto seguro. Sem certificado SSL válido e sem conteúdo misto na página, não existe PWA. Simples assim.
O Chrome não exibe o prompt de instalação por gentileza. Ele checa uma lista objetiva, documentada nos critérios de instalabilidade do web.dev, e você audita tudo no relatório do Lighthouse dentro do DevTools.
Origem servida integralmente via HTTPS, com certificado válido e sem conteúdo misto inseguro carregado por HTTP.
Service worker registrado com manipulador de evento fetch funcional, capaz de responder alguma coisa quando o usuário está offline (nem que seja uma página de fallback).
Web App Manifest válido e linkado no HTML, com nome, ícones de 192×192 e 512×512 pixels, start_url resolvível e display em standalone ou fullscreen.
Sinal mínimo de engajamento do usuário na origem, critério que o navegador usa para não empurrar prompt de instalação para quem acabou de chegar.
Atender à lista garante o convite de instalação. Não garante experiência boa. Isso depende de como o cache foi desenhado.
Existem dois caminhos, e a escolha é de arquitetura, não de gosto.
Para sites de conteúdo com estrutura previsível, plugin resolve:
PWA (feature plugin mantido por contribuidores do core): gera o manifest e registra um service worker básico, servindo de fundação para você estender via código no tema.
Super PWA: configura manifest, ícones, splash screen e página offline personalizada com poucos cliques, indicado para times de marketing sem apoio de desenvolvimento dedicado.
PWA for WP: entrega controle mais granular sobre estratégias de cache e prompts de instalação, para quem quer ajuste fino sem escrever service worker do zero.
A implementação custom faz sentido quando o site tem requisitos próprios de cache, integração com APIs internas ou necessidade de definir exatamente quais rotas respondem offline. Nesse cenário, o service worker é escrito à mão e versionado junto ao tema, entrando no mesmo fluxo de deploy do restante do código.
Um alerta que eu repito em toda reunião de kickoff: monitore o impacto nos Core Web Vitals depois de publicar. Um PWA bem configurado melhora o LCP em visitas recorrentes, porque os recursos vêm do cache local em vez da rede. Um service worker mal escrito faz o contrário: serve HTML velho, compete por processamento e degrada o INP.
Publique, meça no PageSpeed Insights, confirme no relatório de dados de campo do Search Console. Nessa ordem.
Nem todo site precisa disso, e eu prefiro dizer isso antes de você aprovar orçamento.
Site institucional pequeno, com poucas páginas e baixa recorrência de visita, dificilmente justifica o custo de manter um service worker vivo. Você adiciona uma camada de complexidade permanente para atender um usuário que volta uma vez por trimestre.
Loja WooCommerce com checkout complexo pede cautela redobrada. Cache agressivo em carrinho, cálculo de frete e páginas de pagamento gera inconsistência de estado, e inconsistência em checkout custa receita. Nesses projetos, o caminho é excluir rotas transacionais do cache e tratar performance no WordPress na base antes de sobrepor a camada PWA.
Regra prática que eu uso: se o TTFB está ruim e o site não passa nos Core Web Vitals sem cache de navegador, PWA vira maquiagem. Arruma a fundação primeiro.
A decisão entre as três abordagens passa por orçamento, acesso a hardware do dispositivo e estratégia de distribuição.
Critério | Site responsivo | PWA | App nativo |
|---|---|---|---|
Distribuição | URL única indexável | URL única indexável e instalável na tela inicial | App Store e Play Store, com revisão obrigatória |
Publicação de atualização | Imediata, no deploy | Imediata, no próximo ciclo do service worker | Sujeita ao review das lojas, tipicamente dias |
Funcionamento offline | Não | Sim, com escopo definido pelo cache do service worker | Sim, nativo |
Base de código | Uma (web) | Uma (web), com manifest e service worker | Uma por plataforma, ou framework híbrido |
Note que o PWA acumula a vantagem de SEO do site responsivo (conteúdo indexável, uma URL) com parte das capacidades do nativo. O que ele não entrega é acesso profundo a hardware e recursos de sistema, que continuam sendo território do app nativo.
Sim, com ressalvas. O Safari suporta instalação na tela inicial e service worker, mas o suporte a alguns recursos, notadamente notificações push, historicamente ficou atrás do Android e depende da versão do sistema. Antes de prometer push para toda a base, valide o comportamento nas versões de iOS que aparecem no seu analytics.
Não, quando bem implementado. O PWA continua sendo um site com URLs indexáveis, o que é justamente a diferença em relação a um app nativo. O risco real está no cache: se o service worker servir versões antigas de conteúdo, você cria divergência entre o que o usuário vê e o que o rastreador lê. Versione o cache a cada deploy.
Depende do que o produto exige do dispositivo. Se a operação precisa de sensores, integrações profundas com sistema operacional ou presença obrigatória nas lojas por questão de canal, o nativo continua necessário. Para conteúdo, portais, intranets e catálogos, o PWA costuma cobrir o caso de uso com uma fração do custo de manutenção.
O custo não está na implementação inicial, está na manutenção do service worker. Cada mudança relevante de arquitetura, rota ou asset crítico exige revisar estratégia de cache e invalidação. Trate isso como item recorrente de backlog técnico, não como entrega única.
PWA é engenharia de entrega, não enfeite de interface. Service worker controlando cache, manifest declarando identidade, HTTPS garantindo contexto seguro. Com essas três peças no lugar, o site que você já mantém passa a se comportar como app para quem volta.
O que separa um bom PWA de um problema em produção é a disciplina de cache e a medição contínua dos Core Web Vitals depois do lançamento. Aqui na Apiki, nossa equipe trata essa camada dentro da rotina de manutenção do WordPress, junto com performance e deploy, porque service worker mal versionado vira chamado de suporte na segunda-feira.
Se você está avaliando se faz sentido no seu projeto, vale começar por um diagnóstico honesto da operação atual: fale com nosso time sobre uma avaliação de WP Care e a gente olha a fundação antes da camada extra.
E você, já testou o comportamento offline do seu site no Lighthouse?
Marcelo Alexandre 
Leandro Vieira Pinho 
Edison Leandro Vieira Pinho 
