Adaptando la performance a Lighthouse 6
Lighthouse es una de las herramientas bajo la cual Google mide y califica la performance de las páginas. La podemos ver a través de las herramientas de desarrollador que vienen dentro de Chrome como directamente en la página de Page Speed (para conocer más sobre estas y otras herramientas para medir la performance les recomiendo este artículo ).
Durante Mayo del 2020 Google lanzó una actualización que hizo que nuestros diseños de base pasen de medir 90 puntos en Page Speed, a medir 70 puntos (o incluso menos).
La idea de este artículo es compartir que hicimos cuándo sucedió esto y que aprendizajes tuvimos para recuperar este tan preciado color verde en los resultados de Google.
¿Qué pasó?
“Mi tienda está más lenta que antes”
Este es el feedback que comenzó a llegar de vendedores que empezaron a ver que el puntaje de sus tiendas había caído.
La realidad es que al momento que Google aplicó sus cambios, los sitios en general no perdieron velocidad de carga, sino que su puntaje bajó repentinamente.
¿Esto lo hace menos importante? Para nada, si bien un sitio que antes tardaba 3 segundos en cargar ahora tarda lo mismo, para el buscador más grande que existe puede que se califique como más lento.
Si para Google sos más lento, no importa si tenés un fórmula 1, ellos le van a decir a todo el mundo que tenés una bicicleta y todos le van a creer. De hecho el puntaje que usan impacta en el SEO de su buscador.
Hay dos cambios clave que introdujo Google que impactó en nuestras tiendas:
LCP: Largest Contentful Paint
El LCP mide el tiempo que tarda en cargarse y acomodarse en la pantalla el componente visual más grande. Cuanto más rápido se cargue y menos varíe el LCP, mejor es el puntaje.
Un ejemplo de un LCP incorrecto puede verse debajo, donde al parecer al comienzo corresponde al título pero luego cuando se carga la imagen, pasa a ser éste el componente más grande.
Un LCP mejor resuelto se puede ver debajo dónde la mayor parte del tiempo se mantiene el mismo componente como el de mayor tamaño.
CLS: Cumulative Layout Shift
El CLS representa la cantidad de cambios o saltos visuales que se producen en la pantalla hasta que terminó su carga. Cuanto menos saltos visuales sucedan, mejor será la experiencia para el usuario.
Debajo un ejemplo de un típico caso donde los componentes “saltan” o cambian de lugar debido a que se cargan de forma poco eficaz.
La relación entre el LCP y el CLS es muy importante, ya que varios saltos visuales en la carga (mucho CLS) pueden impactar en la lectura del LCP.
Un ejemplo claro se puede dar cuando tenemos un carrusel de imágenes como componente principal (siendo un claro LCP), pero este usa un Javascript muy pesado y demoramos mucho en hacer el pedido de sus imágenes al servidor. Esto puede resultar en un LCP que se carga tarde y a medida que se vaya cargando se generen saltos visuales hasta que quede todo acomodado.
¿Qué hicimos?
Lo primero que tuvimos que entender fue que la performance ya no sólo se trata de “reducir el peso de los archivos que cargamos” (además de muchas cosas más en relación a JS, CSS e imágenes), sino que también se trata de adelantar la carga de lo más importante y dentro de esto empieza a entrar en juego cargar lo antes posible de nuestro LCP.
LCP… CLS… ¿Cómo los mido? ¿Dónde los encuentro?
Hay dos formas de medir estos parámetros. En los resultados de Page Speed podemos ver el resultado en términos de tiempo para el LCP y resultado numérico calculado por Google para el CLS:
Por otro lado para identificar exactamente qué componente necesitamos pulir usamos Google Chrome Canary , haciendo click derecho en la pantalla e inspeccionando elemento.
Una vez que cargue el sitio podemos ir a la tab de Performance y cliquear en el icono circular tipo “refresh” (se llama reload en inglés). Esto va a generar un reporte detallado de la performance medida, para entender más sobre esta herramienta les recomiendo que lean las guías de Google.
El reporte en una plantilla nuestra, Amazonas, se ve como el siguiente:
En la parte derecha encontramos algo que dice LCP, donde al posarnos con el mouse nos va a marcar cuál es el LCP (en este caso la imagen principal del carrusel), mientras que en rojo vemos los CLSs (Layout Shift).
Es importante remarcar que el LCP puede variar en base a distintas personalizaciones de la plantilla y es acá donde hasta hoy tenemos un desafío grande.
El CLS reportado no siempre tiene que estar relacionado al LCP, por lo que nosotros decidimos enfocarnos en esto(por ahora) solo si encontramos CLS que impacte al LCP. Para saber esto, simplemente posamos el mouse sobre el Layout Shift y va a sombrearse el elemento donde impacta.
Ya sé cuales son ¿Y ahora?
Sabiendo cuál es el LCP, tenemos que hacer todo lo posible para que se cargue cuanto antes y con el menor CLS posible. Esto nos lleva a leer los resultados del análisis de performance cómo una línea de tiempo, donde todo lo que está a la izquierda del LCP (mirando la mitad superior de la imagen debajo), es algo que bloquea la carga el mismo.
Acá la solución va a depender de cada sitio, obviamente no podemos remover todos los recursos del sitio antes del LCP porque se vería roto pero si empezar a probar que pedidos al servidor podemos adelantar, posponer o ahorrar.
En nuestras tiendas esto nos llevó a
- Pulir la carga de los recursos en la etiqueta head de HTML (CSS, JS, tipografías) y precargar todo lo crítico que podamos sin bloquear la carga en general.
- Reducir al máximo plugins de Javascript y CSS innecesario.
- Pedirle al servidor sólo las imágenes críticas (el slider principalmente) y el resto cargarlas usando Lazy load.
Algo que ayudó mucho fue la precarga de recursos críticos a través de la etiqueta de html link rel=”preload” dentro de la etiqueta head.
Gracias a esto adelantamos la carga de la primer imagen en el carrusel principal (e incluso en el primer banner que ve en mobile) y el SASS que aplica colores y tipografías. Debajo un ejemplo de cómo implementamos esto.
{% if settings.slider or settings.slider is not empty %}
{% for slide in settings.slider %}
{% if loop.first %}
<link rel="preload" as="image" href="{{ slide.image | static_url | settings_image_url('1080p') }}">
{% endif %}
{% endfor %}
{% endif %}....<link rel="preload" href="{{ 'custom.scss.tpl' | static_url }}" as="style">
¿Seguimos usando placeholders?
Si bien son algo que queda muy bueno a nivel visual, poco a poco con estos cambios vamos a ver que los placeholders para reemplazar el LCP ya no son necesarios.
Tener un placeholder en un LCP es seguir atrasando la carga del mismo y generando un salto visual que ahora Google penaliza, así que si hacemos bien las cosas y cargamos lo más crítico antes y rápido, el sentido del placeholder se pierde.
Por otro lado hablamos anteriormente de reducir la carga de imágenes innecesarias. Esto aplica sobretodo a las imágenes de banners y listado de productos, donde cargar una imagen en baja calidad y luego reemplazarla por la versión final puede verse muy bien pero si nos ahorramos ese pedido al servidor y simplemente mostramos la imagen final por una animación de fundido; podemos estar teniendo un resultado que no daña la experiencia y mejora la performance.
¿Cuál fué el resultado?
Si bien todas las plantillas varían su diseño y aún podemos mejorar la performance en todas, un ejemplo del resultado de estos cambios es con la plantilla Simple donde había bajado su puntaje a 70 pts aproximadamente y ronda los 85 a 89 pts. Debajo podemos ver el antes vs el ahora .
¿Cómo seguimos?
Esta batalla no terminó, seguimos haciendo pruebas y mejoras todo el tiempo porque queremos recuperar los 90 pts estables en todas las plantillas y con todas configuraciones de diseño, pero lo más importante que aprendimos más allá de lo técnico fue:
- No frustrarse. Cada exigencia de Google hace que la experiencia de los usuarios mejore y que nosotros aprendamos algo nuevo.
- Siempre hay lugar para mejorar.
- Probar, probar y probar. Las herramientas de Google ya no son tan exactas como hace un año. No se queden con un sólo resultado o medición, hagan varias pruebas.
Esta historia continuará…
¡Gracias a Bruno Navello y Seba Marcó! Designers que la rompen en Tiendanube y trabajaron conmigo en todas estas mejoras.
Para más información de otras mejoras en relación a performance aplicadas durante el año pasado, les recomiendo leer:
