Skip to content
Novandri.
All articles
Technical SEOPerformanceWeb InfrastructureNetwork

Web Performance from DNS to Browser: Find the Slow Layer

Diagnose web performance bottlenecks across network and compute layers: waterfall decomposition, TTFB analysis, render-blocking resources, and DevTools triage.

Rachmadwipa Novandri7 min read

When a website feels slow, engineering teams often jump straight to optimizing client-side JavaScript or compressing images. While frontend optimizations are valuable, diagnosing performance bottlenecks without measuring the entire request lifecycle frequently addresses the wrong layer. A page with optimized JavaScript will still load sluggishly if origin database queries choke Time to First Byte (TTFB) or if un-cached DNS lookups stall initial connection negotiation.

Direct Answer: Diagnosing web performance requires deconstructing the network and compute waterfall into discrete layers defined by the W3C Navigation Timing API: DNS resolution, TCP handshake, TLS negotiation, Time to First Byte (TTFB), content download, DOM parsing, and main thread execution. Bottlenecks occurring before the first byte arrives indicate network, CDN, or server-side compute issues; bottlenecks occurring after the first byte indicate render-blocking resources, un-optimized assets, or heavy client-side JavaScript.

Isolating exactly where latency accumulates prevents wasted engineering effort and directly improves search engine crawl capacity.

[Browser / Crawler Requests URL]
        │
        ▼ (1. Network Tier)
[DNS Lookup] ──► [TCP Connect] ──► [TLS 1.3 Handshake]
        │
        ▼ (2. Backend Compute Tier)
[Request Sent] ──► [Server Processing & DB Queries] ──► [First Byte Received (TTFB)]
        │
        ▼ (3. Transfer Tier)
[Content Download] (Streaming HTML payload)
        │
        ▼ (4. Browser Execution Tier)
[DOM Parsing] ──► [Fetch Render-Blocking CSS/JS] ──► [Layout & First Paint]

1. The Request Waterfall: Decomposing the Latency Timeline

Standardized under the W3C Navigation Timing API, every web transaction consists of discrete timing milestones. Inspecting these milestones exposes the exact boundary where time is lost:

  1. domainLookupStart to domainLookupEnd (DNS Lookup): Time spent resolving the domain name to an IP address. On cold lookups, this should take under 50ms; on warm cached connections, it takes 0ms.
  2. connectStart to connectEnd (TCP & TLS Connection): The physical network round trips required to establish the TCP socket and negotiate TLS encryption.
  3. requestStart to responseStart (Time to First Byte / TTFB): The duration from when the browser finishes sending the HTTP request until it receives the very first byte of the response from the server.
  4. responseStart to responseEnd (Content Download): The time required to stream the remainder of the HTML document across the network.
  5. domInteractive to domComplete (DOM Construction & Execution): The time the browser engine spends parsing HTML tokens, constructing the DOM tree, and executing synchronous scripts.

2. Isolating the Slow Layer: Network vs Backend vs Frontend

To fix a performance bottleneck, you must assign responsibility to the correct engineering layer:

Symptom Observed                       │ Fault Layer         │ Responsible System
───────────────────────────────────────┼─────────────────────┼──────────────────────────────
High DNS duration (> 100ms)            │ Network             │ Authoritative Nameserver
High Connect / SSL duration (> 150ms)  │ Network / Edge      │ Network routing, TLS ciphers
High TTFB (> 600ms)                    │ Backend Compute     │ Origin app, database, or CDN
Slow Content Download (> 300ms)        │ Transfer / Payload  │ HTML compression, MTU size
Late First Paint / Parser Blocked      │ Frontend Execution  │ Render-blocking CSS/JS files

1. The Network Layer (DNS, TCP, TLS)

If the waterfall shows prolonged latency before requestStart, your server is not at fault. The issue is network distance or connection inefficiency:

  • Remedy: Deploy an Anycast CDN to terminate connections close to users and crawlers; enable HTTP/2 or HTTP/3 multiplexing; and support TLS 1.3 session resumption.

2. The Backend Compute Layer (TTFB)

