Conozca el Thor Render Engine: cree páginas ultrarrápidas

Publicado: 2019-03-18

Mi nombre es Piotr Dolistowski, director sénior de ingeniería en Instapage. Dirijo la rama técnica de la empresa en Varsovia, Polonia, incluida la coordinación de proyectos y la gestión de personas. Todo en el artículo de hoy es el resultado directo de los esfuerzos de mi equipo para crear un sistema de representación de páginas más rápido para los clientes de Instapage.

No es ningún secreto para los especialistas en marketing digital que la velocidad de carga de la página tiene un impacto directo en la participación del usuario y la tasa de rebote. Google y otros han hecho de la velocidad de la página un punto de énfasis para cualquier persona que trabaje en marketing digital durante al menos algunos años, por lo que no hay nada nuevo para 2019.

Hemos presentado esto muchas veces antes, pero la investigación de Google muestra que para las páginas de carga lenta, la participación del usuario cae en picado mientras que las tasas de rebote aumentan:

tasas de rebote de la velocidad de representación de la página

Es por eso que nuestro equipo trabajó incansablemente para traerle Thor Render Engine™. El motor de procesamiento es nuestro nuevo generador de páginas y parte de nuestras experiencias de página totalmente receptivas que garantizan que sus páginas de destino posteriores al clic se carguen increíblemente rápido sin ningún esfuerzo de su parte.

Antes de sumergirnos en los detalles del nuevo sistema de representación de Instapage, revisemos por qué las páginas de destino posteriores al clic de carga lenta son perjudiciales para las conversiones.

El impacto que tienen las páginas de carga lenta en las conversiones

¿Qué tan lenta es una página de carga lenta? Cada segundo retraso en el tiempo de carga de la página móvil conduce a una caída en las conversiones:

caída de la tasa de conversión de renderizado de página

Traducción: los usuarios en línea no tienen la paciencia para esperar mucho tiempo a que se cargue su página. Entonces, si no se carga casi al instante, abandonarán la página. Esto aumenta la tasa de rebote, disminuye la participación del usuario, es malo para la experiencia general del usuario y, en última instancia, limita las conversiones.

Akamai obtuvo los siguientes conocimientos después de recopilar datos sobre 10 000 millones de visitas de usuarios de los principales minoristas en línea:

  • La mitad de los consumidores buscan productos y servicios en sus teléfonos inteligentes, mientras que solo uno de cada cinco compra en sus teléfonos móviles.
  • Un retraso de 100 milisegundos en el tiempo de carga del sitio web puede afectar las tasas de conversión en un 7%
  • Un retraso de dos segundos en el tiempo de carga de la página web aumenta las tasas de rebote en un 103%
  • El 53% de los visitantes del sitio móvil dejarán una página que tarde más de tres segundos en cargarse.
  • Las tasas de rebote de los compradores de teléfonos móviles fueron las más altas, mientras que los compradores de tabletas tuvieron las tasas de rebote más bajas.

Entonces, ¿cómo puede asegurarse de que sus páginas de destino posteriores al clic se carguen rápido? PageSpeed ​​Insights de Google puede ayudar, pero ¿cuánto?

PageSpeed ​​Insights de Google informa sobre el rendimiento de una página, mostrando si una página es rápida, promedio o lenta tanto en dispositivos móviles como de escritorio. También proporciona sugerencias sobre cómo se puede mejorar esa página:

Pero, si no tiene experiencia técnica, la información sobre la velocidad de la página puede confundirlo. Comprender qué métricas First Contentful Paint (FCP) y First Input Delay (FID) pueden pasar por alto.

Ingrese a Thor Render Engine™ de Instapage.

Los detalles detrás de Thor Render Engine™

Desarrollamos Thor Render Engine™ para garantizar que todas las páginas de destino posteriores al clic de Instapage se carguen rápidamente.

Esto significó una reescritura completa de las páginas de destino posteriores al clic en todos los aspectos: cambiar la estructura de HTML, la refactorización de JavaScript y CSS y la capacidad de respuesta de CSS para garantizar que todo en el backend de sus páginas permitiera que se cargaran instantáneamente.

La mejor parte de todos estos cambios es que no necesita hacer nada porque Thor Render Engine™ funciona silenciosamente detrás de escena para hacer que sus páginas sean ultrarrápidas.

