Velocidad de sitios web para principiantes: qué mejora realmente el tiempo de carga

Qué significa realmente “velocidad del sitio web"

Cuando la gente dice “mi sitio es lento”, normalmente se refiere a una de dos cosas:

• La página tarda demasiado en empezar a mostrar algo, o
• Parece lista pero sigue sintiéndose poco responsiva (los botones tardan, las imágenes aparecen tarde, la página se mueve).

“Tiempo de carga” no es un solo número de cronómetro. Una página se carga en etapas: el navegador solicita archivos (HTML, imágenes, fuentes, scripts), los descarga y luego los convierte en una página utilizable. Puedes pensarlo como abrir una tienda: abrir la puerta, encender luces, poner productos en estantes y finalmente estar listo para atender clientes.

Por qué importa la velocidad (más allá de “es agradable”)

La velocidad afecta a:

• Usuarios: las páginas lentas resultan estresantes en móviles y conexiones inestables. La gente se va antes y confía menos en el sitio.
• SEO: Google usa señales relacionadas con la velocidad (incluidas las Core Web Vitals) como parte de la experiencia de página. Un sitio más rápido no garantiza el puesto #1, pero uno lento puede frenarte.
• Conversiones: cada retraso añade fricción: menos registros, menos compras, menos envíos de formularios.

Fija expectativas: la mayoría de las mejoras vienen de pocos puntos

No necesitas 50 micro-optimizaciones. Para la mayoría de sitios de principiantes, las mayores mejoras provienen de una lista corta: imágenes, exceso de JavaScript/CSS, widgets de terceros y tiempo de respuesta del servidor/hosting.

Qué cubrirá (y qué no) esta guía

Esta guía se centra en pasos prácticos y de bajo riesgo que mejoran el tiempo de carga en el mundo real, especialmente en móvil. No profundiza en temas avanzados como reescribir la arquitectura de tu app, construir capas de caché a medida o presupuestos de rendimiento para grandes equipos de ingeniería. El objetivo es ayudarte a hacer cambios que puedas terminar—y verificar—sin romper el sitio.

Métricas clave de velocidad (sin la jerga)

Cuando la gente dice “mi sitio es lento”, normalmente quiere decir una de tres cosas: el contenido principal aparece tarde, la página se siente lenta al interactuar, o el diseño se sigue moviendo. Las Core Web Vitals de Google encajan bien con esas quejas.

Las tres Core Web Vitals

LCP (Largest Contentful Paint): cuánto tarda en aparecer lo más grande y principal (a menudo una imagen hero o el bloque del titular). Si el LCP es alto, los usuarios miran una página mayormente vacía.

INP (Interaction to Next Paint): qué tan rápido responde la página después de una interacción del usuario (tap, clic, escritura). Si el INP es alto, el sitio se siente pegajoso: los botones reaccionan tarde, los menús se abren con retardo.

CLS (Cumulative Layout Shift): cuánto se mueve la página durante la carga. Si el texto cambia de lugar y pulsas el botón equivocado, eso es CLS.

TTFB: el “primer byte”

TTFB (Time to First Byte) es cuánto tarda tu servidor (y todo lo que hay entre medio) en empezar a enviar algo. Un TTFB lento retrasa todo lo demás: no pueden empezar a descargarse imágenes, no cargan fuentes y el LCP suele empeorar. Los problemas de TTFB suelen apuntar a hosting, trabajo pesado del backend o caché mal configurada.

Pruebas en laboratorio vs. datos reales de usuarios

Pruebas en laboratorio (como Lighthouse) simulan una carga bajo condiciones fijas. Son excelentes para depurar y comparar antes/después.

Datos reales de usuarios (a menudo llamados “field data”, como CrUX en PageSpeed Insights) reflejan lo que los visitantes experimentan en la realidad, con distintos dispositivos y redes. Esto es lo que importa para la pregunta: “¿Se siente rápido para la gente de verdad?”

Objetivos “suficientemente buenos” para principiantes

