Velocidad del sitio: imágenes, fuentes y scripts
Por qué un sitio carga lento suele deberse a tres causas: imágenes demasiado pesadas, fuentes lentas y scripts de terceros acumulados. Qué corregir primero.
Equipo de rabbitclipPublicación: 6 min. de lectura
En breve
Un sitio web lento pocas veces tiene una sola causa; suele ser la suma de tres fuentes: imágenes más pesadas de lo necesario, fuentes que retrasan que la página se vuelva visible, y scripts de terceros que se acumulan con el tiempo. Corregir las tres a la vez marca una diferencia notable; corregir solo una rara vez basta.
Google ya no mide la velocidad solo por la rapidez con que aparece una página; también mide qué tan rápido responde la pantalla en cuanto alguien toca un botón. Esa métrica se llama Interaction to Next Paint, o INP (web.dev, INP). La velocidad ya no significa solo «¿cargó la página?», sino «¿puede usarse realmente?».
Este artículo aborda las tres fuentes por separado: imágenes, fuentes, código de terceros. Para cada una, por dónde empezar y qué marca la diferencia de verdad.
Por qué las imágenes cargan con el mayor peso
La mayor parte del peso total de una página suele venir de las imágenes. Piense en la galería de productos de un fabricante de revestimientos de suelo: una página de cincuenta megabytes significa varios segundos de espera, según el dispositivo y la conexión del visitante. Ese peso no desaparece a menos que la imagen se sirva en el tamaño y formato correctos.
La solución tiene dos pasos. Primero, la imagen se recorta al tamaño en que realmente se mostrará; una imagen que en el móvil ocupa cuatrocientos píxeles de ancho no debería enviarse a dos mil píxeles. Después se elige el formato: AVIF y WebP producen archivos mucho más ligeros que el JPEG antiguo con una calidad comparable (web.dev, Optimize LCP). Un framework como Next.js automatiza esto, de modo que nadie tiene que preparar varias versiones a mano.
Por qué las fuentes ralentizan una página
Una fuente propia forma parte de la identidad de una marca, pero cargada de forma incorrecta retrasa que la página se vuelva visible. Si el navegador oculta el texto hasta que se descarga el archivo de fuente, el visitante ve una pantalla en blanco durante uno o dos segundos; a esto se le llama destello de texto invisible.
El ajuste font-display: swap elimina esa espera: el navegador muestra el texto de inmediato con una fuente del sistema y lo sustituye por la fuente propia en cuanto llega (web.dev, Best practices for fonts). La página de reservas de una cadena de spas a veces solo necesita dos pesos, normal y negrita, pero del archivo de diseño suelen pasar cinco o seis tal cual al sitio en producción; cada peso adicional es una descarga aparte.
Por qué los scripts de terceros son la carga más traicionera
Herramientas de analítica, ventanas de chat en vivo, píxeles publicitarios, integraciones de redes sociales: cada una añade un archivo JavaScript externo a la página. Se acumulan en silencio; un sitio con cinco o seis herramientas distintas añadidas a lo largo de un año es habitual.
El problema es que estos scripts ocupan el hilo principal del navegador; mientras ese código se ejecuta, el navegador no puede responder al clic de un visitante, lo que empeora directamente el INP (web.dev, INP). Revisar la lista de herramientas en uso cada pocos meses y retirar un panel de analítica que ya nadie mira, o un widget de chat que ya nadie usa, merece los diez minutos que cuesta.
En qué orden corregirlo
No hace falta corregir las tres fuentes a la vez; un orden facilita el trabajo.
- Medir el estado actual con PageSpeed Insights o Search Console
- Llevar las imágenes más grandes visibles sin desplazar a su tamaño y formato correctos
- Reducir el número de pesos de fuente, añadir font-display: swap
- Eliminar scripts de terceros sin uso, cargar el resto solo cuando haga falta
- Medir de nuevo con la misma herramienta tras el cambio
¿La velocidad es solo un asunto técnico?
La velocidad también es una decisión de marketing, porque es el primer contacto del visitante con el sitio. Si la página de emergencias de un fabricante de generadores carga lento, el visitante vuelve al resultado de búsqueda y prueba con la siguiente empresa; esa pérdida ocurre en silencio, sin queja ni informe de rebote que alguien lea.
El trabajo de velocidad no es un proyecto puntual; forma parte del mantenimiento continuo. La misma disciplina se aplica cada vez que se añade una herramienta nueva o se sube una imagen nueva.
Qué cambian Next.js 16 y React 19 en la velocidad
Next.js 16 y React 19, ya habituales en 2026, llevan más lejos los componentes de servidor: la mayor parte de una página se prepara en el servidor y se envía al navegador ya terminada, lo que reduce la cantidad de JavaScript que el navegador tiene que descargar. Es una decisión de arquitectura que mejora directamente el INP.
Para el catálogo de productos de un fabricante con cientos de páginas, la diferencia es concreta: con una configuración React antigua, cada página se vuelve a renderizar en el navegador; con la arquitectura nueva, la página llega ya lista y el navegador solo asume las partes interactivas, un filtro, un botón de añadir al carrito. Al valorar un cambio así, esa diferencia de arquitectura debería contarse en el presupuesto de velocidad, no solo en el rediseño visual.
Por qué la caché en el servidor marca la diferencia
Una página generada una vez y mantenida en caché durante un periodo fijo, en lugar de reconstruirse en cada visita, llega a los visitantes posteriores mucho más rápido. Es una ganancia que merece la pena para cualquier página cuyo contenido no cambie a menudo, una página de quiénes somos, una descripción de servicio.
Un calendario de eventos en el sitio de una asociación empresarial, que se actualiza a menudo, necesita una duración de caché corta; una página corporativa estática puede mantener la misma versión en caché durante horas o incluso días. La duración correcta depende de con qué frecuencia cambia realmente el contenido.
Una caché mal configurada trae sus propios problemas: un precio antiguo que sigue en caché y se muestra un tiempo después de una actualización, por ejemplo. Por eso conviene planear desde el principio cuándo y cómo se limpia la caché tras una actualización.
Imágenes, fuentes y scripts de terceros, tomados en conjunto, hacen que una página cargue más rápido y responda antes a los clics. En una primera llamada, rabbitclip elabora un informe de velocidad del sitio actual para ver juntos qué fuente cuesta más.
Preguntas frecuentes
¿Dónde puedo medir la velocidad de mi sitio?
Google PageSpeed Insights y el informe de Core Web Vitals en Search Console dan mediciones separadas para móvil y escritorio.
¿AVIF funciona en todos los navegadores?
La mayoría de los navegadores actuales lo admiten; un sitio puede configurarse para servir AVIF donde se admita y pasar automáticamente a WebP o JPEG donde no.
¿Cuántos scripts de terceros son demasiados?
No hay un número fijo; cada script adicional tiene un coste, por eso conviene revisar con regularidad si cada uno se sigue usando de verdad.
¿font-display: swap estropea el aspecto de la fuente de marca?
No, solo muestra brevemente una fuente del sistema mientras se descarga la propia; la fuente de marca toma el relevo poco después.
¿Migrar a Next.js 16 basta por sí solo para la velocidad?
No, el cambio de arquitectura ayuda de forma notable, pero sin disciplina en imágenes, fuentes y scripts no basta por sí solo.