Analicemos los cambios para ver qué hemos hecho para que las páginas se carguen más rápido.

Estructura HTML

Se invirtió mucho en hacer que el sistema de representación de páginas fuera más rápido desde el punto de vista de HTML, comenzando con la priorización de recursos.

Priorización de recursos

Hemos despojado a las páginas de destino posteriores al clic de una gran cantidad de código sin usar, ambiguo o no óptimo, lo que da como resultado un marcado claro y de renderizado rápido.

La nueva estructura HTML garantiza que todos los recursos se cargarán en el orden correcto. Los estilos de página (excepto los estilos de fuente) se agregaron a la sección de encabezado porque, después de eso, las páginas se cargan más rápido que con las hojas de estilo CSS.

La capacidad de respuesta ya no necesita puntos de interrupción adicionales en CSS o JavaScript porque las páginas se cargarán rápido y se verán geniales sin código adicional. Además, todos los scripts se colocan en la parte inferior del cuerpo de la página para que no bloqueen la representación de la página. Los scripts y recursos críticos (p. ej., fuentes) usan capacidades de precarga del navegador, lo que significa que no están bloqueados mientras se procesa la página. Además, no se coloca JavaScript síncrono en la etiqueta principal de la página.

Carga diferida de imagen y video

Aunque las imágenes y los videos no bloquean el renderizado, cuando hay varios presentes en la página, el ancho de banda puede obstruirse con demasiadas solicitudes, especialmente con imágenes grandes. Esto puede dar lugar a una experiencia de usuario deficiente, ya que las imágenes de la parte superior se cargan simultáneamente con las imágenes de la parte inferior, que no son visibles para el visitante.

Para resolver el problema, introdujimos las siguientes optimizaciones:

  • Las imágenes de la parte superior de la página se cargan con mayor prioridad : la descarga comienza de inmediato, por lo que son visibles incluso antes de que la página se vuelva interactiva.
  • Las imágenes y los videos debajo de la tapa se cargan con pereza : la descarga se activa cuando el usuario se desplaza hacia ellos. Los cuadros grises se utilizan como marcadores de posición para las imágenes que aún no se han cargado.
  • Para evitar que el usuario vea estos cuadros grises, las imágenes se cargan cuando se desplazan a la ventana gráfica. Pero cuando se desplazan a una distancia de 400 px hasta la parte inferior de la ventana gráfica. Cuando ingresan a la ventana gráfica, ya están cargados.
  • La misma regla se aplica a los videos que se cargan en iframes.

Para que esto suceda, aprovechamos la API de vanguardia de IntersectionObserver, que hace que la carga diferida sea súper eficiente con un tamaño de código pequeño:

renderizado de página iframe carga diferida

Refactorización de JavaScript

El refactor de JavaScript incluyó las siguientes optimizaciones:

  1. Arquitectura modular: todo el código JavaScript en las páginas de destino posteriores al clic se relaciona con características de widgets específicos. Dividimos nuestro código en varios paquetes, cada uno de los cuales contiene un código para la característica específica. Por lo tanto, cuando un usuario diseña una página con solo imágenes y enlaces, no se cargará ningún código para los widgets de formulario o ventana emergente, lo que hará que la página se cargue rápidamente.
  2. Súper liviano: eliminamos las bibliotecas antiguas y rediseñamos toda la arquitectura del código, lo que nos permitió reducir el tamaño total de JavaScript en la página de más de 1 MB a aproximadamente 200 kB (¡eso es 5 veces menos!), Mientras que una página típica cargará menos de 100 kB gracias a la modularización descrita anteriormente.
  3. All Async: dado que JavaScript bloquea el procesamiento, movimos todas las importaciones de scripts al final de la etiqueta BODY. Esto permite que el navegador muestre la página completa antes de que se ejecuten los scripts, lo que le permite al visitante ver contenido significativo antes. Los scripts que brindan interactividad se cargarán y ejecutarán solo después de que comiencen a interactuar con esa sección de la página. Esto brinda una experiencia muy buena, especialmente en dispositivos móviles con un rendimiento más bajo y, a menudo, una conexión a Internet deficiente.

Refactorización de CSS

