Desenhar para o browser dentro da app.

O dono de um restaurante respondeu à nossa mensagem de Instagram a dizer que o link que tínhamos enviado estava partido. Testámos o URL de imediato. Funcionava na perfeição no Chrome, no Safari, no Firefox — em iOS, em Android, no computador. Todos os browsers que tínhamos o abriam sem qualquer falha.

O problema estava no único browser em que não estávamos a pensar. O Instagram tinha aberto o link dentro do seu próprio browser interno, baralhou-o em silêncio pelo caminho, e deixou-o algures que não era a página que tínhamos construído. Ele viu uma experiência partida e concluiu, com toda a razão, que o site estava partido. Não estava. Mas o estrago estava feito — aquele único momento custou-nos uma semana de impulso, e uma conversa que tínhamos começado com cuidado genuíno por pouco não sobreviveu.

01 · A Web EscondidaExiste uma segunda web, e você não a controla.

Quando alguém toca num link dentro do Instagram, do Facebook, do TikTok ou do LinkedIn, normalmente não sai da app. O link abre num webview — um browser reduzido, embutido na própria app social. Para o utilizador, parece um browser. Tecnicamente, é. Mas não é o browser que o telemóvel traz de origem, e não se comporta como ele.

Cada plataforma constrói o seu. Cada um deles retira e reescreve coisas pelo caminho. Certos cabeçalhos HTTP são descartados. Os cookies de terceiros são frequentemente bloqueados, o que parte logins, carrinhos e tudo o que dependa de uma sessão que não foi a própria app a iniciar. Algumas APIs de JavaScript que existem num browser a sério simplesmente não estão lá — partilha, certas chamadas de armazenamento, ganchos de pagamento e de área de transferência que o seu código assume que pode invocar em segurança.

Depois há aquilo que é mal renderizado em vez de removido. Tipos de letra personalizados acima de cerca de 200KB podem falhar ao carregar, e então o seu tipo de letra cuidadosamente escolhido cai para um do sistema e a página inteira passa de repente a parecer um rascunho. Os codecs de vídeo são uma lotaria — um clip de hero que toca em todo o lado pode recusar-se a arrancar. Favicons dinâmicos, service workers, e qualquer truque que tenha feito com o URL podem comportar-se de forma diferente ou não funcionar de todo.

Pior ainda, estas falhas são inconsistentes entre plataformas e entre versões da app. Um link que sobrevive ao webview do TikTok engasga-se no do LinkedIn. Uma página que renderizava bem no mês passado parte-se depois de a app actualizar o motor embutido — e nunca ninguém o avisa. Não há consola de erros que possa ler, não há ticket de suporte que possa abrir, nem sequer há forma de reproduzir o bug a não ser que calhe ter exactamente o mesmo dispositivo, versão da app e condições de rede que o utilizador tinha.

A parte cruel é a atribuição. O utilizador nunca pensa o browser da app tratou mal isto. Ele pensa o site está partido. E, num sentido muito real, o site está bom — foi o webview que o partiu, num sítio que o dono do site não vê nem consegue controlar por completo. É o mesmo problema de confiança sobre o qual escrevemos em porque a maioria dos chatbots parecem uma parede: a falha recai sobre o negócio mesmo quando o negócio fez tudo bem.

02 · O TesteO que verificar mesmo, em 2026.

A solução não tem glamour. É disciplina, e quase tudo se resume a testar a coisa da forma como ela vai ser realmente usada, em vez da forma como é cómodo construí-la.

Teste o URL publicado onde ele vai viver

Abra sempre o seu link real, já publicado, partilhando-o através da rede social em que o vai mesmo partilhar — cole-o numa mensagem de Instagram para si próprio e toque-lhe a partir de dentro da app. Testar no Chrome do computador não prova nada sobre como ele se comporta no webview do Instagram. O único teste honesto reproduz o caminho real.

Mantenha o link limpo

