Cómo los sitios web y el servicio de marketing de GoDaddy mejoraron las Métricas web esenciales de los clientes en un 75%

Un caso de éxito sobre los cambios que implementó GoDaddy para mejorar el rendimiento de los sitios web de millones de sitios, lo que les permitió obtener buenas puntuaciones en PageSpeed Insights y Métricas web esenciales.

Simon Le Parc
Simon Le Parc

GoDaddy es la plataforma de servicios más grande del mundo para emprendedores de todo el mundo. Nuestra misión es fortalecer a nuestra comunidad mundial de más de 20 millones de clientes y emprendedores de todo el mundo brindándoles toda la ayuda y las herramientas que necesitan para crecer en línea.

En 2019, GoDaddy lanzó Websites + Marketing con el compromiso de ofrecer herramientas y servicios fáciles de usar que ayuden a los propietarios de empresas a alcanzar sus objetivos. Websites + Marketing integra la creación de sitios web con herramientas de marketing y comercio electrónico, y las combina con la mejor orientación para ayudar a los clientes a tener éxito con sus nuevas empresas.

Desde el lanzamiento de Websites + Marketing, el rendimiento ha sido una parte importante del producto y algo en lo que se ha supervisado y trabajado de forma activa. En este artículo, revisaremos el recorrido de GoDaddy desde el uso de pruebas de rendimiento de laboratorio hasta el uso de datos del mundo real con las Métricas web esenciales, y la serie de mejoras que se realizaron en el producto para obtener un porcentaje de aprobación muy alto para los sitios de nuestros clientes.

Realiza un seguimiento del rendimiento con Lighthouse

Nos basamos en los datos de Lighthouse para el seguimiento del rendimiento. Cada vez que se publica un sitio web en la plataforma, medimos su rendimiento con nuestra herramienta interna llamada "Lighthouse4u", que proporciona Google Lighthouse como servicio https://github.com/godaddy/lighthouse4u. Esto nos dio una buena indicación de cómo se desempeñaban los sitios en general en un entorno de lab.

Debido a que los millones de sitios que alojamos en nuestra plataforma tienen una amplia variedad de funciones y contenido, era importante combinar los datos de rendimiento con metadatos sobre cada sitio que se estaba probando (como la plantilla utilizada, el tipo de widgets renderizados, etcétera). Esto nos permitió sacar conclusiones sobre qué funciones del sitio web tenían un rendimiento más bajo y, al mismo tiempo, proporcionar estadísticas sobre dónde buscar mejoras.

Por ejemplo, esto nos ayudó a identificar que el "modal emergente" tenía un impacto negativo en la velocidad de la página; los sitios con la función tenían un rendimiento 12 puntos más bajo que los que no la tenían. Después de actualizar el código para aplazar la carga de JavaScript, mejoramos nuestra puntuación de Lighthouse en 2 puntos. Pudimos aplicar este aprendizaje a otras funciones, como el "banner de cookies" que se renderiza poco después de que se carga la página.

Gráfico que muestra las puntuaciones de Lighthouse para sitios con y sin una ventana modal emergente. Los sitios sin un diálogo modal emergente son más rápidos de forma coherente.
Gráfico que muestra la puntuación de rendimiento de los sitios con y sin un "modal emergente" (líneas azul y verde, respectivamente) antes y después de la mejora del rendimiento.

Además de analizar los sitios problemáticos en función de las funciones, realizamos un análisis de nuestro paquete de JavaScript y descubrimos que una gran parte de su tamaño provenía de dependencias externas (immutable.js y draft.js). Reestructuramos los consumidores para cargar dependencias de forma diferida a pedido y, de esta manera, reducir el tamaño del paquete. Esto generó una disminución de más del 50% en el tamaño del paquete común de JavaScript, que pasó de más de 200 KB a alrededor de 90 KB (reducido). El tamaño más pequeño del paquete permitió que el navegador cargara recursos externos y ejecutara secuencias de comandos críticas antes en el ciclo de vida de carga inicial del sitio, lo que generó mejoras en el procesamiento de imagen con contenido más grande (LCP) y el retraso de primera entrada (FID).

Gráfico que muestra las puntuaciones promedio de Lighthouse a lo largo del tiempo. La puntuación promedio mejora después de eventos como la reducción del paquete de JavaScript, la aplazamiento de los componentes de JavaScript y las optimizaciones de imágenes.
Puntuación promedio de Lighthouse para los sitios publicados recientemente a lo largo del tiempo. Las optimizaciones principales se superponen en el gráfico para mostrar el impacto.

