Cómo optimizar Local WP en Windows para que cargue más rápido

Para clonar una web en local Local WP está muy bien. El problema es que, en ocasiones empieza a ir lento, incluso desde el primer momento y con equipos potentes.

Y claro, cuando va lento, desespera bastante. Porque se supone que, además de por seguridad, estás trabajando en local para ir más rápido, no para esperar tres segundos cada vez que abres una página del admin.

En el proyecto con mi nueva web me pasaba, pero no quería cambiar de herramienta. No quería montar Docker, ni tirar el entorno, ni empezar de cero. Quería que Local WP volviera fuera (muy) usable.

Después de probar varias cosas, estos son los cinco pasos que me funcionaron de verdad.

Hay varias opciones de optimización más, pero yo me ceñí a estás y ahora mi local va como un tiro.

1. Confirmar que Xdebug estaba desactivado

Lo primero fue revisar Xdebug.

Xdebug sirve para depurar PHP. Si vas a poner breakpoints, inspeccionar variables y hacer debugging serio, perfecto. Para eso está.

Pero si no lo estás usando, puede ralentizar bastante el entorno.

En Local WP se revisa desde la ficha del sitio:

Local WP > tu sitio > pestaña Overview / Tools > Xdebug

En mi caso ya estaba desactivado, así que no tuve que tocar nada. Pero por experiencia era el primer sospechoso que había que descartar.

La regla es simple: si no estás depurando PHP activamente, Xdebug desactivado.

Aquí no fue “la solución” en mi caso, porque ya estaba apagado, pero no cuesta nada comprobarlo antes de volverse loco con otras cosas.

2. Cambiar el dominio de .local a .test

Este cambio sí se notó.

Tenía el sitio con un dominio terminado en .local (yg.local) y lo cambié a yg.test.

En Local WP se hace así:

1. Abres Local WP.
2. Seleccionas el sitio.
3. Vas a la pestaña Overview.
4. Buscas el campo Site domain.
5. Pulsas Change.
6. Cambias el dominio de .local a .test.
7. Confirmas el cambio.
8. Reinicias el sitio.

Después, entras con la nueva URL:

https://yg.test

O, si no tienes SSL activo en Local:

http://yg.test

¿Por qué funciona? 

Porque .local puede dar guerra en algunos entornos por cómo se resuelve a nivel de red. .test está mucho más pensado para desarrollo local y evita parte de esa fricción absurda.

Es un cambio sencillo que en mi caso ayudó.

3. Excluir las carpetas de Local WP en el antivirus de Windows

Otro ajuste importante.

Si trabajas con Windows, Windows Defender puede estar revisando constantemente los archivos de WordPress, plugins, temas, uploads, base de datos, logs, cachés y servicios internos de Local.

Y claro, WordPress en local mueve muchísimos archivos pequeños. Si el antivirus se pone a inspeccionar cada cosa que toca PHP, MySQL o nginx, el rendimiento se resiente.

Por supuesto no desactivé el antivirus sino que lo que hice fue añadir exclusiones.

En Windows:

1. Abre Seguridad de Windows.
2. Entra en Protección contra virus y amenazas.
3. Baja hasta Configuración de antivirus y protección contra amenazas.
4. Pulsa Administrar configuración.
5. Baja hasta Exclusiones.
6. Pulsa Agregar o quitar exclusiones.
7. Añade exclusiones de tipo Carpeta.

La carpeta importante es la de los sitios locales:

C:\Users\TU_USUARIO\Local Sites

Y también las carpetas internas de Local, que suelen estar en rutas como:

C:\Users\TU_USUARIO\AppData\Local\Programs\Local

Y:

C:\Users\TU_USUARIO\AppData\Roaming\Local

En mi caso, excluir Local Sites fue especialmente importante, porque ahí está realmente la web: WordPress, plugins, temas, uploads y todo lo que Local está tocando constantemente.

Después de añadir las exclusiones, conviene parar y arrancar de nuevo el sitio desde Local WP.

4. Desactivar plugins que no necesitaba en local

El siguiente paso fue bastante obvio, pero a veces se nos olvida o preferimos no hacerlo por simular mejor el entorno de producción.

