PHP vs Node.js (2026): I Benchmarked Both — Here's What Surprised Me

There is a conversation that has been going on in backend development circles for over a decade now, and it refuses to die. PHP or Node.js? Which one should you use? Which one is faster? Which one has a future?

I spent the last several weeks setting up identical environments, running real benchmarks, building small but representative applications in both, and reading through a significant amount of documentation, community data, and developer surveys. I went in with assumptions. Most of them were wrong.

This is not a fan piece. I have no allegiance to either camp. This is what I actually found.

#Table of Contents

1. Why These Two?
2. The Origin Stories
3. The State of Both in 2026
4. Benchmark Setup
5. Benchmark Results
6. Code Comparison
7. What Real Developers Say
8. Pros and Cons
9. Use Case Guide
10. What the Numbers Actually Mean
11. References
12. The Verdict

#Why These Two?

PHP and Node.js do not look like obvious competitors on paper. PHP is a language with its own runtime. Node.js is a JavaScript runtime. But in practice, both are used to build web backends, APIs, and server-rendered applications — which is why they end up in the same conversation constantly.

They were built for different eras of the web, by different people, with different philosophies. Understanding that context changes how you read the benchmarks.

#The Origin Stories

#PHP — Built to Solve a Real Problem in 1994

Rasmus Lerdorf did not set out to create a programming language. He wrote a set of Common Gateway Interface (CGI) binaries in C to track visits to his online resume. He called it "Personal Home Page Tools." That is the PHP in PHP.

The language grew organically. It was extended, contributed to, and eventually became one of the most deployed server-side languages in the world — not because it won some technical competition, but because it was available, easy to learn, and did the job at a time when the web was exploding and developers needed something that worked.

Its model was simple: a user makes a request, PHP executes a script, the script talks to a database, a response is sent back. New request, new execution. Stateless, predictable, widely understood.

The criticism came later. Function naming was not standardized. Error handling varied. The global state model caused problems at scale. The reputation suffered.

But PHP did not sit still. PHP 7 nearly doubled speed compared to PHP 5. PHP 8.0 introduced JIT compilation. PHP 8.3 and 8.4 continued tightening the language significantly. In 2026, PHP is a substantially different language from what most of its critics remember.

#Node.js — Built to Fix What Ryan Dahl Thought Was Broken

Ryan Dahl introduced Node.js at JSConf EU in 2009 with a presentation that started by criticizing the way Apache handled concurrent connections. His argument was direct: traditional servers spawn a new thread per connection, threads are expensive, and blocking I/O makes the problem worse.

Node.js was built on Google's V8 engine and a non-blocking, event-driven I/O model. Instead of waiting for a database query to return before doing anything else, Node.js could register a callback and move on — handling thousands of concurrent connections on a single thread without the overhead of thread management.

It landed at exactly the right moment. JavaScript was already everywhere on the front end. Developers could suddenly use the same language on both sides of the stack. The npm ecosystem exploded. Real-time applications — chat apps, live dashboards, collaborative tools — became dramatically easier to build.

Node.js was not trying to replace PHP. It was solving a different problem: high-concurrency, real-time, I/O-heavy workloads. The fact that it could also serve web pages and APIs just meant it ended up in the same comparison over and over again.

#The State of Both in 2026

#PHP Today

#Node.js Today

#Benchmark Setup

I ran all tests on the same machine with the same network conditions. Everything was containerized via Docker to eliminate environment differences.

#Hardware

OS:       Ubuntu 22.04 LTS
CPU:      4 vCPUs
RAM:      8 GB
Storage:  SSD
Network:  Loopback (localhost)

#Load Testing Tools

Primary:    wrk -t4 -c400 -d30s
Secondary:  ab -n 10000 -c 200

Each test was run five times. The highest and lowest results were discarded. The three middle results were averaged.

#Stacks Tested

#Test Scenarios

#Benchmark Results

#Test 1 — Hello World (Pure Throughput)

wrk -t4 -c400 -d30s http://localhost/hello

Node.js was significantly faster in its standard configuration. PHP-FPM spawns worker processes with initialization overhead per request. Node.js runs as a persistent process.

What actually surprised me: switching PHP to FrankenPHP worker mode — where the PHP process stays alive between requests — closed the gap considerably. Not equal, but not the landslide most articles suggest.

#Test 2 — JSON Serialization

Node.js wins. JavaScript's JSON handling is native to V8. PHP's json_encode() is fast, but the per-request process startup adds up.

#Test 3 — Database Read (50 rows, PostgreSQL)

Node.js is faster, but the gap narrows dramatically. The database is the bottleneck. Both stacks spend most of their time waiting on PostgreSQL, not executing application code. This test is far more representative of real web applications than the Hello World test.

#Test 4 — Database Write (INSERT + RETURNING)

Same pattern as Test 3. Node.js ahead, but both are constrained by I/O, not the language runtime.

#Test 5 — CPU-Intensive Task (Fibonacci 35)

This is the one that will change how you think about Node.js.

PHP won — and it was not close.

This reveals the most important architectural truth about Node.js: it has a single-threaded event loop. When one request is doing heavy CPU work, every other request waits. PHP-FPM spawns multiple worker processes. A CPU-heavy request in one worker does not block any of the others.

Node.js has worker threads to address this — but you have to deliberately opt into them. Out of the box, a CPU-bound task will destroy your latency across the board.

#Summary — All Tests

#Code Comparison

The same feature implemented in both stacks, side by side.

#REST API Endpoint with Database Query and Cache

PHP 8.4 with Laravel

<?php

use App\Models\Article;
use Illuminate\Support\Facades\Cache;

