Landing pages para tráfico móvil (usabilidad y velocidad de carga)

Hoy vamos a hablar sobre landing pages para tráfico móvil, tema que atacó el gran Fernando Tellado durante el Mobile Marketing Congress. Por si te lo perdiste o necesitas más información… ¡No pierdas detalle de este post! 

• ¡Recuerda descargarte nuestra app Ads Manager y probar todas sus funcionalidades antes de continuar!

Lo primero es lo primero… ¿Con qué monto mi Landing Page?

Fernando nos cuenta que realizó un experimento y montó una landing de producto enfocada nada más en la información de contacto con una empresa y la montó dos veces: una la hizo con HTML5 y la otra la hizo con WordPress; mismas tipografías, mismas imágenes… Y luego las analizó y medió en Pagespeed Insights, que se encarga de medir una serie de parámetros y después les da una puntuación. 

La cruda realidad es que aquella prueba que está hecha en WordPress, da una puntuación baja en móviles, hay ciertos criterios que la penalizan; así mismo, si se mira en escritorio, el rendimiento es menor a 50 en WordPress, mucho menor a lo que es en HTML5.

La realidad es que un HTML estático es más rápido que WordPress porque:

• No hay que hacer consultas a la base de datos para mostrar el contenido, ya que este está ya incorporado.
• El servidor no tiene que convertir PHP con el que están programados todos los CMS ‘s en HTML para que los lea el navegador.
• No hay contenido dinámico, es decir, que todo es estático, todo se muestra en el mismo sitio.
• No se añaden aplicaciones avanzadas, como aquellas que se pueden añadir mediante un CMS.
• Para instalar el eCommerce, se debe de recurrir a una plataforma externa, con lo cual ya no sería HTML puro.
• No hay mejoras de SEO dinámicas.
• No hay plugins que ofrezcan herramientas para nuestro sitio web.

¿Es realmente lento WordPress? 

Después de hacerle unos retoques a WordPress, vemos a través de Pagespeed Insight que este superó en móviles el rendimiento a la página en HTML, lo mismo sucedió en ordenador. Con lo cual se puede concluir de entrada que, en CMS en WordPress es más bajo el rendimiento que en HTML; sin embargo, al usar WordPress se pueden obtener muchas mejoras óptimas, teniendo un esfuerzo bajo, gratuito y sin mucho conocimiento de tener a alguien que sepa programar para montar las landing pages.

• WordPress no se considera lento.
• El contenido es lo que puede ser, en cierto modo, lento. Es lo principal que ralentiza una página: imágenes muy grandes, demasiado texto, muchas funcionalidades dinámicas, bastantes scripts… etc.
• Algunos plugins son lentos. Se recomienda mirar el rendimiento de la página y su velocidad de carga, antes y después de instalar cualquier plugin.
• WordPress necesita optimización, ya que necesita hacer consultas a la base de datos para poder mostrar ese contenido y además, que el navegador lo convierta en HTML.

¿Qué pasa con las Core Web Vitals? 

Mira las métricas web principales traducidas por Google. Estas son:

• LCP (Largest Contentful Paint).
• FID (First Input Delay).
• CLS (Cumulative Layout Shift).

Estas métricas marcan por colores el rendimiento de la página, si esta buena (menos de 2.5 segundos en cargarse), necesita mejora, o, por el contrario, es pobre y hay que hacer mejoras (mayor a 4 segundos). 

 LCP: cuánto tarda en cargar el contenido principal de la landing page

• Problemas y soluciones: 

• • Respuesta lenta del servidor, para lo cual se recomienda buscar el contratar un buen servidor (hosting), optimizarlo, servir recursos de una CDN, aplicar cachés para no tener que recargar todas las consultas, mejorar las imágenes, hacer menor la carga de lazy loading, minimizar los códigos… etc.
  • Renderizado – bloqueo de JS y CSS: esto se refiere a que, hasta que no carga el JavaScript, no se muestra la página. La solución es aplazar los CSS que no son críticos y que hacen que no se cargue nuestra página, para mostrarlos después.
  • Renderizado del navegador, que se refiere a mostrar rápidamente nuestra página en el navegador. La solución es minimizar los códigos, aplazar las imágenes que no se necesitan inicialmente, reducir el tamaño de todo el código que deben de mostrar el navegador.
  •  Carga lenta de recursos.

Características LCP

• Los tiempos de respuesta del servidor dependen del hosting, por eso se debe de buscar uno bueno.
• Técnica de compresión GZIP/Brotli (hosting /CDN).
• Minimizar CSS y JavaScript (plugin): para que todas las líneas que sobran pesen menos. 
• Optimización de imágenes (plugin/servicio): aun aquellas que ya se han subido anteriormente.
• Optimización de fuentes (plugin): existen plugins para optimizar la carga de fuentes, por ejemplo, descargando las tipografías que usaremos previamente, para luego cargarlas más rápido. 
• Aplazar carga de CSS y JavaScript (plugin).
• Precarga de recursos (plugin). 
• Uso de CDN (CloudFlare): para entrega más rápida de distintos servidores. 
• Carga diferida de medios (plugin).
• Ruta crítica de CSS (plugin): si tengo una imagen con un título para mostrar, no se carga hasta que el usuario no comience a navegar por ella, de manera que se cargan solo los estilos que son necesarios para lo que está viendo el usuario, y no comienzan a cargarse recursos de códigos hasta que no sean necesarios debido a que el usuario ya está navegando hacia nuestra landing page. 

