Web lenta: qué la frena de verdad y qué no vas a arreglar

Publicado el 1 de septiembre de 2026 · Por Jesús Iturbide, en colaboración con el equipo de Marketing España · Lectura: 21 min

«Lenta» son cuatro esperas distintas, y no se arreglan igual

Cuando alguien dice que su web va lenta está describiendo una sensación, y esa sensación puede venir de cuatro sitios distintos. Confundirlos es la razón de que tanta gente compre un plugin de optimización, active todas sus casillas y siga exactamente igual de lenta: se atacó la espera equivocada.

Los umbrales exactos de cada indicador no te los voy a recitar de memoria, y desconfía de la guía que lo haga: los publica Google, se revisan cada cierto tiempo y las propias herramientas te los marcan en verde, ámbar o rojo cuando mides. Lo que sí aguanta el paso del tiempo es la lógica de la tabla: identifica cuál de las cuatro esperas es la tuya antes de tocar nada, porque el arreglo de una no mejora las otras tres.

Por dónde se empieza de verdad: el orden de ataque

Casi todas las guías de velocidad empiezan por las imágenes y la caché en la misma frase, como si fueran del mismo tamaño. No lo son. La caché de página es la única medida que cambia todas las páginas de tu sitio a la vez y ataca la primera espera, que es la que el visitante sufre con la pantalla en blanco. Comprimir el CSS mueve milisegundos en una sola de las cuatro esperas. Se hacen las dos cosas, pero no en cualquier orden.

La caché de página guarda el resultado ya cocinado de cada dirección: la primera visita paga la elaboración y las siguientes reciben un archivo hecho. Por eso su efecto es tan grande y tan barato. Y por eso el primer diagnóstico de cualquier web lenta es comprobar si existe, si está activa para las páginas que importan y si alguien la vació la última vez que se tocó algo.

1. Mide primero, y mide en el móvil. Apunta la dirección exacta, la herramienta y la hora. Sin línea de partida no hay mejora que demostrar, solo sensaciones.
2. Caché de página. Que exista, que cubra las páginas que reciben visitas y que se vacíe automáticamente cuando publicas. Es el mayor salto por el menor trabajo.
3. La primera pantalla. La imagen de cabecera en formato moderno y al tamaño en que se ve de verdad, con sus medidas declaradas. Es la que decide la segunda espera.
4. El resto de imágenes. Formato moderno, carga diferida para lo que está más abajo y ni un archivo de cuatro mil píxeles para un hueco de seiscientos.
5. Tipografías. Solo las familias y los grosores que se usan de verdad, servidas desde tu propio dominio.
6. JavaScript, el último y con desglose. Pesa cada archivo por origen antes de decidir. Aquí es donde casi todo el mundo se equivoca, y donde se rompen las webs.

Este orden no es caprichoso: va de lo que afecta a todo el sitio hacia lo que afecta a una página, y de lo reversible a lo que puede romper algo. Si tienes presupuesto para dos días de trabajo, los dos primeros pasos te dan casi todo lo que hay disponible sin tocar el diseño. Del quinto en adelante, el retorno cae y el riesgo sube.

Lo que no vas a poder quitar (y por qué)

Aquí está la parte que casi ninguna guía cuenta, porque no es agradable: en una web moderna, la mayor parte del peso pertenece a piezas que sostienen la web en pie. No son restos de un plugin olvidado. Son el constructor con el que está maquetada cada página, el tema que le da forma, el gestor de consentimiento que te mantiene dentro de la ley y el complemento que pinta los menús. Se pueden aplazar, se pueden servir mejor, se pueden vigilar. Quitarlas, no.

La consecuencia práctica es incómoda pero libera: por debajo de cierto punto, tu web no baja de peso sin cambiar de tecnología. Y cambiar de tecnología pertenece a otra categoría de trabajo: un proyecto de desarrollo con su presupuesto, su calendario y su riesgo. Cuándo compensa esa decisión lo tratamos en nuestro servicio de desarrollo web, y la comparación entre gestores tiene artículo propio: WordPress para empresas.

