Como o web push funciona e por que vale usar

Web push é o recurso que permite a um site enviar notificações para o navegador de um visitante mesmo quando ele não está com a página aberta. 

Funciona parecido com as notificações de um aplicativo, só que sem app instalado: o usuário autoriza uma vez e passa a receber mensagens push do navegador no computador ou no celular. 

Por trás desse recurso estão três tecnologias do próprio navegador, o Service Worker, a Push API e o protocolo Web Push, todas padronizadas e suportadas por Chrome, Firefox, Edge e, desde 2023, pelo Safari no iOS. 

Este guia explica o que é o canal, como o fluxo funciona por dentro, como pedir permissão sem afastar o visitante e como começar a enviar, inclusive de forma automática via API. 

O que é web push e como esse canal funciona na prática? 

Web push é um canal de mensagens curtas que um site envia ao navegador de quem optou por recebê-las, sem depender de e-mail ou de aplicativo. 

O visitante vê um pedido de permissão, aceita, e a partir daí o navegador guarda uma assinatura que liga aquele dispositivo ao seu site. Quando você dispara uma campanha, a mensagem chega como uma notificação do sistema, com título, texto curto, ícone e um link de destino. 

Diferença entre web push, notificação de app e e-mail marketing 

A grande diferença está na barreira de entrada e no canal de entrega. O web push pede só um clique de permissão, sem cadastro de e-mail nem download de aplicativo. 

A notificação de aplicativo exige que a pessoa baixe e instale o app antes de qualquer mensagem, o que cria uma fila maior de atrito. O e-mail marketing depende do endereço da pessoa e disputa atenção dentro de uma caixa de entrada lotada. 

O web push aparece direto na tela do dispositivo, fora do navegador, o que costuma render mais visibilidade imediata, porém com menos espaço para texto e imagem. 

Quais navegadores e sistemas operacionais suportam web push hoje 

O suporte é amplo no desktop e quase completo no celular. Chrome, Firefox, Edge e Opera entregam web push em Windows, macOS, Linux e Android sem restrição relevante. 

No ecossistema da Apple, o Safari passou a aceitar push para sites adicionados à tela inicial a partir do iOS 16.4, lançado em 2023, e o recurso já existia antes no Safari para macOS. 

Na prática, isso significa que um único site, com a mesma configuração, alcança a maior parte dos visitantes, com uma ressalva específica para o iPhone que será detalhada adiante. 

O que o usuário vê quando recebe uma notificação web push 

O usuário recebe uma notificação do sistema, idêntica em aparência às de qualquer outro app. No desktop, ela surge num canto da tela; no celular, na central de notificações e na tela de bloqueio. 

A mensagem traz um título, uma linha de texto, o ícone do site e, opcionalmente, uma imagem maior. Ao tocar nela, o visitante é levado direto à página que você definiu, como um produto, um artigo ou uma área da conta. Essa ponte direta para uma URL específica é o que torna o canal útil para reengajamento. 

Como funciona o fluxo técnico por trás de uma notificação web push? 

O fluxo une um script no navegador, um servidor de push intermediário e o servidor do seu site, com criptografia ponta a ponta entre eles. 

Quando o visitante aceita, o navegador gera uma assinatura única, chamada de endpoint, e a entrega ao seu site. 

Para enviar, o seu servidor empacota a mensagem, assina com uma chave e a envia ao serviço de push do fabricante do navegador, que faz a entrega final ao dispositivo. 

O papel do Service Worker no envio e recebimento de mensagens 

O Service Worker é o motor invisível do web push. Trata-se de um script que o navegador mantém registrado em segundo plano, capaz de rodar mesmo com a aba do site fechada. 

É ele quem escuta o evento de chegada da mensagem e dispara a notificação na tela. Sem um Service Worker ativo e registrado em HTTPS, o navegador simplesmente não aceita assinaturas de push. 

Toda a documentação de referência do recurso, incluindo a Push API e os eventos do Service Worker, é mantida pela Mozilla no portal MDN e descreve cada etapa desse registro. 

Como funciona o protocolo Web Push e a criptografia ponta a ponta 

O protocolo Web Push é um padrão aberto da IETF que define exatamente como o seu servidor fala com o serviço de push do navegador. Ele padroniza o formato da requisição, os cabeçalhos e a expiração da mensagem. 

O conteúdo viaja cifrado, de modo que nem o serviço intermediário consegue ler o texto da notificação. Apenas o navegador do destinatário, com a chave correta, decifra a mensagem antes de exibi-la. 