• LCP: apunta a ≤ 2.5s (hasta 4.0s necesita trabajo)
• INP: apunta a ≤ 200ms (hasta 500ms necesita trabajo)
• CLS: apunta a ≤ 0.10 (por encima de 0.25 es un problema)
• TTFB: apunta a ≤ 0.8s (por encima de 1.8s suele sentirse lento)

Cómo medir tu sitio antes de cambiar nada

Si empiezas a “optimizar” sin una línea base, es fácil perder el tiempo—o hacer el sitio más lento por accidente. Tómate 20 minutos para medir primero y sabrás qué cambios ayudaron.

Ejecuta PageSpeed Insights (chequeo rápido de la realidad)

Usa PageSpeed Insights para un resumen rápido. Informa datos de campo (experiencia real, cuando están disponibles) y datos de laboratorio (prueba simulada). Fíjate en:

• Resultados móvil vs. escritorio (móvil suele ser el problema)
• La lista de “Opportunities” (buena para ideas, no es una lista estricta de tareas)
• Si la prueba tiene datos reales para tu URL

Para pruebas de laboratorio más profundas, ejecuta Lighthouse en Chrome:

1. Abre DevTools → Lighthouse
2. Elige Mobile y Performance
3. Ejecútalo 2–3 veces y guarda el resultado intermedio (las pruebas varían)

Usa WebPageTest para la “vista en cascada”

Cuando necesites ver qué está retrasando la página, WebPageTest es una de las herramientas más claras. La vista en cascada muestra cada archivo que se carga en orden—HTML, imágenes, fuentes, scripts y etiquetas de terceros—y dónde el navegador está esperando.

Empieza con una página clave (home o una landing importante) y prueba:

• First View (caché frío) y Repeat View (caché)
• Un perfil de dispositivo móvil cuando sea posible

Registra las condiciones de la prueba (para que los resultados signifiquen algo)

Anota para cada prueba:

• Dispositivo (tu portátil, un teléfono de gama media, etc.)
• Red (Wi‑Fi, 4G, ajustes de throttling)
• Ubicación (región de prueba en WebPageTest)
• URL exacta (incluyendo parámetros)

Haz una lista sencilla de antes/después

Crea un registro simple (una hoja de cálculo sirve): fecha, herramienta usada, URL, resultados y qué cambiaste. Cambia solo una o dos cosas a la vez y vuelve a probar bajo las mismas condiciones.

Si iteras sobre una app (no solo un sitio estático), ayuda tener una forma segura de desplegar y revertir experimentos de rendimiento. Plataformas como Koder.ai (que puede generar y alojar apps React/Go desde un flujo de chat) son útiles porque puedes tomar snapshots, probar cambios y revertir rápidamente si una “solución de rendimiento” rompe la UX.

Las razones más comunes por las que las páginas cargan lentas

Las páginas lentas raramente se deben a un misterio único. Son el resultado de unos pocos problemas comunes de “peso y demora” que se acumulan—especialmente en móviles.

1) Imágenes más grandes de lo necesario

Las imágenes suelen ser la parte más pesada de una página. Una sola imagen hero exportada en un tamaño incorrecto (o en un formato antiguo) puede añadir megabytes y segundos.

Culpables comunes:

• Subir una foto de 4000px de ancho cuando se muestra a 1200px
• Usar PNG para fotos en lugar de formatos modernos como WebP/AVIF
• Servir la misma imagen grande a desktop y móvil

2) Demasiado JavaScript (y demasiados complementos)

El JavaScript puede retrasar cuánto tarda una página en ser usable. Aunque la página “aparezca”, puede sentirse lenta mientras los scripts se cargan, parsean y ejecutan.

Los scripts de terceros suelen ser los culpables frecuentes: widgets de chat, pop-ups, heatmaps, herramientas de A/B testing, etiquetas de anuncios e embeds sociales. Cada uno puede añadir llamadas de red extra y retrasar trabajo crítico del navegador.

3) Hosting lento o trabajo pesado en el servidor

