Página web lenta: causas y qué arreglar primero
Si tu página tarda en abrir en el celular, mídela antes de cambiar de hosting o de plantilla. La medición te dice qué la frena, y casi siempre es una cosa concreta que se arregla sin rehacer el sitio. Abajo va cómo medir, cómo leer el informe con las cifras reales de tavelik.com y en qué orden arreglar.
En esta guía · 6 partes
Cómo medir tu página
Entra a pagespeed.web.dev, pega la dirección de tu página y deja seleccionada la pestaña Celulares. Mide primero la página de inicio y después la que más te trae clientes, porque cada página carga distinto.
El informe tiene dos partes. Arriba, "Descubre lo que experimentan tus usuarios reales" muestra datos de visitas reales de Chrome de los últimos 28 días. Abajo, "Diagnostica problemas de rendimiento" es una prueba simulada en un solo celular con una red fija. Si tu sitio tiene pocas visitas, la parte de arriba sale vacía. Google lo explica así en la documentación de PageSpeed Insights: una página nueva o con pocas visitas no tiene suficientes muestras.
Un informe real: tavelik.com el 21 de octubre de 2026
Medí la página de inicio de este sitio en PageSpeed Insights, en la pestaña Celulares, el 21 de octubre de 2026 a las 3:06 p. m. (hora de Colombia). La prueba simula un Moto G Power con red 4G lenta. Estas son las cifras:
| Métrica | tavelik.com (celular) | Umbral "bueno" de Google |
|---|---|---|
| Rendimiento (nota) | 95 de 100 | 90 o más |
| First Contentful Paint (primer contenido visible) | 1,7 s | 1,8 s o menos |
| Largest Contentful Paint (elemento más grande visible) | 2,3 s | 2,5 s o menos |
| Total Blocking Time (tiempo bloqueado por código) | 20 ms | No es Core Web Vital |
| Cumulative Layout Shift (saltos de contenido) | 0 | 0,1 o menos |
| Speed Index (qué tan rápido se llena la pantalla) | 4,7 s | No es Core Web Vital |
La parte de usuarios reales salió sin datos, porque el sitio tiene unas siete semanas y pocas visitas. La prueba simulada marcó tres oportunidades: solicitudes que bloquean la renderización (ahorro estimado de 520 ms), entrega de imágenes (83 KiB) y JavaScript sin usar (111 KiB). También avisó de 17 elementos animados. El dato flojo es el Speed Index de 4,7 s: la pantalla tarda en llenarse del todo aunque lo principal aparece a los 2,3 s. Eso es lo que nos toca mejorar a nosotros.
Qué significa cada métrica
| Métrica | Qué mide | Bueno | Malo |
|---|---|---|---|
| LCP | Cuánto tarda en verse el elemento más grande de la pantalla, casi siempre la imagen o el título de arriba | 2,5 s o menos | Más de 4 s |
| INP | Cuánto tarda la página en reaccionar a un toque o un clic. Solo sale con datos de usuarios reales | 200 ms o menos | Más de 500 ms |
| CLS | Cuánto se mueve el contenido mientras carga, como el botón que salta cuando lo vas a tocar | 0,1 o menos | Más de 0,25 |
| FCP | Cuánto tarda en aparecer lo primero | 1,8 s o menos | Más de 3 s |
| TTFB | Cuánto tarda el servidor en empezar a responder | 0,8 s o menos | Más de 1,8 s |
LCP, INP y CLS son las Core Web Vitals, las tres métricas con las que Google mide la experiencia de una página. Los umbrales de la tabla son los que publica la documentación de PageSpeed Insights.
Las causas, en el orden en que conviene arreglarlas
1. La imagen grande de arriba
Si el LCP sale en rojo, empieza aquí. Casi siempre el elemento más grande es la foto de portada, y suele estar subida a tamaño de cámara. La guía de web.dev para mejorar el LCP pide servir la imagen al tamaño en que se muestra, en un formato moderno como WebP o AVIF, y nunca cargarla en diferido con loading="lazy", porque eso siempre la retrasa. También recomienda marcarla con fetchpriority="high" para que el navegador la pida primero.
2. Imágenes sin medidas
Cuando una imagen no tiene ancho y alto declarados, el navegador no sabe cuánto espacio guardarle y el texto salta cuando ella aparece. Eso sube el CLS. web.dev recomienda poner los atributos width y height en todas las imágenes.
3. CSS y scripts que bloquean la carga
Hojas de estilo grandes y scripts en la cabecera de la página hacen que el navegador espere antes de pintar algo. El informe los lista como "Solicitudes de bloqueo de renderización" con el ahorro estimado. La guía de web.dev dice que casi nunca hace falta un script sincrónico en la cabecera.
4. JavaScript de más
Cada plugin, chat flotante, píxel de publicidad o widget de redes agrega código que el celular tiene que descargar y ejecutar. El informe lo muestra como "Reduce el código JavaScript sin usar" y "Terceros". Quita lo que nadie usa y deja para después de la carga lo que no se ve al abrir.
5. El servidor
Si el TTFB pasa de 0,8 s, el servidor tarda en responder antes de que empiece todo lo demás. Ahí sí puede ser el hosting, la falta de caché o una base de datos lenta. Revísalo después de lo anterior, porque las imágenes y los scripts suelen pesar más y son más baratos de arreglar.
Lo que depende de la plataforma
En WordPress casi todo se puede tocar, y lo que más frena suele ser la suma de plugins y un tema pesado. En Wix y plataformas parecidas, parte de la velocidad depende de la plataforma y no se puede cambiar. Una página hecha a la medida se puede ajustar entera. Antes de pagar por arreglos, pregunta qué de lo que marca el informe se puede tocar en tu plataforma.
Qué puedes hacer hoy
- Mide tu página de inicio en pagespeed.web.dev, pestaña Celulares, tres veces.
- Anota el LCP, el CLS y, si aparece, el INP de usuarios reales.
- Abre "Desglose de LCP" para ver cuál es el elemento más grande y revisa el peso de esa imagen.
- Mira la lista de "Terceros" y marca lo que puedes quitar.
- Repite la medición después de cada cambio, para saber qué sirvió.
Preguntas frecuentes
¿Por qué la nota de PageSpeed cambia cada vez que mido?
Según la documentación de Lighthouse, la mayor parte de la variación viene de condiciones externas, como la red, los anuncios o las extensiones del navegador. Mide varias veces y compara lo que se repite.
¿Necesito sacar 100 en PageSpeed?
No. La nota resume una prueba simulada en un solo celular. Google recomienda tener buenas Core Web Vitals, que miden la experiencia de visitas reales: LCP de 2,5 s o menos, INP de 200 ms o menos y CLS de 0,1 o menos.
¿Cambiar de hosting arregla una página lenta?
Solo si el problema es el servidor, y eso se ve en el TTFB. Si pasa de 0,8 s, el hosting puede ser parte del problema. Si el TTFB está bien, lo que frena suele ser imágenes pesadas o código de más.
¿Por qué mi página no tiene datos de usuarios reales?
PageSpeed Insights necesita suficientes visitas de Chrome en los últimos 28 días. Una página nueva o con poco tráfico no las tiene, y entonces solo aparece la prueba simulada.
Fuentes
- Informe de PageSpeed Insights de tavelik.com, celular, 21 de octubre de 2026
- Google for Developers: acerca de PageSpeed Insights (datos reales, datos de laboratorio y umbrales)
- web.dev: optimizar el Largest Contentful Paint
- web.dev: carga diferida de imágenes en el navegador
- Chrome for Developers: cómo calcula Lighthouse la nota de rendimiento
- Google Search Central: Core Web Vitals y los resultados de búsqueda
- web.dev: Web Vitals