Segundo a documentação do web.dev, mantida pela equipe de relações com desenvolvedores do Google, o protocolo Web Push e a autenticação por chaves VAPID asseguram que só quem assinou possa enviar e só o destinatário possa ler. 

O que são as chaves VAPID e por que elas existem 

VAPID é a sigla para identificação voluntária do servidor de aplicação. São um par de chaves, uma pública e uma privada, que identificam o seu site perante o serviço de push. 

A chave pública é entregue ao navegador no momento da assinatura; a privada fica guardada no seu servidor e assina cada envio. Esse mecanismo evita que um terceiro use a sua assinatura para mandar mensagens em seu nome. É a camada de confiança que liga, de forma verificável, o disparo da campanha ao dono do site. 

Como funciona o pedido de permissão para web push e como aumentar a taxa de opt-in? 

A permissão é concedida num prompt nativo do navegador, que só pode ser exibido em resposta a uma ação do visitante. Sem o sim, nenhuma mensagem é enviada. 

A taxa de opt-in, ou seja, a parcela de visitantes que aceita receber, depende muito de como e quando você faz o pedido. Pedir no primeiro segundo da visita, antes de entregar qualquer valor, costuma resultar em recusa. Contextualizar o convite muda esse resultado. 

Quando e como o navegador exibe o prompt nativo de permissão 

O prompt nativo é a caixa do próprio navegador perguntando se o site pode enviar notificações. Ele aparece só uma vez por visitante e a resposta fica registrada. 

Se a pessoa recusar, o navegador bloqueia novos pedidos daquele site, e reverter esse bloqueio exige que ela mexa nas configurações manualmente. Por isso o disparo do prompt nativo é um tiro único: gastá-lo cedo demais, sem contexto, queima a chance de conquistar aquele assinante. 

Estratégia de soft opt-in antes do prompt do navegador 

O soft opt-in é um convite próprio do site, exibido antes do prompt nativo, para medir interesse sem queimar a permissão. É uma faixa ou janela que pergunta se a pessoa quer receber alertas. 

Só quem clica em sim no convite próprio avança para o prompt nativo do navegador. Quem ignora não dispara a caixa oficial, e você pode tentar de novo numa próxima visita. Essa camada intermediária protege o tiro único do prompt nativo e tende a elevar a proporção de aceites reais. 

Boas práticas de copy e contexto para pedir permissão 

O texto do convite precisa deixar claro o que a pessoa ganha ao aceitar. Genéricos como receber notificações convertem pouco. 

Ofertas concretas funcionam melhor, como avisar sobre queda de preço, novos artigos ou status de um pedido. 

O momento também pesa: pedir depois que o visitante demonstrou intenção, como ler um artigo até o fim ou olhar um produto, rende mais aceites do que interromper a chegada. 

Quando o usuário nega, respeite a escolha e invista no soft opt-in numa visita futura, sem insistir de forma agressiva. 

Como começar a enviar web push no meu site sem precisar programar tudo do zero? 

A forma mais rápida é usar uma plataforma de web push pronta, que cuida do Service Worker, das chaves e do painel de envio. Você cola um script no site e passa a disparar campanhas pela interface. 

Para a maioria dos sites, esse caminho elimina a necessidade de escrever código de servidor. A implementação manual com a Push API nativa continua disponível para quem quer controle total, mas exige mais trabalho de desenvolvimento e manutenção. 

Plataformas e ferramentas prontas para web push 

Existem diversas plataformas de web push no mercado, com planos gratuitos para volumes menores e pagos conforme a base cresce. Elas entregam o Service Worker, geram as chaves VAPID e oferecem um painel visual. 

Nesse formato, o trabalho técnico se resume a inserir um trecho de código no site e configurar o ícone e o domínio. Os recursos costumam incluir agendamento, segmentação por comportamento e relatórios de entrega e cliques. A escolha entre uma opção e outra passa por preço por assinante, limites do plano gratuito e disponibilidade de uma API para automação. 

Passo a passo básico de configuração 

O caminho de configuração segue sempre a mesma lógica, independentemente da plataforma escolhida. Os passos centrais são poucos e diretos.  

1. Crie uma conta na plataforma de web push e cadastre o domínio do site. 
2. Insira no site o script fornecido e o arquivo do Service Worker na raiz, sempre em HTTPS. 
3. Configure o convite de permissão, o ícone e a mensagem padrão. 
4. Publique e teste a assinatura no seu próprio navegador. 
5. Crie a primeira campanha pelo painel, defina título, texto e link de destino.  

