{"id":2750,"date":"2026-09-23T09:24:52","date_gmt":"2026-09-23T13:24:52","guid":{"rendered":"https:\/\/www.neothek.com\/soporte\/?post_type=kb&p=2750"},"modified":"2026-09-23T11:23:04","modified_gmt":"2026-09-23T15:23:04","slug":"que-revisamos-cuando-un-wordpress-se-vuelve-lento","status":"publish","type":"kb","link":"https:\/\/www.neothek.com\/soporte\/articulo\/que-revisamos-cuando-un-wordpress-se-vuelve-lento\/","title":{"rendered":"Qu\u00e9 revisamos cuando un WordPress se vuelve lento"},"content":{"rendered":"
<\/p>\n
\u00bfQu\u00e9 revisamos cuando un sitio WordPress se vuelve lento?<\/h1>\n
Cuando recibimos un sitio WordPress lento, no asumimos autom\u00e1ticamente que el problema sea el servidor. Tampoco comenzamos instalando plugins de optimizaci\u00f3n.<\/p>\n
Primero intentamos reproducir la lentitud, medimos d\u00f3nde se concentra el tiempo y relacionamos el s\u00edntoma con los recursos, el c\u00f3digo y la actividad del sitio. Solo despu\u00e9s proponemos cambios.<\/p>\n
Este es el proceso que utilizamos como referencia para distinguir una limitaci\u00f3n de hosting de un problema interno de WordPress.<\/p>\n
1. Definimos el s\u00edntoma con precisi\u00f3n<\/h2>\n
Antes de medir, necesitamos saber qu\u00e9 significa \u201clento\u201d en ese caso:<\/p>\n
\n
\u00bfTarda la primera respuesta o la carga visual completa?<\/li>\n
\u00bfOcurre en todo el sitio o en p\u00e1ginas espec\u00edficas?<\/li>\n
\u00bfAfecta tambi\u00e9n al administrador?<\/li>\n
\u00bfSucede siempre o solo en ciertos horarios?<\/li>\n
\u00bfApareci\u00f3 despu\u00e9s de un cambio?<\/li>\n
\u00bfEl problema depende de la ubicaci\u00f3n o del usuario?<\/li>\n<\/ul>\n
Esta informaci\u00f3n evita confundir una imagen pesada con un proceso PHP lento, o un servicio externo demorado con falta de CPU.<\/p>\n
2. Tomamos una medici\u00f3n inicial<\/h2>\n
Registramos un punto de partida antes de modificar. Observamos el tiempo de respuesta del servidor, la carga total, el peso de la p\u00e1gina, el n\u00famero de solicitudes y los recursos que m\u00e1s tardan.<\/p>\n
Medimos varias p\u00e1ginas porque la portada puede estar en cach\u00e9 mientras una b\u00fasqueda, ficha de producto o pantalla administrativa presenta el verdadero problema.<\/p>\n
La medici\u00f3n inicial permite comprobar despu\u00e9s si el cambio produjo una mejora real o solo una impresi\u00f3n temporal.<\/p>\n
3. Relacionamos la hora con recursos y registros<\/h2>\n
Revisamos CPU, memoria, procesos, almacenamiento y actividad de entrada\/salida durante el periodo afectado. Tambi\u00e9n buscamos errores, tareas programadas, backups, bots o picos de tr\u00e1fico.<\/p>\n
No consideramos que un plan sea insuficiente por un pico aislado. Buscamos patrones:<\/p>\n
\n
Consumo alto durante actividad normal.<\/li>\n
L\u00edmites alcanzados repetidamente.<\/li>\n
Procesos que coinciden con la lentitud.<\/li>\n
Demoras incluso cuando el servidor tiene recursos libres.<\/li>\n<\/ul>\n
4. Separamos frontend y generaci\u00f3n del servidor<\/h2>\n
Si la respuesta inicial es r\u00e1pida pero la p\u00e1gina termina de cargar tarde, revisamos im\u00e1genes, fuentes, JavaScript, CSS, videos, mapas, chats y servicios externos.<\/p>\n
Si la primera respuesta ya es lenta, concentramos la revisi\u00f3n en PHP, WordPress, base de datos, plugins, tema y recursos.<\/p>\n
Esta separaci\u00f3n es importante porque ampliar CPU no corrige una fotograf\u00eda de varios megabytes, y comprimir im\u00e1genes no resuelve una consulta lenta.<\/p>\n
5. Revisamos cambios recientes<\/h2>\n
Actualizaciones, nuevos plugins, cambios de tema, importaciones y modificaciones de PHP ofrecen pistas concretas. Comparamos el inicio del problema con el historial de cambios.<\/p>\n
Si existe una relaci\u00f3n clara, reproducimos el escenario en staging y aislamos el componente. Evitamos desactivar elementos al azar en producci\u00f3n, especialmente en tiendas o sitios con formularios.<\/p>\n
6. Analizamos plugins y tema<\/h2>\n
No contamos plugins para declarar que hay demasiados. Revisamos qu\u00e9 ejecutan, qu\u00e9 consultas realizan, qu\u00e9 tareas programan y si llaman servicios externos.<\/p>\n
Prestamos atenci\u00f3n a:<\/p>\n
\n
Plugins activos en cada solicitud.<\/li>\n
Procesos de estad\u00edsticas, sincronizaci\u00f3n o seguridad.<\/li>\n
Constructores y extensiones con carga duplicada.<\/li>\n
Funciones del tema que consultan datos repetidamente.<\/li>\n
Componentes abandonados o incompatibles.<\/li>\n<\/ul>\n
7. Revisamos PHP y tareas programadas<\/h2>\n
Comprobamos la versi\u00f3n y configuraci\u00f3n de PHP, memoria efectiva, procesos y tiempos de ejecuci\u00f3n. Tambi\u00e9n revisamos tareas programadas que puedan acumularse o ejecutarse durante las visitas.<\/p>\n
Aumentar un l\u00edmite puede ser v\u00e1lido si el proceso lo necesita, pero no lo usamos para ocultar un consumo anormal. Primero identificamos qu\u00e9 utiliza los recursos.<\/p>\n
8. Inspeccionamos la base de datos<\/h2>\n
Buscamos consultas lentas, tablas con actividad inusual, opciones cargadas autom\u00e1ticamente y datos acumulados por plugins.<\/p>\n
Una base grande no es necesariamente lenta. Nos interesa c\u00f3mo se consulta y qu\u00e9 parte del tiempo total concentra. Cualquier limpieza se realiza despu\u00e9s de una copia y conociendo qu\u00e9 componente utiliza esos datos.<\/p>\n
9. Verificamos la cach\u00e9<\/h2>\n
Comprobamos si la cach\u00e9 de p\u00e1gina funciona, si existen exclusiones correctas y si varias herramientas est\u00e1n duplicando funciones. En sitios din\u00e1micos revisamos carrito, cuenta, pago y contenido personalizado.<\/p>\n
Cuando existe cach\u00e9 de objetos, validamos que ayude a las consultas repetidas y que no est\u00e9 introduciendo datos obsoletos. Tambi\u00e9n revisamos navegador y CDN.<\/p>\n
10. Analizamos im\u00e1genes y recursos externos<\/h2>\n
Revisamos dimensiones, compresi\u00f3n, formatos, carga diferida y tama\u00f1os adaptados a cada pantalla. Despu\u00e9s identificamos scripts externos que bloquean o retrasan la carga.<\/p>\n
Publicidad, anal\u00edtica, chat, mapas y fuentes pueden afectar la percepci\u00f3n de velocidad aunque el servidor responda correctamente.<\/p>\n
11. Aplicamos un cambio cada vez<\/h2>\n
Un diagn\u00f3stico pierde valor si se activan cach\u00e9, CDN, compresi\u00f3n, nuevos recursos y varios plugins simult\u00e1neamente. No ser\u00eda posible saber qu\u00e9 cambio ayud\u00f3 o cu\u00e1l cre\u00f3 un efecto secundario.<\/p>\n
Priorizamos el cuello de botella con mayor impacto, aplicamos un cambio, vaciamos las capas necesarias y repetimos la medici\u00f3n inicial.<\/p>\n\nEl diagn\u00f3stico recorre todas las capas y valida cada mejora con la misma medici\u00f3n inicial.<\/figcaption><\/figure>\n
12. Comprobamos funciones, no solo puntuaciones<\/h2>\n
Una optimizaci\u00f3n no est\u00e1 terminada cuando una herramienta muestra una puntuaci\u00f3n mayor. Comprobamos que formularios, sesiones, b\u00fasqueda, carrito, pago y administrador sigan funcionando.<\/p>\n
Tambi\u00e9n revisamos usuarios sin sesi\u00f3n, usuarios autenticados y, cuando corresponde, distintas ubicaciones y dispositivos.<\/p>\n
Cu\u00e1ndo concluimos que el hosting es la limitaci\u00f3n<\/h2>\n
Consideramos un cambio de recursos cuando las mediciones muestran l\u00edmites sostenidos bajo una carga normal y no existe un proceso an\u00f3malo que explique el consumo.<\/p>\n
Tambi\u00e9n valoramos el entorno cuando utiliza versiones obsoletas, no ofrece visibilidad de recursos, carece de una cach\u00e9 adecuada o no permite investigar registros.<\/p>\n
![\"Proceso](\"https:\/\/www.neothek.com\/soporte\/wp-content\/uploads\/2026\/09\/diagnostico-wordpress-lento-proceso.webp\")