Lento por error vs lento por diseño

Lento por error vs lento por diseño.

Cuando me contratas para arreglar o hablar sobre los Core Web Vitals, en algún momento me escucharás hablar de lento por error vs lento por diseño.  Creo que es una distinción fundamental y en este artículo explicaré cómo esto te ayudará a mejorar los Core Web Vitals.

Lento por error

Me encantan los anti-patrones de 'lento por error'. Hiciste algo que ralentizó la página. Cometiste un error. No sabías que hay una forma mucho más rápida de hacer esto. No te preocupes, puedo arreglar errores. 

Así que categorizar estos 'errores' tiene sentido. Me dará una lista de mejoras fáciles de implementar y de alto impacto que puedo enviar a tu equipo de desarrollo (o arreglar yo mismo). Normalmente no se necesita mucha discusión. Mejorar estos anti-patrones simplemente tiene sentido desde todos los ángulos. Una vez que se arreglen, los Core Web Vitals mejorarán.

Aquí hay algunos ejemplos de anti-patrones que encuentro a diario. Cuando explico qué y por qué, normalmente obtengo un 'ohh, no sabía que esto ralentizaría la página'.

1. Imágenes sin lazy load

El anti-patrón más común son las imágenes sin lazy load. Las imágenes que no tienen lazy load se pondrán en cola para descarga durante las primeras etapas de carga de la página. Esto utilizará recursos de red y CPU. No tiene sentido asignar recursos valiosos a imágenes que ni siquiera son visibles, ¿verdad? 

2. Fuentes de terceros

3. Scripts de terceros

4. Imágenes de fondo

5. Hojas de estilo grandes

Lento por diseño

Lento por diseño es la parte que debería preocuparte. Tomaste decisiones estructurales que ralentizaron la página.  Normalmente involucran decisiones de diseño UX o código JavaScript que modifica la parte visible de la página hasta tal punto que no hay buenas soluciones alternativas.

El problema con 'lento por diseño' es que no se puede arreglar inmediatamente haciendo pequeños cambios. Requiere más planificación y reescribir algunas funcionalidades principales del sitio. 

Lo primero que necesito hacer es entender la intención: ¿Por qué hiciste esto? ¿Cuáles fueron las consideraciones y qué exactamente pretendías lograr? ¡Y luego dentro de esos parámetros encontrar una mejor alternativa!

Aquí hay algunos ejemplos de los errores más comunes de 'lento por diseño'.

1. Sliders

Los sliders normalmente funcionan así: Cuando la página se renderiza, un JavaScript inyectará el slider en la página. Sin este JavaScript la página se vería completamente diferente.  Esto causará un Largest Contentful Paint más largo, probablemente un Layout Shift y muy probablemente problemas con el First Input Delay.

No hay una solución rápida. Diferir el JavaScript mejorará las métricas de pintado pero retrasará el slider y causará un layout shift. Hacer el script del slider crítico arreglará el Layout Shift pero ralentizará las métricas de pintado.

La solución es mejorar progresivamente la página. Primero asegúrate de que el slider se renderice sin JavaScript y luego mejora la página y transforma la imagen del slider ya presente en un slider completo. 

Lo divertido es: 9 de cada 10 veces cuando explico esto, el propietario del sitio inmediatamente sugiere eliminar el slider. Por eso es importante preguntar sobre las intenciones y consideraciones de estos sliders. Normalmente 'simplemente estaban ahí'.

2. Zoom de producto

El zoom de producto funciona así: en tu tienda online promedio, pasa el cursor sobre una imagen de producto y podrás hacer zoom en una parte del producto.  El 'zoom de producto' normalmente tiene el mismo problema que los sliders.  Un fragmento de código JavaScript tomará tus imágenes, las ocultará, y las reescribirá en la página como imágenes con zoom. Esto causará un Largest Contentful Paint más largo, probablemente un Layout Shift y muy probablemente problemas con el First Input Delay.

La diferencia con el slider es que ningún propietario de producto dirá nunca: "oh, simplemente elimina esta funcionalidad". Es importante y aumenta la conversión.

La solución es la misma que la del slider. El script de zoom no debería ocultar las imágenes originales sino extender la funcionalidad de la imagen del producto. Desafortunadamente la funcionalidad de zoom normalmente no se arregla fácilmente y requerirá  algo de trabajo para dejarlo bien.

3. jQuery inline / dependencias de JavaScript inline

jQuery inline es un problema que empezó como un 'lento por error' pero empeoró con el tiempo. Aproximadamente el 50% de los sitios que analizo sufren este problema. Debido a que los scripts inline dependen de un script anterior (normalmente jQuery) ya no puedes diferir jQuery. Esto retrasará todas las métricas de pintado.

La solución es simple: Solo mueve estos scripts a un script externo. Ahora puedes diferir tanto jQuery como el script personalizado. 

Entonces, ¿por qué lo coloqué en la categoría de 'lento por diseño'? Cuando pregunto sobre la intención y la consideración normalmente obtengo un 'oh, no sé'. Y ese es el verdadero problema. Hay una falta de conocimiento sobre cómo funciona JavaScript.  Puedo estar bastante seguro de que este error se repetirá en el futuro. Esto significa que la solución no es lo mismo que el arreglo. Necesitaré educar al equipo de desarrollo sobre las dependencias y la temporización de JavaScript.

4. Imágenes grandes (hero)

Otro problema de lento por diseño son las imágenes grandes. Algunos sitios simplemente necesitan 'impresionar a la audiencia' con muchas imágenes a tamaño completo. Imagina que vendes pósters. Probablemente querrías servir imágenes grandes y de alta calidad a tus visitantes. Estas imágenes, sin importar cuánto las optimices, siempre tardarán más en descargarse que las imágenes más pequeñas. 

En este punto (asumiendo que las imágenes están todas optimizadas) lo único que puedo hacer es ver si hay algo de margen. ¿Realmente necesitamos imágenes 4K o sería suficiente con full-HD?

5. Mapas interactivos

Otro problema que encuentro frecuentemente son los mapas interactivos. Cuando una página tiene un mapa interactivo, toda la intención de esta página es hacer que el visitante interactúe con el mapa. Obviamente va a tomar algo de tiempo para que ese mapa cargue. 

No hay forma de evitar esto. Tendremos que aceptar algo de lentitud. Pero hay cosas que podemos hacer. Podemos asegurarnos de que los mapas se carguen con la máxima prioridad. Normalmente estas páginas no están optimizadas para la ejecución temprana de JavaScript. En este caso esa fue la elección equivocada. ¡Necesitamos que el script se descargue y ejecute lo antes posible!

6. APIs lentas

Conclusión

Puede ser útil distinguir entre lento por error y lento por diseño cuando se trata de los Core Web Vitals. Lento por error normalmente se arregla fácilmente mientras que lento por diseño requiere un enfoque más profundo y multidimensional.