# Second Meaningful Content: a pior métrica de performance > Second Meaningful Content: a pior métrica de performance web. Entenda pintura de conteúdo significativo e real impacto em UX. Analise criticamente! URL: https://dpw.dev/miscelanea/second-meaningful-content-performance-metrica/ Publicado em: 2019-01-07 Categoria: miscelanea Tags: performance Autor: Tárcio Zemel **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. > Artigo baseado em [Second Meaningful Content: the Worst Performance Metric](https://www.filamentgroup.com/lab/second-meaningful-content.html). 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](https://twitter.com/scottjehl/status/1061985477694316544) um tanto quanto explícita, chamada **Second Meaningful Content** ("Segundo Conteúdo Significativo"), que ocorre muito tempo depois do **First Meaningful Content** (ou [Paint](/miscelanea/desenvolvedor-frontend-renderizacao-paginas-web/)), 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: ![Second Meaningful Content: linha do tempo](/images/blog/second-meaningful-content-performance-metrica/2ndmeaningfulcontent.webp) 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](https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4). 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. --- Fonte: [dpw - desenvolvimento para web](https://dpw.dev/) (pt-BR). Guia para agentes: https://dpw.dev/llms.txt Índice completo: https://dpw.dev/sitemap-index.xml Feed: https://dpw.dev/rss.xml