Depois do primeiro envio funcionando, vale crescer a operação com segmentos e automações simples, separando assinantes por página visitada ou por ação realizada no site. 

Como segmentar assinantes e criar automações simples 

Segmentar é separar a base em grupos para enviar a mensagem certa a cada perfil. Em vez de um disparo único para todos, você fala com quem tem interesse real. 

Os critérios mais comuns são página ou categoria visitada, ação realizada, como abandono de carrinho, e tempo desde a última visita. 

Sobre esses segmentos, automações disparam mensagens por gatilho, sem trabalho manual: um lembrete de carrinho algumas horas depois, um aviso quando um item volta ao estoque. 

É aí que o canal deixa de ser apenas alerta em massa e vira reengajamento orientado por comportamento. 

Como enviar web push de forma programática via API REST? 

O envio programático usa uma API REST da plataforma para disparar notificações direto do seu sistema, sem abrir o painel. Você faz uma requisição HTTP autenticada e a mensagem segue para a base. 

Esse modo é o que conecta o web push a outras partes do seu negócio, como um sistema de pedidos, um estoque ou um fluxo de automação. 

Quando o evento acontece no seu lado, o disparo da notificação é automático. 

Quando faz sentido usar a API em vez do painel da plataforma 

A API compensa quando o disparo precisa nascer de um evento do seu sistema, e não de uma decisão manual. O painel serve para campanhas pontuais; a API serve para escala e tempo real. 

Casos típicos são confirmar um pedido no instante em que ele é pago, avisar sobre uma atualização de status assim que ela ocorre, ou integrar o push a um fluxo de automação que já roda no seu servidor. 

Sempre que a mensagem depender de um dado que só o seu sistema conhece, a integração via API é o caminho. 

Estrutura de uma requisição de envio: endpoint, autenticação e payload 

Uma requisição de envio tem três partes: o endereço da API, a autenticação e o corpo da mensagem. A plataforma documenta cada uma com exemplos prontos. 

O endpoint é a URL para onde você manda a requisição. A autenticação costuma ser uma chave de API enviada num cabeçalho, que prova que o disparo é seu. O payload é o conteúdo em formato estruturado, com título, texto, ícone, link de destino e, quando aplicável, o segmento que deve receber. 

O serviço responde confirmando o recebimento e, em geral, devolve um identificador da campanha para acompanhamento. 

Exemplo prático de integração e onde encontrar documentação de referência 

Na prática, integrar significa, ao detectar um evento no seu sistema, montar a requisição e enviá-la ao endpoint de criação de campanha. A maior parte das plataformas oferece endpoints para listar tópicos, listar países e criar campanhas. 

Como exemplo de referência, a documentação da API do AI Web Push descreve a obtenção da chave de API e os endpoints de criação de campanha de forma direta. 

Com esse material em mãos, um desenvolvedor monta a primeira integração em pouco tempo, reaproveitando a mesma estrutura de endpoint, autenticação e payload para todos os disparos futuros. 

O web push funciona com o navegador fechado ou quando o usuário está offline? 

Sim, o web push funciona com o navegador fechado, porque quem recebe a mensagem é o sistema operacional, não a aba aberta. Já offline, a entrega fica em espera. 

O Service Worker registrado é acordado pelo sistema quando a mensagem chega, exibe a notificação e volta a dormir. Isso acontece mesmo sem o navegador visível na tela, desde que o dispositivo esteja ligado e conectado em algum momento. 

O que acontece com a notificação enquanto o navegador está fechado 

Com o navegador fechado, a notificação ainda chega, porque o serviço de push do sistema opera de forma independente da janela. O sistema operacional acorda o Service Worker só para entregar a mensagem. 

No desktop, isso costuma exigir que o navegador esteja em execução em segundo plano, comportamento comum em Windows e macOS. No celular, o sistema gerencia esse despertar de forma nativa. 

Se o aparelho estiver desligado ou sem conexão, a mensagem aguarda no serviço de push até um prazo de validade definido no envio, e é descartada caso o prazo expire antes da reconexão. 

Comportamento em dispositivos móveis Android vs desktop 

No Android, o web push se comporta como uma notificação de app nativo, integrado ao sistema. A mensagem aparece na central de notificações mesmo com o navegador encerrado. 

No desktop, a entrega depende um pouco mais de o navegador estar ativo em segundo plano, o que é o padrão na maioria das instalações. 