A veces el navegador está esperando a tu servidor antes de poder empezar a cargar la página. Esto se siente como una respuesta inicial lenta (TTFB). Las causas incluyen hosting insuficiente, bases de datos ocupadas, temas/plugins no optimizados o páginas que se generan dinámicamente en cada visita.

4) Sin caché + demasiadas solicitudes

Si tu sitio obliga a empezar desde cero en cada visita, los visitantes recurrentes pagan la factura. Sin caché, el servidor reconstruye páginas repetidamente y el navegador vuelve a descargar archivos que rara vez cambian.

Además, muchos archivos pequeños (fuentes, scripts, estilos, trackers) crean “overhead” de solicitudes. Aunque cada archivo sea pequeño, el tiempo de espera combinado suma.

La buena noticia: estas causas son solucionables—y normalmente obtendrás las mayores ganancias tratándolas en este orden.

Imágenes: la mejora de rendimiento más rápida y fiable

Si solo haces una mejora de rendimiento, hazla en imágenes. En muchos sitios de principiantes, las imágenes representan la mayor parte del “peso” descargado de la página—especialmente en móvil. La buena noticia: las correcciones de imagen suelen ser seguras, rápidas y no requieren cambiar el diseño.

1) Redimensiona imágenes al tamaño mostrado

Un error común es subir una foto enorme (por ejemplo, 4000px de ancho) y mostrarla a 800px. El navegador sigue teniendo que descargar el archivo grande.

Exporta imágenes cerca del tamaño máximo al que realmente se mostrarán. Por ejemplo, si el área de contenido de tu blog es de 800px, no subas imágenes de 3000–4000px “por si acaso”.

2) Usa formatos modernos (WebP/AVIF) cuando sea posible

JPEG y PNG siguen funcionando, pero los formatos modernos ofrecen la misma calidad visual con un tamaño de archivo mucho menor.

• WebP tiene amplio soporte y es una excelente opción por defecto.
• AVIF puede ser aún más pequeño, pero la codificación es más lenta y el soporte varía.

Si tu CMS o plugin de imágenes puede servir WebP/AVIF con retrocesos, eso es ideal.

3) Comprime imágenes y elimina metadatos innecesarios

La compresión es donde se encuentran la mayoría de las ganancias inmediatas. Una imagen “visualmente idéntica” se puede reducir a menudo entre un 30–70%.

También elimina metadatos que no necesites (info de cámara, ubicación). No cambia la apariencia pero añade bytes.

Regla práctica: comprime hasta que notes una caída visible en la calidad y luego retrocede un nivel.

4) Usa imágenes responsivas (srcset) para móvil y desktop

Los usuarios móviles no deberían descargar imágenes de escritorio. Las imágenes responsivas permiten al navegador elegir el tamaño adecuado según el ancho de pantalla.

Si tu sitio genera varios tamaños automáticamente, asegúrate de que tu tema los use correctamente. En el HTML de la página busca srcset (múltiples versiones) en lugar de un único archivo gigante.

Lista rápida

Antes de pasar a ajustes más avanzados (como minificar código), audita solo tus imágenes principales:

• ¿Están dimensionadas según dónde aparecen?
• ¿Se sirven como WebP/AVIF cuando es posible?
• ¿Están comprimidas de forma sensata?
• ¿Reciben los dispositivos móviles versiones más pequeñas?

Haz consistentemente esas cuatro cosas y la velocidad de tu sitio y el tiempo de carga mejorarán inmediatamente—a menudo lo suficiente para mover las Core Web Vitals en la dirección correcta.

Lazy loading y prioridades above-the-fold

Lazy loading significa que la página retrasa la descarga de algunas imágenes (y a veces iframes) hasta que estén cerca de aparecer en pantalla. Eso puede reducir el tiempo de carga inicial porque el navegador no solicita todo de golpe—muy útil en páginas largas con muchas imágenes debajo del pliegue.

Cuándo ayuda la carga diferida

La carga diferida es más útil para:

