Lento por error vs. Lento por diseño: Un framework de rendimiento web

Lento por error vs. lento por diseño.

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

Última revisión por Arjen Karel en marzo de 2026

Cuando alguien me pide consultoría y arreglar los Core Web Vitals siempre hay algo mal. La lentitud siempre proviene de los antipatrones. Por ejemplo, una 'imagen Largest Contentful Paint con lazy loading', 'Imágenes grandes sin optimizar', 'Sliders', 'JavaScript bloqueante', etc.

No se necesita mucho para introducir un antipatrón. A veces, todo lo que necesitas hacer para crear un antipatrón es instalar un plugin o ignorar las mejores prácticas por un momento.

Ahora bien, me gusta categorizar estos antipatrones en 'lento por error' y 'lento por diseño' porque la manera en que los soluciono es completamente opuesta.

Solo el 48% de los orígenes móviles superan los tres Core Web Vitals según el 2025 Web Almanac. En mi experiencia, la mayoría de esos fallos provienen de problemas 'lentos por error' que se pueden solucionar en horas.

Lento por error

Me encantan los antipatrones 'lentos por error'. Hiciste algo que ralentizó la página. Cometiste un error. No sabías que hay una manera mucho más rápida de hacerlo. No te preocupes, puedo arreglar errores.

Así que categorizar estos 'errores' tiene sentido. Me dará una lista de mejoras fáciles de solucionar y de alto impacto que puedo enviar a tu equipo de desarrollo (o arreglar yo mismo). Por lo general, se necesita muy poca discusión. Mejorar estos antipatrones simplemente tiene sentido desde todos los ángulos. Una vez solucionados, los Core Web Vitals mejorarán.

Aquí hay algunos ejemplos de antipatrones con los que me encuentro a diario. Cuando explico qué son y por qué, normalmente obtengo un 'ohh, no sabía que esto ralentizaría la página'.

1. Imágenes sin carga diferida (lazy loading)

El antipatrón más común son las imágenes sin lazy loading. Las imágenes que no tienen carga diferida se pondrán en cola para su descarga durante las primeras etapas de carga de la página. Esto consumirá recursos de red y CPU. No tiene sentido asignar recursos valiosos a imágenes que ni siquiera son visibles, ¿verdad? Aprende más sobre cómo diferir imágenes fuera de pantalla.

El error opuesto es igual de común: hacer lazy loading a la imagen LCP. Alrededor del 15% de los sitios hacen esto, y hace que la imagen más importante de la página cargue más lento en lugar de más rápido.

2. Fuentes de terceros

Las fuentes web son geniales. Personalizarán y mejorarán el aspecto y la sensación de la página. Lamentablemente, el uso de un proveedor externo como Google Fonts no optimizará las fuentes para tu situación específica.

Las fuentes de terceros requerirán una hoja de estilos extra que bloquea el renderizado, una nueva conexión a un servidor web (mientras que ya tienes esta conexión realmente rápida a tu servidor de origen) y probablemente añadirán más fuentes al navegador de las que realmente utilizas.

Tendría mucho más sentido alojar tus propias fuentes, precargarlas y asignar una estrategia de carga de fuentes personalizada a cada archivo. ¡Ahí tienes otra victoria rápida!

3. Scripts de terceros

Aunque no hay nada de malo en los scripts de terceros, causan muchos problemas debido a la forma en que se añaden a las páginas. Me encuentro con scripts de terceros sin importancia (como los píxeles de seguimiento de Facebook, botones de redes sociales, widgets de calificación, etc.) que realmente bloquean toda la página.

Es relativamente fácil y tiene sentido diferir y programar estos scripts hasta que el navegador haya hecho el trabajo más importante. Al final, realmente no cambié nada crítico en el sitio, sigue viéndose igual y carga mucho más rápido. Solo cambié el orden en el que se hacen las cosas.

4. Imágenes de fondo

Desde la perspectiva de los Core Web Vitals, las imágenes de fondo tienen poco sentido. Las imágenes de fondo no tienen soporte nativo para lazy loading, no son responsivas y tienes poco control sobre su sincronización y prioridad.

Con unas cuantas soluciones sencillas podemos transformar estas imágenes de fondo en imágenes normales a las que les podemos aplicar lazy loading, hacerlas responsivas y ajustar su prioridad. Eso sin duda mejorará el Largest Contentful Paint.

5. Hojas de estilo grandes

Las hojas de estilo son bloqueantes de renderizado. Eso significa que mientras el navegador esté cargando las hojas de estilo, la página permanecerá en blanco. Hay muchas cosas que puedes hacer para solucionar esto. Por ejemplo, eliminar estilos no utilizados, dividir la hoja de estilos, mejorar la caché del navegador o añadir Critical CSS.

