Laravel's preload curve: 123 files buy eight times what the last 1,912 do

The opcache measurement left Laravel between two points: no preload file of its own, a cold first request of 76 ms, and a blanket classmap preload that reaches 14 ms while adding 2.3 seconds to php-fpm’s start-up. That record measured the blanket version as a ceiling. This one draws the curve between the two — and shows the ceiling is a bad place to stand.

The curve

Load the interactive chart

Loads ~60 kB of JavaScript for tooltips and cursor readings. The data table below is always open.

Data table

bench/preload-curate.sh, median of three repeats

Series	0	1,592	2,686	2,809	4,721
cold first request	68.37 ms	38.01 ms	28.48 ms	12.77 ms	10.96 ms

The chart is drawn in the browser; the table below carries the same data.

Slice	Compiled	Cold request	fpm ready	Marginal gain	Marginal cost
no preload	0	68.37 ms	382 ms	—	—
laravel/framework	1,592	38.01 ms	1,553 ms	−30.4 ms	+1,171 ms
+ symfony	2,686	28.48 ms	1,538 ms	−9.5 ms	free
+ psr, carbon the sweet spot	2,809	12.77 ms	1,514 ms	−15.7 ms	free
everything	4,721	10.96 ms	2,691 ms	−1.8 ms	+1,177 ms

Not how many, which ones

The curve’s shape is not proportional to volume, and that is the finding.

123 files buy eight times what the last 1,912 do. The psr and carbon slice adds 123 files and takes the cold request from 28.48 ms to 12.77 ms. The 1,912 files after it take only 1.8 ms.

The reason is date handling: Laravel’s first request pulls on Carbon’s loading chain, and that chain is deeply linked — without preloading it gets resolved again on every cold start. A framework being “heavy” is not about how many files it has; it is about which tree the first request walks.

”Compile everything” is the worst choice

The earlier record measured the blanket classmap as an optimistic upper bound. The curve shows it differently: 4,721 files buy 1.8 ms over 2,809 and cost 1,177 ms of start-up. The last slice charges 654 milliseconds of start-up for every millisecond it saves.

For a service deploying ten times a day that is twelve seconds of added start-up in exchange for 1.8 ms for the first visitor. Even on steady traffic the trade is weak.

It does not catch Symfony

Symfony reaches 2.50 ms with its own official file. Laravel’s best point here is 10.96 ms — four times behind, and that is with everything preloaded.

The difference is structural. Symfony’s preload file is generated from its compiled container, so resolving the service definitions has already happened at build time. Laravel’s container resolves at runtime, and preload does not remove that work — it only removes class compilation. Preload saves you from compiling PHP source; it does not save you from the application’s own set-up.

The file Laravel does not ship

What this leaves is not a number but a file: a preload generated with the filter ^/vendor/(laravel\/framework|symfony|psr|nesbot|carbon)/, giving 12.77 ms at 1.5 seconds of start-up — the thing the framework itself does not publish. The generator is in the repository and runs against any Laravel application.