Second Meaningful Content (ou Segundo Conteúdo Significativo) é uma (possível) nova métrica de performance que surgiu através de uma brincadeira, mas que, por fazer bastante sentido, talvez deva ser levada bastante a sério.
Testes de conteúdo personalizados e testes A/B são recursos comuns em muitos sites atualmente porque podem ajudar as equipes a melhorar a conversão e o engajamento. Nos últimos anos, no entanto, foi possível notar muitos sites migrarem esses fluxos de trabalho de conteúdo dinâmico do lado do servidor para o lado do cliente — para facilitar o trabalho das equipes de marketing e UX com menos suporte do desenvolvedor.
Infelizmente, essa mudança para o JS do lado do cliente pode ter um grande impacto na performance.
Explicando Second Meaningful Content
Para recapitular uma implementação típica desse padrão: o servidor fornece conteúdo HTML utilizável junto com algum JavaScript que bloqueará a renderização da página enquanto o script é carregado e avaliado (evaluated). Esse período de bloqueio é o primeiro antipattern de performance do fluxo de trabalho, mas segue-se um mais notório: assim que o script for executado, ele removerá uma parte do conteúdo da página e a substituirá por um novo conteúdo em seu lugar.
Esse novo conteúdo pode ser mais segmentado para um determinado usuário, mas o tempo e a complexidade envolvidos na entrega podem significar longos atrasos para todos. Ironicamente, a oportunidade de aumentar a conversão com essas ferramentas pode custar a capacidade de muitas pessoas usar o site.
Esse padrão leva a um efeito tão único no carregamento da página, que, na semana da última Conferência Perf.Now(), meio que por brincadeira Scott Jehl criou uma nova métrica de performance um tanto quanto explícita, chamada Second Meaningful Content (“Segundo Conteúdo Significativo”), que ocorre muito tempo depois do First Meaningful Content (ou Paint), que, de outra forma, marcaria a hora em que uma página começa a aparecer utilizável.
Uma linha do tempo visual desse pattern tende a se parecer com isso:
Esse padrão pode pegar um site anteriormente rápido e otimizado e renderizá-lo dolorosamente lento; foram vistos sites com páginas que costumavam ser interativas em 4 ou 5 segundos em um telefone e rede comuns, levando de repente 12 segundos para começar a parecer usáveis… Quanto menor o tempo para se chegar ao segundo Second Meaningful Content (“2nd MC”), melhor.
Parte do motivo desse atraso é que o JavaScript atualmente leva muito tempo para ser processado em smartphones, mesmo que seja baixado rapidamente — por exemplo, um smartphone novo médio (na data da publicação deste artigo) leva atualmente 2 segundos para processar 200kb de JavaScript compactado.
Outra parte do atraso é que, às vezes, esses scripts iniciam solicitações adicionais de bloqueio para o servidor enquanto o usuário espera, introduzindo ainda mais ciclos de download e avaliação de scripts (evaluating scripts).
Chegando mais rápido à Second Meaningful Content
Este padrão tornou-se tão comumente integrado em sites hoje em dia que parece que agora é mais fácil criar um site rápido do que manter um site rápido. Então, o que seria possível fazer a este repeito? Algumas dicas práticas podem ajudar:
Fazer testes A/B somente em visitas repetidas
Recomenda-se não variar o conteúdo para visitantes que acessam o site pela primeira vez e, em vez disso, apenas pré-carregar os scripts para que eles sejam armazenados em cache e prontos para uso nas visualizações de páginas subsequentes. Obviamente, ter os scripts em cache só ajudará no tempo de carregamento. O tempo que os scripts passam realmente a ser executados depois de carregados é o atraso mais problemático e prejudicial.
Pré-carregar o inevitável
Usar link[rel=preload] no cabeçalho de um documento HTML para pré-carregar scripts que serão solicitados posteriormente pode melhorar drasticamente o tempo de carregamento. Mais uma vez, isso não alterará os delays de avaliação (evaluating) e execução (running) dos scripts após o download, mas poderá economizar segundos no tempo de carregamento inicial.
Somente fazer testes A/B de conteúdo “abaixo da dobra” e (idealmente) delay nos scripts
Ao longo de linhas semelhantes, é possível recomendar que o conteúdo dinâmico seja usado apenas para partes de uma página fora da viewport quando a página for carregada pela primeira vez para que os usuários não vejam o “flash do conteúdo não resolvido” (flash of unswapped content) acontecer. Se esse caso de uso for possível, vale a pena considerar também se os scripts de bloqueio (blocking scripts) podem ser referenciados e carregados posteriormente, talvez um pouco antes da parte do conteúdo a que eles se dirigem.
Mudar para o teste do lado do servidor
Por último (e idealmente), recomenda-se que os sites substituam suas ferramentas de conteúdo do lado do cliente por aquelas que funcionam no lado do servidor, para que o trabalho pesado possa ocorrer antes de o conteúdo ser entregue ao navegador. Muitas ferramentas de personalização e kits de teste A/B oferecem alternativas do lado do servidor para suas ferramentas do lado do cliente, e é preciso incentivar os proprietários/desenvolvedores de sites a considerarmos essas ferramentas.
Conclusão
Passar testes de conteúdo e A/B para serem feitos no lado do cliente, num primeiro momento, pode parecer uma grande vantagem; mas, antes de tomar esta decisão, é preciso considerar seus impactos negativos. Além disso, existem técnicas e conselhos práticos que devem ser observados ao se usar este tipo de testes em sites e apps.
Através da prática de dicas simples, é possível mitigar bastante a Second Meaningful Content e eventuais problemas de performance que possam ocorrer, tais como o momento certo de executar testes A/B, pré-carregar conteúdos importantes e alterar este tipo de testes para o lado do servidor.
Obviamente, são conselhos que não constituem regras infalíveis, mas devem ser ponderados caso-a-caso em tomadas de decisão estratégicas dentro de um projeto.