Conheça o motor de renderização do Thor: crie páginas extremamente rápidas

Meu nome é Piotr Dolistowski, diretor sênior de engenharia da Instapage. Lidero o ramo técnico da empresa em Varsóvia, Polônia, incluindo coordenação de projetos e gestão de pessoas. Tudo no artigo de hoje é resultado direto dos esforços da minha equipe para criar um sistema de renderização de página mais rápido para os clientes do Instapage.

Não é segredo para os profissionais de marketing digital que a velocidade de carregamento da página tem um impacto direto no engajamento do usuário e na taxa de rejeição. O Google e outros fizeram da velocidade da página um ponto de ênfase para quem trabalha com marketing digital há pelo menos alguns anos, então não é novidade para 2019.

Já apresentamos isso muitas vezes antes, mas a pesquisa do Google mostra que, para páginas de carregamento lento, o engajamento do usuário cai enquanto as taxas de rejeição aumentam:

É por isso que nossa equipe trabalhou incansavelmente para trazer a você o Thor Render Engine™. O mecanismo de renderização é nosso novo gerador de página e parte de nossas experiências de página totalmente responsivas que garantem que suas páginas de destino pós-clique sejam carregadas incrivelmente rápido sem nenhum esforço de sua parte.

Antes de mergulharmos nos detalhes do novo sistema de renderização do Instapage, vamos analisar por que o carregamento lento das páginas de destino pós-clique prejudica as conversões.

O impacto que as páginas de carregamento lento têm nas conversões

Quão lenta é uma página de carregamento lento? Cada segundo de atraso no tempo de carregamento da página móvel leva a uma queda nas conversões:

Tradução: os usuários online não têm paciência para esperar muito tempo para que sua página carregue. Portanto, se não carregar quase instantaneamente, eles sairão da página. Isso aumenta a taxa de rejeição, diminui o engajamento do usuário, é ruim para a experiência geral do usuário e limita as conversões.

A Akamai teve os seguintes insights depois de coletar dados sobre 10 bilhões de visitas de usuários dos principais varejistas online:

• Metade dos consumidores procura produtos e serviços em seus smartphones, enquanto apenas um em cada cinco realmente compra em seus celulares.
• Um atraso de 100 milissegundos no tempo de carregamento do site pode prejudicar as taxas de conversão em 7%
• Um atraso de dois segundos no tempo de carregamento da página da Web aumenta as taxas de rejeição em 103%
• 53% dos visitantes do site mobile sairão de uma página que leva mais de três segundos para carregar
• As taxas de rejeição dos compradores de celulares foram as mais altas, enquanto os compradores de tablets tiveram as taxas de rejeição mais baixas

Então, como você pode garantir que suas páginas de destino pós-clique carreguem rapidamente? O PageSpeed ​​Insights do Google pode ajudar, mas quanto?

Os relatórios do PageSpeed ​​Insights do Google sobre o desempenho de uma página, mostrando se uma página é rápida, média ou lenta em dispositivos móveis e desktop. Ele também fornece sugestões sobre como essa página pode ser melhorada:

Mas, se você não tiver conhecimento técnico, os insights de velocidade da página podem confundi-lo. Compreender quais são as métricas do First Contentful Paint (FCP) e do First Input Delay (FID) pode passar despercebido.

Entre no Thor Render Engine™ da Instapage.

Os detalhes por trás do Thor Render Engine™

Desenvolvemos o Thor Render Engine™ para garantir que todas as páginas de destino pós-clique do Instapage sejam carregadas rapidamente.

Isso significou uma reescrita completa das páginas de destino pós-clique em todos os aspectos - alterando a estrutura HTML, refatoração de JavaScript e CSS e capacidade de resposta de CSS para garantir que tudo no back-end de suas páginas permitisse que elas fossem carregadas instantaneamente.

A melhor parte de todas essas mudanças é que você não precisa fazer nada porque o Thor Render Engine™ trabalha silenciosamente nos bastidores para tornar suas páginas extremamente rápidas.