Hay plugins que hacen llamadas externas, tareas programadas, comprobaciones de seguridad, backups, logs, cachés, análisis SEO, integraciones con newsletters, monitorización, optimización de imágenes y mil cosas más.

Todo eso en local puede sobrar, según lo que estés probando.

Así que revisé la lista de plugins y desactivé los que no necesitaba para trabajar en ese momento.

La pregunta era esta: 

¿Necesito este plugin activo para lo que estoy haciendo ahora?

Si la respuesta era no, lo desactivaba.

En mi caso:

1. Plugins de backup.
2. Plugins de Genesis.
3. Plugins de seguridad.
4. Plugins de caché.
5. Plugins de analítica.
6. Plugins que lanzan tareas programadas

Menos plugins activos significa menos carga, menos procesos de fondo y menos cosas compitiendo por recursos.

De todas formas, no observé una gran mejora aquí, por lo que quizás convendría dejar este paso para el final, si con todo lo demás no es suficiente.

5. Limpiar la base de datos desde la shell de Local

El último paso fue limpiar la base de datos.

WordPress acumula basura con mucha facilidad: revisiones, borradores automáticos, transients caducados, comentarios en papelera, spam, metadatos huérfanos y restos de plugins.

Para hacerlo, abrí la shell del sitio desde Local WP:

Local WP > tu sitio > Open Site Shell

Antes de limpiar, hice copia de seguridad de la base de datos:

wp db export backup-before-cleanup.sql

Luego ejecuté este bloque de limpieza:

wp post delete $(wp post list --post_type='revision' --format=ids) --force
wp post delete $(wp post list --post_status='auto-draft' --format=ids) --force

wp post delete $(wp post list --post_status='trash' --format=ids) --force

wp comment delete $(wp comment list --status=spam --format=ids) --force

wp comment delete $(wp comment list --status=trash --format=ids) --force

wp transient delete --expired

wp db query "DELETE pm FROM wp_postmeta pm LEFT JOIN wp_posts p ON p.ID = pm.post_id WHERE p.ID IS NULL;"

wp db query "DELETE cm FROM wp_commentmeta cm LEFT JOIN wp_comments c ON c.comment_ID = cm.comment_id WHERE c.comment_ID IS NULL;"

wp db query "DELETE tm FROM wp_termmeta tm LEFT JOIN wp_terms t ON t.term_id = tm.term_id WHERE t.term_id IS NULL;"

wp db query "DELETE um FROM wp_usermeta um LEFT JOIN wp_users u ON u.ID = um.user_id WHERE u.ID IS NULL;"

wp db optimize

Ojo con una cosa: esto asume que el prefijo de las tablas es wp_.

Si estás en Windows y esa sintaxis de variable no te funciona, usa directamente el prefijo que te devuelva:

wp db prefix

y sustitúyelo a mano.

Este paso no es para hacerlo alegremente en producción. En local, con backup previo, sí.

Resultado

Después de estos cinco pasos, Local WP empezó a ir bastante mejor. Lógico, porque mi Ryzen 7 2700 Pro con NMVE y 24GB es considerablemente más potente que el servidor de producción.

Por eso tenía claro que merecía la pena dedicar un ratito.

Ahora va como debe y me he ahorrado muchos ratitos.

El resumen sería:

1. Comprobar que Xdebug está desactivado.
2. Cambiar el dominio de .local a .test.
3. Excluir carpetas de Local WP en Windows Defender.
4. Desactivar plugins innecesarios en local.
5. Limpiar la base de datos desde la shell.

Básicamente quitarle lastre al entorno.

En este caso Local WP no va lento por una sola causa, sino por la suma de pequeñas cosas: resolución del dominio, antivirus mirando cada archivo, plugins que sobran y una base de datos llena de restos.

No medí cada una con cronómetro, pero sí con sensaciones. Por eso sé lo que me funcionó.

Ahora tengo mi copia local que va como un tiro, así que me he quedado sin excusas para trabajar en producción y no probar.

Y tú, ¿sigues usando la misma excusa?