Evite encurtadores de URL, cadeias de redireccionamento e query strings decorativas. Cada redireccionamento é mais uma oportunidade para um webview perder o rasto, e os URLs longos e cheios de parâmetros de seguimento são precisamente aquilo em que alguns browsers internos tropeçam. Um link curto, directo e em https:// sobrevive mais vezes do que um link engenhoso.

Faça o primeiro ecrã absurdamente leve

Mantenha o peso acima da dobra punitivamente pequeno — abaixo de uns 200KB, se conseguir. Os webviews numa ligação fria dentro de uma app são o pior ambiente de carregamento que existe, e quanto mais pesado o primeiro desenho, mais hipóteses há de algo falhar. É também por isto que mantemos o nosso próprio trabalho de manutenção e desempenho aborrecido de propósito: a leveza é uma funcionalidade, não uma sobra.

Prefira links simples a routing por JavaScript

Um <a href="https://…"> simples ganha sempre à navegação encaminhada por JavaScript dentro de um webview. Os routers do lado do cliente dependem de APIs de histórico e de armazenamento que os browsers internos por vezes restringem, e quando falham, falham de forma invisível. As âncoras a sério não falham.

Codifique o vídeo para o pior espectador

Para o vídeo de hero, use H.264 com carregamento progressivo. O AV1 e o HEVC são mais eficientes e ficam lindíssimos num browser moderno, mas os webviews recusam-nos de forma inconsistente — e uma recusa inconsistente é pior do que uma limitação previsível, porque não há forma fiável de a contornar a testar.

Avise no topo de tudo o que for interactivo

Para planos, propostas ou configuradores interactivos, imprima uma nota visível logo no topo: melhor aberto no computador — copie este link para o seu browser. Não é elegante. É honesto, e poupa o cliente de concluir que o seu trabalho cuidadoso está partido quando é o recipiente que lhe está a falhar.

03 · O Ponto Mais FundoDe quem é esta falha, ao certo?

Eis a parte que nos deixa desconfortáveis. Sempre que dizemos a um cliente "copie e cole isto no Safari", estamos a tapar uma falha de UX real — em nome de uma grande plataforma, com a nossa própria credibilidade. A instrução resulta. Mas também treina as pessoas, em silêncio, a esperar que os links sejam pouco fiáveis e que a solução seja tarefa delas.

Não devia ser. O link partilhável é uma promessa: toca aqui e vês a coisa. Quando a promessa se parte dentro de uma app com mil milhões de utilizadores, o utilizador não abre um relatório de erro com essa app — perde uma lasca de confiança no destino, que costuma ser um pequeno negócio que não fez nada de errado. A plataforma fica com a conveniência de manter os utilizadores dentro da sua app, e é outra pessoa que paga o custo de reputação.

Há também um custo mais silencioso. Cada instrução de "abra isto no Safari" acrescenta um micro-passo de atrito a um percurso que era suposto não ter nenhum. Para um pequeno negócio que envia um menu, uma página de reservas ou uma proposta, esse passo a mais é precisamente onde as pessoas desistem — não por má vontade, mas porque o momento de intenção é frágil e um desvio de copiar-colar basta para o quebrar. Estamos, no fundo, a pedir ao visitante que faça QA não pago em nome de uma plataforma.

E, no entanto — até as plataformas lançarem webviews melhores, queixarmo-nos disto não é uma estratégia. A responsabilidade, justa ou não, é nossa. Podemos construir para o pior espectador, testar pelo canal real, e manter o primeiro ecrã leve o suficiente para que nem um webview hostil o consiga estragar. Isso está sob o nosso controlo. Um browser do Instagram mais afinado não está.

04 · Para FecharUm pequeno coxear de UX.

Cada link que enviamos hoje leva consigo uma pequena nota impressa: "Melhor aberto no computador. Se a página parecer estranha, copie e cole fora do Instagram." É um pequeno coxear de UX, e reparamos nele de cada vez que o acrescentamos. Gostávamos de o reformar. Até lá, desenhe em conformidade.