Sitio web y ventas
Página web lenta: cómo medirla y mejorar con PageSpeed Insights
Interpreta el informe de velocidad, identifica el paso que falla y pide un diagnóstico con evidencia. Ejemplos y plantilla para tu negocio antes de comprar más infraestructura.
Por ZonaPyme ·
Respuesta rápida
Un sitio web lento puede hacer perder clientes cuando retrasa la información principal, responde tarde a los botones o dificulta contactar, cotizar y pagar. Para comprobarlo, prueba el recorrido completo con datos móviles, revisa la página de entrada y la de conversión, usa PageSpeed Insights como diagnóstico, verifica formularios y pagos, y compara las acciones comerciales antes y después de corregir. No culpes al hosting sin medir: imágenes, plugins, scripts, base de datos y servicios externos también pueden ser la causa.
Tu página no necesita un puntaje perfecto. Necesita permitir que una persona entienda tu oferta, vea la información principal y pueda contactarte o comprar sin esperar ni pelear con la pantalla.
Una web lenta puede hacer perder oportunidades, pero no conviene culpar al hosting sin medir. El problema también puede estar en imágenes pesadas, plugins, anuncios, scripts, la base de datos, el diseño móvil o un formulario que responde tarde.
Cómo usar PageSpeed Insights para revisar una página web lenta
Abre la herramienta oficial PageSpeed Insights, pega la dirección pública exacta y pulsa Analizar. Empieza por móvil y después compara escritorio. Guarda fecha y URL del informe; repite con la página de servicio o producto que recibe visitas, no únicamente con la portada. No introduzcas enlaces privados de clientes ni accesos al administrador.
El informe combina dos perspectivas que pueden discrepar:
| Parte del informe | Qué representa | Cómo interpretarla |
|---|---|---|
| Experiencia de usuarios reales | Datos CrUX de los últimos 28 días cuando hay muestras suficientes | Comprueba si corresponden a esa URL o al origen completo. No describas datos del sitio entero como resultado exclusivo de una ficha. |
| Diagnóstico de laboratorio | Una carga simulada con Lighthouse | Úsala para investigar y comparar cambios bajo condiciones equivalentes; no representa cada visita real. |
| Puntuación de rendimiento | Resumen de la prueba de laboratorio de 0 a 100 | Una nota no acredita ventas, funcionamiento del contacto ni necesidad de contratar otro servidor. |
Si dice que no hay datos suficientes, no significa que la página sea rápida, lenta o esté desindexada. Puede faltar una muestra representativa. Continúa con laboratorio y pruebas del recorrido; no conviertas la ausencia de datos en un diagnóstico. La documentación de Google PSI explica esta separación.
TBT no es INP. Lighthouse puede mostrar Total Blocking Time como indicio de tareas que bloquean el navegador. No lo presentes como una medición real del tiempo de interacción de tus visitantes. Las explicaciones de Web Vitals distinguen ambas métricas.
Qué revisar según el problema que aparece
| Lo que observa el visitante | Primera revisión | Responsable habitual |
|---|---|---|
| La imagen o texto principal aparece tarde | Tamaño y entrega de la imagen, prioridades de carga, estilos y respuesta inicial | Quien desarrolla o mantiene la página; proveedor cuando hay evidencia de infraestructura |
| El menú o botón reacciona tarde | Scripts, tareas largas y recursos de terceros | Desarrollo y responsables de las integraciones |
| El botón cambia de posición mientras carga | Espacio reservado para imágenes, anuncios e incrustaciones | Diseño y desarrollo |
| La página abre, pero el formulario no llega | Errores del formulario, correo, bandeja de entrada y confirmación | Responsable de la página y del correo |
| La espera ocurre antes de mostrar contenido | Redirecciones, respuesta del servidor, caché, consultas y ruta de red | Responsable técnico, con evidencia compartida al proveedor |
Esta tabla orienta la investigación; no certifica una causa. Si usas un creador de páginas con alojamiento incluido, primero revisa sus herramientas y soporte. No contrates otro hosting por defecto. Para WordPress, un cambio de caché o plugins debe probarse con respaldo y reversión, especialmente si existe carrito, sesión de cliente o reserva.
Cinco señales visibles para el dueño de una pyme
- La portada tarda en mostrar lo importante. El visitante ve un espacio vacío, un cargador o una imagen enorme antes de saber qué vendes.
- Los botones reaccionan tarde. Al tocar WhatsApp, el menú, “cotizar” o “comprar”, no ocurre nada inmediatamente y la persona vuelve a tocar.
- El contenido se mueve mientras carga. El botón cambia de lugar y el visitante termina abriendo otra cosa.
- En datos móviles todo empeora. Una prueba en el Wi-Fi de la oficina no representa a quien llega desde la calle.
- El recorrido comercial exige demasiada paciencia. La página puede abrir, pero buscar el contacto, completar el formulario o terminar el pago sigue siendo lento.
Haz estas pruebas antes de llamar a un proveedor
1. Prueba el recorrido con datos móviles
Abre una ventana privada desde el teléfono, desactiva el Wi-Fi y realiza la acción que esperas de un cliente: encontrar un servicio, abrir WhatsApp, cotizar, reservar o comprar. Cronometra la experiencia completa, no solo la aparición del logo.
2. Revisa tres páginas, no solo la portada
Prueba la página de inicio, la página que recibe más visitas y la página donde ocurre la conversión. Una portada rápida no compensa un carrito, formulario o ficha de servicio lenta.
3. Usa PageSpeed Insights como diagnóstico, no como veredicto
PageSpeed Insights puede mostrar datos de usuarios reales cuando existe suficiente información y también una prueba de laboratorio. Sirve para detectar oportunidades, pero un número aislado no demuestra cuánto dinero pierdes ni identifica automáticamente al responsable.
Los Core Web Vitals observan tres experiencias importantes:
- LCP: cuándo aparece el contenido principal; web.dev considera bueno un LCP de hasta 2,5 segundos en el percentil 75.
- INP: cuánto demora la página en responder a interacciones; el umbral bueno es hasta 200 milisegundos en el percentil 75.
- CLS: cuánto se mueve inesperadamente el contenido mientras carga.
- Para CLS, el umbral bueno es hasta 0,1. Los objetivos LCP, INP y CLS se evalúan en el percentil 75 de datos de campo; no son una garantía para cada visita. TTFB —tiempo hasta el primer byte— ayuda a diagnosticar la respuesta inicial, pero no es una de esas tres Core Web Vitals.
4. Comprueba si el contacto realmente funciona
Envía el formulario, abre WhatsApp, toca el teléfono, prueba el correo y completa una compra de prueba cuando corresponda. Una web técnicamente rápida que no entrega el mensaje o rompe el pago también pierde oportunidades.
5. Compara antes y después con una métrica comercial
Registra durante un periodo comparable:
- visitas a la página;
- clics en WhatsApp, teléfono o correo;
- formularios enviados;
- compras o reservas completadas;
- errores y abandonos del paso principal.
Después de corregir, mide las mismas acciones. Esa comparación permite saber si la mejora técnica ayudó al negocio.
¿Es el hosting, la página o un tercero?
Puede ser el hosting cuando el servidor responde tarde, se queda sin recursos o se vuelve inestable bajo carga. Puede ser la aplicación cuando existen consultas lentas, plugins, temas pesados o falta de caché. Puede ser el navegador cuando debe descargar imágenes, fuentes y scripts excesivos. También puede ser un tercero: chat, anuncios, mapas, seguimiento o medios de pago.
No migres solo porque una herramienta mostró rojo. Primero identifica dónde se consume el tiempo y quién puede corregirlo. Una migración que conserva los mismos problemas puede cambiar la factura sin mejorar la experiencia.
Si el diagnóstico apunta a conexión o respuesta inicial, la guía de latencia VPS, ping y TTFB en TopHosting permite separar esas fases. Si necesitas evaluar un cambio de alojamiento, revisa hosting para pymes y migración de página y correo, no únicamente RAM o mensualidad.
Relación comercial: ZonaPyme y TopHosting pertenecen al mismo proyecto afiliado de HostingPlus y podemos recibir comisión mediante enlaces comerciales. El diagnóstico no exige comprar hosting ni VPS; ninguna comparación sustituye la revisión de tu página.
Ejemplos ficticios para decidir la siguiente tarea
Una peluquería obtiene buena respuesta inicial, pero su portada tarda en mostrar una fotografía enorme. La primera tarea es revisar esa imagen y su carga, no dar por probado que el servidor sea pequeño. Una tienda muestra el catálogo rápido, pero el botón de compra reacciona tarde: toca revisar interacciones y scripts, además del pago. Una consultora tiene buena puntuación, pero el formulario termina sin entregar el mensaje: primero se corrige el contacto.
Son escenarios educativos, no clientes reales de ZonaPyme ni resultados medidos. No permiten calcular cuánto dinero pierde un negocio concreto. Registra el síntoma, confirma la causa y cambia una cosa a la vez para poder interpretar el resultado.
Plantilla para pedir una revisión
Copia esta estructura y completa solo lo que comprobaste. Evita contraseñas, datos personales de clientes y pedidos reales:
Página pública y acción a revisar:
Fecha, país y conexión de la prueba:
Dispositivo y navegador:
Síntoma exacto y pasos para reproducirlo:
Informe PageSpeed móvil y escritorio:
Datos de URL u origen; campo o laboratorio:
Qué cambio se propone y qué evidencia lo respalda:
Responsable, respaldo y forma de revertir:
Prueba de contacto o compra después del cambio:
Fecha para medir de nuevo:
Para el registro del negocio, separa visitas, clics en el contacto y consultas efectivamente recibidas. En una página con 100 visitas y cuatro clics, la proporción de clics es 4%; eso no demuestra cuatro consultas ni cuatro ventas. Es un ejemplo ficticio de cálculo, no una tasa objetivo. Con pocas visitas evita atribuir una variación al cambio técnico sin más evidencia.
Qué pedir en una revisión seria
- medición en móvil y escritorio;
- datos reales y prueba de laboratorio distinguidos;
- revisión del recorrido comercial principal;
- causa probable y evidencia;
- acciones priorizadas por impacto y esfuerzo;
- responsable de cada cambio;
- medición posterior;
- respaldo y plan de reversión antes de modificar producción.
Conclusión
La pregunta correcta no es “¿mi web obtiene 100?”. Es “¿una persona puede llegar, entender, confiar y actuar sin que la tecnología se interponga?”. Empieza por el recorrido de venta, mide el problema y corrige la causa antes de comprar más infraestructura.
Preguntas frecuentes sobre una página web lenta
¿Por qué cambia la puntuación sin que cambie mi página?
Las condiciones de una prueba pueden variar. Conserva varios resultados comparables y sus métricas, no solo el mejor. Los datos reales de 28 días tampoco desaparecen al aplicar una mejora: comprueba la ventana temporal antes de concluir que no funcionó.
¿Tengo que llegar a 100 para posicionarme en Google o Bing?
No. Un informe de velocidad no garantiza posiciones. Google documenta que los buenos Core Web Vitals son parte de la experiencia, no una promesa de primera posición. Contenido útil, acceso y recorrido funcional siguen siendo necesarios; la nota no sustituye esa revisión.
¿Una página rápida puede seguir perdiendo consultas?
Sí. Puede explicar mal el servicio, ocultar condiciones o tener un contacto que falla. Usa la plantilla de página de servicio y SEO local para revisar lo que entiende la persona, además del tiempo de carga.
¿Cuándo tiene sentido cambiar de hosting?
Cuando el diagnóstico confirme una limitación que el servicio actual no pueda resolver y el nuevo alcance cubra esa necesidad. Define quién mantiene la aplicación, cuánto cuesta renovar y cómo se restaurará si falla. Más infraestructura no arregla automáticamente el contenido, un plugin o un formulario.
Fuentes reconsultadas el 13-10-2026: Google experiencia de página, documentación PSI, Web Vitals, TTFB y optimización TTFB.