• Grillas de productos, artículos de blog y landings con mucho contenido bajo la primera pantalla
• Vídeos/Mapas embebidos que no son necesarios inmediatamente
• Usuarios móviles en conexiones lentas

Bien usada, reduce el “trabajo inicial” y ayuda a que la página se sienta más rápida.

No cargues de forma diferida tu hero (protege el LCP)

Tu imagen más grande above-the-fold suele ser la hero. Si la cargas de forma diferida, el navegador puede tardar en pedirla y eso perjudica el Largest Contentful Paint (LCP).

Regla: nunca hagas lazy-load de la imagen hero o de cualquier cosa crítica en la primera pantalla (imagen del titular, foto primaria del producto, banner superior).

Evita desplazamientos reservando ancho/alto

La carga diferida puede provocar “saltos” cuando las imágenes aparecen. Para prevenir CLS, reserva espacio:

• Define width y height en las imágenes, o
• Usa CSS con una relación de aspecto fija

Así el diseño se mantiene estable mientras las imágenes cargan.

Preload solo lo que realmente importa

Si una imagen o fuente above-the-fold es esencial para la primera impresión, considera preload para que el navegador la descargue temprano. Usa esto con moderación: preloading en exceso puede competir por el ancho de banda y empeorar la carga.

Si quieres un enfoque en checklist, combínalo con tu paso de medición en /blog/how-to-measure-site-speed-before-you-change-anything.

Conceptos básicos de caché: hace las visitas repetidas mucho más rápidas

La caché es la forma en que el navegador dice: “ya descargué esto—¿puedo reutilizarlo?” En vez de volver a descargar el mismo logo, fichero CSS o bundle JS en cada vista (o visita), el navegador guarda una copia local por un tiempo. Eso hace que las visitas repetidas sean notablemente más rápidas y reduce el uso de datos—especialmente en móvil.

Caché del navegador, en palabras sencillas

Cuando tu sitio envía un archivo (como styles.css o app.js), puede enviar también instrucciones sobre cuánto tiempo se puede reutilizar ese archivo. Si el navegador puede conservarlo 30 días, la próxima vez que alguien visite, esos archivos se cargan instantáneamente desde su dispositivo en vez de desde tu servidor.

Esto no acelera la primera visita, pero sí puede mejorar mucho:

• La segunda página que alguien abre
• Visitas repetidas durante días/semanas
• Usuarios con conexiones inestables

Configura cabeceras de caché para archivos “estáticos”

Los archivos estáticos son cosas que no cambian cada minuto: imágenes, CSS, JavaScript, fuentes. Son candidatos perfectos para tiempos de caché largos.

Qué quieres (conceptualmente):

• CSS/JS/imagenes: caché por mucho tiempo (semanas/meses)
• Páginas HTML: cachear con cuidado (suele ser corto), porque el contenido puede cambiar y no quieres que la gente vea versión antigua

Tu hosting, CMS o framework puede ofrecer una opción simple de “static asset caching”. Si trabajas con un desarrollador, pídele que ponga cabeceras Cache-Control apropiadas para los assets.

Usa nombres versionados para que las actualizaciones no queden atrapadas

Una preocupación común: “Si cacheamos archivos por un mes, ¿cómo obtienen los usuarios la actualización mañana?” La solución son nombres versionados.

En lugar de usar siempre app.js, tu proceso de build (o desarrollador) puede generar algo como:

• app.3f2a1c.js
• styles.a81b09.css

Cuando el contenido cambia, cambia el nombre de archivo, así el navegador lo trata como nuevo y lo descarga de inmediato—mientras sigue cacheando versiones antiguas de manera segura.

Nota sobre service workers (avanzado)

Los service workers pueden llevar la caché más lejos permitiendo que tu sitio controle qué se almacena y cuándo, incluso habilitando comportamiento offline. También pueden causar problemas de contenido “obsoleto” si se implementan mal. Si eres principiante, trata los service workers como una opción avanzada—genial cuando tienes objetivos claros y alguien con experiencia para mantenerlos.

