How Much Faster Is PHP 8.5? Benchmark Results for Laravel, Symfony & WordPress

Benchmark Overview

PHP 8.5 was officially released on November 21. To assess the performance impact of this new version, we benchmarked three widely used PHP projects—Symfony, Laravel, and WordPress—across PHP 8.2, 8.3, 8.4, and 8.5 (plus PHP 7.4 for WordPress).

Setup

Code and infrastructure: github.com/tideways/php-benchmarks Machine: Hetzner CCX 33 (8 dedicated AMD vCores)

OS: Debian 13 ("Trixie")

Database:

MySQL 8.4.7 for WordPress and Laravel

SQLite 3 for Symfony

PHP builds (from deb.sury.org): 7.4.33, 8.2.29, 8.3.27, 8.4.14, 8.5.0 RC 3 (JIT disabled, FPM static pool with 17 workers)

Projects: Laravel 12.37.0, Symfony 7.3.6, WordPress 6.8.3

Load generator: Vegeta v12.12.0

Load balancer: HAProxy 3.0.11

More methodological details are provided after the results.

Results

Symfony

Upgrading from PHP 8.4 to 8.5 produced virtually identical performance under a fixed load of 100 requests per minute; variations were within the error margin.

With 15 concurrent requests, requests per second remained indistinguishable across PHP versions.

Laravel

Moving from PHP 8.4 to 8.5 did not change the response time of the Laravel demo application.

Requests per second were also comparable.

WordPress

Similarly, upgrading WordPress from PHP 8.4 to 8.5 showed no noticeable change in response time.

Under 15 concurrent users, requests per second were close across versions, with PHP 7.4 lagging about 5%.

Additional Methodology Details

The benchmark results heavily depend on assumptions and settings. We ran tests in two modes:

Fixed requests per second, focusing on response time.

Fixed concurrency level, focusing on requests per second.

We avoided reporting only requests‑per‑second because that metric can be artificially inflated by pushing the application to its capacity limits, which does not reflect real‑world usage. Instead, we measured response time and time‑to‑first‑byte (TTFB) under normal load to gauge impact on actual users.

Tests were not run at extreme concurrency to prevent CPU scheduler contention, ensuring the numbers reflect PHP performance rather than OS scheduling effects.