Cuando un cliente me dice «creo que mi web va lenta», lo primero que hago es preguntarle: ¿lenta en qué? Casi siempre la respuesta es «no sé, la abrí en el ordenador de la oficina y tardó un poco». Y ahí ya tenemos el primer problema, que ni siquiera es de la web.
La velocidad de una web no es un número único. Es una combinación de métricas que miden cosas distintas: cuándo empieza a aparecer algo en pantalla, cuándo el usuario puede interactuar, si los elementos se mueven mientras cargan. Y cada una de esas métricas tiene causas distintas y soluciones distintas.
Esto es lo que reviso en cada auditoría de velocidad, en el orden en que lo reviso, y por qué cada punto importa.
Lo primero que miro: el móvil, no el ordenador
La mayoría de quienes revisan si su web va rápido lo hacen desde el ordenador de la oficina, con fibra, en horario de poco tráfico. Ese no es el escenario real. La mayoría de las visitas a una web de negocio llegan desde el móvil, con datos, muchas veces con mala cobertura.
Una web puede sentirse instantánea en un portátil con fibra y tardar 6 segundos en el móvil de alguien que va caminando por la calle. Y es esa segunda persona la que decide si te llama o se va a la siguiente opción de Google. El punto de partida siempre es PageSpeed Insights con la URL de tu web, mirando la puntuación móvil. Si está por debajo de 50, el problema es real y medible.
Las causas más habituales de una web lenta
Después de revisar la velocidad de más de 160 webs de pymes españolas, hay un patrón que se repite con una consistencia que ya no me sorprende. La causa número uno, de lejos, son las imágenes sin comprimir. Una foto de móvil moderno pesa entre 4 y 6 megabytes. Subida directamente a WordPress sin procesar, esa imagen sola puede hacer que tu web tarde el doble en cargar. Y casi nadie lo sabe porque nadie se lo ha dicho.
La causa número dos son los sliders y carruseles a pantalla completa. Visualmente llaman la atención, pero suelen cargar varias imágenes pesadas de golpe, además del código JavaScript necesario para que se muevan. En casi todos los proyectos que he optimizado, eliminar o simplificar el slider de portada ha sido el cambio con mayor impacto inmediato en la puntuación de velocidad.
La causa número tres son los plugins acumulados en WordPress. Cada plugin instalado carga su propio CSS y JavaScript en cada página, aunque no se use ahí. Con los años, esto se acumula sin que nadie lo note hasta que alguien mide cuánto pesa todo junto. He visto webs con 40 plugins activos donde la mitad llevaban meses sin ser necesarios. Cada uno de esos plugins es peso que la web carga gratis, para nada, en cada visita.
La causa número cuatro, y la que más sorprende cuando aparece, es el hosting. Si tu web está en un servidor compartido de 3 o 4 euros al mes, ese es el techo de lo que puedes conseguir en velocidad, independientemente de lo bien que esté programada. El tiempo de respuesta del servidor, el TTFB, es el primer número que miro en cualquier auditoría. Si supera los 600 milisegundos, el hosting es el problema y no hay optimización de código que lo compense del todo.
Qué son los Core Web Vitals y por qué importan para Google
Google mide la velocidad de tu web con tres métricas concretas que desde 2021 son factor de ranking directo. No es teoría: una web con Core Web Vitals en rojo pierde posiciones frente a competidores con contenido similar pero mejor rendimiento técnico.
El LCP, o Largest Contentful Paint, mide cuánto tarda en aparecer el elemento principal de la pantalla: la imagen de portada, el titular, el bloque más grande visible. El objetivo es menos de 2,5 segundos. En mi análisis de 160 webs, el 98% de las que tenían LCP medible lo superaban. La causa más habitual es siempre la misma: una imagen pesada sin comprimir en el hero de la página.
El INP, o Interaction to Next Paint, mide cuánto tarda la web en responder cuando el usuario hace algo: hace clic en un botón, abre un menú, escribe en un campo. El objetivo es menos de 200 milisegundos. Los problemas de INP casi siempre vienen de demasiado JavaScript ejecutándose en el hilo principal del navegador, que es exactamente lo que genera Elementor con muchos widgets.
El CLS, o Cumulative Layout Shift, mide si los elementos de la página se mueven mientras carga. Todos hemos experimentado esto: vas a hacer clic en algo y en el último momento se desplaza hacia abajo porque acaba de cargar un banner o una imagen sin dimensiones definidas. Es frustrante para el usuario y Google lo penaliza. La solución es siempre la misma: definir las dimensiones de las imágenes en el HTML para que el navegador reserve el espacio antes de que carguen.
Lo que puedes hacer tú mismo sin tocar código
Hay tres cosas que cualquiera puede hacer sin ser developer y que tienen un impacto real en la velocidad.
La primera es comprimir las imágenes antes de subirlas. Squoosh es una herramienta gratuita de Google que funciona en el navegador: subes la imagen, eliges el formato WebP y el nivel de compresión, y la descargas lista para subir. La pérdida de calidad visual es imperceptible y el ahorro en peso puede ser del 70 al 80%.
La segunda es revisar si ese slider de portada hace falta. Si tu web tiene un carrusel de 4 o 5 imágenes, probablemente con una sola imagen bien elegida transmites lo mismo, y tu web carga la mitad de rápido. Es el cambio con mejor ratio impacto/esfuerzo que puedo recomendar sin ver la web.
La tercera es hacer una limpieza de plugins. Si tienes WordPress, entra en la sección de plugins y mira cuántos hay instalados pero desactivados, o activos sin que nadie sepa para qué sirven. Cada uno de esos es peso que tu web carga en cada visita. Eliminar los que no hacen nada es trabajo de una tarde y no requiere tocar ningún código.
Cuándo el problema requiere un developer
Las tres acciones anteriores resuelven los problemas más superficiales. Pero hay causas de lentitud que requieren intervención técnica: un TTFB alto por culpa del hosting o de la configuración del servidor, JavaScript de terceros bloqueando el renderizado, CSS crítico no inlineado, fuentes web mal cargadas, o un tema de WordPress que genera decenas de peticiones innecesarias en cada página.
Para esos casos, lo que tiene sentido es una auditoría de WPO que identifique exactamente qué está causando el problema y en qué orden tiene sentido resolverlo. No todas las causas de lentitud tienen el mismo impacto, y arreglarlas en el orden equivocado es trabajo perdido. Si quieres entender en detalle qué métricas reviso y cómo las interpreto en el contexto de WordPress con Elementor, tienes la guía completa de Core Web Vitals para WordPress aquí.
Y si prefieres que alguien revise directamente tu caso, cuéntame qué está pasando con tu web y en 24 horas te digo qué está causando el problema y cuánto cuesta resolverlo.
Preguntas frecuentes sobre velocidad web
¿Por qué mi web va lenta si la hicieron hace poco?
Porque la velocidad no es algo que se configure automáticamente al construir una web. Un diseñador puede entregar algo visualmente perfecto que carga en 8 segundos en móvil, simplemente porque las imágenes no están comprimidas, el hosting es demasiado básico o el tema de WordPress carga código que no se usa en ninguna página. Sin una revisión técnica específica de rendimiento, estos problemas pasan desapercibidos hasta que alguien los mide.
¿Comprimir imágenes afecta a la calidad visual?
Con los formatos modernos como WebP o AVIF, la pérdida de calidad es imperceptible a simple vista mientras el ahorro en peso puede ser del 70 al 80%. Una imagen de 4 MB comprimida a WebP puede pesar 400 KB con el mismo aspecto visual. La diferencia en tiempo de carga es brutal.
¿Cómo sé si mi puntuación de velocidad es buena o mala?
PageSpeed Insights usa un sistema de colores: verde es bueno (90 a 100), naranja es mejorable (50 a 89) y rojo es problemático (0 a 49). En móvil, la puntuación siempre es más baja que en escritorio porque simula condiciones de red más lentas. Una puntuación móvil por encima de 70 ya es mejor que la mayoría de webs de pymes en España. Por encima de 90 es excelente.
¿Mi web va lenta porque el hosting es malo?
Puede ser. El hosting es el factor que más se infravalora y que más impacto tiene en el tiempo de respuesta del servidor. Si PageSpeed Insights muestra un «Tiempo de respuesta inicial del servidor» superior a 600 milisegundos, el hosting es el problema principal y ninguna optimización de código lo va a compensar del todo. Un cambio a un hosting de calidad, entre 15 y 30 euros al mes, suele tener un impacto inmediato y medible.
¿Esto sirve también si mi web no es WordPress?
El consejo de las imágenes y los sliders aplica a cualquier web, sea la plataforma que sea. Lo de los plugins es específico de WordPress, pero casi todas las plataformas tienen su equivalente en apps o extensiones que también pesan. Y los Core Web Vitals los mide Google en todas las webs por igual, independientemente de la tecnología con la que estén construidas.
¿Cuánto cuesta una auditoría de velocidad web?
En Daruma Producciones la auditoría de WPO parte desde 300€ más IVA e identifica exactamente qué está causando el problema de velocidad, en qué orden tiene sentido resolverlo y qué impacto potencial tiene cada mejora. Si además quieres que implementemos los cambios, la auditoría más implementación parte desde 600€ más IVA. Tienes todos los detalles en el servicio de optimización de velocidad.
Más sobre SEO técnico y rendimiento web
¿TU WEB TIENE ALGUNO DE ESTOS PROBLEMAS?
Cuéntame tu caso y en 24h sabes qué está fallando y cuánto cuesta arreglarlo. Sin coste y sin compromiso. Cris Culebras · Daruma Producciones.
Escríbenos →
