POST API slower than GET: check request processing or network connections first?

When POST API tests are slower than GET, the differences usually fall into three areas: whether connection setup is comparable, whether uploading the request body takes longer, and whether the gateway and application perform more work. Do not assume the database is slow just because POST is often used for writes, or immediately blame the network because the browser shows “Waiting for server response.”

A more effective starting point:First confirm that GET and POST are comparable, then check connection setup. If connection times are similar but POST has a much later first byte, separate request upload time from server-side processing.For small request bodies using the same egress, protocol, and connection conditions, check caching, authentication, gateways, and application processing paths earlier. For file uploads, mobile networks, large bodies, or cross-origin calls, prioritize upstream transfer, preflight, and request body reception policies.

Fast GET and slow POST may not be a like-for-like comparison

The same domain does not mean the same processing path

A GET request may receive a cached object directly from the CDN, while a POST request passes through edge security checks, gateway authentication, application validation, database transactions, and third-party services. Even with the same domain and URL path, the actual workloads may be entirely different.

A homepage GET time is therefore not a valid network baseline for an order submission POST. A better reference is an uncached diagnostic endpoint on the same domain with a similar response size, or a lightweight request-receiving endpoint provided by the application. If GET and POST perform different business operations, their timings only show different user wait times; they do not prove that the POST method itself is slower.

Caching cannot be inferred from the method alone either. GET may miss the cache because of authentication, Cookie, cache rules, or response directives. Whether POST can be cached or receives special acceleration depends on product capabilities and explicit configuration. Do not assume every CDN always caches GET and sends POST directly to the organization's origin.

One browser action may involve multiple requests

Cross-origin JSON POST often triggers CORS preflight, while a regular GET may not require it without additional triggering conditions. The operation time users observe may include OPTIONS, POST, and a follow-up query after submission.

In browser developer tools, record the start time, duration, status code, and initiator relationships for OPTIONS and POST separately. Also check whether JavaScript waits for a login session refresh, reads a local file, or performs calculations before sending the request. A fast API request does not necessarily mean a short interval between clicking a button and seeing the page update.

By default, curl neither simulates browser preflight decisions nor performs browser cross-origin response checks. A successful curl POST only proves that the request received a response under those network and request conditions; it does not prove browser CORS is working.

First control the test conditions that can change the conclusion

Before comparing results, record at least the following to avoid mixing unlike samples:

• Client region, carrier, and egress type, distinguishing home broadband, mobile networks, and cloud hosts.

• IPv4 or IPv6, HTTP version, and whether an explicit proxy or VPN is used.

• Whether the connection is new, redirects occur, or an existing browser connection is reused.

• URL, authentication identity, key request headers, request body bytes, and response body size.

• Whether GET hits the cache and POST triggers a challenge, rate limiting, or other security processing.

• Test period, concurrency, business data state, and any failures, retries, or timeouts.

These are not incidental notes; they are evidence that determines troubleshooting priorities. A GET reusing an HTTP/2 connection cannot be directly compared by total time with a POST that resolves the domain again and establishes TLS.

Using timings to decide whether to check connections or processing first

Do not treat cumulative curl timings as individual phase durations

Common curl timing fields measure elapsed time from the start of the transfer to an event, not independent phase durations. For an HTTPS request using a new connection, with no proxy, redirects, or special authentication round trips, the following table provides an approximate breakdown.

A common mistake is to label all oftime_starttransfer - time_pretransferas “backend processing time.” For POST, this interval may include uploading the request body. If the gateway must receive the entire body before forwarding it, the application may not even have started processing.

With informational responses, streaming uploads, early server rejection, or overlapping requests and responses, the first byte does not mean business processing has finished. In particular, when100 Continueis involved, interpret tool output alongside the request and response sequence rather than using a single TTFB value to locate the wait for the final response.

With connection reuse, some connection fields may be zero, so new-connection formulas no longer apply. HTTP/3 does not use TCP, so TCP phase interpretations cannot be carried over either. You can initially fix the protocol to HTTP/1.1 to reduce variables, but must then verify results with the HTTP/2 or HTTP/3 used in practice. Do not confuse diagnostic conditions with the production experience.

