Short answer. Slow loading decomposes into phases: DNS resolution, TCP/TLS setup, time to first byte (TTFB), and browser rendering. To speed a site up, first measure which phase is slow with curl -w. If TTFB is high, the problem is the server (slow backend, database, no caching). If render is slow, it is the frontend (heavy JS/CSS, unoptimized images). Measure first, don't guess.
Break the load into phases
The main mistake is optimizing blindly. First measure where the time goes:
curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.com
# Example output:
# dns:0.012 connect:0.045 tls:0.120 ttfb:0.890 total:1.230
# High ttfb (0.89s) with low connect = the server is slow
TTFB (time to first byte) is the key indicator of server speed. If the first byte takes more than 600 ms, optimizing images is pointless — the bottleneck is the backend.
What each phase means
| Phase (curl) | What it measures | If high — cause |
|---|---|---|
| time_namelookup | DNS resolution | Slow/distant DNS resolver |
| time_connect | TCP handshake | Network latency, distant server |
| time_appconnect | TLS handshake | Heavy TLS, no session resumption |
| time_starttransfer (TTFB) | Time to first byte | Slow backend, DB, no cache |
| time_total | Full document load | Large response payload |
If TTFB is high (server side)
- Enable page caching (Redis/Memcached, page cache).
- Optimize slow SQL — add indexes, check EXPLAIN.
- Remove N+1 queries and heavy external API документацию calls from synchronous code.
- Enable OPcache/JIT for PHP, check the number of PHP-FPM workers.
- Check CPU/RAM load — the server may be overloaded.
If render is high (frontend)
- Compress and minify CSS/JS, remove unused code.
- Optimize images: WebP/AVIF, correct sizes, lazy-loading.
- Remove render-blocking scripts, use defer/async.
- Enable HTTP/2 or HTTP/3 and keep-alive.
- Add a CDN for static assets closer to users.
If DNS/TCP/TLS is high (network)
- High DNS — switch resolver or use a fast authoritative DNS.
- High connect — the server is physically far; a CDN or nearer region helps.
- High TLS — enable TLS 1.3, OCSP stapling, and session resumption.
If the site is fast from one region and slow from another, it is network distance. A single server cannot be equally fast worldwide without a CDN.
Compare several runs
A single measurement is misleading — run 3-5 times to rule out noise and see cache warm-up:
for i in 1 2 3 4 5; do
curl -o /dev/null -s -w "ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.com
done
The first run is cold (empty cache); subsequent ones should be faster. If TTFB stays high, caching is not working.
How enterno.io helps
The enterno.io PageSpeed check breaks the load into metrics (LCP, FCP, TBT, CLS) and shows exactly what is slow — server or frontend. The HTTP checker shows caching and compression headers. Uptime monitoring records the response time of every check, so you see TTFB degradation over time, not just at a single moment. Multi-region checks (RU/EU/US) reveal whether it is slow everywhere or only from one region — that points to network distance vs a server problem. Alerts on rising response time go to Telegram/Slack/email/webhook. enterno.io measures and warns; the optimization itself is done by the owner.
FAQ
What TTFB is considered normal?
A good TTFB is under 200 ms, acceptable up to 600 ms. Above 600 ms is a clear signal to optimize the backend and caching.
The site is fast for me but a client reports it's slow?
Measure from their region. It is likely network distance to the server — a CDN helps, and regional monitoring confirms it.
Where do I start optimizing?
With a phase measurement via curl -w. First learn where time is lost, then fix that specific thing, not everything at once.
Does simply enabling Cloudflare help?
A CDN speeds up static assets and TLS but does not cure a slow backend. If TTFB is high on dynamic pages, you need server-side caching and query optimization.
Next step: run the site through the PageSpeed check and inspect headers in the HTTP checker. See also the monitoring guide and turn on response-time tracking.