A diferença prática é que o Android tende a ser mais consistente na entrega em segundo plano, enquanto no computador a notificação pode esperar a próxima vez que o navegador rodar, caso ele tenha sido totalmente fechado. 

Limitações no iOS e Safari: o que mudou recentemente 

O iPhone é o caso com regra própria. No iOS, o web push só funciona para sites que o usuário adicionou à tela inicial como web app, não para abas comuns do Safari. 

Esse suporte chegou no iOS 16.4, em 2023, e exige que o pedido de permissão venha de um toque direto do usuário, como apertar um botão de inscrever. 

A Apple documenta o comportamento no blog da equipe do WebKit, que detalha o web push para web apps no iOS e iPadOS e suas exigências. 

Versões mais recentes do iOS evoluíram o recurso, mas a condição de adicionar o site à tela inicial permanece como o ponto de atenção para quem mira o público de iPhone. 

Quais são os melhores casos de uso para web push? 

Os melhores casos de uso são os de tempo sensível, em que a velocidade do alerta gera ação imediata. Carrinho abandonado, queda de preço e conteúdo novo lideram a lista. 

O canal brilha quando a mensagem é curta, oportuna e leva a uma única ação clara. Quando o conteúdo é longo ou exige reflexão, outros canais costumam servir melhor. 

E-commerce: carrinho abandonado, queda de preço e reposição de estoque 

No comércio eletrônico, o web push recupera vendas que escapariam em silêncio. O alerta de carrinho abandonado lembra quem saiu sem comprar e oferece um caminho de volta. 

A queda de preço de um item que a pessoa olhou e o aviso de reposição de estoque de um produto esgotado são gatilhos de alta intenção. 

Como esses eventos dependem de dados do seu sistema, eles se beneficiam do envio via API, que dispara a notificação no instante exato em que a condição acontece. 

Portais de notícias e blogs: alertas de conteúdo novo 

Para portais e blogs, o web push avisa o leitor recorrente assim que sai matéria nova. É um substituto leve do feed por e-mail, com entrega mais rápida. 

O segredo é segmentar por interesse, enviando esporte para quem lê esporte e economia para quem lê economia, em vez de despejar tudo para todos. Assim o alerta mantém relevância e o leitor não trata o canal como ruído. Frequência calibrada é o que separa fidelização de cancelamento. 

SaaS e plataformas: lembretes de ação e alertas de sistema 

Em software como serviço, o web push reduz a fricção de trazer o usuário de volta a uma tarefa pendente. Um lembrete de ação ou um alerta de sistema chega sem depender do e-mail. 

Avisos de relatório pronto, prazo se aproximando ou atividade na conta cabem bem no formato curto da notificação. Por nascerem de eventos internos do produto, esses disparos são quase sempre automáticos, conectados por API ao próprio sistema. 

Quando o web push claramente não é o canal certo 

Há momentos em que o canal atrapalha mais do que ajuda, e reconhecer isso evita desgaste. Mensagens longas, institucionais ou que exigem anexos não cabem numa notificação de uma linha. 

Sites de visita única, sem motivo de retorno, dificilmente sustentam uma base de push ativa. E públicos que reagem mal a interrupções podem cancelar em massa diante de qualquer excesso. Nesses cenários, e-mail ou conteúdo no próprio site entregam o recado sem o custo de irritar quem você quer manter por perto. 

Vale a pena usar web push no meu site ou é mais spam do que resultado? 

Vale a pena quando o seu site tem motivo legítimo de retorno e mensagens de real utilidade para enviar. Sem isso, o canal vira ruído e gera cancelamento. 

O web push tem baixo custo de aquisição do assinante, já que dispensa cadastro de e-mail, e entrega visibilidade alta porque aparece fora do navegador. O risco mora no excesso: a mesma facilidade de envio que ajuda também tenta o disparo em demasia. 

Taxas de opt-in, cliques e retenção que você pode esperar 

A taxa de opt-in do web push costuma ser menor que a de um cadastro de e-mail, porque o aceite é por impulso e não por intenção declarada. 

Em compensação, o volume de assinantes cresce rápido, dado o atrito baixo. 

O clique depende quase inteiramente da relevância e do timing da mensagem. Alertas oportunos, como queda de preço, rendem muito mais do que avisos genéricos. 

A retenção, por sua vez, é frágil: cada notificação irrelevante aproxima o assinante do cancelamento, então a régua de qualidade importa mais aqui do que em canais de saída lenta. 