Vamos detalhar as alterações para ver o que fizemos para carregar páginas mais rapidamente.

estrutura HTML

Muito foi feito para tornar o sistema de renderização de página mais rápido do ponto de vista HTML, começando com a priorização de recursos.

Priorização de recursos

Removemos muito código não utilizado, ambíguo ou não ideal das páginas de destino pós-clique, resultando em uma marcação clara e de renderização rápida.

A nova estrutura HTML garante que todos os recursos serão carregados na ordem correta. Estilos de página (exceto estilos de fonte) foram adicionados à seção de cabeçalho porque, depois disso, as páginas carregam mais rápido do que usando folhas de estilo CSS.

A capacidade de resposta não precisa mais de pontos de interrupção adicionais em CSS ou JavaScript porque as páginas carregam rapidamente e ficam ótimas sem código adicional. Além disso, todos os scripts são colocados na parte inferior do corpo da página para que não bloqueiem a renderização da página. Scripts e recursos críticos (por exemplo, fontes) usam recursos de pré-carregamento do navegador, o que significa que não são bloqueados enquanto a página é renderizada. Além disso, nenhum JavaScript síncrono é colocado na tag head da página.

Carregamento lento de imagem e vídeo

Embora imagens e vídeos não bloqueiem a renderização, quando há vários presentes na página, a largura de banda pode ser obstruída com muitas solicitações, especialmente com imagens grandes. Isso pode levar a uma experiência de usuário insatisfatória, pois as imagens na dobra superior são carregadas simultaneamente com as imagens abaixo da dobra, que não são visíveis para o visitante.

Para resolver o problema, introduzimos as seguintes otimizações:

• As imagens acima da dobra são carregadas com maior prioridade — o download começa imediatamente para que fiquem visíveis antes mesmo de a página se tornar interativa.
• Imagens e vídeos abaixo da dobra são carregados lentamente - o download é acionado quando o usuário rola até eles. As caixas cinzas são usadas como espaços reservados para imagens ainda não carregadas.
• Para evitar que o usuário veja essas caixas cinzas, as imagens são realmente carregadas quando são roladas na janela de visualização. Mas quando eles são rolados a uma distância de 400px para a parte inferior da janela de visualização. Quando eles entram na viewport, eles já estão carregados.
• A mesma regra se aplica aos vídeos carregados em iframes.

Para que isso aconteça, aproveitamos a API de ponta do IntersectionObserver, que torna o carregamento lento supereficiente com tamanho de código reduzido:

Refatoração do JavaScript

A refatoração do JavaScript incluiu as seguintes otimizações:

1. Arquitetura modular: todo o código JavaScript nas páginas de destino pós-clique está relacionado a recursos de widgets específicos. Dividimos nosso código em vários pacotes, cada um contendo um código para o recurso específico. Portanto, quando um usuário cria uma página apenas com imagens e links, nenhum código para widgets de formulário ou pop-up será carregado, tornando a página carregada rapidamente.
2. Super leve: removemos as bibliotecas antigas e redesenhamos toda a arquitetura do código, o que nos permitiu reduzir o tamanho total do JavaScript na página de mais de 1 MB para cerca de 200 kB (ou seja, 5 vezes menos!), enquanto uma página típica carregará menos de 100 kB graças à modularização descrita acima.
3. All Async: como o JavaScript bloqueia a renderização, movemos todas as importações de script para a parte inferior da tag BODY. Isso permite que o navegador renderize a página inteira antes que os scripts sejam executados, permitindo que o visitante veja o conteúdo significativo mais cedo. Os scripts que fornecem interatividade serão carregados e executados somente depois que começarem a interagir com essa seção da página. Isso proporciona uma experiência muito boa, especialmente em dispositivos móveis com desempenho inferior e, muitas vezes, com uma conexão de internet ruim.

Refatoração CSS

