Landing page mobile-first: o checklist completo para 2026

Em 2026, em Portugal, 75-85% do tráfego de landing pages chega de telemóvel — mais em B2C, um pouco menos em B2B. O design "mobile-first" é tecnicamente lugar-comum há uma década e continua, na prática, esquecido: páginas com fontes de 13px, botões com 32px de altura, formulários de 9 campos a obrigar a abrir teclado em scroll, e LCP de 3,2s em 4G. Cada uma destas falhas custa 10-25% de conversão. Combinadas, transformam tráfego de 1€/clique em CPL de 60€.

Este é o checklist. Não é teoria. São itens binários — passas ou não passas. Aplica-os antes de ligar a campanha.

1. Velocidade — LCP <1,5s em telemóvel 4G

A métrica mãe. Se falhas aqui, o resto importa menos.

• LCP < 1,5s em telemóvel via PageSpeed Insights (campo "Mobile").
• TBT < 200ms, CLS < 0,1.
• Imagem do hero pré-carregada (<link rel="preload" as="image" fetchpriority="high">).
• Imagens em WebP/AVIF, com srcset e dimensões corretas.
• Fontes locais (não Google Fonts externos), font-display: swap.
• CSS crítico inline, resto adiado.
• Sem builders pesados (Elementor, Divi, WPBakery) — JS bundle <100 KB compressed.
• Scripts de tracking (GTM, Pixel, chat) gated por consentimento e não bloqueantes.

Como o LCP funciona em detalhe. E como a Page Experience do Google tudo isto integra.

2. Tap targets — 48x48 px de alvo mínimo

WCAG e Google Material recomendam 48x48 px como alvo mínimo de toque. Em 2026 ainda há landings com botões de 36 px que falham no polegar adulto.

• Botões com 48 px de altura mínima, padding generoso.
• Links inline em parágrafos com espaçamento entre linhas ≥ 1,5 — para não falhar no toque.
• Espaço entre tap targets ≥ 8 px — 16 px ideal.
• CTA primário ocupa pelo menos 80% da largura útil em telemóvel.

Se o teu CTA tem 200 px de largura ao centro num ecrã de 375 px, o dedo bate em vazio nas zonas mortas. Largo, alto, óbvio.

3. Tipografia — 16 px mínimo, hierarquia clara

• Corpo de texto ≥ 16 px — abaixo disto, iOS faz zoom automático em inputs (mau UX) e leitura torna-se cansativa.
• Headline 28-40 px em telemóvel — se está a 22 px, parece subheadline.
• Linha de texto ≤ 75 caracteres — em telemóvel, ~35-40 caracteres por linha.
• Espaçamento de linha (line-height) ≥ 1,5 para corpo.
• Contraste ≥ 4,5:1 texto/fundo (WCAG AA).

Tipos clássicos do erro: texto branco sobre imagem de hero sem overlay — ilegível em 50% das fotos. Solução: overlay escuro 30-50% sob o texto, ou caixa de texto com fundo opaco.

4. Hero em mobile — o que cabe num ecrã

Em telemóvel típico (iPhone 14: 390x844, com barras: ~600 px úteis):

• Headline + subheadline + CTA primário cabem sem scroll.
• Logo no canto superior (40-50 px de altura), não a ocupar 1/4 do ecrã.
• Visual abaixo ou em background com overlay — não competindo com a headline.
• Menu hamburger no canto direito ou ausente em landing dedicada.
• Sem carrossel de slides no hero — divide intenção, nunca chega ao slide 3.

Testa no iPhone SE (375x667). Passa lá, passa em tudo.

5. Sticky CTA — quando aparece

O sticky CTA é o botão fixo no fundo do ecrã que segue o scroll. Aumenta conversão em mobile em 15-30% quando bem implementado.

• Aparece quando o utilizador faz scroll abaixo do hero (não desde o início — competiria com o CTA do hero).
• Desaparece quando o utilizador chega ao formulário ou CTA final.
• Altura 56-64 px, fixo no bottom: 0.
• Botão único, mesmo texto do CTA principal.
• Acima do banner de cookies em z-index, ou esconde quando o banner aparece.
• Respeita safe-area-inset-bottom em iOS (evita ficar tapado pela home bar).

Implementação em CSS é trivial (position: fixed; bottom: 0). O cuidado está em quando aparece e desaparece — IntersectionObserver para detetar o hero e o formulário.

6. Formulários mobile — o checklist anti-fricção

Formulário em mobile é onde a maioria das landings PT morre. Cada campo a mais corta 5-10% de conversão.

• Campos verticais, um por linha — nunca dois lado a lado.
• Labels visíveis sempre — placeholder não substitui label (acessibilidade + UX).
• Tipos de input corretos — type="email" (teclado @), type="tel" (teclado numérico), type="number" (teclado numérico), type="date" (date picker nativo).
• inputmode="numeric" para campos numéricos não-tel.
• autocomplete correto — autocomplete="name", email, tel, street-address — usa o preenchimento automático do iOS/Android.
• Validação em tempo real — mostra erro quando o utilizador sai do campo, não só ao submeter.
• Mínimo de campos — 3-5 ideal, 7 máximo.
• Botão de submit em destaque, abaixo, ocupando largura total.
• Sem CAPTCHA visível — usa invisible reCAPTCHA, Cloudflare Turnstile ou honeypot.

Mais sobre formulários que convertem, em PT.

7. Imagens — formato, peso, lazy load

• WebP/AVIF com fallback JPEG para Safari antigo (cada vez menos necessário).
• Dimensões corretas — não servir 2000 px para um slot de 400 px.
• srcset + sizes para responsive.
• loading="lazy" em tudo abaixo da dobra.
• alt descritivo em todas as imagens informativas (acessibilidade + SEO).
• decoding="async" para imagens não críticas.
• Hero image pré-carregada com fetchpriority="high".

