A landing page que converte não precisa de JavaScript para enviar o formulário
Formulário que só funciona depois que um script carrega perde lead em conexão ruim, em navegador antigo e no indexador. E dá para não ser assim.
É uma decisão de arquitetura com consequências comerciais diretas, e ela costuma ser tomada sem que ninguém do lado do negócio saiba que existe.
O que custa um formulário que depende de script
Quem tem conexão ruim vê um retângulo em branco no lugar do campo, pelo tempo que o script levar. Numa página de anúncio pago, esse tempo é dinheiro já gasto.
O indexador não vê o formulário. Não é só sobre ranquear: o buscador não entende do que a página trata quando o miolo dela chega depois.
Bloqueador de script derruba a conversão inteira. O visitante enxerga a página e não consegue enviar nada, sem nenhuma mensagem de erro.
Um erro de JavaScript em qualquer ponto leva o formulário junto. Com HTML, uma parte quebrada não impede o resto de funcionar.
A alternativa tem trinta anos
Um <form> com action e method, <label> associado a cada <input>, e required nos campos obrigatórios. O navegador envia, valida o que falta e mostra a mensagem — sem uma linha de script.
O servidor recebe o envio, grava o lead e devolve a pessoa para a mesma página com uma marca na URL. A mensagem de agradecimento já está no HTML, escondida, e aparece por CSS. Não há nada para carregar.
O nome do campo faz o trabalho
Quando o name de cada campo é o destino dele no lead — nome, email, telefone — o preenchimento automático do navegador funciona de graça, e é ele que faz um formulário de cinco campos ser respondido no celular. Nomes como field_7 desligam esse recurso sem que ninguém perceba.
Então o JavaScript não serve para nada?
Serve, e é aqui que está o ponto: ele deve melhorar o que já funciona, nunca ser a condição para funcionar. A ordem certa é construir a página que envia sem script e depois acrescentar as camadas.
Envio sem recarregar a página, com o retorno aparecendo no lugar.
Os parâmetros de campanha viajando junto com o lead, para a atribuição fechar.
Os eventos de conversão indo para o Google Analytics no momento certo — quando o formulário entra na tela, quando alguém começa a preencher, quando envia.
Se qualquer uma dessas camadas falhar, o formulário continua enviando. É a diferença entre uma melhoria e uma dependência.
O peso da página é o segundo argumento
Uma landing page não tem estado nem navegação interna: ela mostra um texto e recebe um envio. Servir um framework de interface para isso significa que o visitante baixa o motor, baixa o conteúdo empacotado dentro do script, e a página só se desenha depois de os dois chegarem.
Servida como documento — HTML de verdade, uma folha de estilo e um script pequeno e opcional —, ela pinta na primeira leitura. Em anúncio pago, onde uma fração dos cliques desiste antes de a página aparecer, essa diferença é medida em leads.
Como conferir a sua
Abra a página publicada e peça para ver o código-fonte (não o inspetor: o código-fonte, que é o que o servidor mandou).
Procure pelo texto do seu título e pelos campos do formulário. Se não estiverem ali, eles chegam depois.
Desligue o JavaScript no navegador e recarregue. O formulário ainda envia?
Como o uleadflow publica
A landing page publicada é um documento: <!doctype html>, o conteúdo dentro do <main>, um <form> que envia sem script, e dados estruturados para o buscador. O único arquivo de JavaScript tem cerca de 2 KB e tudo nele é melhoria — o envio sem recarregar, a contagem regressiva andando e os eventos no Analytics.