Evidence that changes troubleshooting priorities

If GET and POST have similar DNS, TCP, and TLS times in new-connection tests, but only POST has a longer wait after transfer begins, connection setup is usually not the primary issue. Next inspect request body size, upload completion time, gateway reception time, and application processing logs rather than changing DNS first.

If both methods show slower connection setup in a particular region, prioritize local access connectivity, IPv4/IPv6 differences, proxies, and edge access paths. POST may simply make the issue more noticeable to users rather than being a condition specific to the fault.

If small POST requests work normally but large ones slow down without a corresponding increase in application execution time, first check upload bandwidth, packet loss, request body buffering, and request size limits. Conversely, if the body is small and fully received by the gateway but application processing remains slow, prioritize database locks, connection pool queues, and synchronous third-party calls.

A minimal practical comparison: collect interpretable samples first

Compare on a safe diagnostic endpoint, not by repeating real transactions

The following uses a documentation example domain and assumes a/diagnostics/echoendpoint that allows GET and POST without write side effects. Before running it, substitute an authorized diagnostic endpoint and prepare a localpayload.jsonthat conforms to its protocol. Do not treat the example path as a real service or repeatedly test payment, order placement, or SMS-sending endpoints.

If no such endpoint exists, measure the real GET and POST separately, but compare only connection setup rather than attributing their overall difference to the HTTP method. For actual writes, use a test environment and an idempotency mechanism supported by the service. Do not add an unsupported idempotency header and assume requests will not execute twice.

The following function fixes the protocol to HTTP/1.1 and outputs cumulative timings. Each curl invocation runs independently without automatically following redirects;-qprevents the default curl configuration file from adding options, although environment proxy settings may still apply.

measure() {
  curl -q --http1.1 \
    --connect-timeout 5 --max-time 30 \
    --silent --show-error \
    --write-out '\ncode=%{http_code} ip=%{remote_ip} http=%{http_version} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} pre=%{time_pretransfer} first=%{time_starttransfer} total=%{time_total} uploaded=%{size_upload} downloaded=%{size_download}\n' \
    "$@"
}

measure --dump-header get.headers --output get.response \
  'https://api.example.com/diagnostics/echo'

measure --dump-header post.headers --output post.response \
  --header 'Content-Type: application/json' \
  --data-binary @payload.json \
  'https://api.example.com/diagnostics/echo'

--data-binarymakes this request use POST. The necessary differences between GET and POST are the method, body, and content type; keep other headers affecting business processing paths as consistent as possible. If authentication is required, use controlled test credentials. Never paste real Cookie, Token, or keys into public logs, tickets, or articles.

Check status codes and response content before examining timings. HTTP 200 may simply wrap a business-level error. Responses with 403, 413, 429, or 5xx also follow different processing paths and should not be pooled with normal successful responses for latency calculations. For 3xx, first establish whether the destination and method change, then analyze the redirect chain separately. Do not simply add-Land continue treating the result as a single request.

Response files may contain sensitive information. Save them in a controlled directory with restricted access. After testing, retain only sanitized business results and timing fields.

Use small sample batches to identify consistent differences

If the endpoint has no side effects and capacity allows, start with a dozen or so samples of each method, run serially at a low rate. Alternate GET and POST and retain every raw record. Do not run all GET tests first and test POST much later, as changes in backend load and network conditions will affect the comparison.

This sample size can reveal obvious problems but cannot reliably estimate tail latency. To compare P95, collect more samples within a defined sampling window and examine results separately by region, carrier, address family, protocol, cache status, and success outcome. Regional P95 values cannot simply be averaged into an overall P95.

Do not discard timeouts as missing data. At minimum, report the latency distribution of successful requests, failure rate, timeout threshold, and failure types together. If an overall experience metric is needed, define in advance how failures count. Otherwise, as more slow requests time out, the reported “average successful request time” may misleadingly improve.

When connection times are similar, separate request upload from server wait