FID: Cuánto tarda el usuario en poder interactuar con nuestra página 

El FID se refiere a la métrica que representa cuánto tarda el usuario en poder interactuar con nuestra página cuando existe algún elemento, como por ejemplo hacer un click, introducir sus datos en un formulario… etc.

• Problemas y soluciones:

• • Ejecución pesada de JavaScript, ya sea por la gran cantidad de código o por algún otro motivo. La solución es reducir el tiempo de ejecución minimizando y aplazando JS no utilizado o no crítico con async o defer, (code-split) dividir el código para carga condicional, evitar tareas de más de 50 ms y usar web workers, aplicaciones que cargan a medida que son necesarios nuestros recursos. 
  • Ejecución lenta del servidor: la solución Gzip, Brotli.

Características FID

• Aplazar carga de JavaScript (plugin).
• Comprimir Javascript con GZIP/Brotli (Hosting /CDN).
• Minimizar Javascript (plugin).
• Reducir peticiones (cachés – CDN).

CLS: Cuánto cambia tu contenido visual 

Normalmente esto cambia de manera directa en el diseño de nuestra landing. Tienes que preocuparte de no marear al usuario haciendo cambios grandes de diseños, como por ejemplo movimientos extraños dentro de la página, imágenes grandes que no se vean, los carruseles, que pueden ser engañosos… etc. ¡Cuidado con esto!

• Problemas y soluciones:

• • Imágenes no redimensionadas, que no tienen el tamaño adecuado y que por lo tanto cuando el usuario cambia de dispositivo se ven mal. La solución es incluir el ancho (width) y el alto (height) concreto en imágenes y vídeos para cada tipo de dispositivo (responsive).
  • Anuncios, embeds, e iframes no dimensionados. La solución es reservar estáticamente espacio para esos elementos en nuestra página y que así no rompan el resto de elementos en nuestra web.
  • JavaScripts que añaden contenido al DOM (tamaño total del documento). La solución es evitarlos, porque no son fáciles de corregir. Si tenemos un formulario, es mejor ponerlo en una página aparte para no romper con el rendimiento de la página. 
  • Técnicas FOIT vs. FOUT (fuentes web) para la carga de tipografías. La solución es Font-display y Font Loading API.

Características CLS

• Optimización de fuentes web (plugin/tema). Hay muchos temas que ya tienen la precarga e incluso almacenamiento en caché de las fuentes necesarias.
• Imágenes, iframes, anuncios sin dimensiones específicas (plugin), se puede solucionar ya sea al 90% con un plugin.

Si uso WordPress… ¿Cómo lo hago? 

1. Primero debes comenzar por tener el hosting.
2. Segundo, elegir un plugin que tenga casi todo lo que vamos a necesitar.
3. Se debe de optimizar todo: 

• Reducir las consultas, esto es, cachear todo lo que podamos almacenar en caché y mejor si es del servidor. 
• Reducir el peso de imágenes comprimiendo todo.
• Minimizar todos los códigos que podamos. 
• Optimizar todos los elementos.
• Precargar todo los elementos.

Este es el resumen de lo que se debe de hacer para que nuestras paginas carguen de manera perfecta en todo tipo de dispositivos, especialmente en móviles, que es donde primero van a caer los usuarios en una landing del sitio web.

Se recomienda utilizar el plugin gratuito llamado “SG Optimizer”, pero este sólo está disponible para los usuarios de SiteGround. 

Normalmente solo hay hasta 3 tipos de caché:

