¿Sitio Web Lento? Cómo Mejorar la Velocidad y Core Web Vitals
Optimizaciones prácticas de TTFB, LCP, CLS, imágenes, caché y SSR para acelerar aplicaciones web.
Erlan Carreira
Ingeniero de Software y Emprendedor
Un sitio lento debe ser tratado con medición, no con una lista aleatoria de plugins. El camino más seguro es separar los datos de usuarios reales de las pruebas de laboratorio, localizar la etapa que consume tiempo y alterar una variable a la vez. Este tutorial muestra cómo hacerlo sin ocultar el problema.
Respuesta directa: qué hacer cuando el sitio está lento
Prueba la URL en PageSpeed Insights en móvil y computadora. Anota LCP, INP, CLS y TTFB, abre los diagnósticos de Lighthouse y revisa la pestaña Network del navegador. Luego corrige primero el recurso que forma el LCP, reduce JavaScript bloqueante, estabiliza dimensiones de los elementos y mejora el caché o servidor. Publica, mide nuevamente y compara en las mismas condiciones.
Entiende los números antes de optimizar
PageSpeed combina dos tipos de información. Los datos de campo provienen del Chrome UX Report y representan visitas reales de los últimos 28 días, cuando hay suficiente muestra. Los datos de laboratorio simulan una visita y ayudan a reproducir cuellos de botella. Una nota alta en el laboratorio no sustituye la experiencia real.
| Métrica | Bueno | Qué suele empeorarla |
|---|---|---|
| LCP | hasta 2,5 s | imagen principal pesada, fuente, CSS o servidor lento |
| INP | hasta 200 ms | JavaScript largo, componente pesado, exceso de terceros |
| CLS | hasta 0,1 | imagen sin tamaño, banner tardío, cambio de fuente |
Estos límites son evaluados en el percentil 75. Corregir solo la página de inicio puede no resolver un grupo entero de URLs con la misma plantilla.
Paso 1: reproduce el problema
Abre una ventana anónima, desactiva extensiones y prueba la página en una red comparable a la del público. En Chrome DevTools, abre Network, marca Disable cache y recarga. Ordena por duración y tamaño. Observa el documento HTML, la imagen principal, fuentes, CSS, JavaScript y llamadas externas.
Usa también:
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s Total: %{time_total}s\n" https://exemplo.com/paginaUn TTFB alto apunta a servidor, consulta a la base de datos, función remota o caché. Un HTML rápido seguido de muchos segundos hasta la imagen principal apunta al front-end o a los medios.
Paso 2: corrige el LCP
Descubre qué elemento es el LCP en el informe. Si es una imagen, entrega AVIF o WebP en el tamaño visual correcto, informa width y height, usa srcset y no apliques lazy loading a la imagen que aparece inmediatamente. Un preload solo ayuda cuando el navegador descubriría el recurso tarde; usado en exceso, compite por ancho de banda con elementos esenciales.
Si el LCP es texto, verifica fuentes y CSS. Hospeda solo los pesos utilizados, prefiere WOFF2 y configura una estrategia de visualización que no deje el texto invisible. Elimina CSS no utilizado con cuidado y carga estilos críticos temprano.
Paso 3: reduce el INP
Haz clic en los controles durante una grabación en la pestaña Performance. Tareas largas bloquean el hilo principal. Divide el procesamiento grande, pospone scripts que no participan en la primera interacción y evita recalcular toda la interfaz cuando solo una parte ha cambiado.
Scripts de chat, mapas, video, pruebas A/B y publicidad también consumen procesamiento. Cárgalos cuando sean necesarios y mide el costo de cada proveedor. Para AdSense, reserva previamente el espacio del anuncio y evita insertar bloques que desplazan el contenido.
Paso 4: elimina cambios de diseño
Define dimensiones o aspect-ratio para imágenes, videos y anuncios. No inyectes avisos por encima del contenido después de que la página haya aparecido. En fuentes, elige una alternativa del sistema con proporciones cercanas. Reproduce la página lentamente: el elemento que salta suele revelar la causa del CLS.
Paso 5: trabaja en caché y servidor
Archivos versionados pueden recibir caché largo; HTML dinámico exige una política coherente con la actualización del contenido. Usa CDN para contenido público, comprime respuestas y elimina redirecciones innecesarias. En el back-end, registra el tiempo de consultas y llamadas externas. No aumentes recursos de la máquina sin saber si el cuello de botella es CPU, base de datos, red o código.
Checklist de validación
- compara antes y después en la misma URL y dispositivo;
- prueba páginas internas, no solo la de inicio;
- confirma que las imágenes continúan nítidas;
- verifica login, formulario y menú después de reducir scripts;
- sigue datos de campo por al menos 28 días;
- configura alertas para regresiones de build y tamaño.
Para una reconstrucción más amplia, ve sitio institucional o landing page. Si el cuello de botella está en integraciones, entiende cómo monitorear APIs.
Preguntas frecuentes
¿Instalar caché resuelve cualquier sitio lento?
No. El caché puede reducir servidor y transferencia, pero no corrige JavaScript excesivo, medios desproporcionados o cambios de diseño.
¿La nota 100 es obligatoria para aparecer en Google?
No. La relevancia y calidad siguen siendo fundamentales. El objetivo es ofrecer una buena experiencia y alcanzar métricas consistentes, no perseguir una puntuación aislada.
Fuentes primarias
Erlan Carreira
Ingeniero de Software y Emprendedor
Especialista en desarrollo de software, automatización y SaaS. Escribo sobre tecnología, negocios digitales, IA y buenas prácticas de ingeniería para equipos que buscan excelencia en la ejecución.