Riscos reais: cancelamento em massa, bloqueio de navegador e reputação 

O maior risco é o cancelamento em massa provocado por frequência alta ou conteúdo irrelevante. Diferente do e-mail, o descadastro no push é um toque, sem fricção. 

Há ainda o bloqueio no nível do navegador, que é difícil de reverter, e o desgaste de reputação do domínio entre os visitantes, que passam a ignorar qualquer convite. 

Por isso a moderação não é só cortesia, é defesa do próprio canal: queimar a base uma vez deixa pouca margem de volta. 

Perfil de site e audiência em que o canal tende a performar bem 

O web push performa melhor em sites de visita recorrente, com eventos frequentes e relevantes para comunicar. Comércio eletrônico, portais de conteúdo e plataformas de uso contínuo são o terreno fértil. 

Audiências acostumadas a notificações, que valorizam rapidez de informação, aceitam e mantêm a inscrição com mais facilidade. Já públicos avessos a interrupção ou sites de propósito único raramente sustentam uma base ativa, e nesses casos o esforço rende mais em outro canal. 

Web push ou e-mail: qual canal escolher para reengajar visitantes? 

Não é escolha excludente: web push e e-mail resolvem problemas diferentes e funcionam melhor juntos. O push ganha em velocidade e visibilidade; o e-mail, em profundidade e alcance. 

Para um alerta curto e urgente, o push chega na hora e dispensa cadastro. Para uma mensagem rica, com texto longo, imagens e histórico consultável, o e-mail continua superior. 

A tabela abaixo resume as diferenças que mais pesam na decisão. 

Na maioria das operações, o desenho mais sólido usa os dois: push para o gatilho rápido e e-mail para a comunicação que precisa de contexto e permanência. 

Web push vs notificação de aplicativo: qual a diferença real e quando cada um faz sentido? 

A diferença central é a dependência de app instalado. O web push roda no navegador, sem download; a notificação de aplicativo exige que a pessoa instale o app antes. 

Isso muda toda a equação de custo e alcance. 

O web push alcança qualquer visitante com um clique, enquanto a notificação de app só atinge quem se dispôs a baixar e manter o aplicativo no dispositivo. 

Diferenças técnicas de entrega e dependência de app instalado 

Tecnicamente, ambos usam serviços de push do sistema, mas o ponto de partida é distinto. O web push se apoia no Service Worker do navegador e numa assinatura ligada ao site. 

A notificação de app depende do aplicativo instalado e registrado nas lojas, com a notificação amarrada ao ciclo de vida desse app. 

O alcance do web push é mais largo na entrada, porque não há barreira de instalação; o da notificação de app é mais profundo, porque quem instalou já demonstrou compromisso maior. 

Experiência do usuário: como cada formato aparece no dispositivo 

Na tela, os dois formatos se parecem: ambos surgem como notificações do sistema, com ícone, título e texto. A diferença está no que acontece ao tocar. 

O web push abre uma página no navegador; a notificação de app abre uma tela dentro do aplicativo. 

Para quem usa muito o navegador, o push é mais natural; para quem vive dentro de um app específico, a notificação nativa oferece uma experiência mais integrada e recursos mais ricos. 

Custo e complexidade de implementação para o desenvolvedor 

Do lado do desenvolvimento, o web push é bem mais barato e rápido de colocar de pé. Basta um script e um Service Worker num site que já existe. 

Construir e manter um aplicativo, com publicação nas lojas, aprovações e versões para cada sistema, custa muito mais tempo e dinheiro. 

Por isso, para reengajar visitantes de um site, o web push costuma ser o primeiro passo lógico, deixando o app para quando houver uma necessidade de produto que justifique o investimento. 

Quanto custa implementar e usar web push em um site? 

O custo varia de gratuito a uma mensalidade que cresce com o tamanho da base. Plataformas prontas oferecem planos sem custo para volumes iniciais e cobram por faixa de assinantes acima disso. 

Para quem começa, dá para validar o canal sem desembolso, usando o plano gratuito de uma plataforma. O gasto aparece à medida que a base de assinantes e o volume de disparos sobem. 

A implementação própria, com a Push API nativa, troca a mensalidade por custo de desenvolvimento. 

Você não paga por assinante, mas assume o trabalho de construir e manter o Service Worker, a gestão de chaves VAPID, o armazenamento das assinaturas e a infraestrutura de envio. 