• Caché estática: que todos la podemos conseguir mediante plugins. Hablamos de que todos nuestros recursos, imágenes, códigos…etc, podemos guardarlos en caché para que el segundo visitante que llegue, WordPress no necesite consultar en la base de datos para entregar lo que quiere ver el usuario en esa URL concreta; es decir, le entrega al siguiente visitante lo mismo que le ha mostrado al anterior, mientras no haya un cambio en el diseño de nuestra página o alguien haya creado un modificación editando la página. Eso es lo bueno de WordPress, que todo esto te lo reconoce dinámicamente y cuando por ejemplo, editas una landing page, WordPress lo entiende, vacía la caché anterior y con el primer visitante que llegue justo después de la modificación va a tener que hacer todas las consultas para saber qué mostrarle a ese usuario, pero para el siguiente visitante, ya le va a entregar instantáneamente estos resultados. En conclusión, cuando visitamos una página web, la primera vez tarda mucho en cargar, pero cuando volvemos a visitar esa misma URL después, ya no tarda casi nada; esto es porque se ha almacenado todo tanto en la caché del servidor como en la caché del navegador del usuario, ya que el navegador también guarda las páginas que cargamos, entonces no vuelve a descargarse esa imagen, porque ya la tiene descargada en el navegador.
• Caché dinámica: todos los contenidos en vez de guardarlos en disco, los guarda en memoria RAM, es parecido a los móviles, ya que va almacenando las aplicaciones que vamos abriendo, todos los datos necesarios que vamos introduciendo, por ejemplo, un juego o alguna consulta web los almacena la memoria RAM del dispositivo; solamente lo guarda en disco cuando le damos a guardar. Esta caché volátil es mucho más rápida, ya que hace las consultas al disco directamente. 
• MemCached: caché de objetos. Las consultas más frecuentes que se hacen a la base de datos, por ejemplo, para mostrar comentarios, mostrar un menú desplegable,etc, también se almacenan en un caché que se sirve al mismo usuario. Este tipo de caché es importante porque marca la diferencia entre un CMS, en este caso WordPress, y un HTML. Lo que hace con la caché es entregar el HTML directamente, ya se tiene el HTML creado con una copia y para el próximo visitante que llegue no hay que hacer ninguna consulta, sino que le entrega la página ya hecha. 

Componentes del PLUGIN

Optimización de Heartbeat de WordPress

Es un motor que tiene WordPress por detrás, una aplicación en segundo plano que hace comprobaciones de actualización de plugin, o algo que se debe guardar, pero consume muchos recursos y a veces ralentiza la carga de la página porque debe de hacer muchas consultas a la base de datos. Todo esto se puede optimizar desactivándolo completamente o activándose sólo para ciertos elementos, por ejemplo, solamente cuando se está editando, para que te haga los guardados automáticos. 

Es importante precargar las DNS de dominios externos, si ya sabemos que siempre vamos a hacer una consulta al servidor de Google Analytics para revisar la analitica de nuestra landing. Lo que se hace es precargar la consulta al servidor de ese dominio de manera que reducimos el tiempo de espera. Así mismo, mantener la base de datos en condiciones, vaciar lo que ya no usamos… etc., tener en cuenta la compresión GZIP, que debe venir activa por defecto desde el servidor y la caché del navegador. Nuestro navegador también guarda imágenes,esto se puede optimizar forzando a que el navegador de nuestro usuario guarde por más tiempo los recursos de nuestra página hasta que estos hayan cambiado; se maneja como una especie de comunicación entre nuestra landing y el navegador de los usuarios que nos visitan, mediante una cookie, que comprueba cuán antiguo es el contenido que tiene almacenado tu navegador y si tú tienes algo más novedoso se lo entregas, y si no. que el navegador tire de él.

Optimización de entrega de nuestra landing

Se busca minimizar toda la serie de códigos, HTML, JavaScript…etc. Como por ejemplo,  espacios que sobran, líneas vacías, líneas muertas… Con esto se logra convertir un HTML de 1000 KW en 20 KW.  Al final con menos peso, tarda menos en mostrarse en el navegador. Esto es, sobre todo, para una buena carga en dispositivos móviles, ya que el primer contacto desde una landing page o de una newsletter siempre será por móvil. 

Optimización de la portada

Hay muchos recursos que WordPress carga de manera automática y nosotros podemos quitarlos para mejorar la optimización, como por ejemplo combinar o minimizar archivos CSS, u optimizar la carga de Google Fonts, eliminar todas las consultas extrañas que se hagan de recursos.

Se deben optimizar las nuevas imágenes 

Se deben entregar en formato WebP, formato de imágenes que permite tener una carga menos pesada y lograr optimizarla para cuando tengamos muchas imágenes en la landing page. 

Carga diferida de medios: se busca que todos aquellos elementos como avatares, las fotos en miniatura, videos…etc, se vayan cargando a medida de que el usuario navegue. 

SpeedTest

Muestra un poco los consejos de optimización de acuerdo a google score.

Si no se puede utilizar el SG Optimizer se puede utilizar una Optimización (plus), que sirve todo el contenido que tengamos desde CDN, estas se definen como copias de nuestra página que se alojan en servidores externos, y entrega copias dependiendo de donde se conecte el usuario.

También, existe el plugin “WP Rocket”, se puede utilizar en cualquier hosting, es de pago, 60€ al año, y prácticamente tiene todas las optimizaciones antes vistas.

Opciones de plugin de Optimización

• Cache Enabler por KeyCDN.
• Mejoras y optimizaciones de WPO por Fernando Tellado.
• Autoptimize por Frank Goossens.
• WebP Express.

Conclusión: 

WordPress no es lento, se puede optimizar con una landing hecha con WordPress o HTML, requiere un poco más de trabajo pero nos da flexibilidad y facilidad a la hora de modificar nuestras landing pages, gracias a la cantidad de plantillas con la que cuenta WordPress.