Una vez que hayamos mejorado las hojas de estilo, ¡tu Largest Contentful Paint y First Contentful Paint mejorarán drásticamente!

Lento por diseño

Lento por diseño es la parte por la que deberías preocuparte. Hiciste elecciones estructurales que ralentizaron la página. Por lo general, implican decisiones de diseño UX o código JavaScript que modifica la parte visible de la página a tal grado que no hay buenas alternativas.

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

Lo primero que debo hacer es entender la intención: ¿Por qué hiciste esto? ¿Cuáles fueron las consideraciones y qué intentabas lograr exactamente? ¡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 generalmente 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á completamente diferente. Esto causará un Largest Contentful Paint más largo, probablemente un Layout Shift y muy probablemente problemas con el Interaction to Next Paint (INP).

No hay una solución rápida. Diferir el JavaScript mejorará las métricas de renderizado, pero retrasará el slider y causará un Layout Shift. Hacer que el script del slider sea crítico solucionará el Layout Shift pero ralentizará las métricas de renderizado.

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

Lo curioso es: solo alrededor del 1% de los visitantes hace clic en un slider. 9 de cada 10 veces que explico esto, el propietario del sitio sugiere inmediatamente eliminar el slider. Por eso es importante preguntar sobre las intenciones y consideraciones de estos sliders. Por lo general, simplemente 'estaban ahí'.

2. Zoom de producto

El zoom de producto funciona así: en una tienda online promedio, al pasar el cursor sobre la imagen de un producto, puedes hacer zoom en una parte del mismo. Los 'zooms de producto' generalmente tienen el mismo problema que los sliders. Un fragmento de código JavaScript tomará tus imágenes, las ocultará y luego las reescribirá en la página como imágenes ampliables. Esto causará un Largest Contentful Paint más largo, probablemente un Layout Shift y muy probablemente problemas con el Interaction to Next Paint (INP).

La diferencia con el slider es que ningún propietario de producto dirá jamás: "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 debe ocultar las imágenes originales, sino ampliar la funcionalidad de la imagen del producto. Lamentablemente, la funcionalidad de zoom generalmente no se arregla fácilmente y requerirá algo de trabajo para que quede perfecta.

3. jQuery inline / dependencias de JavaScript inline

El jQuery inline es un problema que comenzó como un 'lento por error' pero empeoró con el tiempo. Alrededor del 50% de los sitios que analizo sufren este problema. jQuery todavía se ejecuta en aproximadamente el 70% de todos los sitios web según W3Techs, por lo que esto no desaparecerá a corto plazo. Debido a que los scripts inline dependen de un script anterior (generalmente jQuery), ya no puedes diferir jQuery. Esto retrasará todas las métricas de renderizado.

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é ubiqué esto en la categoría de 'lento por diseño'? Cuando pregunto sobre la intención y la consideración, normalmente recibo un 'oh, no lo 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 la misma que la corrección. Necesitaré educar al equipo de desarrollo sobre las dependencias de JavaScript y el timing.

4. Imágenes grandes (hero images)

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

Llegados a este punto (asumiendo que las imágenes están todas optimizadas) lo único que puedo hacer es ver si hay algún margen de maniobra. ¿Realmente necesitamos imágenes 4k o el full-hd también sería suficiente? Consulta cómo solucionar imágenes hero lentas para conocer técnicas prácticas.

5. Mapas interactivos

Otro problema con el que me encuentro con frecuencia son los mapas interactivos. Cuando una página tiene un mapa interactivo, la intención general de esta página es hacer que el visitante interactúe con el mapa. Evidentemente, va a llevar algún tiempo que ese mapa cargue.

No hay forma de evitar esto. Tendremos que aceptar cierta lentitud. Pero hay cosas que podemos hacer. Podemos asegurarnos de que los mapas se carguen con la prioridad más alta. Por lo general, 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 se ejecute lo antes posible! Escribí una guía completa sobre cómo incrustar Google Maps sin perder PageSpeed.

6. APIs lentas

Los problemas de lento por diseño que surgen de las APIs lentas generalmente se pueden encontrar en sitios SPA como React, Next.js o Angular. Las APIs lentas generalmente causarán grandes Layout Shifts debido a que los componentes se renderizan demasiado tarde después de la interacción del usuario. Problemas como este generalmente requieren un enfoque de múltiples equipos.

Puede ser útil distinguir entre lento por error y lento por diseño en lo que respecta a los Core Web Vitals. Lo lento por error suele ser fácil de solucionar, mientras que lo lento por diseño requiere un enfoque multidimensional más exhaustivo. Una vez que hayas categorizado y solucionado los problemas de 'lento por error', configura el Real User Monitoring para rastrear el impacto. Los datos de campo te dicen si tus correcciones realmente mejoraron la experiencia para los visitantes reales. Los problemas de 'lento por diseño' destacarán claramente en tus datos porque son lo que queda.