Mejorar la velocidad de carga de una web no consiste en perseguir una puntuación perfecta. Consiste en conseguir que una persona vea el contenido principal pronto, pueda interactuar sin retrasos y no encuentre elementos que cambian de sitio mientras la página carga. Cuando algo falla, la solución depende de la causa, puede estar en una imagen, el servidor, el tema, un plugin o un script externo.
Qué significa realmente que una web sea rápida.
Una web rápida no es solo la que termina de descargar todos sus archivos pronto. Para quien la visita importan tres momentos, cuándo aparece lo que venía a buscar, cuándo puede utilizar la página y si la interfaz se mantiene estable. Por eso conviene combinar una prueba técnica con una revisión del recorrido real.
Los Core Web Vitals ayudan a ordenar esa revisión. Actualmente se centran en LCP, INP y CLS. Google considera buenos un LCP de hasta 2,5 segundos, un INP de hasta 200 milisegundos y un CLS de hasta 0,1, evaluados en el percentil 75 de las visitas. La explicación y los umbrales se pueden consultar en la documentación de web.dev.
| Métrica | Qué observa | Umbral bueno |
|---|---|---|
| LCP | Cuánto tarda en aparecer el contenido principal. | Hasta 2,5 s |
| INP | Cómo responde la página al interactuar. | Hasta 200 ms |
| CLS | Cuánto se mueve inesperadamente el contenido. | Hasta 0,1 |
Estas métricas son útiles, pero no cuentan toda la historia. Una página puede aprobarlas y seguir siendo incómoda por una navegación confusa, un formulario largo o un aviso que tapa el contenido. Google también aclara que obtener buenos resultados no garantiza una posición alta, la relevancia y la calidad del contenido siguen siendo fundamentales.
Empieza por medir antes de cambiar cosas.
PageSpeed Insights combina dos tipos de información. Los datos de laboratorio simulan una carga y ayudan a diagnosticar problemas. Los datos de campo proceden de visitas reales y muestran cómo se comporta la web en condiciones distintas. Cuando hay suficiente tráfico, estos últimos son los que mejor reflejan la experiencia de los usuarios.
No conviene instalar varios plugins o cambiar de servidor solo porque una herramienta muestra una advertencia. Primero hay que localizar qué recurso está afectando al contenido principal, qué bloquea el navegador y qué se carga sin aportar nada a esa página.
Las imágenes suelen ser el primer lugar donde mirar.
Una fotografía de portada puede pesar mucho más que todo el HTML y el CSS juntos. Antes de subirla hay que ajustar sus dimensiones, comprimirla y elegir un formato adecuado. WebP y AVIF suelen reducir el peso, pero el formato no sustituye a una buena compresión ni a servir el tamaño correcto para cada pantalla.
- La imagen principal necesita prioridad. No debería cargarse de forma diferida si es el elemento que ocupa la parte visible al entrar.
- Las imágenes inferiores pueden esperar. La carga diferida evita descargar contenido que todavía está fuera de la pantalla.
- El ancho y el alto deben estar definidos. Así el navegador reserva el espacio y se reducen los saltos de diseño.
- El móvil no necesita la imagen de escritorio completa. Las imágenes adaptables permiten entregar una versión más pequeña.
Después revisa JavaScript, CSS y recursos externos.
Los constructores visuales, chats, mapas, píxeles publicitarios, reproductores y banners pueden competir por el procesador justo cuando el usuario intenta interactuar. El problema no siempre es el tamaño del archivo, también importa cuánto trabajo obliga a realizar en el navegador.
La prioridad es eliminar lo que no se utiliza y cargar lo demás cuando corresponde. El CSS necesario para la primera pantalla debe llegar pronto. Los scripts no esenciales pueden retrasarse. Las tipografías necesitan pocos pesos, archivos bien preparados y una estrategia que evite bloquear el texto.
Con las herramientas de medición ocurre lo mismo. Analítica, consentimiento y seguimiento deben funcionar, pero no hace falta cargar etiquetas duplicadas ni eventos que nadie utiliza. Una implementación más pequeña suele ser más rápida y también más fácil de mantener.
Servidor, caché y CDN, cuándo marcan la diferencia.
Si el servidor tarda en empezar a responder, optimizar una imagen no resolverá todo el problema. Una web dinámica puede necesitar caché de página, consultas más ligeras o una infraestructura distinta. Una CDN ayuda a servir recursos estáticos desde ubicaciones próximas al visitante y absorbe parte del trabajo, pero no corrige una aplicación lenta en origen.
En una web corporativa con pocas actualizaciones, generar páginas estáticas puede simplificar mucho la entrega. En WordPress, una buena caché y un tema contenido suelen aportar más que acumular plugins de optimización. En un ecommerce hay que separar las páginas que se pueden almacenar de las partes dinámicas, como el carrito, la cuenta o el proceso de pago.
La velocidad móvil necesita una revisión propia.
Probar una web desde un ordenador conectado por fibra oculta problemas que aparecen con un móvil menos potente o una conexión irregular. Conviene revisar menús, filtros, formularios y carruseles con interacción táctil, además de medir la carga. La guía de optimización web móvil desarrolla esta parte con más detalle.
Un caso donde el rendimiento condicionaba el proyecto.
En la red formada por TuAppleMundo, TuTecnoMundo y TuPcMundo había que hacer convivir portadas editoriales, imágenes, carruseles, tipografías y recomendaciones entre medios. La solución no podía limitarse a comprimir recursos al final, el rendimiento debía formar parte de la arquitectura y del tema de WordPress desde el principio.
En el caso de TuAppleMundo explicamos cómo se planteó una base compartida para los tres blogs. Es un buen ejemplo de por qué la velocidad no debería tratarse como un parche posterior.
Qué relación tiene la velocidad con el SEO.
Los Core Web Vitals forman parte de los sistemas que Google utiliza para evaluar la experiencia, pero no sustituyen a la intención de búsqueda, el contenido ni la autoridad. Una web rápida con una respuesta pobre no se convierte en el mejor resultado. Una web relevante que carga mal puede perder oportunidades cuando existen alternativas igualmente útiles y más cómodas.
La mejora debe perseguir las dos cosas, una respuesta clara y una página fácil de utilizar. La documentación de Google Search Central sobre experiencia de página recomienda precisamente una evaluación conjunta.
Un orden práctico para mejorar una web lenta.
- Mide una página representativa. Empieza por la home, una página de servicio y la plantilla que recibe más tráfico.
- Localiza el elemento principal. Comprueba qué forma el LCP y por qué tarda.
- Revisa los recursos más pesados. Imágenes, vídeo, tipografías y scripts externos suelen concentrar el coste.
- Comprueba la respuesta al interactuar. Menú, filtros, formularios y consentimiento deben reaccionar sin bloqueo.
- Busca movimientos inesperados. Reserva espacio para imágenes, banners y contenido que aparece después.
- Cambia una causa y vuelve a medir. Así sabes qué mejora ha producido el resultado.
- Observa datos reales. Search Console y la analítica ayudan a comprobar si la mejora se mantiene.
¿Tu web tarda o no sabes por dónde empezar?
Podemos revisar el origen del problema y decirte qué cambios tienen sentido antes de plantear un rediseño o una migración.
Preguntas frecuentes sobre velocidad web.
¿Qué velocidad de carga debería tener una web?
Como referencia, Google considera bueno un LCP de hasta 2,5 segundos. También hay que revisar la respuesta a las interacciones y la estabilidad visual, no solo el tiempo total de carga.
¿Una puntuación de 100 en PageSpeed mejora el SEO?
No garantiza mejores posiciones. PageSpeed ayuda a detectar problemas de rendimiento, pero Google también valora la relevancia, la calidad del contenido y otros factores.
¿Qué suele ralentizar más una página web?
Las causas habituales son imágenes demasiado grandes, JavaScript innecesario, recursos externos, tipografías mal configuradas, un servidor lento o una combinación de varios factores.
¿Un CDN hace que cualquier web sea rápida?
No. Puede acelerar la entrega de recursos y reducir distancia con el visitante, pero no corrige consultas lentas, código pesado ni una mala estrategia de carga.
¿Hace falta rediseñar una web para mejorar su velocidad?
No siempre. A veces basta con corregir imágenes, scripts, caché o servidor. Si el problema nace de la arquitectura o de una base técnica muy pesada, un rediseño puede resultar más razonable que seguir añadiendo parches.