Mientras tanto, hay margen real en cómo se sirven esas piezas: aplazar lo que no interviene en la primera pantalla, cargar el anti-spam solo en la página del formulario, no arrastrar el constructor en plantillas que no lo usan. Es trabajo fino, se nota menos que la caché y exige comprobar página por página que no se ha roto nada.

Lo hemos probado: 850 KB que parecían margen

La suma de la lista no da la cifra del informe, y conviene decirlo en voz alta: la herramienta cuenta el JavaScript de una manera y el navegador descarga otra cosa. Esa discrepancia es la primera lección del caso. La segunda es peor y es nuestra: el candidato que teníamos apuntado para eliminar era el equivocado. Íbamos a por los 22 KB del complemento del menú, que parecía accesorio por el nombre. Habría dejado la web sin navegación en escritorio y en móvil, y el fallo no se habría visto en la portada, que es donde todo el mundo comprueba.

El matiz honesto, porque sin él el caso engaña: esos 7 KB no cambiaron ningún tiempo que un visitante pueda notar. La web ya respondía entre 21 y 67 milisegundos gracias al trabajo de caché hecho antes, y siguió igual después. Lo que cambió no fue la velocidad, fue el diagnóstico: dejamos de perseguir un margen que no existía y cerramos el asunto por escrito. Bajar de ahí exigía salir del constructor, y eso es un rediseño. Saber cuándo parar de optimizar también es parte del trabajo, y es la parte que nadie factura.

Por qué la puntuación baila cada vez que la miras

La puntuación que devuelve una herramienta de velocidad no es tu web: es una simulación de una carga, en un dispositivo simulado, con una conexión simulada, en un momento concreto. Repite la medida cinco minutos después y saldrá distinta. Eso no es un defecto de la herramienta, es lo que ocurre cuando mides un sistema con red por medio.

Hay tres motivos habituales para que dos medidas de la misma página no coincidan. El primero, la caché: la primera visita después de publicar algo paga la elaboración completa y la siguiente ya recibe el archivo hecho. El segundo, el vecindario: en alojamiento compartido, tu web convive con otras que a veces se ponen a trabajar. El tercero, y el más frecuente de todos, es el ordenador desde el que mides.

En casa tenemos una regla escrita al respecto, y nació de un error propio: el día que fuimos a medir el JavaScript de nuestra web, el equipo tenía trece sesiones de trabajo abiertas. Una medición hecha así no vale, y la dimos por nula. Si tu portátil está compilando, sincronizando la nube o con cuarenta pestañas, lo que estás midiendo es tu portátil.

Cuatro reglas para que tus mediciones signifiquen algo. Mide siempre la misma dirección, con la misma herramienta y en la misma franja horaria. Toma tres medidas y quédate con la del medio, nunca con la mejor. Haz una con la caché fría y otra con la caché caliente, y compara cada una con su equivalente. Y mide en el perfil de móvil, que es donde entra la mayoría de tus visitas y donde la diferencia duele. Un informe que compare una medida de móvil de hoy con una de escritorio de la semana pasada no demuestra nada.

Imágenes, tipografías y vídeo: el peso que sí es tuyo

Frente a lo intocable, hay una franja de peso que es enteramente tuya y donde casi siempre hay margen de sobra. Es la parte aburrida del trabajo, la que no luce en ninguna reunión y la que más devuelve por hora invertida.

Las imágenes. El patrón se repite en casi todas las webs que auditamos: fotos subidas tal como salieron de la cámara o del banco de imágenes, de varios miles de píxeles de ancho, para huecos que en pantalla miden una fracción de eso. Convertirlas a un formato moderno, generar los tamaños que el diseño usa de verdad y declarar el ancho y el alto en el propio código quita peso y, de paso, evita que la página salte mientras carga.

Las tipografías. Cada familia y cada grosor es un archivo que hay que descargar antes de poder pintar el texto con su forma definitiva. Tres familias con cuatro grosores cada una son doce descargas para algo que el lector no distingue. Elige dos, sirve solo los grosores que aparecen en el diseño y aloja los archivos en tu dominio en lugar de pedirlos a un tercero.

