Reverse Proxy TTFB: Does a Proxy Slow Your Site?
In this article
- What does time to first byte actually measure?
- What TTFB counts as good, and why it matters for SEO
- Where a reverse proxy adds latency
- How to measure reverse proxy TTFB before and after
- Keepalive to upstream and other settings on your own NGINX
- When the proxy is not the cause of slow TTFB
- What to do with your TTFB numbers
- FAQ
Yes, a reverse proxy adds one more network hop, so it can push up your time to first byte. How much? With a sane config, usually very little. And the only honest way to know is to measure before and after. If you’re worried that putting NGINX in front of your hosting will hurt page speed and rankings, this guide walks through what reverse proxy TTFB actually includes, where proxy latency comes from, how to measure it and how to keep it low.
What does time to first byte actually measure?
Time to first byte is the time from the start of navigation until the first byte of the response shows up, as the web.dev guide to TTFB describes it. That covers connection setup (DNS lookup, TCP connection, TLS handshake) plus whatever time your backend spends building the page. Network work counts. Server work counts. Both. There’s a subtlety people miss: Early Hints responses and early flushing of headers or the <head> also count as the first byte, while a separate timing entry, finalResponseHeadersStart, marks when the final document response actually begins. And since TTFB comes before First Contentful Paint and Largest Contentful Paint, a slow first byte delays every paint that follows it.
What TTFB counts as good, and why it matters for SEO
Per web.dev’s TTFB thresholds, good means 0.8 seconds or less, and poor means anything over 1.8 seconds. TTFB isn’t a Core Web Vitals metric on its own. But it feeds straight into LCP, which is.
Google’s Core Web Vitals documentation for Search recommends that site owners achieve good Core Web Vitals for success in Search. So server response time hits SEO indirectly. A slow backend or a badly placed proxy drags down the user-centric loading metrics Google does look at (and that’s the part worth caring about, not TTFB as some magic ranking number).
Where a reverse proxy adds latency
A proxy adds delay in two places: the extra hop between visitor, proxy and origin, and the new connection it may open to the origin on every single request. Distance is the big one. Put a proxy far from your origin, or far from your readers, and you pay in round trips. That’s why picking a hosting location deserves as much thought as the proxy itself.
The second cost is upstream connection setup. With keepalive off, the proxy redoes a TCP and TLS handshake to the origin for each request. Wasteful. But here’s the flip side: the same setup can actually help you. Terminate TLS close to readers, hold warm connections to the origin, and you can offset the extra hop. Jalvo, for example, is an NGINX reverse proxy with European and US proxy IPs, so where it sits relative to your origin and your audience shapes the result.
How to measure reverse proxy TTFB before and after
Compare the same URL through the proxy and directly against the origin, from the same location, several times over. One request tells you almost nothing. Network noise swings individual values all over the place.
- Run curl with timing fields against the proxy hostname:
curl -o /dev/null -s -w "connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer}\n" https://example.com/ - Run the same command against the origin, with
--resolve example.com:443:ORIGIN_IPor a hosts file entry so the certificate still matches. - Repeat each run many times and compare medians, not single values.
- Test from the regions where your readers actually are, not just from your laptop.
For field data, the Navigation Timing API or the web-vitals library reports TTFB for real visitors. The Resource Timing API handles other requests, cross-origin ones included. Heads-up, though: same-origin resources can report zero, because the connection is already open or the file came from cache. When you read the results, look at the gaps. A bigger difference in connect and TLS time points to network cost. A gap only in time to first byte? That’s the backend.
Keepalive to upstream and other settings on your own NGINX
The biggest proxy-side win is reusing connections to the origin instead of opening a fresh one per request. On your own NGINX that comes down to three settings:
- an
upstreamblock with akeepalivedirective that keeps idle connections open, proxy_http_version 1.1;in the location that proxies the traffic,proxy_set_header Connection "";to clear the header that would otherwise close each connection.
Keep the proxy and origin close on the network, and don’t chain several proxies, because every layer adds its own hop. To be clear, these are settings for your origin or your own NGINX, not options in the Jalvo panel. And if backend processing dominates your measurements, fix the origin first. No amount of proxy tuning will hide a slow application.
When the proxy is not the cause of slow TTFB
If the origin is already slow when you hit it directly, pulling the proxy out won’t fix TTFB. Usual suspects on the origin side: heavy database queries, no page caching in the CMS, overloaded shared hosting.
Signs it’s the backend and not the network:
- direct origin requests show a similarly slow first byte,
- connect and TLS times stay low while time to first byte stays high,
- static files come back fast but dynamic pages lag,
- things get slower at busy hours.
Not sure a proxy even fits your setup? Then think through when a proxy as the right tool makes sense before you change anything.
What to do with your TTFB numbers
Yes, a reverse proxy adds a hop. But in practice the measured delay mostly comes down to distance and upstream connection reuse, and you can fix both. Measure origin against proxy, compare medians, check field data against the web.dev threshold. For more on placement and server setup, browse the hosting notes on our blog. My advice? Run one curl comparison today. A clear baseline is the fastest way to find out whether reverse proxy TTFB is really your problem.
FAQ
Does adding a reverse proxy always increase TTFB?
Not always. It adds a network hop, sure, but reused upstream connections and TLS terminated closer to readers can offset that cost. Only a before-and-after measurement tells you what it really does on your site.
How do I check TTFB with and without the proxy?
Use curl timing fields against the proxy hostname, then against the origin with --resolve so the same certificate applies. Run each test several times from the same location. Then compare medians, not single results.
Is TTFB a Google ranking factor?
It isn’t a Core Web Vitals metric itself, but it comes before LCP, which is one. Google recommends good Core Web Vitals for success in Search, so a slow first byte can hurt you indirectly.