Páginas com 30 imagens otimizadas pesam menos que páginas com 6 imagens descontroladas.

8. Vídeo em mobile — o que muda

• Sem autoplay com som — bloqueado nativamente, hostil quando passa.
• Poster image leve (<100 KB) que carrega antes do vídeo.
• preload="metadata" ou none — não carrega o vídeo completo até ao play.
• playsinline — para autoplay silenciado em iOS.
• Legendas em PT-PT via WebVTT.
• Não é o LCP — sempre abaixo do hero.

9. Touch gestures — o que não inventar

• Sem swipe horizontal obrigatório (carrosséis) para informação crítica.
• Sem long press para ações importantes.
• Sem pinch-to-zoom desativado (maximum-scale=1 é um erro de acessibilidade).
• Scroll vertical natural, sem interceções de JS que quebram o "momentum scroll".

A regra: o telemóvel já tem gestos que toda a gente conhece. Reinventas, perdes.

10. Acessibilidade em mobile — WCAG 2.1 AA mínimo

• Contraste ≥ 4,5:1 em texto, ≥ 3:1 em UI.
• Foco visível em navegação por teclado/screen reader.
• lang="pt-PT" no <html>.
• Hierarquia de headings correta (H1 único, H2-H3 sequenciais).
• Alt em todas as imagens (vazio se decorativa: alt="").
• Sem texto em imagem para conteúdo principal.
• <button> para ações, <a> para navegação. Não inverter com JS.

As WCAG 2.1 quickref é o catálogo completo.

11. Banner de cookies — não tapar o conteúdo

Em PT, RGPD + CNPD obrigam opt-in. Mas se o banner ocupa metade do ecrã do telemóvel no primeiro carregamento:

• Banner no fundo ou em barra estreita (≤ 80 px), não em modal.
• Opções "Aceitar / Recusar / Personalizar" com igual destaque.
• Sem dark patterns — botão "recusar" do mesmo tamanho e cor que "aceitar".
• Scroll do conteúdo permitido durante a decisão.
• Reabrir definições acessível no rodapé.

12. Performance de scripts de terceiros

Os assassinos comuns de landings PT em mobile:

Script	Impacto típico	Solução
GTM (sem otimização)	+400 KB de JS	Carregar só após consentimento + defer
Meta Pixel	+120 KB	Após consentimento
Hotjar / Clarity	+250 KB	Adiar 3-5s ou só em sessões >30s
Chat widget (Tawk, Intercom)	+500 KB	Lazy load com botão fake
Google Maps embed	+300 KB	Substituir por imagem estática
YouTube embed	+500 KB	Substituir por preview clicável (lite embed)

Cada script de terceiros tem de justificar o custo. Se Hotjar custa 250 ms de TBT e a equipa de marketing vê os relatórios uma vez por mês, tira.

13. Navegação interna — sem distrações em landing dedicada

Landing dedicada a uma campanha tem menu reduzido ou ausente:

• Sem menu principal com 8 links que distraem do CTA.
• Logo navega para a própria landing (não para a home).
• Links no rodapé apenas para legais (privacidade, termos, contacto).
• Sem links externos para redes sociais — vão sair e não voltam.

A diferença entre uma landing e uma home page é exatamente esta — a home tem 12 caminhos, a landing tem 1.

14. Erros que matam em mobile PT

• Pop-ups de exit-intent em mobile — não existem tecnicamente (não há mouse), são geralmente disparados por timing e irritam.
• Banners de "instala a app" sem necessidade — empurra para fora.
• Chat em pop-up ao fim de 5s com mensagem genérica — fechado, conversão perdida.
• Vídeo full-screen autoplay — bloqueia o ecrã, fechado.
• Logo enorme + tagline a comer 50% da dobra.

Se vês algum destes na tua landing, é prioridade máxima de correção.

15. Teste real em dispositivo, não em emulador

DevTools do Chrome em desktop não simula mobile real. Testa:

• iPhone SE / iPhone 13 real, 4G (não Wi-Fi).
• Android médio (Samsung A-series, Xiaomi Redmi) — performance típica do utilizador PT.
• Browser do utilizador, não browser de developer (Chrome iOS, Safari, Samsung Internet).
• Modo de poupança de bateria — alguns recursos JS são limitados.

A diferença entre "carregou bem no MacBook" e "carregou em 5,2s no Redmi Note 8" pode ser de 4 segundos.

Em resumo

Mobile-first em 2026 não é breakpoint CSS. É decidir desde o início que o ecrã principal tem 375 px de largura e o utilizador tem o polegar grosso, 4G fraco e 4 abas abertas. O checklist acima é binário: passas ou não passas. Se há 5+ falhas, a página está partida — não é "menos otimizada", está partida. Reescreve as falhas antes de gastar 1€ em anúncio.

E uma regra simples para validar tudo: pega no telemóvel, abre a tua landing em modo 4G, faz a primeira coisa que pedes ao utilizador, e mede quantos segundos demoraste. Se foram mais de 30, o utilizador comum nem chega lá. Se foram mais de 60, és tu a comprar tempo do utilizador a 60€/CPL.

---

No sitesfixe.pt construímos landing pages mobile-first com LCP <1,5s, formulários que convertem em 4G fraco e zero builders pesados. Landing pages desde 400€. Sites desde 1.500€. Pedir orçamento sem compromisso.

Lê também:

• Mobile-first em telemóvel: o que muda em 2026
• Anatomia da landing page que converte
• Erros comuns em landing page: como detetar e corrigir

Fontes

• web.dev — Largest Contentful Paint (LCP)
• Google Search Central — Page Experience
• WCAG 2.1 Quick Reference