Conheça o Thor Render Engine ™: Sistema de renderização de página mais rápido da Instapage

Publicados: 2019-03-18

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 é um resultado direto dos esforços de minha equipe para criar um sistema de renderização de página mais rápido para clientes Instapage.

Não é segredo para os profissionais de marketing digital que a velocidade de carregamento da página tem um impacto direto no envolvimento do usuário e na taxa de rejeição. O Google e outros fizeram da velocidade da página um ponto de destaque para qualquer pessoa que trabalhe com marketing digital por 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 despenca 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 carreguem incrivelmente rápido sem nenhum esforço de sua parte.

Antes de mergulharmos nos detalhes do novo sistema de renderização da Instapage, vamos revisar por que o carregamento lento das páginas de destino pós-clique é prejudicial para 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 para celular leva a uma queda nas conversões:

Tradução: os usuários online não têm paciência para esperar muito 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 envolvimento do usuário, é ruim para a experiência geral do usuário e, por fim, limita as conversões.

A Akamai teve os seguintes insights após 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 para celular deixarão 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 menores taxas de rejeição

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 tem um conhecimento técnico, os insights de velocidade da página podem confundi-lo. Entender quais métricas de First Contentful Paint (FCP) e First Input Delay (FID) podem passar direto por sua cabeça.

Digite 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 iniciais de pós-clique do Instapage carreguem rapidamente.

Isso significou uma reescrita completa das páginas de destino pós-clique em todos os aspectos - alterando a estrutura HTML, JavaScript e Refatoração CSS e Responsividade CSS para garantir que tudo no back-end de suas páginas permitisse que carregassem 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 analisar as alterações para ver o que fizemos para aumentar a velocidade das páginas.

Estrutura HTML

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

Priorização de recursos

Eliminamos as páginas de destino pós-clique de muitos códigos não utilizados, ambíguos ou não otimizados, 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 eles 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 as imagens e os 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 do usuário ruim, 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 prioridade mais alta - o download começa imediatamente para que fiquem visíveis antes mesmo de a página ficar interativa.
Imagens e vídeos abaixo da dobra são carregados lentamente - o download é acionado quando o usuário rola até eles. Caixas cinza 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 para a janela de visualização. Mas quando eles são rolados a uma distância de 400 px até a parte inferior da janela de visualização. Quando eles entram na janela de visualização, eles já estão carregados.
A mesma regra se aplica a vídeos, que são carregados em iframes.

Para fazer isso acontecer, aproveitamos a API de ponta do IntersectionObserver, que torna o carregamento lento supereficiente com pegada de código pequeno:

Refatorar JavaScript

O refatorador de JavaScript incluiu as seguintes otimizações:

Arquitetura modular: Todo o código JavaScript em 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 com apenas imagens e links, nenhum código para widgets de formulário ou pop-up será carregado, tornando o carregamento da página mais rápido.
Superleve: removemos 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, 5x menos!), Enquanto uma página típica carrega menos de 100 kB graças à modularização descrita acima.
Tudo assíncrono: 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. Scripts que fornecem interatividade serão carregados e executados somente depois que começarem a interagir com aquela seção da página. Isso fornece uma experiência muito boa, especialmente em dispositivos móveis com desempenho inferior e, muitas vezes, uma conexão de Internet ruim.

Refatorar CSS

Também reescrevemos nossas folhas de estilo CSS inteiras, removendo o código de terceiros desnecessário 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 tanto quanto possível.

Também implementamos animações somente CSS com aceleração de GPU. A mudança mais importante em nossa pilha CSS foi a introdução da 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 monitores de desktop de 4k.

Responsividade 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 da largura fixa é 400 px para celulares e 1200 px para desktops.

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

Resumindo:

o conteúdo abaixo de 400px é dimensionado automaticamente para caber na largura da tela
entre 400px e 767px a largura do conteúdo é fixa
da visualização móvel de 768 pixels para a visualização em desktop
de 768 px a 1200 px o conteúdo é dimensionado automaticamente para se ajustar à largura da tela
acima de 1200 px, o conteúdo é fixo

Exemplo de teste de velocidade 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 página da mesma página, embora com URL diferente. (Observação: as páginas não estão mais ativas, pois esses URLs são apenas para fins de teste):

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

Resultados do Thor Render Engine ™:

Marcar 56 no primeiro teste e aumentar para 95 no segundo teste é 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 imagem só mostra a parte superior) 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 o 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 Instapage: 4,5 segundos para começar a carregar
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ápido com o Thor Render Engine ™

A velocidade da página desempenha um papel significativo na experiência do usuário e, em última análise, em suas conversões. Quando o tempo de carregamento de uma página é lento, 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 carreguem instantaneamente, sem nenhum esforço de sua parte. Inscreva-se para uma demonstração do Instapage Enterprise hoje mesmo e experimente você mesmo a diferença.