Reconstruir a página inicial: a oferta primeiro

Contei os deslizes. De pé numa fila, com o meu próprio site aberto no telemóvel, a puxar com o polegar até à secção que diz o que é que nós vendemos afinal, contei 4.9 ecrãs. Cinco ecrãs de telemóvel cheios de preâmbulo antes de um visitante ficar a saber que serviços é que um estúdio de software oferece. Tinha construído aquela página secção a secção ao longo de dois meses, e cada uma delas tinha sido uma boa ideia no dia em que aterrou.

É assim que a arquitetura de informação de uma landing page corre mal. Ninguém decide enterrar a oferta. A ordem da página acaba por ser a ordem por que o trabalho aconteceu, que é uma cronologia que significa tudo para mim e nada para quem tem o telemóvel na mão. A sequência de uma página é uma afirmação sobre o tempo de quem é que vale mais, e a minha estava a fazer a afirmação errada bem alto.

A ordem por que o trabalho aconteceu

A página antiga tinha catorze secções e cerca de 13 900 píxeis de altura. Abria com o herói e depois vagueava: profundidade de marca, processo, um teaser autónomo para o Reliquary, uma secção separada a explicar a nossa cadência de sprints e, por fim — algures muito abaixo do horizonte da dobra — serviços e preços. Cada acrescento tinha sido posto onde cabia, ou seja, no fim, que é como uma página se transforma numa camada de sedimento.

O que tornava isto difícil de ver é que cada secção, isoladamente, estava bem. A secção de processo explicava bem o nosso processo. O carril de cadência era uma boa peça de design. O problema não era de qualidade em lado nenhum; era que um visitante de primeira vez tinha de merecer a resposta a «o que é que vocês fazem» rolando à procura dela, e a maioria das pessoas, e muito bem, não o faz.

Uma landing page não é uma autobiografia. É uma resposta, e a resposta pertence ao topo.

A ordem que devia ter lançado

A nova sequência é: herói, prova, serviços, trabalhos, o Padrão Vaynerov, o percurso, a montra dos jogos, as etapas do Lab, preços, testemunhos, FAQ, CTA. No código está escrita como comentário por cima da lista de secções, porque uma ordem de execução é o tipo de decisão que a próxima pessoa com pressa desfaz sem dar por isso — eu incluído:

Prova → oferta → evidência → profundidade de marca → processo → recreio do Lab → fecho comercial.

A prova vem antes da oferta de propósito. A faixa de métricas logo por baixo do herói está lá para comprar a credibilidade que a secção de serviços depois gasta. A evidência — trabalho real, casos de estudo reais — segue-se de imediato, porque uma afirmação que se pode verificar ganha a uma afirmação em que é preciso acreditar. Só então chegamos a quem somos e a como trabalhamos, e o fecho comercial espera pelo fim, onde pertence. Os serviços começam agora 1.75 ecrãs abaixo, num telemóvel.

Há uma regra visual por baixo da ordem de execução de que gosto mais do que consigo justificar. Um motivo de circuito — uma linha fina traçada, marcadores de etapa, a sensação de que há corrente a atravessar a página — percorre as primeiras seis secções. Faz uma pausa nas etapas do Lab e retoma nos testemunhos, antes de terminar no CTA. A pausa é o essencial. O Lab é outra sala: jogos, o museu, o Orrery e o Blueprint que lançámos há três dias. Fazer passar a mesma corrente por ali diria que essas coisas fazem parte do argumento de venda, e não fazem. São a oficina, vista através de uma porta.

Cortar é a maior parte do trabalho

Reordenar é a metade fácil. A página melhorou porque duas secções deixaram de existir.

O carril semanal da cadência de sprints fundiu-se na secção do percurso, onde sempre pertenceu — o percurso já contava aquela história em prosa, e o carril contava-a outra vez em imagens, um ecrã depois. A secção de processo na página inicial desapareceu por completo; quem quiser a versão integral pode ler a página de processo, que é mais detalhada do que uma secção da home alguma vez terá licença para ser. E o Reliquary perdeu o seu teaser privado, porque a 2 de julho já tínhamos três destes instrumentos e dar uma secção inteira a um deles tinha passado a ser um acidente da ordem de publicação e não um juízo sobre importância.

No lugar dele: um carril do Lab, três a par — Museu, Orrery, Blueprint. A minha primeira versão punha o texto numa placa sobreposta à imagem de cada instrumento, o que ficava bem no meu portátil e cortava o texto a 390 px de largura, ou seja, no telemóvel com que eu estivera de pé na fila. A reconstrução é imagem em cima, texto por baixo. Nada de inteligente, e encaixa.

Uma mão-cheia de correções mais pequenas apanhou boleia: a etiqueta de modo da montra de jogos esconde-se abaixo do breakpoint sm em vez de amontoar o cartão; o sobretítulo de cada secção recebe agora o seu espaçamento de 0.3em do SectionHeader partilhado, e não do que me apeteceu escrever nesse dia; a grelha do Padrão está limitada a 1600 px para deixar de se esticar até ao horizonte em monitores largos.