Também reescrevemos todas as nossas folhas de estilo CSS, removendo o código desnecessário de terceiros para que nossas folhas de estilo sejam reutilizáveis, legíveis e leves. Além disso, usamos classes CSS genéricas para reutilizar o código CSS o máximo possível.

Também implementamos animações somente CSS com aceleração de GPU. A mudança mais importante em nossa pilha CSS foi introduzir a unidade relativa “rem” em vez de pixels. Graças a isso, as páginas de destino pós-clique agora são dimensionadas sem problemas em todos os tamanhos de dispositivo, de smartphones a telas de desktop 4K.

Capacidade de resposta do CSS

Estamos usando “rem” em combinação com a unidade “vw” para tornar as páginas de destino pós-clique responsivas. Isso significa que há duas lacunas nas resoluções do dispositivo quando a página de destino pós-clique é reduzida entre 768 e 1200 pixels de largura e abaixo de 400 pixels de largura. Em todas as outras resoluções, o conteúdo principal permanece com uma largura fixa, assim como no construtor. O valor de largura fixa é 400px para celulares e 1200px para desktop.

As unidades “Rem” nos permitem recalcular a posição e o tamanho do widget sem problemas. Isso também significa que não precisamos usar JavaScript para fazer isso acontecer.

Resumindo:

• abaixo de 400px , o conteúdo é dimensionado automaticamente para caber na largura da tela
• entre 400px e 767px a largura do conteúdo é fixa
• da visualização móvel de 768px muda para a visualização da área de trabalho
• de 768px a 1200px , o conteúdo é dimensionado automaticamente para caber na largura da tela
• acima de 1200px o conteúdo é fixo

Exemplo de teste de velocidade do Thor Render Engine™

Como você nunca sabe como as pessoas visualizam sua página de destino pós-clique (desktop, celular ou tablet), é importante que a experiência da página seja totalmente responsiva. A solução Thor Render Engine™ é totalmente responsiva em todas as resoluções.

Agora vamos comparar o novo mecanismo de renderização com nosso antigo gerador de páginas. As imagens abaixo mostram os resultados de velocidade da mesma página, embora com URL diferente. (Observação: as páginas não estão mais ativas, pois essas URLs são apenas para fins de teste):

Resultados de renderização da página antiga do Instapage:

Resultados do Thor Render Engine™:

Marcar 56 no primeiro teste e aumentá-lo para 95 no segundo teste representa um aumento de 58,9% na velocidade de carregamento da página!

Comparação da velocidade de carregamento da página

Tendo resumido todas as mudanças com o Thor Render Engine™, vamos ver como a velocidade de carregamento da página do Instapage se compara à da concorrência.

Testamos a velocidade desta página (a captura de tela mostra apenas acima da dobra) em uma conexão 3G:

Veja quanto tempo a página leva para carregar:

• Com o antigo sistema de renderização de página Instapage (linha superior): 10,5 segundos para começar a carregar
• Thor Render Engine™ (linha do meio): Em 5 segundos, a página está 98% carregada
• Usando concorrente (linha inferior): 8 segundos para começar a carregar

Em uma conexão 4G, aqui estão os resultados:

• Com o antigo sistema de renderização de página do Instapage: 4,5 segundos para iniciar o carregamento
• Thor Render Engine™: carrega completamente em 3,5 segundos
• Usando concorrente: 4,5 segundos apenas para começar a carregar

Desfrute de páginas de carregamento mais rápidas com o Thor Render Engine™

A velocidade da página desempenha um papel significativo na experiência do usuário e, por fim, nas suas conversões. Quando o tempo de carregamento de uma página demora, você não apenas corre o risco de uma alta taxa de rejeição, mas também cria usuários frustrados no processo.

Com o Thor Render Engine™, agora podemos garantir que suas páginas de destino pós-clique serão carregadas instantaneamente sem nenhum esforço de sua parte. Inscreva-se hoje para uma demonstração do Instapage Enterprise e experimente você mesmo a diferença.