Cuando una web va lenta, la conversación suele empezar por la herramienta equivocada: «instala un plugin de caché», «cambia de hosting», «ponle una CDN». A veces funciona. Casi nunca es el diagnóstico.
La velocidad es una cadena. Si el cuello está en una consulta de base de datos, comprimir imágenes no lo arregla. Si el problema es una fuente que bloquea el render, cambiar de servidor tampoco. Por eso la primera pregunta no es qué herramienta, sino quién tiene que mirar esto.
Estos son los cinco perfiles que intervienen, qué resuelve cada uno y cómo saber a cuál necesitas.
01Resumen rápido
- FrontendCSS, JavaScript, fuentes, imágenes y todo lo que ocurre en el navegador. Suele tener el mayor margen de mejora visible.
- Backend / WordPressPHP, consultas, plugins y tiempo de respuesta del servidor. Si el HTML tarda en llegar, el navegador no puede hacer magia.
- Hosting e infraestructuraServidor, versión de PHP, caché de objetos, CDN y WAF. Es la base; no sustituye al resto.
- Contenido y diseñoPeso de imágenes, tipografías, vídeos y terceros. Decisiones editoriales con consecuencias técnicas.
- Negocio y analíticaQué significa «suficientemente rápido», qué se mide y qué se prioriza. Sin esto, se optimiza a ciegas.
02Cómo se mide la velocidad
Antes de tocar nada, hay que separar tres cosas que suelen mezclarse:
- Laboratorio: condiciones controladas. Sirve para comparar y detectar cuellos, no para representar a todos los usuarios.
- Campo: datos reales de personas con su red, su dispositivo y su ubicación. Es la referencia que importa.
- Percepción: cuándo parece que la página responde. Un render bloqueado puede hacer que una web «se sienta» lenta aunque el servidor responda rápido.
Las métricas que uso para ordenar el trabajo son LCP (cuándo aparece el contenido principal), INP (cuánto tarda la interfaz en responder) y CLS (cuánto salta el layout). El TTFB ayuda a separar el problema del servidor del problema del navegador.
No se optimiza una métrica que no se ha medido dos veces: antes y después. Y no se promete un 100/100 de Lighthouse como resultado de negocio.
03Los cinco perfiles
1. Desarrollo frontend
Qué resuelve: el camino crítico del navegador. CSS y JavaScript que bloquean, fuentes que tardan, imágenes que se cargan cuando no toca, animaciones que compiten con la interacción.
Cuándo entra: el TTFB es razonable, pero el LCP tarda; la página «salta» al cargar; el INP empeora al interactuar.
Qué le puedes pedir: priorizar el contenido above-the-fold, reducir JS de terceros, cargar fuentes con disciplina, reservar espacio para imágenes y medir el resultado en campo.
El HTML llega rápido, pero el navegador tarda en pintar el contenido principal o la interfaz no responde al hacer clic.
2. Backend y WordPress
Qué resuelve: el tiempo que tarda el servidor en construir la respuesta. Consultas lentas, plugins que se ejecutan en cada carga, hooks pesados, bucles mal planteados, caché de objetos ausente.
Cuándo entra: el TTFB es alto, la web tarda igual en incógnito, o el problema aparece solo con ciertos plugins o páginas.
Qué le puedes pedir: perfilar consultas, revisar plugins, separar el problema del tema y del core, y dejar un diagnóstico reproducible.
El servidor tarda más de lo razonable en devolver el HTML, o la lentitud cambia según la página y el plugin activo.
3. Hosting e infraestructura
Qué resuelve: la base sobre la que corre todo. Versión de PHP, límites de memoria, caché de página y objetos, CDN, WAF, base de datos y backups.
Cuándo entra: hay errores 5xx, el TTFB es inestable, la caché no acierta o el servidor se queda corto en picos.
Qué le puedes pedir: una configuración coherente con el stack, métricas del servidor, caché que no rompa el sitio y un plan de rollback.
La lentitud es intermitente, afecta a todo el sitio o coincide con picos de tráfico. Un plugin no va a arreglar un servidor mal dimensionado.
4. Contenido y diseño
Qué resuelve: el peso que se decide antes de programar. Imágenes de 4 MB, tipografías innecesarias, vídeos incrustados, widgets de terceros y secciones que cargan cosas que nadie ve.
Cuándo entra: el diseño está aprobado y el rendimiento se descubre al final; o cada nueva landing vuelve a introducir el mismo problema.
Qué le puedes pedir: formatos y tamaños de imagen, fuentes limitadas, criterios de carga para vídeos y embeds, y una revisión de lo que realmente necesita el primer viewport.
La página pesa varios megas antes de interactuar y las capturas del diseño incluyen recursos que no aportan a la decisión del usuario.
5. Negocio y analítica
Qué resuelve: la prioridad. Define qué página importa, qué métrica se mueve y cuánto cuesta cada milisegundo en conversión. Evita optimizar la home mientras el checkout sigue roto.
Cuándo entra: hay varias cosas lentas y no se sabe por dónde empezar; o se quiere justificar la inversión con datos y no con una puntuación.
Qué le puedes pedir: un orden de intervención, una línea base y una forma de medir el impacto después del cambio.
Todo el mundo tiene una teoría distinta sobre qué es «lento» y nadie ha definido qué página, dispositivo o usuario es prioritario.
04Qué perfil según el síntoma
Esta tabla no sustituye a un diagnóstico, pero evita la primera llamada equivocada.
| Síntoma | Perfil que entra primero | Primera comprobación |
|---|---|---|
| El HTML tarda en llegar | Backend / hosting | TTFB y tiempo de consultas |
| Aparece el contenido tarde | Frontend | LCP y recursos que bloquean |
| La página salta al cargar | Frontend / contenido | Dimensiones de imágenes y fuentes |
| Va lenta solo en móvil | Frontend / contenido | Peso real y terceros en móvil |
| Va lenta a ratos | Hosting / backend | Picos, errores y caché |
05Lo que no arregla nadie
Hay límites que conviene decir antes de cobrar por una optimización:
- Un plugin no sustituye un diagnóstico. La caché ayuda, pero no arregla una consulta lenta ni un exceso de JavaScript.
- No existe el «100/100» universal. Lighthouse cambia con el dispositivo, la red y la versión. El objetivo es el usuario real, no la puntuación.
- No se puede optimizar todo a la vez. Cada decisión tiene coste: menos efectos, menos fuentes, menos widgets, más disciplina editorial.
- La velocidad no compensa una web rota. Si el checkout falla, el problema no es el LCP.
Si alguien promete una posición concreta en Google o un tiempo de carga exacto sin medir tu caso, está vendiendo una plantilla, no un diagnóstico.
Si quieres que alguien mida, priorice y ejecute con este criterio, el servicio de optimización de velocidad y WPO parte de una medición y un alcance cerrado. Y si antes necesitas saber qué tienes, la auditoría WordPress documenta el estado y el coste de la siguiente fase.
06Preguntas frecuentes
¿Necesito contratar a los cinco perfiles?
No. La mayoría de proyectos necesitan uno o dos según dónde esté el cuello. La secuencia lógica es medir, identificar el origen y sumar el perfil que corresponda.
¿Un plugin de caché arregla la velocidad?
Puede mejorar el TTFB y aliviar el servidor, pero no reduce el JavaScript que bloquea el navegador ni arregla una consulta lenta. Es una capa, no el diagnóstico.
¿Cuánto tarda una optimización?
Depende del alcance. Un diagnóstico permite separar lo que se arregla en una tarde de lo que exige tocar tema, plugins o infraestructura. Sin medir, cualquier plazo es una promesa vacía.
¿Puedo hacerlo yo?
Algunas cosas sí: imágenes, fuentes y plugins evidentes. Otras requieren tocar producción con backup, staging y rollback. Si no hay red de seguridad, el ahorro puede costar más que la intervención.