Los iconos. Un patrón silencioso y muy caro: instalar una fuente de iconos completa, con cientos de símbolos, para pintar cuatro flechas y un teléfono. Se sustituyen por los cuatro dibujos que usas, incrustados directamente donde van.

El vídeo de fondo de la cabecera. Es el elemento más pesado que puede llevar una web y el que menos gente mira. Si el diseño lo pide, que no cargue en móvil y que tenga una imagen de reserva. Si no lo pide nadie, fuera.

Los carruseles. Arrastran su propia biblioteca, cargan varias imágenes grandes de las que solo se ve una y suelen esconder el mensaje principal en la diapositiva tres, que no ve casi nadie. Antes de optimizar un carrusel, plantéate si hace falta.

Cuándo el problema está debajo de la web

Hay una comprobación de dos minutos que separa un problema de página de un problema de servidor. Abre la misma página dos veces: una como visitante anónimo y otra recién publicado un cambio, con la caché vacía. Si la primera vuela y la segunda tarda varios segundos, tu web depende por completo de la caché y debajo hay algo lento. Es la señal más clara de que el trabajo no está en las imágenes.

Las causas habituales son cuatro. Un alojamiento compartido con demasiadas webs por máquina, que va bien a las tres de la mañana y mal a media mañana. Una versión antigua del lenguaje del servidor, que ejecuta el mismo código bastante más despacio que la actual. Una base de datos que ha ido acumulando años de revisiones, registros de plugins y datos de sesiones sin que nadie la limpie. Y consultas caras en cada carga, que en las páginas que no se cachean, como el carrito o el buscador interno, se notan enteras.

Cuando el problema está aquí, ninguna galería optimizada lo tapa. La secuencia sensata es: comprobar que la versión del lenguaje es la que soporta tu gestor, limpiar la base de datos con copia de seguridad delante, activar caché de objetos si el alojamiento la ofrece y, si con todo eso el suelo sigue siendo alto, cambiar de alojamiento. Mudarse asusta más de lo que duele, y suele ser la mejora más grande disponible en una tarde.

Cinco formas de dejar la web peor intentando acelerarla

El plugin de optimización es una caja de herramientas afiladas, y viene sin instrucciones de seguridad. Estos son los cinco destrozos que más vemos, todos evitables:

• Activar todas las casillas de golpe. Si algo se rompe, ya no sabes cuál de las once opciones fue. Se activa de una en una, se comprueba y se pasa a la siguiente. Es más lento y es la única forma de saber qué hiciste.
• Unificar y comprimir el código sin recorrer la web después. Es la opción que más rompe cosas, y lo que rompe casi nunca está en la portada: se cae el envío del formulario, el menú de móvil deja de abrirse o el buscador no responde. Se revisa una página de cada tipo, no solo la principal.
• Aplazar el JavaScript del aviso de cookies. Ganas unas décimas y te quedas sirviendo scripts que necesitan permiso antes de tenerlo. Ese ahorro no compensa el riesgo legal.
• Dos sistemas de caché a la vez. El del plugin y el del alojamiento peleándose dan páginas servidas a destiempo, cambios que no aparecen y avisos de sesión cruzados. Se elige uno.
• Medir la mejora sobre la copia cacheada. Si mides justo después de tocar algo sin vaciar la caché, estás midiendo la página vieja y celebrando un arreglo que todavía no existe. Vacía, recarga dos veces y mide entonces.

Qué puedes esperar de verdad

Una web lenta que se arregla bien sigue siendo la misma web: mejor servida, no más persuasiva. Merece la pena decirlo antes de empezar, porque la decepción típica de este trabajo no viene de que la velocidad no mejore, viene de esperar que la velocidad venda por sí sola. Si el problema es que la página no da motivos para contactar, eso se arregla en otro sitio, y lo contamos en los cambios que sí mejoran una web que no convierte.

Con expectativas ordenadas, esto es lo razonable. La caché de página y el alojamiento pueden cambiar la sensación entera del sitio en una tarde de trabajo, y son mejoras que se notan en todas las páginas. Las imágenes y las tipografías dan una mejora grande y visible, medible en peso descargado, en un par de días. El afinado de código da mejoras pequeñas con riesgo alto, y por eso va al final. Y el peso del constructor, del tema y del consentimiento no se mueve sin cambiar de tecnología, que es otra conversación y otro presupuesto.

