How to Cut Server Delays and Hit Google's INP Target

Click a button. Page updates. That is INP.

INP stands for Interaction to Next Paint. It counts how long the page takes to update after a click or tap.

Google calls 200ms or less Good. Anything above that hurts your search ranking.

Most guides focus on browser code. But server delays are a common cause too.

What INP measures

INP is the longest click during a visit. It has three parts.

Input Delay is how long before your code starts to run.

Processing Duration is how long your code takes to run.

Presentation Delay is how long the browser takes to paint the new frame.

Your code often calls a server. If that call takes 400ms, the whole click waits 400ms. The browser cannot paint until the server replies.

What is a good INP score

Google uses real visitor data over 28 days.

• Under 200ms is Good.
• 200ms to 500ms Needs Improvement.
• Over 500ms is Poor.

If more than one in four visits has a slow click, your page fails.

This matters for search. Google uses page speed as a ranking signal. Slow pages rank lower than fast ones. AI search bots also skip slow pages.

Five server problems that hurt INP

1. Workers are all busy

PHP, Node, and Python each handle one call at a time. When all workers are busy, new calls wait in a queue.

CPU use may be low. But response times jump when traffic spikes.

Start all workers in advance. This removes the wait when traffic jumps.

2. Database holds

When two users click at the same time, one waits for the other. A slow query can hold an entire table.

500 errors appear during concurrent writes. Full table scans show in the slow query log.

Add indexes on every column used in lookups. Use row-level locks instead of table-level locks.

3. Server holds responses

The server holds responses before sending them to the client. For large HTML pages this is fine. For small data payloads it adds delay.

Turn off buffering for your API routes.

4. Slow tasks in the click path

Sending an email or generating a PDF inside the click code blocks the reply.

Response times jump at irregular times.

Move non-critical work to a background queue. Reply right away. Handle the rest separately.

5. Server is far away

A round trip from India to a US server takes 160 to 220ms. That uses most of your 200ms budget before your code runs.

Pages feel slow on mobile in India.

Host in India. Domestic round trips drop to 10 to 25ms. That leaves 175ms for your app.

How to fix each one

Fix 1: Move slow tasks to a background queue

Instead of doing everything in the click code, push heavy work to a Redis queue. Return a reply right away.

import express from 'express';
import { Queue } from 'bullmq';
import Redis from 'ioredis';

const app = express();
const connection = new Redis({ host: '127.0.0.1', port: 6379 });
const interactionQueue = new Queue('user-interactions', { connection });

app.post('/api/interactions/submit', async (req, res) => {
  const { userId, action, payload } = req.body;

  if (!userId || !action) {
    return res.status(400).json({ error: 'Invalid parameters' });
  }

  await interactionQueue.add('process-event', {
    userId,
    action,
    payload,
    timestamp: Date.now()
  }, {
    attempts: 3,
    backoff: { type: 'exponential', delay: 1000 }
  });

  return res.status(202).json({ status: 'queued' });
});

The browser gets a reply in under 20ms. A background worker handles email and other tasks separately.

Fix 2: Turn off buffering for API routes

location /api/ {
    proxy_pass http://backend_api;
    proxy_http_version 1.1;
    proxy_set_header Connection "";

    proxy_buffering off;
    tcp_nodelay on;
}

Small data payloads now reach the browser right away.

Fix 3: Start all PHP workers in advance

; /etc/php/8.3/fpm/pool.d/www.conf
[www]
listen = /run/php/php8.3-fpm.sock
listen.backlog = 65535

pm = static
pm.max_children = 50
pm.max_requests = 1000

request_terminate_timeout = 10s

Starting all workers in advance removes the gap when traffic jumps.

Fix 4: Tune Linux socket queues

Add these to /etc/sysctl.d/99-latency.conf and run sudo sysctl --system.

net.core.somaxconn = 65535
net.core.netdev_max_backlog = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
net.ipv4.tcp_fastopen = 3

These settings let the kernel accept calls without queuing delays.

Fix 5: Host in India

A server in Palitana, Gujarat adds 10 to 25ms of round-trip time for most Indian cities. A server in the US adds 160 to 220ms. For pages serving Indian visitors, domestic hosting leaves 175ms of headroom in the INP budget.

How to check your API response time

curl -w "\
DNS Lookup:        %{time_namelookup}s\n\
TCP Handshake:     %{time_connect}s\n\
Time to First Byte: %{time_starttransfer}s\n\
Total Duration:    %{time_total}s\n" \
  -o /dev/null -s -X POST https://api.webhost24.in/api/interactions/submit \
  -H "Content-Type: application/json" \
  -d '{"userId":"test_1","action":"ping"}'

A healthy API route returns the first byte in under 50ms.

Check your socket queue depth.

ss -lntp '( sport = :443 or sport = :9000 )'

If Send-Q equals Recv-Q under load, calls are queuing. You need more workers.

Check for slow database writes.

sudo mysqldumpslow -s t -t 5 /var/log/mysql/mysql-slow.log

Every column in a WHERE, JOIN, or UPDATE clause needs an index.

Summary

INP is not only a JavaScript problem. Server-side delays push clicks past the 200ms threshold too.

To keep INP under 200ms:

• Move slow tasks to a background queue. Reply right away.
• Turn off buffering for API routes.
• Start all workers in advance.
• Tune socket queues so calls do not back up.
• Host your app close to your users.

All of these changes work whether you run one VPS or a full cluster. Start with the queue fix. It usually gives the biggest INP gain for the least effort.

If your visitors are in India, a domestic VPS drops your round-trip latency from 180ms to under 25ms. WebHost24 VPS plans run on fast storage in Palitana, Gujarat. Every plan is month-to-month with a 30-day money-back guarantee.

Need help checking your server stack? Message our team on WhatsApp at +919687572424 or use the /contact page.