Larger request bodies make upstream networking a more likely cause

GET often contains only a request line and a few headers, while POST may carry JSON, forms, or files. Upload conditions on home broadband and mobile networks may differ from download conditions; a normal download speed test does not prove uploads are healthy. Packet loss, wireless handovers, and concurrent uploads can also significantly affect large request bodies.

The minimal validation step is not to switch networks blindly. Use a diagnostic endpoint that supports the business protocol to test progressively larger, structurally valid bodies while keeping response sizes as similar as possible. Record client upload bytes, gateway body reception completion, application start, and full response time. If total time grows substantially with upload size while time after application start remains stable, prioritize the upload and reception path.

Correlation alone is not enough: larger JSON can also increase parsing, validation, decompression, and database write costs. Supplement your assessment with server-side records rather than deriving bandwidth directly from file size. A client reporting “upload complete” does not mean the organization's origin has received the full body, since an intermediate gateway may still be buffering or forwarding it.

Request body buffering can make the backend appear to start late

CDNs, WAFs, reverse proxies, and API gateways may receive the entire request body before inspecting or forwarding it. Large bodies may be affected by memory buffer thresholds, temporary file writes, inspection queues, and transfer speed to the next hop.

Application logs may then show a short execution time even though users wait a long time. There is no contradiction: application timing starts when business processing begins, not when the client starts uploading, and does not cover the entire interval through the complete response.

Check timing definitions at each layer: does total request time include body reception, when does upstream timing start, does it include queuing, and are there internal retries? Fields differ across proxies and versions. A field containing “upstream” does not necessarily measure pure application execution time.

If streaming is genuinely required, assess whether the gateway and application support forwarding and consuming chunks. Do not disable request body inspection simply to reduce latency. Streaming changes security inspection, backpressure, retries, and partial-write handling. Limit it to specific endpoints, establish size and rate boundaries, and design cleanup or recovery for midstream failures.

For fixed waiting intervals, check Expect and authentication round trips

Some clients useExpect: 100-continueto wait for server confirmation before sending the request body. Whether this header appears and how the wait behaves depend on the client version, request type, and configuration. Do not assume every POST follows this process.

If the request headers do containExpect: 100-continueand timings show a relatively consistent additional wait, run a controlled diagnostic comparison, keeping other conditions unchanged and adding only--header 'Expect:'. If the difference disappears, investigate whether intermediate proxies correctly forward and handle informational responses rather than immediately removing this mechanism site-wide.

Also investigate authentication challenges and automatic client retries. One client call may involve multiple HTTP exchanges. Method-specific server rate limits or challenges may affect only POST. If necessary, inspect detailed timing on test requests without sensitive credentials. Restrict access to real request traces and sanitize them first.

Once the application receives the request, how do you locate slow processing?

Correlate edge, gateway, and application records with request identifiers

The most useful evidence is not three unrelated durations but a timeline for the same request across layers. Use existing request IDs or distributed tracing identifiers to correlate edge access records, gateway logs, and application traces. A new diagnostic request header may change cross-origin preflight conditions, so keep browser comparison tests consistent too.

Record clearly defined events: gateway request arrival, completed body reception, application execution start, key dependency call start and end, response header transmission, and completed response transmission. Verify clock synchronization before subtracting absolute timestamps across machines. Within each process, prefer a clock suitable for measuring elapsed time.

If a long interval separates gateway arrival from application entry, inspect gateway queues, connection pools, upstream availability, and request body reception. If the application starts quickly but waits to obtain a database connection, check database connection pools and concurrency capacity rather than adjusting CDN caching first.

POST-specific business work may matter more than the network

Write APIs often perform authorization, signature verification, field validation, transactions, uniqueness checks, auditing, and message delivery. If GET only reads a cache, the two operations have fundamentally different costs. Break this work into observable spans to identify where duration changes with concurrency or data state.

For databases, distinguish slow execution from long waits: fast SQL execution does not rule out transaction lock waits or connection pool queuing. For third-party APIs, separate connection setup, waiting for the remote response, and client retries. Additional retries can substantially increase total POST time and risk duplicate side effects.