Catorze secções e 13 900 píxeis passaram a doze e 12 500. A página diz mais do que dizia e é mais curta do que era, que é o único tipo de edição que vale a pena fazer duas vezes.

O sprint do Lighthouse

Com a forma assente, fui atrás dos números, e é aqui que a história deixa de ser sobre gosto. O desktop acabou em 100/100. O Speed Index caiu de 1.7 s para 0.5 s, e o CLS de 0.079 para 0.001. Em mobile, o Speed Index passou de 4.3 s para 1.7 s, com um tempo total de bloqueio de 30 ms, CLS a zero e um LCP observado de 207 ms.

Duas das alavancas eram sobre deixar de fazer coisas. O nosso preloader — a breve cortina de marca — passou a correr apenas em navegações do lado do cliente, nunca num carregamento a frio, onde estava à frente de uma página que já estava pronta. E a Inter é servida com display: optional, o que significa que o navegador usa a alternativa em vez de deixar a pintura refém de um ficheiro de tipo de letra. Nenhuma das mudanças é interessante. Ambas eram de graça.

Dois truques de LCP, contados com honestidade

O resto do ganho de Speed Index veio de perceber como é que o Chrome regista realmente o Largest Contentful Paint, e quero descrever isto com cuidado porque é a parte que pode soar a batota.

Primeiro: o título do herói aparecia em fade. O Chrome não regista um candidato a LCP de texto enquanto a animação de opacidade não termina, portanto o nosso carimbo temporal de LCP chegava cerca de 2.5 segundos depois de o título já estar visualmente presente no ecrã. Os píxeis estavam lá. A medição é que esperava pelo fim da animação para concordar. Tirar o fade do título mudou a métrica para onde a realidade já estava.

Segundo, e mais estranho: as outras entradas do herói começam agora a opacidade 0.011, e não 0, porque os elementos com opacidade exatamente zero são excluídos por inteiro da consideração do LCP. Onze milésimos são invisíveis para um olho humano e visíveis para a métrica.

Andei para trás e para a frente com esse segundo caso durante algum tempo. O teste em que assentei é se a mudança torna o número mais honesto ou menos. Aqui, o visitante vê o título exatamente no mesmo instante em que sempre viu — a pontuação é que estava a mentir sobre uma página que já era rápida, e agora não está. Se em vez disso eu tivesse atrasado uma imagem pesada para a métrica escolher um elemento mais barato, isso seria o outro tipo de truque e merecia outra palavra. O preloader levou o mesmo tratamento ao contrário: o seu tempo mínimo de exibição caiu de 1800 ms para 1100 ms e, num aparelho real, isso levou a dispensa de 2.5 s para 1.8 s. Isso não é um ajuste de métrica. São 700 ms da vida de alguém devolvidos.

Contraste, e uma navegação que sai da frente

A acessibilidade passou de 95 para 100 em desktop e em mobile, e a correção que contou foi uma única variável. A nossa cor de primeiro plano nas superfícies primária e de destaque era branca, a 2.5:1 contra o destaque — um rácio de contraste que falha, pura e simplesmente, nos botões mais clicados do site. É agora um azul-petróleo escuro, #042F2E, a 5.8:1. Texto escuro sobre um botão de azul-petróleo vivo pareceu-me errado durante cerca de um dia e depois passou a parecer certo, que é mais ou menos a meia-vida de um hábito de design. O desempenho em desktop passou de 94 para 97 na mesma passagem.

A última peça foi a navegação. Numa página que se rola ao longo de 12 500 píxeis, uma barra permanentemente fixa é um imposto permanente sobre o ecrã. A nossa esconde-se agora ao fim de 48 px de rolagem descendente sustentada, passado um piso de 160 px, e volta com 10 px de rolagem ascendente — o piso impede-a de tremeluzir no topo da página, e a assimetria faz com que apareça no instante em que se estende a mão para ela. O filete de progresso de leitura por baixo dela é uma única variável CSS escrita a partir do gestor de rolagem que já estava a correr; a alternativa seria um segundo ouvinte para calcular um número que o primeiro já tinha.

Trouxe também um pequeno defeito do género que só aparece em combinação: com o menu móvel aberto, a transformação da barra criava um contexto de empilhamento que fechava o seu botão de alternância em z-50 por baixo da sobreposição em z-40. Abria-se o menu e o botão para o fechar deixava de ser clicável. A correção retira a transformação sob [data-menu-open]. Em separado, a barra completa de desktop passa a aparecer em xl (1280 px) e não em lg, pela razão pouco glamorosa de que dispô-la honestamente precisa de cerca de 1232 px e eu andava a pedir-lhe que coubesse em menos.

Nada disto está terminado. A ordem das secções é uma hipótese sobre desconhecidos, e a maneira honesta de a segurar é com pouca força — conto voltar a mexer nas coisas assim que houver tráfego suficiente para discutir comigo. Mas a medição que vou manter é a que fiz na fila: não quantas secções tem a página, mas quantos ecrãs são precisos para responder à pergunta com que o visitante chegou. A nossa está em 1.75 ecrãs. Se voltar a descer, vocês saberão antes de mim.