Route::get('/articles/{id}', function (int $id) {
    \(article = Cache::remember("article:{\)id}", 300, function () use ($id) {
        return Article::with('author', 'tags')
            ->findOrFail($id);
    });

    return response()->json([
        'data'   => $article,
        'cached' => Cache::has("article:{$id}"),
    ]);
});

Node.js with Fastify + TypeScript

import { FastifyInstance } from 'fastify';
import { pool } from '../db';
import { redis } from '../cache';

export async function articleRoutes(fastify: FastifyInstance) {
  fastify.get<{ Params: { id: string } }>('/articles/:id', async (request, reply) => {
    const { id } = request.params;
    const cacheKey = `article:${id}`;

    const cached = await redis.get(cacheKey);
    if (cached) {
      return reply.send({ data: JSON.parse(cached), cached: true });
    }

    const result = await pool.query(
      `SELECT a.*, u.name AS author_name
       FROM articles a
       JOIN users u ON a.author_id = u.id
       WHERE a.id = $1`,
      [id]
    );

    if (!result.rows[0]) {
      return reply.status(404).send({ error: 'Not found' });
    }

    await redis.setex(cacheKey, 300, JSON.stringify(result.rows[0]));
    return reply.send({ data: result.rows[0], cached: false });
  });
}

The PHP version is more concise because Laravel's Eloquent ORM absorbs the boilerplate. The Node.js version is more explicit — you see exactly what queries run and what hits the cache. Both are valid depending on your team's preferences.

#Handling Concurrent Async Operations

PHP 8.4 — Guzzle with concurrent pooled requests

<?php

use GuzzleHttp\Client;
use GuzzleHttp\Pool;
use GuzzleHttp\Psr7\Request;

$client = new Client();

$requests = function () {
    yield new Request('GET', 'https://api.example.com/users');
    yield new Request('GET', 'https://api.example.com/products');
    yield new Request('GET', 'https://api.example.com/orders');
};

\(pool = new Pool(\)client, $requests(), [
    'concurrency' => 3,
    'fulfilled'   => function (\(response, \)index) {
        // handle each response
    },
]);

$pool->promise()->wait();

Node.js — native async/await with Promise.all

const [users, products, orders] = await Promise.all([
  fetch('https://api.example.com/users').then(r => r.json()),
  fetch('https://api.example.com/products').then(r => r.json()),
  fetch('https://api.example.com/orders').then(r => r.json()),
]);

This gap matters in daily development. The Node.js version is two lines. PHP requires a library, a generator function, a pool constructor, and a promise wait call. Async is not bolted onto Node.js — it is the entire foundation of it.

#What Real Developers Say

"The vast majority of web applications are not performance-limited by their language runtime. They are limited by database queries, external API calls, and business logic complexity."

— Taylor Otwell, creator of Laravel

"I made some choices early in Node that I now regret. The module system, the callback model — these were harder than they needed to be."

— Ryan Dahl, creator of Node.js, from his Deno introduction (2018)

"Performance that developers cannot maintain or reason about is not actually useful performance."

— Evan You, creator of Vite and Vue.js

"Fastify's overhead is minimal. Most performance problems in Node.js applications come from userland code, not the framework."

— Matteo Collina, Node.js core contributor, co-creator of Fastify

Notice that Ryan Dahl — the person who built Node.js — publicly acknowledged its architectural regrets. That kind of self-awareness from a creator should factor into how you evaluate the runtime's design decisions.

#Pros and Cons

#PHP

#Strengths

#Weaknesses

#Node.js

#Strengths

#Weaknesses

#Use Case Guide

#Use PHP When

#Use Node.js When

#What the Numbers Actually Mean

After running all the benchmarks, the honest summary is this:

For most web applications — the kind that serve pages, handle form submissions, run database queries, and send emails — the performance difference between PHP and Node.js is not your bottleneck. Your database is your bottleneck. Your external API calls are your bottleneck. The framework overhead is rounding error compared to a missing index on a frequently queried column.

This is not a dismissal of performance. It is a prioritization of it.

The benchmark where PHP was three times slower than Node.js (Hello World) will never matter in a real application, because no real application serves only a Hello World response. The benchmark where the gap narrowed to 30% (database read) is far more representative — and even then, a Redis cache collapses most of that gap entirely.

The benchmark where PHP beat Node.js by 4x (CPU task) matters a great deal if your application does image processing, PDF generation, data transformation, or complex calculations in the request path. That result should directly inform your architecture decisions.

The right question is not which runtime is faster in a benchmark. It is which ecosystem will let your team ship correct, maintainable software faster — given the specific problem you are solving.

#References

#The Verdict

I went into this expecting Node.js to win convincingly on performance and PHP to win on ecosystem maturity for web applications. I was partially right on both.

Node.js is faster in throughput benchmarks. That advantage is real and consistent. But it is smaller than conventional wisdom suggests, and it comes with a meaningful tradeoff on CPU-bound work. PHP with modern versions and FrankenPHP worker mode is no longer the slow runtime of 2012.

What surprised me most was not a benchmark result. It was realizing how rarely the benchmark result is even the right question.

Both languages are alive. Both are actively developed. Both have communities worth being part of.

The "PHP is dead" narrative was never accurate. The "Node.js solves everything" narrative was always a sales pitch.

Use the right tool. Understand its actual tradeoffs. The verdict is not that one won — it is that the competition was never as simple as people made it sound.

All benchmarks were run on Ubuntu 22.04 LTS, 4 vCPU / 8 GB RAM, Docker containers with equivalent resource limits. PHP 8.4.1 with OPcache enabled and realpath_cache_size=4096K. Node.js 22.11.0 LTS with Fastify 4.x. PostgreSQL 16 on localhost. Five iterations per test — high and low discarded, middle three averaged.