También hemos reescrito todas nuestras hojas de estilo CSS, eliminando el código de terceros innecesario para que nuestras hojas de estilo sean reutilizables, legibles y livianas. Además, usamos clases CSS genéricas para reutilizar el código CSS tanto como sea posible.

También hemos implementado animaciones solo CSS con aceleración de GPU. El cambio más importante en nuestra pila de CSS fue la introducción de la unidad relativa "rem" en lugar de píxeles. Gracias a esto, las páginas de destino posteriores al clic ahora se escalan sin problemas en todos los tamaños de dispositivos, desde teléfonos inteligentes hasta pantallas de escritorio de 4k.

Capacidad de respuesta de CSS

Estamos utilizando "rem" en combinación con la unidad "vw" para que las páginas de destino posteriores al clic respondan. Esto significa que hay dos brechas en las resoluciones de los dispositivos cuando la página de destino posterior al clic se reduce entre 768 y 1200 píxeles de ancho y por debajo de los 400 píxeles de ancho. En todas las demás resoluciones, el contenido principal permanece con un ancho fijo, al igual que en el constructor. El valor de ancho fijo es 400 px para móviles y 1200 px para escritorio.

Las unidades "Rem" nos brindan la capacidad de recalcular la posición y el tamaño del widget sin problemas. También significa que no tenemos que usar JavaScript para que esto suceda.

En resumen:

  • por debajo de 400 píxeles , el contenido se escala automáticamente para adaptarse al ancho de la pantalla
  • entre 400px y 767px el ancho del contenido es fijo
  • de 768 px , la vista móvil cambia a la vista de escritorio
  • de 768 px a 1200 px el contenido se escala automáticamente para adaptarse al ancho de la pantalla
  • por encima de 1200px el contenido es fijo

Ejemplo de prueba de velocidad de Thor Render Engine™

Dado que nunca se sabe cómo ven las personas su página de destino posterior al clic (escritorio, dispositivo móvil o tableta), es importante que la experiencia de la página sea completamente receptiva. La solución Thor Render Engine™ responde completamente en todas las resoluciones.

Ahora comparemos el nuevo motor de renderizado con nuestro antiguo generador de páginas. Las imágenes a continuación muestran los resultados de la velocidad de la página de la misma página, aunque con una URL diferente. (Nota: las páginas ya no están activas ya que estas URL son solo para fines de prueba):

Resultados de representación de la página Instapage antigua:

velocidad de renderizado de página antes

Resultados de Thor Render Engine™:

velocidad de renderizado de la página después

¡Obtener un 56 en la primera prueba y aumentarlo a 95 en la segunda prueba es un aumento del 58,9% en la velocidad de carga de la página!

Comparación de velocidad de carga de página

Habiendo resumido todos los cambios con Thor Render Engine™, veamos cómo se compara la velocidad de carga de la página de Instapage con la competencia.

Probamos la velocidad de esta página (la captura de pantalla solo muestra la parte superior del pliegue) en una conexión 3G:

ejemplo de prueba de velocidad de renderizado de página web

Este es el tiempo que tarda la página en cargarse:

  • Con el antiguo sistema de representación de páginas de Instapage (fila superior): 10,5 segundos para comenzar a cargar
  • Thor Render Engine™ (fila central): en 5 segundos, la página se carga en un 98 %
  • Usando competidor (fila inferior): 8 segundos para comenzar a cargar

comparación de velocidad de renderizado de páginas web

En una conexión 4G, estos son los resultados:

comparación de la velocidad de renderizado de la página web con la competencia

  • Con el antiguo sistema de renderizado de páginas de Instapage: 4,5 segundos para comenzar a cargar
  • Thor Render Engine™: se carga por completo en 3,5 segundos
  • Usando competidor: 4.5 segundos solo para comenzar a cargar

Disfruta de páginas que se cargan más rápido con Thor Render Engine™

La velocidad de la página juega un papel importante en la experiencia del usuario y, en última instancia, en sus conversiones. Cuando el tiempo de carga de una página se retrasa, no solo corre el riesgo de una alta tasa de rebote, sino que también crea usuarios frustrados en el proceso.

Con Thor Render Engine™, ahora podemos garantizar que sus páginas de destino posteriores al clic se cargarán instantáneamente sin ningún esfuerzo por su parte. Regístrese para una demostración de Instapage Enterprise hoy y experimente la diferencia usted mismo.