Gracias a nuestros esfuerzos continuos, la puntuación promedio de Lighthouse de los sitios de clientes pasó de alrededor de 40 puntos en noviembre de 2020 a más de 70 puntos en mayo de 2021. Sin embargo, no todos nuestros intentos funcionaron y, a veces, nos sorprendimos cuando los resultados no siempre fueron coherentes entre lo que se probó en los entornos de prueba locales y los resultados que obtuvimos en el campo. Los resultados de las pruebas de laboratorio fueron muy útiles, pero era hora de enfocarse en las experiencias reales de los usuarios observadas en el campo.

Realiza un seguimiento de los datos de usuarios reales con las Métricas web esenciales

Después de agregar la biblioteca web-vitals a los sitios de nuestros clientes, pudimos medir los datos en dispositivos reales de visitantes reales, en los que el hardware, la velocidad de la red y la interacción del usuario (como el desplazamiento o los clics) no se encuentran en un modelo de referencia coherente como en un entorno de laboratorio con Lighthouse. Este fue un gran paso en la dirección correcta, ya que ahora teníamos datos representativos de lo que experimentaban los visitantes de nuestro sitio web.

El análisis de datos nuevos nos dio una nueva perspectiva sobre lo que debíamos hacer para mejorar la velocidad del sitio web. Debido al trabajo que realizamos para mejorar la puntuación de Lighthouse, nuestro LCP del percentil 75 fue de 860 ms y nuestro FID en el mismo umbral fue inferior a 10 ms, por lo que disfrutamos de un alto porcentaje de aprobación para estas métricas en los sitios de nuestros clientes: 78% y 98%, respectivamente. Sin embargo, los números de Cambio de diseño acumulado (CLS) se ven muy diferentes de lo que estábamos acostumbrados a ver con Lighthouse. Nuestro CLS en el percentil 75 fue de 0.17 (por encima del umbral de 0.1 para "aprobar") y, por lo tanto, nuestro porcentaje de aprobación fue de solo el 47% en todos nuestros sitios.

Esa métrica redujo nuestro porcentaje de aprobación general al 40%, por lo que decidimos establecer un objetivo ambicioso para aumentar esa cifra a más del 60% a fines de agosto de 2021. Para ello, deberíamos enfocarnos en el CLS.

En la vida real, los usuarios interactúan con la página y se desplazan más allá del contenido "sobre la mitad superior de la página", lo que las Métricas web esenciales captan mejor. Debido a la variabilidad en la forma en que los usuarios interactúan con el sitio mientras se carga inicialmente, el CLS difería de los datos de campo y de laboratorio.

El camino para aprobar todas las Métricas web esenciales

Mejorar el rendimiento requiere un proceso de prueba y error, y no siempre cada intento funciona como se espera. Sin embargo, estas son algunas mejoras que nos ayudaron a alcanzar nuestros objetivos.

Reservar espacio para cargar imágenes mejoró drásticamente nuestra puntuación de CLS, ya que evita que el contenido debajo de las imágenes se desplace. Usamos la propiedad aspect-ratio de CSS para abordar este problema en los navegadores que la admiten. En el caso de los que no lo hacen, cargamos una imagen de marcador de posición transparente que se almacenó en caché y tiene un tamaño de solo unos pocos bytes, por lo que se carga casi de forma instantánea.

Este comportamiento genérico de las imágenes nos permitió calcular previamente la altura de la imagen final durante la renderización del servidor, en función del ancho del viewport y la relación de aspecto de la imagen. Esto generó un marcado HTML con espacio vertical reservado de forma adecuada para la imagen final. La mejora se observó especialmente en los dispositivos móviles, ya que las imágenes se renderizan en todo el rango de viewports para dispositivos móviles.

Algunos componentes de los sitios de nuestros clientes tienen contenido dinámico (por ejemplo, una lista de opiniones externas de clientes) y no se pudieron convertir a CSS puro para aprovechar los beneficios de rendimiento de la renderización del servidor. Estas son áreas difíciles para mejorar los cambios de diseño porque el contenido (y, por lo tanto, la altura) variará. En esos casos, unimos el componente en un contenedor con un min-height aplicado, predeterminado en función de la observación de la altura promedio de cada uno de los componentes específicos. El min-height se quita una vez que se termina de renderizar el componente dinámico interno. Si bien no es perfecta, esta solución nos permitió reducir mucho el cambio de diseño.

