Post actualizado el día octubre 29, 2026 by DeiviSanzPlay
Recuerdo una tarde de sábado que se suponía tranquila. Estaba migrando un sitio WordPress de pruebas a mi portátil de trabajo, un equipo con 8 GB de RAM y un SSD normalito. Instalé XAMPP, importé una base de datos de unos cientos de MB y, al abrir el frontend, el navegador se quedó pensando varios segundos. Cada recarga tardaba una eternidad. El ventilador rugía. Había empezado a buscar cómo hacer XAMPP optimizar rendimiento local sin entender todavía qué estaba pasando, y el primer impulso —subir el número de procesos de Apache— solo empeoró las cosas. MySQL se comía la memoria y el portátil empezaba a usar swap. El sitio iba peor que antes.
Ese caso me enseñó algo que casi nadie menciona al hablar de rendimiento en entornos locales: el cuello de botella no siempre está donde crees. En mi caso no era Apache ni PHP; era la configuración por defecto de MariaDB dentro de XAMPP, pensada para funcionar en cualquier equipo, no para ir rápido en uno concreto.
Qué mirar antes de tocar archivos de configuración
Antes de abrir my.ini o httpd.conf, conviene medir. Yo perdí una hora moviendo valores a ciegas. Abrir el Administrador de tareas mientras se carga una página pesada dice más que cualquier tutorial genérico. En mi caso vi que MySQL usaba casi toda la RAM disponible y que el disco trabajaba sin parar. Ahí estaba la pista.
Optimizar el rendimiento de XAMPP en local no va de aplicar una lista mágica de parámetros. Va de identificar qué componente está frenando tu flujo de trabajo real: importar bases de datos, ejecutar tests, previsualizar cambios de tema o compilar assets con herramientas externas.
El error que cometí con Apache y los módulos
Mi primer reflejo fue activar más módulos y subir MaxRequestWorkers. Error. En un entorno doméstico con un solo usuario, cargar módulos que no usas —como mod_ldap o mod_proxy si no los necesitas— solo consume recursos. Desactivarlos no fue la solución definitiva a mi problema, pero aligeró el arranque y me dejó ver con más claridad el verdadero culpable.
También descubrí que dejar Apache y MySQL corriendo todo el día mientras hago otras tareas no tiene sentido. Para sesiones cortas de pruebas, arrancar los servicios solo cuando los necesito marca una diferencia que se nota, sobre todo en portátiles modestos.
La configuración de MySQL que cambió el escenario
El ajuste que realmente movió la aguja fue tocar innodb_buffer_pool_size. En una instalación por defecto suele ser pequeño, y para una base de datos de prueba con muchas tablas eso significa leer constantemente del disco. Subirlo sin pasarse de la RAM disponible del equipo hizo que las consultas dejaran de arrastrarse. No prometo cifras concretas porque dependen de cada máquina, pero el cambio fue evidente.
Ojo con el matiz: si tu equipo tiene poca memoria o trabajas con varias aplicaciones abiertas, asignar demasiado a MySQL puede provocar justo el efecto contrario, con el sistema recurriendo al archivo de paginación. Esto no funciona igual en un portátil de 8 GB que en un sobremesa con 32.
OPcache y lo que sí importa en PHP
Activar OPcache en XAMPP es una de esas cosas que casi todo el mundo recomienda y que, en mi caso, aportó una mejora modesta pero real al recargar páginas con mucho código PHP. La clave está en entender que OPcache ayuda a no recompilar scripts en cada petición, pero no arregla consultas mal escritas ni un WordPress con veinte plugins activos.
Hay una limitación que conviene asumir: si tu problema es que el sitio tarda por llamadas externas, por imágenes sin optimizar o por un tema pesado, tocar XAMPP no lo va a resolver. He visto a gente frustrada buscando optimizar el rendimiento local cuando el verdadero problema era un plugin que hacía peticiones a una API lenta en cada carga.
Herramientas y hábitos que marcan diferencia
Algunas cosas que incorporé después de aquel sábado: mantener las bases de datos de prueba lo más pequeñas posible, usar versiones de PHP acordes al proyecto en lugar de la más reciente por inercia, y cerrar XAMPP cuando no lo uso. Ninguna es espectacular por separado, pero juntas cambian la experiencia diaria.
Para diagnosticar, herramientas como el monitor de recursos del sistema y los logs propios de Apache y MySQL dan información más útil que cualquier ajuste copiado de un foro. La documentación oficial de Apache y de MariaDB sigue siendo la referencia cuando dudas sobre qué hace cada parámetro.
Al final, el episodio de aquel sábado terminó con una configuración razonable de MySQL, menos módulos cargados y la costumbre de arrancar servicios solo cuando hacen falta. No fue una transformación radical, pero el sitio dejó de arrastrarse. Y aprendí que buscar cómo optimizar el rendimiento de XAMPP sin medir antes es la forma más rápida de perder una tarde.
Perfiles verificables: Sitio web
Publicado el 29 de October de 2026. Última revisión: 29 de October de 2026.