TTFB measures the latency of server-side computation. If TTFB exceeds 600ms (Google's recommended threshold for server responsiveness), the delay stems from:

  • Uncached database queries.
  • Synchronous template rendering in the application runtime.
  • Cache misses at the CDN edge that pass directly to a saturated origin server.

3. The Frontend Execution Layer (Parsing and Rendering)

If TTFB is fast (under 150ms), but the page remains blank for several seconds, the bottleneck is on the client:

  • Synchronous <script> tags in the <head> blocking the HTML parser.
  • Heavy external stylesheets forcing the browser to wait before computing the Render Tree.

3. TTFB (Time to First Byte): Why Search Crawlers Care

While human users experience performance as visual rendering, search engine crawlers evaluate performance at the socket and protocol level. TTFB is the primary performance metric that directly affects search engine crawling.

Fast TTFB (< 200ms) ──► Crawler finishes fetch quickly ──► Crawl Capacity Expands
Slow TTFB (> 1000ms) ──► Crawler socket waits idle      ──► Crawl Capacity Throttled

The Crawl Capacity Equation

Search engine crawlers allocate a finite bandwidth budget to every domain. If your server responds with sub-200ms TTFB, Googlebot can crawl dozens of URLs concurrently without taxing your origin.

If your backend TTFB spikes to 1.5 seconds, Googlebot’s host capacity algorithms immediately reduce the number of concurrent connections to avoid crashing your server, leading to indexing delays across new content.

4. Render-Blocking Resources: Critical CSS and Deferring JavaScript

When a browser engine parses raw HTML, it builds the DOM (Document Object Model). However, when it encounters external stylesheets or scripts, parsing behavior changes:

CSS Blocks Rendering (CSSOM)

The browser will not render any visual content until it has fully downloaded and parsed all external stylesheets declared in the <head>. A browser cannot paint a page without constructing the CSSOM (CSS Object Model); otherwise, users would see an un-styled flash of content (FOUC).

  • Remedy: Inline critical, above-the-fold CSS directly into the HTML <style> tag, and load non-critical stylesheets asynchronously.

JavaScript Blocks Parsing

By default, when the HTML parser encounters a <script src="..."> tag without attributes, it pauses HTML parsing entirely, downloads the script, and executes it before continuing down the document:

<!-- BAD: Blocks HTML parser while downloading and executing -->
<script src="/bundle.js"></script>

<!-- GOOD: Downloads asynchronously, executes only after DOM parsing finishes -->
<script src="/bundle.js" defer></script>

<!-- GOOD: Downloads asynchronously, executes immediately when ready (for analytics) -->
<script src="/analytics.js" async></script>

Engineering Rule: Never declare synchronous scripts in the document <head>. Use defer for scripts that depend on the complete DOM, or modern ES modules (type="module"), which defer execution by default.

5. Diagnosing Bottlenecks via DevTools and Terminal

To inspect timing breakdowns on a live URL, use DevTools Network Waterfall or terminal automation:

Recipe: Measuring Phase Latency with curl

Execute curl with a structured timing format string to isolate every network and compute phase:

curl -s -w "\
DNS Lookup:        %{time_namelookup}s\n\
TCP Connect:       %{time_connect}s\n\
TLS Handshake:     %{time_appconnect}s\n\
TTFB:              %{time_starttransfer}s\n\
Total Request:     %{time_total}s\n\
Response Code:     %{http_code}\n" \
-o /dev/null https://example.com/articles/slug

Sample Output Analysis:

DNS Lookup:        0.015s
TCP Connect:       0.045s
TLS Handshake:     0.078s
TTFB:              0.142s
Total Request:     0.185s
Response Code:     200
  • Interpretation: Network connection was negotiated in 78ms, server compute was 64ms (0.142s - 0.078s), and payload transfer took 43ms. This profile indicates healthy edge caching and optimal server response.

6. The Performance Triage Checklist

When auditing a slow endpoint, work through these layers in order:

  1. Verify Edge Caching: Does the response header show cf-cache-status: HIT or x-cache: HIT? If MISS, fix your cache keys.
  2. Audit Backend TTFB: If uncached, does the server compile the dynamic document in under 300ms? If not, inspect database slow query logs.
  3. Check Compression: Does the response header confirm content-encoding: br (Brotli) or gzip?
  4. Audit the <head>: Are all external JavaScript files configured with defer or type="module"?
  5. Optimize Critical CSS: Are render-blocking stylesheets minimized and loaded without chained @import rules?

Summary & Next Steps

Web performance is an engineering chain: a delay at the network tier cascades into the server compute tier, which delays document delivery and stalls frontend rendering. By measuring the full request waterfall and isolating bottlenecks to their responsible layer, engineering teams can systematically eliminate crawl latency and improve real user responsiveness.

Continue exploring user-centric performance metrics: