PWA (Progressive Web App) é uma aplicação web que usa service workers, Web App Manifest e HTTPS para entregar uma experiência equivalente à de um aplicativo nativo: funciona offline, é instalável na tela inicial e envia notificações push, sem depender de app store.
Se você gerencia conteúdo e campanhas em um site WordPress corporativo, conhece bem o impasse. A diretoria pede uma experiência mobile próxima de app, mas você não quer abrir um chamado interminável com a equipe de desenvolvimento mobile nem criar uma stack paralela só para isso. É exatamente nesse ponto que o PWA entra: ele aproveita o site que você já tem e adiciona capacidades de app sobre a mesma base de código.
Neste guia, vamos explicar o mecanismo por trás de um PWA, os critérios técnicos para que ele seja instalável, como implementar no WordPress e em quais cenários ele não compensa. O objetivo é dar a você argumentos técnicos para decidir, e não apenas mais um texto motivacional sobre experiência do usuário.

O que é PWA (Progressive Web App)?
Um PWA é a web operando com capacidades de app. Não é um aplicativo nativo disfarçado, e também não é só um site responsivo bonito. É uma camada de tecnologias padronizadas que transforma um site comum em algo instalável e resiliente a falhas de rede.
Toda essa experiência se apoia em três pilares técnicos:
- Service worker: um script JavaScript que roda em segundo plano no navegador, controla o cache de recursos e intercepta requisições de rede, permitindo funcionamento offline e notificações push.
- Web App Manifest: um arquivo JSON que descreve nome, ícones, cor de tema e modo de exibição do app, tornando o site instalável na tela inicial com ícone próprio e tela de abertura.
- HTTPS: conexão criptografada obrigatória, porque service workers só funcionam em contexto seguro por questões de integridade e segurança.
Você encontra a referência completa na documentação oficial do Google sobre PWA e em Progressive Web Apps na MDN, que mantêm os padrões atualizados.
Por que PWA virou padrão em projetos mobile-first?
O termo Progressive Web App foi cunhado em 2015 pelo engenheiro Alex Russell, do Google, para descrever sites que progressivamente ganham capacidades de app conforme o navegador suporta. A ideia ganhou tração por um motivo simples: o tráfego mobile domina.
Segundo dados do Statcounter, dispositivos móveis respondem pela maior parte do tráfego web global, à frente de desktop. Em mercados como o Brasil, essa concentração é ainda mais alta.
Os cases públicos ajudam a entender o apelo. O Pinterest reconstruiu sua experiência mobile como PWA e relatou aumento expressivo no engajamento e na receita gerada por anúncios, conforme documentado nos estudos de caso publicados pelo Google. O Twitter Lite e o Starbucks seguiram caminho parecido, entregando interfaces leves que carregam rápido mesmo em redes instáveis.
Para quem gerencia marketing, o ponto central é este: um PWA reduz a fricção entre encontrar o conteúdo e usá-lo. Não há download de centenas de megabytes nem espera por aprovação na loja. O usuário acessa pela URL e, se quiser, instala em um toque.
Como um PWA funciona tecnicamente?
A mágica do PWA está em três componentes trabalhando juntos. Entender o papel de cada um ajuda a dimensionar o esforço de implementação.
Qual o papel do service worker?
O service worker é o coração do PWA. Ele é um proxy programável que fica entre a página e a rede. Quando o usuário acessa o site pela primeira vez, o service worker armazena em cache os recursos essenciais (HTML, CSS, JavaScript, fontes e imagens críticas).
Nas visitas seguintes, ele decide o que servir do cache e o que buscar na rede, seguindo estratégias como cache-first ou network-first. É isso que permite carregamento instantâneo e funcionamento offline. O service worker também recebe e exibe notificações push, mesmo quando a aba está fechada.
Qual o papel do Web App Manifest?
O Web App Manifest é um arquivo JSON (geralmente manifest.json) que diz ao navegador como o site deve se comportar quando instalado. Nele você define o nome do app, os ícones em diferentes resoluções, a cor da barra de status, a tela de abertura e o modo de exibição (tela cheia ou com barra do navegador).
Sem um manifest válido, o navegador não oferece a opção de instalação. É ele que transforma a aba em um ícone na tela inicial do celular.
Por que o HTTPS é obrigatório?
Service workers têm poder para interceptar todas as requisições de uma origem. Permitir isso em conexões não criptografadas abriria brecha para ataques do tipo man-in-the-middle. Por isso, o navegador só registra um service worker em páginas servidas via HTTPS (a exceção é localhost para desenvolvimento). Sem certificado SSL ativo, não existe PWA.
Quais são os critérios para um site ser considerado PWA instalável?
O Chrome usa um conjunto definido de requisitos para exibir o prompt de instalação. Você pode auditar todos eles no relatório PWA do Lighthouse, integrado ao DevTools. Os critérios de instalabilidade do Chrome incluem:
- Servir o site via HTTPS em toda a origem, com certificado SSL válido e sem conteúdo misto inseguro.
- Registrar um service worker com um manipulador de evento
fetchfuncional, capaz de responder quando offline. - Disponibilizar um Web App Manifest válido com nome, ícone de pelo menos 192×192 e 512×512 pixels, URL de início e modo de exibição definido como standalone ou fullscreen.
- Ter sido acessado pelo usuário com um mínimo de engajamento, critério que o Chrome usa para evitar prompts intrusivos.
Atender a esses critérios garante que o navegador ofereça a instalação. A qualidade da experiência, no entanto, depende de quão bem o cache e as estratégias de rede foram configurados.
Como implementar PWA no WordPress?
Há dois caminhos para transformar um site WordPress em PWA: usar um plugin ou desenvolver uma implementação custom. A escolha depende da complexidade do projeto.
Para a maioria dos sites de conteúdo, os plugins resolvem bem:
- PWA (plugin oficial do feature project): mantido por contribuidores do core, gera o manifest e registra um service worker básico, servindo de fundação para customizações.
- Super PWA: configura manifest, ícones e service worker em poucos cliques, com suporte a página offline personalizada e notificações.
- PWA for WP: oferece controle granular sobre estratégias de cache, telas de abertura e prompts de instalação, indicado para quem quer ajuste fino sem código.
A implementação custom faz sentido quando o site tem requisitos específicos de cache, integração com APIs internas ou necessidade de controlar exatamente quais rotas funcionam offline. Aqui você escreve o service worker manualmente e versiona o manifest junto ao tema.
Atenção ao impacto nos Core Web Vitals. Um PWA bem configurado melhora o LCP em visitas recorrentes, porque os recursos vêm do cache. Mas um service worker mal escrito pode servir conteúdo desatualizado ou competir por recursos e prejudicar o INP. Monitore essas métricas no PageSpeed Insights e no Search Console depois de publicar.
Nem sempre o PWA compensa. Sites institucionais simples, com poucas páginas e baixa recorrência de visita, raramente justificam o esforço de manutenção do service worker. Lojas WooCommerce com checkout complexo também exigem cuidado: cache agressivo em páginas de carrinho e pagamento pode gerar inconsistências. Nesses casos, vale priorizar a performance no WordPress de base antes de adicionar a camada PWA.
PWA, site responsivo ou app nativo: qual escolher?
A decisão entre as três abordagens depende do orçamento, da necessidade de acesso a hardware e da estratégia de distribuição. A tabela abaixo resume os critérios práticos.
| Critério | Site responsivo | PWA | App nativo |
|---|---|---|---|
| Distribuição | URL única indexável | URL única indexável + instalável | App Store / Play Store (revisão obrigatória) |
| Tempo médio de atualização | Instantâneo (deploy) | Instantâneo (service worker) | 1 a 7 dias (review das lojas) |
| Funcionamento offline | Não | Sim (cache configurável via service worker) | Sim (nativo) |
| Push notifications | Não | Sim (Android/desktop; iOS 16.4+) | Sim (todas plataformas) |
| Acesso a hardware (câmera, GPS, sensores) | Limitado | Parcial (Web APIs) | Total (SDK nativo) |
| Custo médio de desenvolvimento | Base | +15% a 30% sobre o site | 2x a 4x o custo do site (iOS + Android) |
| Indexável pelo Google | Sim | Sim | Não (apenas via app indexing) |
Para a maioria dos projetos de conteúdo e serviços, o PWA é o ponto de equilíbrio: aproveita a indexação e o custo do site, adiciona instalabilidade e offline, e evita a fila das lojas de aplicativos.
Perguntas frequentes sobre PWA
PWA funciona no iOS?
Sim. O Safari suporta PWA no iOS, incluindo instalação na tela inicial. As notificações push para PWA passaram a funcionar a partir do iOS 16.4, lançado em 2023. Houve um episódio em 2024 em que a Apple sinalizou a remoção do suporte na Europa, mas a decisão foi revertida e os PWAs seguem funcionando no iOS.
PWA substitui aplicativo nativo?
Depende do que o app precisa fazer. Para conteúdo, notícias, catálogos e serviços baseados em web, o PWA substitui com folga e custo menor. Para apps que dependem intensamente de hardware (sensores avançados, câmera com processamento pesado, Bluetooth de baixo nível) ou de recursos exclusivos das lojas, o nativo ainda leva vantagem.
Qual o impacto de PWA no SEO?
Positivo na maioria dos casos. Um PWA mantém URLs únicas e indexáveis, e o ganho de velocidade em visitas recorrentes contribui para sinais de experiência da página. O importante é garantir que o service worker não bloqueie o Googlebot e que o conteúdo seja renderizado corretamente.
PWA melhora os Core Web Vitals?
Pode melhorar, especialmente o LCP em visitas recorrentes, porque os recursos cacheados carregam do dispositivo. Mas não é automático. Um service worker mal configurado pode degradar o INP ou servir conteúdo antigo. Medir antes e depois com o PageSpeed Insights é essencial.
Quanto custa transformar um site WordPress em PWA?
Com plugins como Super PWA ou PWA for WP, o custo direto pode ser próximo de zero em licença e algumas horas de configuração e testes. Implementações custom, com estratégias de cache sob medida e integrações, somam de 15% a 30% sobre o custo de desenvolvimento do site, conforme a complexidade.
PWA precisa estar nas app stores?
Não. A instalação acontece direto pelo navegador, sem passar por App Store ou Play Store. Se você quiser presença nas lojas mesmo assim, é possível empacotar o PWA com tecnologias como Trusted Web Activity (Android), mas isso é opcional.
O service worker prejudica a indexação no Google?
Não, quando bem configurado. O Googlebot renderiza páginas sem registrar o service worker para a primeira indexação, então o conteúdo precisa estar disponível na resposta inicial do servidor. O problema só aparece se o site depender do service worker para exibir conteúdo essencial.
Conclusão
Um PWA permite entregar experiência próxima de app nativo sem abrir um projeto mobile do zero. Com service worker, Web App Manifest e HTTPS, você transforma o site WordPress que já tem em algo instalável, rápido e resiliente a falhas de rede, mantendo a indexação e o custo de uma única base de código.
O ponto de atenção é que PWA não é configurar plugin e esquecer. Service worker mal escrito quebra cache, prejudica Core Web Vitals e pode servir conteúdo desatualizado. É uma camada que precisa de manutenção e monitoramento contínuos, exatamente o tipo de evolução técnica que acompanhamos no WP Care, nosso serviço de manutenção e cuidado contínuo de sites WordPress. Se você quer adicionar capacidades de PWA sem sobrecarregar o time interno, fale com a nossa equipe.