Para a maioria dos sites, a plataforma pronta sai mais barata no total, porque concentra esse esforço técnico num custo previsível. 

A rota nativa compensa em operações grandes, com equipe própria e volume alto o suficiente para que a mensalidade por assinante supere o custo de manter a estrutura. 

Quais são as boas práticas de web push para não irritar o assinante e manter a base engajada? 

A regra de ouro é enviar menos e melhor: cada notificação precisa ter utilidade clara para quem recebe. Frequência alta e mensagem genérica são o caminho mais curto para o cancelamento. 

Quem trata a base com respeito preserva o canal por muito mais tempo. As práticas a seguir reúnem o que sustenta uma lista de assinantes saudável. 

Frequência de envio e horários com melhor desempenho 

A frequência precisa caber na expectativa do assinante, sem soterrar a tela de avisos. Para a maioria dos sites, poucos envios bem escolhidos por semana rendem mais que disparos diários. 

O horário também influencia a resposta. 

Mensagens enviadas quando o público costuma estar ativo, como início da manhã ou começo da noite no Brasil, tendem a ter mais cliques do que as de madrugada. 

O melhor ritmo se descobre testando e observando os cancelamentos a cada envio. 

Como escrever título e corpo da notificação que geram clique 

O título tem poucos caracteres para conquistar a atenção, então precisa ser direto e específico. Prometa algo concreto, como o nome do produto que baixou de preço. 

O corpo complementa com a informação que falta para a pessoa decidir tocar, sem repetir o título. Evite promessa vazia e curiosidade enganosa: a notificação que entrega menos do que sugere ensina o assinante a ignorar as próximas. Clareza sobre o destino do clique sustenta a confiança no canal. 

Segmentação e personalização para reduzir cancelamento 

Segmentar é a defesa mais forte contra o cancelamento, porque garante que cada mensagem fale com quem tem interesse. Enviar tudo para todos é o erro mais comum e mais caro. 

Separe a base por comportamento, interesse e estágio na jornada, e ajuste o conteúdo a cada grupo. Personalizar pelo que a pessoa viu ou fez no site eleva a relevância e baixa a sensação de ruído. Quanto mais a notificação parecer feita para aquele assinante, menor a chance de ele desligar o canal. 

Como monitorar métricas e identificar sinais de fadiga na base 

Acompanhar números é o que transforma envio em aprendizado. As métricas centrais são taxa de aceite, cliques por campanha e, sobretudo, cancelamentos. 

Um salto de descadastros após um envio é o sinal mais claro de fadiga: indica frequência alta ou conteúdo fora do interesse. Queda gradual de cliques ao longo do tempo aponta desgaste mais lento. 

Lendo esses indicadores a cada disparo, dá para corrigir a rota antes de queimar a base, reduzindo frequência ou apertando a segmentação quando os sinais acendem. 

Perguntas frequentes sobre web push 

Reunimos as dúvidas mais comuns sobre web push, com respostas diretas para quem está pensando em adotar o canal de notificações do navegador no próprio site. 

O que é web push? 

Web push é o recurso que permite a um site enviar notificações ao navegador de um visitante que autorizou recebê-las, mesmo com a página fechada. Funciona sem app instalado e sem cadastro de e-mail, usando o Service Worker e a Push API do próprio navegador. 

Como funciona o web push no navegador? 

O visitante aceita um pedido de permissão e o navegador cria uma assinatura única do dispositivo. 

Para enviar, o seu servidor manda a mensagem cifrada ao serviço de push do navegador, que a entrega ao Service Worker, responsável por exibir a notificação na tela. 

Qual a diferença entre web push e notificação de aplicativo? 

O web push roda no navegador e dispensa download, alcançando qualquer visitante com um clique de permissão. A notificação de aplicativo exige que a pessoa instale o app antes. O push tem alcance mais largo na entrada; o app, vínculo mais profundo com quem já instalou. 

O web push funciona com o navegador fechado? 

Sim. A mensagem é entregue pelo sistema operacional, que acorda o Service Worker para exibir a notificação mesmo com a aba ou o navegador fechado. Se o dispositivo estiver offline, a mensagem aguarda no serviço de push até o prazo de validade definido no envio. 

Como começar a enviar web push em um site? 

O caminho mais rápido é usar uma plataforma de web push, inserir o script no site em HTTPS, configurar o convite de permissão e disparar a primeira campanha pelo painel. 

Para escala e tempo real, a mesma plataforma costuma oferecer uma API REST para envio automático.