On shared PHP hosting, the homepage shows 180 ms TTFB. The team optimizes SQL — 30 ms saved. Then an audit shows Composer bootstrap alone eats 40 ms per request: hundreds of PSR-4 lookups, dev dependencies still in prod, and autoload never dumped optimized after the last deploy.
Composer is invisible until it isn't. Yet every HTTP request starts with vendor/autoload.php, loading namespace maps and resolving classes on the fly. On Laravel, Symfony, or modern WordPress, thousands of files may enter the graph — even if the page uses only a dozen.
PSR-4, classmap, and what PHP actually loads
Composer supports several strategies:
- PSR-4: namespace → folder resolution, flexible, slightly costlier at runtime.
- Classmap: exhaustive class → file list from
dump-autoload. - Authoritative classmap (
--classmap-authoritative): Composer never falls back to PSR-4 — error if class missing from map.
| Command | Effect | When |
|---|---|---|
composer dump-autoload | Regenerates autoload | After every deploy |
composer dump-autoload -o | Optimized classmap | Standard production |
composer dump-autoload -o -a | Authoritative mode | Stable prod, no dynamic classes |
composer install --no-dev | Removes dev dependencies | Always in prod |
Optimizing autoload means fewer filesystem stat() calls before your controller even runs.
Dev dependencies, autoload files, and useless noise
Classic mistake: deploying full vendor/ including PHPUnit, fixtures, and CI tools. Disk grows — and autoload indexes more namespaces.
The "autoload": { "files": [...] } section is worse: those files are required every request. Reserve it for truly global polyfills or helpers. Prefer service injection or explicit imports.
On shared hosting without SSH, a CI pipeline running composer install --no-dev -o before rsync avoids shipping a developer vendor tree.
Opcache, APCu, and invalidation on deploy
OPcache caches PHP bytecode — essential, but separate from autoload. APCu can cache the Composer classmap in PHP-FPM shared memory.
Common trap: deploy without PHP-FPM restart → workers serve stale classmap or inconsistent mix. Add php-fpm reload after vendor sync.
Also check opcache.validate_timestamps=0 in prod (with clean redeploy) to avoid repeated stat() on thousands of files — per your release policy.
Autoload and frameworks: Laravel, Symfony, WordPress
Laravel loads heavily via service providers — Composer autoload remains the first link. Symfony 6+ with flex stays lean, but third-party bundles quickly inflate vendor.
WordPress with Bedrock or Composer components faces the same issue: plugins shipping nested vendor sometimes duplicate packages (Guzzle, Symfony components) — heavier autoload and version conflict risk.
Quick audit: composer du (duplicate) and composer why to spot removable redundancy.
On shared hosting where you cannot restart PHP-FPM yourself, ask support whether deploy triggers a pool reload. Some hosts cache opcode aggressively but leave autoload stale for minutes after rsync — symptoms look like random 500 errors on new classes until the next scheduled restart.
Measure before micro-optimizing
Profile a representative request (cart page, admin dashboard). If autoload > 5–10% of request CPU time, optimized dump belongs in the pipeline. Otherwise tackle SQL, HTTP cache, and sessions first.
A simple CLI check helps before investing in profiling tools: time php -r "require 'vendor/autoload.php';" on the production server. Repeat after composer dump-autoload -o. A gap above twenty milliseconds multiplied by your daily request count is often enough to justify pipeline changes.
In long-running CLI (queue workers), autoload is paid once at boot — the main concern is PHP-FPM request/response sites.
The peak: vendor copied from the dev laptop
Until deploy guarantees install --no-dev -o and PHP-FPM reload, application tuning is cosmetic on global latency.
Decide and move forward without blind spots
Add to your pipeline composer install --no-dev --prefer-dist -o -a if compatible, a PHP-FPM reload, and an audit of autoload files entries. Measure one representative request before and after optimization.
To pick PHP hosting with OPcache and APCu configured correctly, browse our directory and comparator. The guides cover PHP performance framing.
Frequently asked questions
What does composer dump-autoload -o do?
It builds an optimized classmap so classes resolve without walking PSR-4 each lookup — run in production after every deploy.
Should I use APCu for autoload?
Useful under concurrent PHP-FPM; invalidate on deploy via FPM reload.
Why avoid autoloading non-class files?
The "files" section is included on every request — keep it minimal.
How do I measure impact before optimizing?
Profile a request (Blackfire, Xdebug) or time require autoload.php; compare before/after optimized dump.
Before upgrading your plan, check one thing: is production vendor as lean as your application code?