CDNs explicadas: cuándo ayudan (y cuándo no)

Un CDN (Content Delivery Network) es un conjunto de servidores distribuidos por regiones que pueden entregar los archivos de tu sitio desde un lugar más cercano al visitante. En lugar de que cada solicitud llegue hasta tu servidor único, muchas solicitudes se atienden “cerca”.

Qué hace realmente un CDN

Los CDNs son mejores para acelerar assets estáticos—cosas que no cambian en cada petición—como imágenes, CSS, JavaScript, fuentes y vídeos. Estos archivos se copian (“cachean”) en servidores CDN y se reutilizan para muchos visitantes.

Quién se beneficia más: sitios con visitantes en varias ciudades/países, sitios con mucho contenido multimedia y negocios con campañas pagadas que envían tráfico desde todo el mundo.

Cómo reduce la latencia para visitantes globales

La distancia añade demora. Si tu servidor está en un país y el visitante en otro continente, cada petición tarda más. Un CDN reduce esa demora sirviendo archivos cacheados desde un servidor edge más cercano, lo que suele mejorar el tiempo de carga y puede ayudar las Core Web Vitals—especialmente en conexiones móviles.

Assets estáticos vs. páginas dinámicas

• Assets estáticos: ajuste perfecto para CDN. Cachéalos agresivamente.
• Páginas dinámicas (carrito, área de cuenta): a menudo no se pueden cachear de forma segura, o sólo partes. Algunos CDNs ofrecen “dynamic acceleration”, pero eso es más avanzado y no siempre es un beneficio garantizado.

Errores comunes a vigilar

Cabeceras de caché mal configuradas pueden impedir el cacheo por completo (o cachear demasiado). El problema opuesto es el cache obsoleto: actualizas un archivo pero los visitantes siguen viendo la versión vieja. Para evitarlo, usa nombres versionados y aprende a usar la función de “purge” de tu CDN.

Un CDN no sustituye arreglar imágenes pesadas, scripts hinchados o hosting lento—pero puede multiplicar las mejoras una vez tengas lo básico en orden.

Recortar CSS y JavaScript sin romper el sitio

El CSS y JavaScript suelen ser el “peso invisible” que ralentiza una página. A diferencia de las imágenes, no siempre puedes ver el problema—pero el navegador sigue descargando, procesando y ejecutando esos archivos.

Minificar CSS y JavaScript (qué cambia y qué no)

Minificar quita espacios, comentarios y formato. Normalmente reduce el tamaño de archivo y acelera la descarga.

Lo que cambia: el tamaño del archivo.

Lo que no cambia: cuánto trabajo necesita el navegador para parsear y ejecutar el código. Si tus scripts hacen mucho trabajo en la carga, la minificación no lo solucionará—piensa en minificar como una victoria rápida, no la solución completa.

Elimina CSS no usado y envía solo lo que la página necesita

Muchos sitios cargan una hoja de estilos “talla única” que incluye reglas para páginas y componentes que la página actual no usa. Ese CSS extra se descarga igualmente y puede ralentizar el render.

Un enfoque práctico:

• Si usas un page builder o un tema grande, busca opciones como “cargar assets por página” o “solo cargar CSS usado”.
• Si tienes un desarrollador, pide “critical CSS” (estilos necesarios para la primera pantalla) y carga el resto de forma diferida.

El objetivo es simple: la página principal no debería cargar con el peso de todo el sitio.

Defer o async para JavaScript no crítico

Algunos scripts bloquean que la página sea interactiva porque el navegador se detiene para ejecutarlos.

• defer suele ser mejor para tus scripts que pueden esperar hasta que el HTML esté parseado.
• async es más adecuado para scripts independientes (a menudo de terceros) que no dependen de otro código.

Si tienes dudas, comienza por diferir lo que no sea necesario para la primera pantalla (menús, animaciones, sliders, tracking extra).

Limita librerías pesadas y frameworks grandes cuando sea posible

Las librerías grandes pueden añadir cientos de KB (o más). Antes de añadir otro plugin o framework, pregúntate:

