Thanks a lot for the answer, I tested all of it but the issue was the DB, the moment I tried connecting my local environment to prod DB I got exactly the same load times, so my server and network are fine, the database connection is the bottleneck

Thanks a lot for the answer, I tested all of it but the issue was the DB, the moment I tried connecting my local environment to prod DB I got exactly the same load times, so my server and network are fine, the database connection is the bottleneck

1. Confirm if it’s Laravel or the server

Create a simple test route:

Route::get('/ping', fn () => 'ok');

If /ping is also slow (~2s) → server / PHP issue If /ping is fast → Laravel / middleware / Inertia issue

2. If /ping is slow (most likely server-level)

Common causes I’ve seen in this exact scenario:

OPcache disabled → Laravel boot becomes very slow PHP-FPM misconfigured → requests queue even with low CPU Apache reverse DNS lookup → adds ~1–2s delay (HostnameLookups Off) No config caching

Run this (just to be sure)

php artisan config:cache
php artisan route:cache
php artisan view:cache

Verify OPcache:

php -i | grep opcache

3. If /ping is fast (Laravel layer)

hen focus on hidden app overhead:

a. Middleware

Temporarily disable session/CSRF to test:

->withoutMiddleware([
    \Illuminate\Session\Middleware\StartSession::class,
]);

b. Inertia shared props (very common bottleneck)

Check HandleInertiaRequests:

public function share(Request $request)
{
    return [
        'auth.user' => fn () => $request->user(),
    ];
}

Even this can trigger unnecessary work per request.

Test by returning:

return [];

Top suspects:

1. OPcache not enabled
2. PHP-FPM worker bottleneck
3. Inertia shared props doing hidden work

Did you follow the deployment chapter. Also did you make sure to set for production and not install debugging tools in production.

https://laravel.com/docs/13.x/deployment

What’s the fastest way to isolate whether the delay is coming from TTFB vs frontend rendering?

Run Lighthouse from Chrome's dev tools.

How are you serving the app? Just to be sure: are you building the assets, and not using any development tool (npm run dev or php artisan serve) in production?

In Apache, have you:

• Enabled http2 or http3? This is pretty important.
• Enabled traffic compression (gzip)?

What's the size of the largest javascript bundle when you build the assets?

The first things I'd do is open the browser dev tools and check the console for any errors, the network tab for any glaring issues, and then run Lighthouse or equivalent. You can analyze the waterfall graph in the Network tab, but I'd check the other stuff first.

Hey everyone,

I’m working on an Inertia.js app with Laravel + Vue, and I’m seeing slow page transitions (~2–3 seconds) in production, while everything is fast locally.

What’s interesting is that this happens even on a freshly deployed version with no meaningful data in the database.

Environment:

• DigitalOcean droplet (Apache)
• CPU/memory usage stays below ~20%
• Same server runs other Laravel apps without issues (non-Inertia, Vue inside Blade)

What I’ve checked so far:

• No obvious database bottlenecks
• Issue persists across all routes (not tied to specific queries)

For example, a simple “Forgot Password” page (no DB interaction) shows:

• ~1.9s total request time
• ~269 B response size
• Most of the time spent in “waiting” (TTFB)

At this point, I’m trying to narrow down whether this is:

• Backend response time (Laravel / middleware / config)
• Inertia overhead (shared props, etc.)
• Frontend hydration or asset-related

Questions:

• What’s the fastest way to isolate whether the delay is coming from TTFB vs frontend rendering?
• In Inertia apps, what are the most common hidden bottlenecks in production environments?

If anyone has a go-to debugging approach for this kind of issue, I’d really appreciate it.