If a required external workflow causes the delay, architectural decisions may help more than network tuning. Where business requirements allow, move noncritical processing to asynchronous execution, distinguish “accepted” from “completed,” and provide a way to query results. This requires sound idempotency, persistence, failure compensation, and state visibility. Returning an HTTP response earlier alone does not mean the operation succeeded.

When to compare CDN and origin paths

Verify edge and origin-fetch differences before changing architecture

Investigate edge processing and origin connectivity when the same POST differs substantially across access paths or a large gap appears between edge and origin logs. An edge cache miss does not necessarily mean the request reached the organization's origin. It may pass through an upper-tier cache or intermediate gateway, or terminate at a security check.

Provider identification, CNAME, response headers, and IP ownership offer clues but cannot independently prove the full delivery path. Useprovider identification and node cross-checkingto organize entry-point information, then confirm actual routing against account configuration and available logs.

If authorized and the origin permits diagnostic access, use the preceding function for the following comparison.203.0.113.10is a documentation example address and must be replaced with a controlled test origin address. Do not disclose real origin information.

measure --dump-header origin-post.headers --output origin-post.response \
  --resolve 'api.example.com:443:203.0.113.10' \
  --header 'Content-Type: application/json' \
  --data-binary @payload.json \
  'https://api.example.com/diagnostics/echo'

--resolvepreserves the hostname in the URL, retaining the corresponding Host and TLS SNI. This makes it more suitable for comparison than accessing the HTTPS origin IP directly. Do not add-kto skip certificate verification, as that may hide virtual host or certificate problems. If an explicit proxy is used, verify the actual connection destination before assuming the request has bypassed the edge.

A faster CDN bypass does not justify bypassing the CDN everywhere

Both tests should use the same POST URL, body, authentication identity, and key headers, run close together from the same egress, with responses confirmed to have equivalent business meaning. If a firewall blocks the origin comparison, do not temporarily expose the entire origin to the internet for testing. Use an authorized test egress or internal connectivity evidence instead.

Even if direct origin access is faster, the client may simply be closer to the origin, a necessary inspection may have been bypassed, or a dedicated origin entry point may apply different rules. This does not prove the edge network is generally slower or that users in other regions would benefit.

Consider changing entry points, edge inspection, or origin-fetch policies for specific APIs only when multi-region comparisons, business semantics, origin load, and security processing conditions are understood. To cover real user regions, usewebsite speed testingas a supplementary view of accessible pages or entry points, alongside your own business probes and server logs. Public page probes cannot replace authenticated POST validation with a request body.

How to confirm configuration changes actually solve the problem

Target the identified phase rather than changing DNS, caching, WAF, and database parameters all at once. The broader each change, the harder it is to identify what worked or detect newly introduced issues.

1. Limit the scope.Choose one diagnostic endpoint, test tenant, or small traffic percentage. Record the original configuration and a rollback version. Do not disable security checks globally.

2. Validate the mechanism.If adjusting body buffering, confirm reception and forwarding times change as expected. If optimizing the database, verify reduced lock waits or connection pool queuing rather than looking only at total time.

3. Check business outcomes.Beyond status codes, verify business success, data integrity, idempotent behavior, and error distribution to avoid faster responses that conceal processing failures.

4. Recheck real access conditions.Return to the production protocols and browsers. Cover preflight, new and reused connections, small and typical request bodies, and major regions and network egress points.

5. Check trade-offs and rollback.Monitor origin concurrency, gateway resources, security events, and failure retries. If anomalies occur, restore the original configuration and verify that the original processing path is restored.

The final question is not whether POST should be as fast as GET, but whether every wait has a clear explanation.When connection times match and the body is small, prioritize cache differences, gateway queues, and business processing. When bodies are large or uploads finish late, prioritize upstream transfer, reception, and forwarding. Put DNS, connection setup, and TLS first only when connection timings themselves are abnormal.Following this sequence turns a single total duration into evidence that guides fixes and architectural decisions.