Mientras nos enfocamos en las mejoras de CLS, seguimos trabajando en el LCP. En muchos sitios web, las imágenes son el principal factor que afecta el LCP, y para nosotros era un área de mejora evidente. Realizamos mejoras en la carga diferida de imágenes con IntersectionObserver, pero nos dimos cuenta de que los tamaños de las imágenes no se configuraban de la manera más óptima para cada punto de inflexión (dispositivos móviles, tablets, computadoras de escritorio y computadoras de escritorio grandes), por lo que actualizamos nuestro código de generación de imágenes para restringir y escalar las imágenes por punto de inflexión y, luego, volver a escalar la resolución en función de la densidad de píxeles. A modo de ejemplo, esto redujo el tamaño de una imagen grande específica de 192 KB a 102 KB.

Para renderizar sitios web rápidamente en dispositivos con conexiones de red deficientes, agregamos código para reducir de forma dinámica la calidad de la imagen según la velocidad de conexión. Esto se puede hacer con la propiedad downlink que devuelve navigator.connection. Aplicamos parámetros de consulta basados en URLs para reducir la calidad de las imágenes a través de nuestra API de recursos según esas condiciones de red.

Algunas secciones de los sitios de nuestros clientes se cargan de forma dinámica. Como sabemos qué secciones se renderizarán en un sitio determinado cuando se publique, usamos la sugerencia de recursos rel=preconnect para inicializar la conexión y los protocolos de enlace necesarios con anticipación. También usamos sugerencias de recursos para cargar fuentes y otros recursos importantes con rapidez.

Cuando crean sus sitios, los clientes agregan varias secciones que pueden tener secuencias de comandos intercaladas para permitir diferentes funcionalidades. Tener estas secuencias de comandos intercaladas en toda la página HTML no siempre es lo más adecuado para el rendimiento. Decidimos externalizar estas secuencias de comandos para permitir que el navegador cargue y analice el contenido de la secuencia de comandos de forma asíncrona. Las secuencias de comandos externas nuevas también se pueden compartir entre páginas. Esto permitió obtener mejoras de rendimiento adicionales en forma de almacenamiento en caché del navegador y de la CDN. Mantuvimos las secuencias de comandos críticas intercaladas para que el navegador las analice y ejecute más rápido.

Resultados

Enfocar nuestros esfuerzos en la CLS dio sus frutos, ya que nuestro porcentaje de aprobación de las Métricas web esenciales pasó de alrededor del 40% a casi el 70%: ¡una mejora del 75%!

Gráfico que muestra las Métricas web esenciales a lo largo del tiempo. Todas las Métricas web esenciales (excepto la FID) mejoran de forma constante con el tiempo.
Porcentaje de sitios web activos y de sitios web de marketing que "superan las métricas web esenciales" a lo largo del tiempo (general y submétrica).

A medida que los usuarios vuelven a nuestra plataforma para actualizar y volver a publicar sus sitios, obtienen las mejoras de rendimiento más recientes y, como resultado, la cantidad de sitios que “superan las Métricas web esenciales” ha aumentado de forma constante, como se muestra en el siguiente gráfico:

Gráfico que muestra Métricas web esenciales óptimas a lo largo del tiempo segmentadas en segmentos de dispositivos móviles y computadoras de escritorio. La tendencia mejora con el tiempo.
Gráfico que representa los sitios del Creador de sitios web de GoDaddy con "Métricas web esenciales buenas". Fuente: cwvtech.report

Conclusiones

Encontrar áreas para mejorar el rendimiento y hacer un seguimiento exitoso del progreso depende en gran medida de las herramientas que se usen para la medición. Si bien Lighthouse era útil para medir el rendimiento de la mitad superior de la página en un "entorno de lab", no capturaba con precisión los problemas de rendimiento que solo se producían por las interacciones del usuario (como desplazarse por la página).

El seguimiento de las Métricas web esenciales reales con metadatos nos permitió visualizar, segmentar y medir el impacto de nuestras mejoras. El proceso para mejorar las puntuaciones de las Métricas web esenciales permitió al equipo identificar y reemplazar los patrones de bajo rendimiento que se encontraban en toda nuestra base de código. A veces, los cambios prometedores no tuvieron el impacto que esperábamos, y en otras ocasiones sucedió lo contrario. No es un mundo perfecto, así que debes seguir intentándolo.