Un caso de éxito sobre los cambios que implementó GoDaddy para mejorar el rendimiento de millones de sitios y ayudar a obtener buenas puntuaciones de PageSpeed Insights y las Métricas web esenciales.
GoDaddy es la plataforma de servicios para emprendedores más grande del mundo. Tenemos la misión de empoderar 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ó Sitios web y marketing con el compromiso de ofrecer herramientas y servicios que sean fáciles de usar y ayuden a los propietarios de empresas a alcanzar sus objetivos. Sitios web y marketing integra la creación de sitios web con herramientas de marketing y comercio electrónico, y los combina con una guía de primer nivel para ayudar a los clientes a alcanzar el éxito con sus nuevos emprendimientos.
Desde el lanzamiento de los sitios web y el marketing, el rendimiento ha sido una parte importante del producto y es algo que se ha supervisado y trabajado activamente. En este artículo, revisaremos el recorrido de GoDaddy desde las pruebas de rendimiento de laboratorio hasta el uso de datos reales con Métricas web esenciales y la serie de mejoras realizadas en el producto para obtener una tasa de aprobación muy alta en los sitios de nuestros clientes.
Cómo hacer un seguimiento del rendimiento con Lighthouse
Nos basamos en los datos de Lighthouse para realizar un seguimiento del rendimiento. Cada vez que se publica un sitio web en la plataforma, medimos su rendimiento con nuestra herramienta interna llamada "Lighthouse4u", que ofrece Google Lighthouse como un servicio en https://github.com/godaddy/lighthouse4u. Esto nos proporcionó una buena indicación del rendimiento general de los sitios en una configuración del lab.
Debido a que los millones de sitios que alojamos en nuestra plataforma tienen una amplia gama de funciones y contenido, era importante combinar datos de rendimiento con metadatos sobre cada sitio que se estaba probando (como la plantilla utilizada, el tipo de widgets renderizados, etc.). Esto nos permitió sacar conclusiones sobre las funciones del sitio web que tenían un rendimiento más bajo y, al mismo tiempo, nos brindó información sobre dónde buscar mejoras.
Por ejemplo, esto nos ayudó a identificar que la "ventana modal emergente" tenía un impacto negativo en la velocidad de la página; los sitios con esta función tuvieron un rendimiento 12 puntos más bajo que sin ella. Después de realizar actualizaciones en el código para diferir 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.
Además de analizar los sitios problemáticos en función de las funciones, realizamos un análisis de nuestro paquete de JavaScript y vimos que una gran parte de su tamaño provino de dependencias externas (inmutable.js y draft.js). Redujimos el tamaño del paquete mediante la reestructuración de los consumidores para que carguen de forma diferida las dependencias a pedido. Como resultado, se redujo en más del 50% el tamaño común del paquete de JavaScript, que pasó de 200 KB a alrededor de 90 KB (minificado). El tamaño del paquete más pequeño permitió que el navegador cargara elementos externos y ejecutara secuencias de comandos críticas antes en el ciclo de vida de carga inicial del sitio, lo que generó ganancias en el Largest Contentful Paint (LCP) y el Retraso de primera entrada (FID).
Gracias a nuestros esfuerzos continuos, la puntuación promedio de Lighthouse en el sitio del cliente pasó de alrededor de 40 puntos en noviembre de 2020 a superar los 70 puntos en mayo de 2021. Sin embargo, no todos nuestros intentos funcionaron y a veces nos sorprendíamos cuando los resultados no siempre eran coherentes entre lo que se probó en los entornos de pruebas locales y los resultados que obtuvimos en el campo. Los resultados de los laboratorios habían sido muy útiles, pero era hora de centrarnos en las experiencias de usuario reales observadas en el campo.
Seguimiento de 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 datos en dispositivos reales de visitantes reales, donde el hardware, la velocidad de la red, la interacción del usuario (como el desplazamiento o los clics) no están en un modelo de referencia coherente como en la configuración de un lab con Lighthouse. Este era 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.
Enfócate en el vínculo más débil: Cambio de diseño acumulado (CLS)
Analizar los datos nuevos nos brindó una nueva perspectiva sobre lo que teníamos que hacer para mejorar la velocidad del sitio web. Debido al trabajo realizado para mejorar la puntuación de Lighthouse, nuestro LCP del percentil 75 fue de 860 ms y nuestro FID en el mismo umbral era inferior a 10 ms, por lo que disfrutamos de una tasa de aprobación alta 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 bastante diferentes a los que estábamos acostumbrados 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 nuestra tasa 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 que esa cifra superara el 60% a fines de agosto de 2021. Para ello, tendríamos que enfocarnos en CLS.
En la vida real, los usuarios interactúan con la página y se desplazan más allá del contenido de la "mitad superior de la página", algo que las Métricas web esenciales capturan mejor. Debido a la variabilidad en la forma en que los usuarios interactúan con el sitio mientras se carga inicialmente, CLS difiere de los datos de laboratorio y campo.
El camino para aprobar todas las Métricas web esenciales
Mejorar el rendimiento requiere un proceso de prueba y error, y los intentos no siempre funcionan 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 cambie. Usamos la propiedad aspect-ratio de CSS para solucionar este problema en navegadores que la admiten. Para quienes no lo tengan, cargamos una imagen de marcador de posición transparente que se almacenó en caché y con un tamaño de unos pocos bytes, por lo que se carga casi de inmediato.
Este comportamiento de imagen genérica nos permitió calcular previamente la altura final de la imagen durante la renderización del servidor, según el ancho de la vista del puerto y la relación de aspecto de la imagen. Como resultado, se usó el lenguaje de marcado HTML con el espacio vertical correctamente reservado para la imagen final. La mejora fue especialmente observable en dispositivos móviles, ya que las imágenes se renderizan en la totalidad de las vistas del puerto de 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 puros 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 (por lo tanto, la altura) variará. En esos casos, unimos el componente a 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. Se quita el min-height una vez que finaliza la renderización del componente dinámico interno. Si bien no era perfecta, esta solución nos permitió reducir mucho el cambio de diseño.
Si bien nos enfocamos en las mejoras de CLS, continuamos trabajando en el LCP. En muchos sitios web, las imágenes son el mayor responsable de contribuir al LCP y, para nosotros, fue un área de mejora evidente. Hicimos mejoras para la carga diferida de imágenes con IntersectionObserver, pero nos dimos cuenta de que los tamaños de imagen no se configuraban de la manera más óptima para cada punto de interrupción (dispositivo móvil, tablet, computadora de escritorio y computadora de escritorio grande), por lo que actualizamos nuestro código de generación de imágenes para restringir y ajustar las imágenes por punto de interrupción y, luego, ajustamos la resolución de nuevo en función de la densidad de píxeles. Por ejemplo, esto redujo el tamaño de una imagen grande específica de 192 KB a 102 KB.
Para renderizar rápidamente sitios web en dispositivos con conexiones de red deficientes, agregamos código para reducir dinámicamente la escala de la calidad de la imagen en función de la velocidad de conexión. Esto se puede hacer con la propiedad downlink que muestra navigator.connection. Aplicamos parámetros de búsqueda basados en URLs para reducir la calidad de las imágenes a través de nuestra API de recursos en función de 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 del recurso rel=preconnect para inicializar la conexión y los protocolos de enlace necesarios de antemano. También usamos sugerencias de recursos para cargar fuentes y otros recursos importantes rápidamente.
Cuando los clientes crean sus sitios, agregan varias secciones que pueden tener secuencias de comandos intercaladas para permitir diferentes funcionalidades. Tener estas secuencias de comandos intercaladas en la página HTML no siempre es lo óptimo para el rendimiento. Decidimos externalizar estas secuencias de comandos para permitir que el navegador cargue y analice el contenido de las secuencias de comandos de forma asíncrona. Las secuencias de comandos recientemente externalizadas también se pueden compartir entre páginas. Esto permitió obtener mejoras de rendimiento adicionales en forma de almacenamiento en caché de la CDN y el navegador. Mantuvimos las secuencias de comandos críticas en línea para que el navegador las analice y las ejecute más rápido.
Resultados
Al enfocar nuestro esfuerzo en CLS, comprobamos que la tasa de aprobación de las Métricas web esenciales pasa de alrededor del 40% a casi el 70%, lo que representa una mejora del 75%.
A medida que los usuarios regresan a nuestra plataforma para realizar actualizaciones y vuelven a publicar sus sitios, obtienen las mejoras de rendimiento más recientes y, como resultado, la cantidad de sitios que "aprueban las Métricas web esenciales" crece de forma constante, tal como se muestra en el siguiente gráfico:
Conclusiones
Encontrar áreas para mejorar el rendimiento y hacer un seguimiento satisfactorio del progreso depende en gran medida de las herramientas que se utilizan para la medición. Si bien Lighthouse resultó útil para medir el rendimiento de la mitad superior de la página en un "parámetro de configuración de lab", no capturó con precisión los problemas de rendimiento que solo se producían a partir de las interacciones del usuario (como el desplazamiento 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 recorrido para mejorar las puntuaciones de las Métricas web esenciales le permitió al equipo identificar y reemplazar los patrones sin rendimiento encontrados en nuestra base de código. A veces, los cambios prometedores no tenían casi el impacto que esperábamos; otras veces, ocurrió lo contrario. No es un mundo inmaculado, así que tienes que seguir intentándolo.