• ¿Se puede hacer la función con código más simple?
• ¿Se puede eliminar una librería que solo se usa en una página?

Menos scripts suele significar menos sorpresas—especialmente en rendimiento móvil, donde el tiempo de CPU importa tanto como el tamaño de descarga.

Scripts de terceros: widgets pequeños, grandes ralentizaciones

Los scripts de terceros son cualquier cosa que tu sitio carga desde servidores de otra compañía. Son populares porque añaden funciones rápido—pero también pueden ser algunas de las causas más grandes e impredecibles de lentitud.

Culpables comunes (y por qué perjudican)

La mayoría de las ralentizaciones provienen de pocas categorías:

• Analytics y tracking (Google Analytics, píxeles, tag managers)
• Widgets de chat (chat en vivo, chatbots)
• Anuncios y retargeting (redes de anuncios, header bidding)
• Embeds (YouTube, posts sociales, mapas, widgets de reseñas)

Estos scripts suelen descargar archivos extra, ejecutar mucho JavaScript y a veces bloquear que el navegador termine de cargar la página.

Cómo detectar “long tasks” y scripts que bloquean

Abre Chrome DevTools → Performance, graba una carga y busca:

• Long tasks (bloques grandes en el hilo principal). Normalmente significan que JavaScript mantiene al navegador ocupado.
• Scripts que se ejecutan temprano (antes de que puedas desplazarte o clicar) y retrasan el render.

También puedes ejecutar Lighthouse y revisar recomendaciones como “Reduce JavaScript execution time” y “Eliminate render-blocking resources”.

Haz los scripts de terceros menos dañinos

Algunas mejoras amigables para principiantes:

• Cargar tras interacción cuando sea posible: no inicialices chat, reseñas o embeds hasta que el usuario haga clic, se desplace o abra un panel.
• Retrasar etiquetas no esenciales: si un script no es necesario para la primera vista, no lo ejecutes en el momento crítico de carga.

Reemplaza embeds pesados con vistas previas ligeras

En vez de cargar un embed completo de YouTube/Facebook/Map en la carga, muestra una vista previa simple (miniatura + botón de reproducción). Solo carga el embed real cuando el usuario haga clic.

Esto mantiene la página rápida para todos—especialmente en móviles—sin eliminar la funcionalidad.

Hosting y rendimiento del servidor: TTFB en palabras llanas

TTFB (Time to First Byte) es el tiempo que tarda tu servidor en empezar a responder después de que el navegador solicita una página. Piénsalo como “cuánto tarda la cocina en empezar a cocinar”, no cuánto tarda en servirse la comida completa.

Un sitio bien diseñado puede sentirse lento si el TTFB es alto—especialmente en redes móviles donde cada retraso es más notable.

Qué suele hacer lento al TTFB

El TTFB depende sobre todo del trabajo del lado servidor antes de enviar algo:

• Tiempo de procesamiento del servidor: el código del sitio debe ejecutarse, construir la página y ensamblar la respuesta.
• Retrasos de base de datos: cada consulta (especialmente muchas pequeñas) añade tiempo.
• Fallas de caché: si no hay caché, el servidor hace la “construcción completa” para cada petición.

Aunque optimices imágenes y scripts, una respuesta de servidor lenta puede mantener al navegador esperando con una pantalla en blanco.

La mejora más fácil: caché del lado servidor para páginas dinámicas

Si tu sitio usa un CMS o genera páginas dinámicamente, la caché del lado servidor suele ser la mayor mejora en TTFB. En lugar de reconstruir la misma página para cada visitante, el servidor puede almacenar una versión lista para servir.

Ejemplos prácticos:

• Cachea posts de blog y páginas de marketing que no cambien cada minuto.
• Usa caché de página completa cuando la plataforma lo permita.
• En tiendas o sitios con membresías, cachea lo que puedas (páginas para usuarios no autenticados) y sé selectivo con las páginas personalizadas.

No olvides la compresión (Brotli/Gzip)

