En un PHP compartido, la página de inicio muestra 180 ms en el lado TTFB. El equipo optimiza las consultas SQL, ahorrando 30 ms. Luego, una auditoría revela que el arranque de Composer por sí solo consume 40 ms por solicitud: cientos de búsquedas de PSR-4, dependencias de desarrollo aún presentes en la producción y una carga automática nunca volcada en modo optimizado después de la última implementación.
Composer es invisible mientras se está ejecutando. Sin embargo, cada solicitud HTTP comienza con vendor/autoload.php, que carga el mapeo del espacio de nombres y resuelve las clases sobre la marcha. En Laravel, Symfony o WordPress moderno, miles de archivos pueden ingresar al gráfico, incluso si la página solo usa diez aproximadamente.
PSR-4, mapa de clases y lo que realmente carga PHP
Composer admite varias estrategias:
- PSR-4: resolución por espacio de nombres → carpeta, flexible, un poco más caro de ejecutar.
- Classmap: clase exhaustiva → lista de archivos, generada por
dump-autoload. - Mapa de clases autorizado (
--classmap-authoritative): Composer nunca recurre a PSR-4: error si falta una clase en el mapa.
| Orden | Efecto | Cuando |
|---|---|---|
componer volcado-autocarga | Regenera la carga automática | Después de cada implementación |
componer volcado-autocarga -o | Mapa de clase optimizado | Producción estándar |
componer dump-autoload -o -a | Modo autoritario | Producción estable, sin clases dinámicas |
instalación del compositor --no-dev | Eliminar dependencias de desarrollo | Todavía en producción |
Optimizar la carga automática significa reducir la cantidad de estadísticas del sistema de archivos() incluso antes de que se ejecute el controlador.
Dependencias de desarrollo, archivos de carga automática y ruido innecesario
Un error clásico: implementar con un proveedor/ completo que incluye PHPUnit, accesorios y herramientas de CI. El disco no solo se hace más grande: la carga automática indexa más espacios de nombres.
La sección "autoload": { "files": [...] } es peor: estos archivos son requeridos en cada solicitud. Resérvelo para polyfills o ayudantes verdaderamente globales. Prefiere inyección de servicios o importaciones explícitas.
En alojamiento compartido sin acceso SSH, una canalización de CI que ejecuta composer install --no-dev -o antes de rsync evita dejar al proveedor desarrollador local en producción.
Opcache, APCu e invalidación durante la implementación
OPcache almacena en caché el código de bytes PHP: esencial, pero independiente de la carga automática. APCu puede ocultar el mapa de clases de Composer en la memoria compartida entre trabajadores PHP-FPM.
Error común: implementar sin reiniciar PHP-FPM → los trabajadores aún sirven el mapa de clases antiguo o una combinación inconsistente. Integre php-fpm reload o toque controlado después de la sincronización del proveedor.
También verifique opcache.validate_timestamps=0 en prod (con redistribución propia) para evitar stat() repetido en miles de archivos, dependiendo de su política de lanzamiento.
Carga automática y frameworks: Laravel, Symfony, WordPress
Laravel carga mucho a través de proveedores de servicios: Autoload Composer sigue siendo el primer enlace. Symfony 6+ con flex genera una carga automática eficiente, pero los paquetes de terceros inflan rápidamente al proveedor.
WordPress con componentes Bedrock o Composer hereda el mismo problema: los complementos que envían su propio proveedor anidado a veces duplican paquetes (componentes Guzzle, Symfony): carga automática más pesada y riesgo de conflictos de versiones.
Auditoría rápida: composer du (duplicado) y composerWhy para detectar paquetes redundantes que se pueden eliminar.
Medir antes de microoptimizar
Perfile una consulta representativa (página de cesta, panel de administración). Si la carga automática > 5–10 % del tiempo de solicitud de la CPU, el volcado optimizado merece la canalización. De lo contrario, ataque SQL, caché HTTP y sesiones primero.
En CLI (cola de trabajadores) de larga duración, la carga automática solo se paga una vez en el arranque; el problema es principalmente PHP-FPM y los sitios de solicitud/respuesta.
La cumbre: el proveedor copió de la computadora portátil de desarrollo
Mientras el proceso de implementación no garantice install --no-dev -o y una recarga de PHP-FPM, la optimización del código de la aplicación sigue siendo cosmética en términos de latencia general.
Decide y avanza sin puntos ciegos
Agregue a la canalización composer install --no-dev --prefer-dist -o -a si es compatible, una recarga de PHP-FPM y una auditoría de las entradas de archivos de carga automática. Mida una consulta representativa antes y después de la optimización.
Para elegir un hosting PHP con OPcache y APCu correctamente configurados, navegue por el directorio y la comparación. Las guías detallan el marco de rendimiento de PHP.
Preguntas frecuentes
¿Qué hace el compositor dump-autoload -o?
Genera un mapa de clases optimizado para resolver clases sin atravesar PSR-4 en cada búsqueda, que se ejecutará en producción después de cada implementación.
¿Deberíamos usar APCu para la carga automática?
Útil bajo PHP-FPM concurrente; invalidar el caché en la implementación mediante la recarga de FPM.
¿Por qué evitar la carga automática de archivos no clasificados?
La sección "archivos" se incluye con cada consulta; manténgala al mínimo.
¿Cómo medir el impacto antes de optimizar?
La solicitud de perfil (Blackfire, Xdebug) o el tiempo requieren autoload.php; comparar antes/después del volcado optimizado.
Antes de comprar un plan superior, verifique una cosa: ¿su proveedor de producción es tan eficiente como su código?