Tu sitio de clínica en WordPress está lento: ¿optimizar o reconstruir?
28 de septiembre, 2026 · 4 min de lectura
Muchas clínicas de la ciudad tienen un sitio en WordPress que alguien hizo hace unos años. Funcionaba bien al principio. Hoy tarda, el panel se congela cuando quieres cambiar algo y nadie sabe bien por qué.
La pregunta que siempre llega es la misma: ¿se puede arreglar o hay que hacerlo de nuevo? La respuesta depende de dónde viene la lentitud. Aquí va un caso real, con sus números, para que veas cómo se decide.
El caso: 21.5 segundos
CIPAG Clinic llegó con un sitio que tardaba 21.5 segundos en mostrar su contenido principal. Google pide menos de 2.5. En la práctica, el paciente se iba antes de ver la primera pantalla.
El panel de administración era otro problema. Cada vez que la clínica entraba a cambiar algo, esperaba cerca de veinte segundos. Llevaban meses así, pensando que su computadora era la lenta.
De dónde venía la lentitud
Tres cosas, y conviene separarlas porque cada una tiene un arreglo distinto.
La primera: no había caché. Cada visita obligaba al servidor a armar la página desde cero. Eso se arregla rápido y sin tocar el diseño.
La segunda: un plugin roto. Uno de los más de veinte que tenía el sitio le hablaba a un servidor externo que ya no existía, y el panel se quedaba esperando esa respuesta en cada carga. Eso también se arregla, una vez que lo encuentras.
La tercera es la que decide todo: la página pesaba 3.10 MB, y 2.10 MB de eso era JavaScript. Ese código lo generaban el tema y dos constructores de páginas trabajando al mismo tiempo. Se puede retrasar para que no estorbe a lo primero que se ve. Lo que no se puede es quitarlo sin rehacer las páginas.
Lo que se logró optimizando
Caché de página, compresión, almacenamiento en el navegador, código minificado, scripts externos cargando después y los plugins rotos corregidos. Sin cambiar una sola página de lugar.
El resultado: el sitio pasó a mostrar su contenido en 1.8 segundos, y el panel pasó de veinte segundos de espera a abrir de inmediato. Para un sitio que la clínica ya tenía, es la diferencia entre perder al paciente y enseñarle quién eres.
Dónde estaba el techo
La optimización tiene un límite, y es honesto decirlo en el reporte. Los 2.10 MB de JavaScript seguían ahí, solo que cargando después. Y con más de veinte plugins activos, el tipo de falla que congeló el panel iba a volver a pasar: basta con que otro servicio externo se caiga.
El reporte le dijo eso a la clínica. Que el arreglo servía y que la solución de fondo era reconstruir. Por eso encargaron la reconstrucción completa.
Cómo saber cuál es tu caso
Optimizar tiene sentido si el sitio está bien hecho en su base y lo que falla es configuración: falta de caché, imágenes enormes, un plugin que sobra. Son arreglos de días, y el sitio queda igual por fuera.
Reconstruir tiene sentido si la lentitud viene de cómo se construyó: un tema pesado, dos o tres constructores de páginas encimados, veinte plugins que nadie se atreve a quitar. Ahí cada arreglo es un parche sobre algo que va a seguir fallando.
Una señal práctica: si tu sitio tiene más plugins de los que puedes nombrar y un constructor visual para armar cada página, lo más probable es que estés en el segundo caso.
La otra señal es el costo de mantenerlo. Si cada año pagas por arreglar algo que se rompió solo, la reconstrucción se paga en poco tiempo.
Antes de decidir, mide
No decidas por intuición ni por lo que te diga quien te quiere vender algo. Mide tu sitio en un teléfono, con la herramienta gratuita de Google, y sobre tu dominio real. Hay una forma de medir sin engañarte y vale la pena leerla antes.
Si quieres que alguien lo revise y te diga honestamente si se rescata, eso es un rediseño. A veces la respuesta es optimizar y listo, y está bien que así sea.