• Exige la medición de antes y la de después. Misma dirección, misma herramienta, mismo perfil de dispositivo y franja horaria parecida. Sin eso, no hay mejora demostrada.
• Pide la lista de lo que se tocó. Qué opción se activó, en qué orden y qué se comprobó después de cada una.
• Comprueba tú lo que da dinero. Envía el formulario, abre el menú en el móvil, busca algo, termina una compra. Esa comprobación no la delegues.
• Pregunta qué se ha decidido no tocar. Un informe de rendimiento honesto termina diciendo qué margen no existe, no solo lo que se ha ganado.

Trabajamos desde Navarra para clientes de toda España, y el patrón se repite con independencia del tamaño y del sector: casi siempre hay una mejora grande esperando en la caché o en el alojamiento, casi siempre hay margen en las imágenes, y casi nunca hay tanto margen en el JavaScript como dice el informe.

Preguntas frecuentes

¿Cuánto debería tardar en cargar mi web?

La cifra útil no es universal, es comparativa. Mide tu web y mide tres competidores con la misma herramienta, el mismo perfil de móvil y el mismo día. Si estás claramente por detrás, tienes trabajo; si estás en la media de tu sector, el siguiente euro rinde más en otra parte. Perseguir un número redondo porque lo dijo un blog es la forma más común de gastar de más en esto.

¿Me basta con instalar un plugin de caché?

Para la mayoría de webs pequeñas, un plugin de caché bien configurado es la mitad del resultado disponible. La otra mitad son las imágenes y el alojamiento. Lo que no arregla ningún plugin es un servidor lento por debajo ni un constructor pesado por arriba, y ninguna casilla va a hacer que quepan más cosas en la primera pantalla.

¿La velocidad afecta al posicionamiento en Google?

Es uno de los factores que Google mide y publica en Search Console, pero es un factor entre muchos. Arreglar la velocidad no sube posiciones por sí solo si el contenido no responde a lo que se busca. Su efecto más claro y más inmediato es sobre la gente que ya está entrando: la que se cansa de esperar se va, y esa pérdida sí la controlas tú.

¿Puedo desactivar plugins para ir más rápido?

Puedes, y es justo donde hay que ir con más cuidado. Antes de desactivar nada, mira qué pinta cada uno en la página, no qué promete su nombre. Nosotros estuvimos a punto de quitar el que dibuja los menús de nuestra propia web. Desactiva uno, recorre las plantillas principales, envía el formulario y solo entonces sigue.

Mi web va lenta solo a ratos. ¿Qué pasa?

Los picos apuntan casi siempre al servidor, no a la página. Un alojamiento compartido saturado a ciertas horas, una copia de seguridad programada en horario de oficina, un proceso interno del gestor o un límite de recursos que se alcanza y encola las peticiones. Se diagnostica midiendo la misma dirección a varias horas durante unos días, no una sola vez.

¿Cuánto se tarda en arreglar una web lenta?

La parte grande cabe en una o dos jornadas de trabajo: medición, caché, alojamiento y la primera pantalla. Las imágenes de un catálogo entero y las tipografías llevan otro par de días según el volumen. El afinado de código es trabajo de semanas con revisión página a página. Y cambiar de tecnología para bajar el peso del constructor ya es un proyecto de desarrollo, con su presupuesto propio.

¿Y si mi web es antigua? ¿Compensa optimizarla o rehacerla?

Optimizar primero, decidir después. Una web sobria de hace años que carga rápido cumple perfectamente; la antigüedad por sí sola no es un defecto de rendimiento. La conversación de rehacerla se abre cuando el peso irreducible del constructor y el tema te deja por debajo de tus competidores aun después de hacerlo todo bien, o cuando el mantenimiento cuesta más que empezar de nuevo. Esa cuenta se hace con las mediciones delante, no con la impresión de que la web «se ve vieja».

Sigue por aquí

• Los cambios que sí mejoran una web que no convierte
• WordPress para empresas: cuándo conviene y cuándo no
• Nuestro servicio de desarrollo web