DNS, CDN, and Browser Cache: Why Websites Feel Slow Even When Servers Are Fine

A website can feel slow even when the server looks healthy. CPU is low, RAM is fine, the database responds quickly, and yet users complain that pages take too long to open. This happens because the request path from browser to server is longer than what server dashboards show.

To understand these cases, look at the full path: DNS lookup, TCP connection, TLS handshake, CDN, browser cache, API requests, and frontend rendering. One slow piece can make the whole page feel heavy.

DNS lookup: the first step people forget

Before the browser contacts a server, the domain must resolve to an IP address. If the DNS resolver is slow, users feel delay before the request reaches your infrastructure. A TTL that is too short can cause more frequent lookups. Messy DNS configuration can route users from certain regions through poor paths.

For debugging, check DNS timing from multiple networks. Compare ISP resolvers, Google DNS, Cloudflare DNS, and mobile networks. If the issue appears only on one provider, the application may not be the source.

CDN: faster, but another layer

A CDN serves static assets from locations closer to users. It can also make debugging confusing. A stale cache, wrong rule, or problematic edge location can make users see old files while developers believe the latest version is deployed.

Use versioning for CSS and JavaScript files. For assets that change often, do not rely on the same filename forever. Add a version query or filename hash so browsers and CDN edges know when to fetch a new file.

Browser cache and service workers

Browser cache can make pages very fast, but it can also keep old files alive. Service workers are even stronger because they can control requests from the origin. If the update strategy is unclear, users may run old JavaScript while the server already has a newer version.

For dashboards, be careful when caching the app shell. Do not let users run an old UI that calls new APIs with a different contract. Provide a refresh mechanism or update prompt when the app version changes.

TLS and first connection

HTTPS requires a handshake. It is usually fast, but it can become visible on poor networks, certificate issues, or servers that are not configured for modern protocols. HTTP/2 and HTTP/3 can help, but bad configuration can still hurt performance.

Fast API, slow frontend

Sometimes APIs respond in 100 ms, but the page still feels slow because the frontend sends too many sequential requests. Profile loads first, then notifications, then active orders, then history. If the data is independent, load it in parallel. If not all data is needed above the fold, delay some of it.

Use the DevTools waterfall. Look at blocking requests, large files, and JavaScript that delays rendering. Do not diagnose performance by feeling alone.

Debugging from the user side

When users report slowness, ask for concrete details: location, network, device, browser, time of incident, and a waterfall screenshot if possible. For apps like OTPZap, this matters because users may use web, Telegram, or API. A slowdown in one platform does not always mean the others are affected.

Diagnosis checklist

• Check DNS timing from several resolvers.
• Check CDN cache status and purge rules.
• Make sure assets use versioning.
• Audit service workers if present.
• Look at browser waterfalls, not only server CPU.
• Separate network latency from backend latency.