Activa Brotli (preferible) o Gzip para archivos de texto como HTML, CSS y JavaScript. Esto reduce la cantidad de datos que viajan por la red y mejora la velocidad percibida—especialmente en cargas repetidas y usuarios móviles.

Cuándo mejorar el hosting

Un hosting mejor puede reducir el TTFB, pero es más inteligente arreglar problemas front-end evidentes primero (imágenes enormes, demasiados scripts de terceros, JavaScript pesado). Si el navegador descarga megabytes, un hosting más rápido no hará que la experiencia sea realmente rápida.

Una vez controlados los básicos, mejorar el hosting (más CPU/RAM, base de datos afinada, mejor runtime) puede ser el paso final que deje tu sitio ágil.

Si estás creando un producto nuevo y quieres menos variables de hosting desde el día uno, considera una plataforma gestionada que incluya ajustes sensatos por defecto. Por ejemplo, Koder.ai aloja apps en AWS globalmente y soporta despliegues, dominios personalizados y rollbacks de entorno—útil al probar cambios de rendimiento por regiones o cumplir requisitos de residencia de datos.

Plan práctico de 1 semana para principiantes

No necesitas un proyecto enorme para mejorar la velocidad. Necesitas un orden simple de operaciones, una forma de confirmar que no empeoraste y una preferencia por soluciones que reduzcan el tiempo de carga de forma fiable.

El orden de 1 semana: medir → imágenes → caché → recortar JavaScript

Día 1: Medir (antes de tocar nada).

Elige 2–3 páginas importantes (home, landing clave, un post/producto popular). Ejecuta:

• PageSpeed Insights (fíjate en Core Web Vitals)
• Chrome DevTools Lighthouse

Anota la línea base para móvil y escritorio. Si puedes, prueba también en un teléfono real (incluso el tuyo) por datos celulares—eso suele revelar problemas que las pruebas de laboratorio ocultan.

Días 2–3: Arregla imágenes (la victoria más rápida y fiable).

Prioriza:

• Comprimir imágenes grandes y servir formatos modernos (WebP/AVIF)
• Redimensionar imágenes al tamaño máximo mostrado
• Asegurar que la imagen “hero” principal cargue rápido (a menudo es lo primero que notan los usuarios)

Vuelve a probar después de actualizar solo unas pocas imágenes para ver el efecto.

Días 4–5: Configura caché (haz las visitas repetidas mucho más rápidas).

Activa caché básica de navegador y caché de servidor/página cuando proceda. La meta: no regenerar ni volver a descargar los mismos assets en cada visita. Tras activar la caché, verifica que volver a la página sea notablemente más rápido.

Días 6–7: Recorta JavaScript (a menudo la mayor ganancia a largo plazo).

Busca:

• Plugins/características no usadas (elimínalas en lugar de “optimizarlas”)
• Sliders/animaciones pesadas que no mejoran conversiones
• Etiquetas de tracking sobrantes

Pequeños cambios aquí pueden mejorar drásticamente la interactividad y las Core Web Vitals, especialmente en móvil.

Chequeos simples de regresión tras cada cambio

Después de cada modificación importante (imágenes, caché, scripts), haz tres comprobaciones rápidas:

1. Ejecuta las mismas pruebas en las mismas páginas y compara con la línea base del Día 1.
2. Navega por el sitio como un visitante (formularios, checkout, menús). Las mejoras de velocidad no valen si rompen la usabilidad.
3. Prioriza móvil: si solo va rápido en escritorio, no está realmente optimizado.

Cuándo pedir ayuda

Si has optimizado imágenes y caché y aún ves TTFB persistentemente alto, suele indicar configuración de hosting/servidor, base de datos lenta o trabajo pesado en el backend. También pide ayuda si tu sitio es una app compleja (sitios con membresía, marketplaces, mucha personalización) donde “simplemente cachearlo” no es sencillo.

Si quieres una guía más profunda sobre tiempo de respuesta del servidor, consulta /blog/ttfb-explained.