Loading full navigation.

Autonomous IT is here. The alert loop ends now. LEARN MORE

Partners

Docs

LM Academy

LM Community

Pricing

Platform
Solution
Industry
Role
There is no result.

LOGICMONITOR BLOG

How HTTP Works: Understanding HTTP Transactions and Web Performance

See how an HTTP transaction moves from DNS lookup to response download, how HTTP/2 and HTTP/3 change it, and how timing reveals what makes a request slow.

8–12 minutes
Denton Chikura

NEWSLETTER

Subscribe to our newsletter

Get the latest blogs, whitepapers, eGuides, and more straight into your inbox.

SHARE

The quick download:

Naming the slow stage of an HTTP transaction turns a vague complaint into a specific fix.

  • Every request moves through six stages, from DNS resolution to browser rendering, and each stage points to a different owner

  • HTTP/1.1, HTTP/2, and HTTP/3 move data differently, so the protocol a request used shapes its performance

  • A waterfall chart shows where the time went, guiding you to DNS, the network, the server, or the download

  • Measure your most important user flow from the locations your customers use, so “slow” becomes a specific question your team can answer

A customer reports that checkout feels slow, or that the login page hangs before it loads. Your infrastructure dashboards show healthy servers and normal CPU, yet the person on the other end still waits. Understanding how HTTP works, and how a single HTTP transaction moves from a click to a rendered page, separates a guess from a diagnosis.

The word “slow” hides a lot. A delay can begin in DNS (Domain Name System) resolution, the network path, or TLS (Transport Layer Security) setup. It can also come from server processing, a CDN, or a third-party dependency your team doesn’t control.

HTTP transaction timing helps you isolate which of those stages caused the wait, instead of treating page speed as one number. Once you can name the slow stage, you know which team, system, or vendor to investigate first.

This guide walks through the stages of an HTTP transaction and how the major protocol versions move data. It then covers how to read the timing, so a report of “slow checkout” becomes a specific place to look. The goal is a repeatable method you can apply to any customer request.

The stages of an HTTP transaction

An end-to-end web request may include these stages. Not every request incurs every phase: cached DNS, reused connections, and multiplexed HTTP/2 and HTTP/3 streams skip or overlap some of them. Naming the stages still gives you a checklist to work through when a page is slow.

  1. DNS resolution: the client translates a hostname like shop.example.com into an IP address.
  2. Connection and security setup: the client opens a connection to that IP address, and for HTTPS it negotiates encryption through TLS.
  3. Request sent: the browser sends the HTTP request, such as GET /checkout, with headers describing what it wants.
  4. Server processing and first byte: the server, cache, or CDN builds a response, and time to first byte (TTFB) marks the first byte back.
  5. Response download: the client receives the response body, such as the HTML for the checkout page.
  6. Browser processing and dependent requests: the browser parses HTML, runs scripts, renders, and requests more resources like images, fonts, and APIs.

A slow product page might spend 10 milliseconds on DNS, 2 seconds waiting for the server, and another second downloading oversized images. Three stages point to three owners: the DNS provider, the application team, and whoever manages image compression.

The value of the sequence is that it turns one vague complaint into measurable pieces. A team that reports timing per stage can compare a healthy request against a slow one and see which phase grew. That comparison is usually faster than reading application logs blind.

The stages of a modern web request. These are diagnostic phases, not an identical packet-by-packet sequence for every HTTP version or tool.

Treat these six stages as diagnostic phases, not an identical packet-by-packet sequence for each HTTP version or monitoring tool. HTTP/2 and HTTP/3 reorder and overlap much of this work, but the stages still give your team shared language for finding delay.

How HTTP/1.1, HTTP/2, and HTTP/3 handle connections

HTTP has kept the same request-and-response idea across versions. What changed is how it moves data across the network. That affects how much setup each request costs and how many requests can share a connection.

HTTP/1.1 runs over TCP (Transmission Control Protocol). It keeps connections open so requests can reuse them, and a browser often opens several connections at once to fetch resources in parallel. Each new connection still pays for a handshake, and for HTTPS a TLS negotiation on top, so reuse is what keeps setup cost down.

HTTP/2 also runs over TCP. It multiplexes many streams over one connection, which reduces the need for many parallel connections. It doesn’t remove network or server bottlenecks, and packet loss on that single TCP connection can still stall unrelated streams.

HTTP/3 changes the transport. It runs over QUIC (a transport protocol built on UDP rather than TCP), with TLS 1.3 negotiated during connection setup. HTTP/3 still establishes a connection and negotiates encryption, so it isn’t handshake-free and isn’t automatically faster.

HTTP messages aren’t all plain ASCII text. HTTP/2 and HTTP/3 use binary framing, and response bodies such as images, video, or compressed data are often binary too.

A product page that loads 60 small thumbnails tends to finish faster on HTTP/2 than on HTTP/1.1. Those requests share one multiplexed connection instead of competing for a small pool of parallel ones. On a shaky mobile connection, the same page can do better on HTTP/3, because QUIC handles packet loss per stream (RFC 9000).

Record which protocol a slow request used. A page that’s fine on a wired office connection but slow on mobile can point to protocol and network conditions rather than the application itself. That single field often saves a round of guessing.

ProtocolTransportHow requests are handledPractical performance implication
HTTP/1.1TCPPersistent connections; browsers may open multiple connectionsReused connections reduce setup overhead, but concurrency is more constrained
HTTP/2TCPMultiple streams can share one connectionMultiplexing reduces the need for many parallel connections
HTTP/3QUIC over UDPMultiple streams over QUIC, with TLS 1.3 negotiated during setupCan improve behavior on lossy or changing networks and reduce some connection-establishment costs

These behaviors are defined in IETF standards. See HTTP/1.1 in RFC 9112, HTTP/2 in RFC 9113, HTTP/3 in RFC 9114, and QUIC in RFC 9000.

Reading an HTTP waterfall chart

A waterfall chart breaks a request, or a whole page load, into the stages above and shows how long each one took. Exact field names vary by tool, but the shape of the timing points you toward where delay happened.

Say a waterfall shows 5 milliseconds of DNS and 8 milliseconds to connect, then 2 seconds of waiting. The delay lives in server processing, not the network. The chart moves you from “the page is slow” to “the server is slow to respond.”

What looks slowLikely areas to investigateQuestions to ask
DNSResolver, authoritative DNS, geography, DNS configurationIs resolution slow everywhere or only from certain regions?
Connection or TLSNetwork reachability, packet loss, certificate or configuration issues, CDN edge behaviorDoes the delay occur before the application receives the request?
Wait / time to first byteOrigin server, application code, database, cache misses, upstream APIsIs the server slow to begin responding?
DownloadLarge payloads, compression, CDN delivery, last-mile conditionsIs the response too large or slow to transfer?
Page completionRender-blocking resources, third-party scripts, client-side work, dependent APIsIs the main document fast but the user journey still slow?

Compare each request against a baseline before you react. A 300-millisecond wait phase might be normal for one endpoint and a red flag for another.

The useful question is how far a stage drifted from its own history. Comparing the same HTTP transaction across regions and times of day exposes patterns a single snapshot hides.

A download problem looks different again. Say DNS, connection, and wait times are small, but the response still takes two seconds to arrive. The body is probably too large or poorly compressed, and turning on compression or resizing an image often removes that stage from the waterfall.

No single timing bar proves a root cause on its own. A long wait phase is evidence that narrows the search to the server side; it doesn’t name the exact query or line of code. Read timing as a signal that shows you where to look next.

Diagnosing a slow customer transaction

Consider a login page that loads quickly from North America but slowly from a test location in Frankfurt. The waterfall from Frankfurt shows normal DNS and a normal server response, but a connection phase that stretches to several seconds.

That pattern points toward connectivity, routing, a CDN edge, an ISP, or regional reachability, rather than an application change someone shipped that morning. Two colleagues in different regions would see two different waterfalls for the same page, which is why one internal view can mislead you. The fix, if there is one, likely lives with the network or CDN provider rather than the code repository.

A high wait time changes the conclusion. Say DNS and connection times look normal from all test locations, but wait time (TTFB) climbs to three seconds. The investigation then starts at the application, cache, database, or an upstream dependency.

A cache that stopped serving hits, or a slow database query, produces exactly this signature. That’s a cue to check recent deploys, cache hit ratios, and slow-query logs before touching the network.

The stage that’s slow decides where you begin. A prolonged connection phase sends you to the network and delivery path; a high TTFB sends you into the application stack. Chasing the wrong layer costs hours, and the waterfall is what keeps the investigation honest.

Timing across locations adds another clue. When one region is slow and the rest are healthy, the problem usually lives between the user and your edge. When a stage is slow from all locations at once, the cause is more likely a shared component such as the origin or the database.

Why external measurement matters for HTTP performance

Internal infrastructure health shows one layer of the picture. What an external user experiences also depends on DNS, a CDN, an ISP, the network path, a cloud provider, third-party APIs, and regional conditions. Most of those rarely appear on an internal server dashboard.

Digital experience monitoring shows the timing a real customer would see. It draws on two kinds of data that answer different questions.

Synthetic monitoring tests key user journeys from external locations on a schedule. It gives consistent, comparable timing for each HTTP transaction stage, even when no real user is active. Real user monitoring shows what actual users experienced across their real devices, browsers, networks, and regions.

Using both together gives a fuller picture. Synthetic tests deliver controlled, repeatable baselines and proactive detection, and real user data shows the timing users actually experienced.

LogicMonitor Digital Experience runs those synthetic tests from external locations, extending visibility across the Internet path, including DNS, CDN, network, and last-mile connectivity. Paired with website monitoring and internal infrastructure telemetry, teams can compare the external experience with the systems behind it.

Turn timing data into faster diagnosis

When an HTTP transaction is slow, work in the same order each time:

  1. Identify which stage is slow.
  2. Compare results across locations and time periods.
  3. Investigate the layer responsible for that stage.

That habit keeps you from restarting servers on a hunch or blaming code for a network problem. The waterfall shows whether to call the DNS provider, the network team, the application owner, or the CDN. It also gives you evidence to hand to a vendor when the slow stage is one you don’t operate yourself.

Start with your most important user flow, whether that’s a checkout, an API endpoint, or a login. Monitor it from the locations that matter to your users. Timing data turns “the site is slow” into a specific question your team can answer.

Pinpoint slow HTTP transactions across the full Internet path with LogicMonitor Digital Experience

LogicMonitor Digital Experience combines synthetic tests, real user data, and internet performance monitoring so your team sees every stage a customer experiences and fixes the right layer fast.

FAQs

What are the stages of an HTTP transaction?

An HTTP transaction moves through DNS resolution, connection and TLS setup, the request, server processing and first byte, the response download, and browser processing. Cached DNS and reused connections mean a given request can skip or overlap some of these stages. Naming each stage gives your team a shared checklist for finding where a page slowed down.

How do DNS time, connect time, and time to first byte differ?

DNS time measures how long it takes to resolve a hostname to an IP address. Connect time covers opening the connection, and for HTTPS the TLS negotiation; tools may report connection and TLS separately or together. Time to first byte measures the wait from request sent to the first response byte, which reflects server and application delay.

Is HTTP/3 always faster than HTTP/2?

Not necessarily. HTTP/3 still establishes a connection and negotiates TLS 1.3, and on a stable, low-loss network the difference can be small. It tends to help most on lossy or changing networks, such as mobile connections, where its handling of packet loss reduces stalls.

By Denton Chikura

Content Marketing Manager

Denton Chikura is a Content Marketing Manager for LogicMonitor Digital Experience, where he drives content on observability, Internet performance, and digital experience. He writes for SREs, IT operations teams, and business leaders, turning performance data into guidance they can act on.

Disclaimer: The views expressed on this blog are those of the author and do not necessarily reflect the views of LogicMonitor or its affiliates.

© LogicMonitor 2026 | All rights reserved. | All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.

Related Blogs

Optimizing Website Performance: Harnessing the Power of Image Lazy Loading
Blog Digital Experience

Optimizing Website Performance: Harnessing the Power of Image Lazy Loading

Image lazy loading can speed up your site, or slow it down. Learn how to apply it selectively, protect Core Web Vitals, and measure the real-world impact.
October 30, 2026
Learn more
Outage Retrospective: What a Google Cloud Incident Revealed About Hidden Service Dependencies
Blog Internet Performance Monitoring

Outage Retrospective: What a Google Cloud Incident Revealed About Hidden Service Dependencies

See how a Google Cloud outage took major brands like Home Depot offline, and why digital experience monitoring spots failures before status pages update.
October 30, 2026
Learn more
Outage Retrospective: How the Adobe Experience Cloud Outage Exposed Third-Party Blind Spots
Blog DevOps & CI/CD

Outage Retrospective: How the Adobe Experience Cloud Outage Exposed Third-Party Blind Spots

See how Internet-health signals, synthetic tests, and Real User Monitoring exposed third-party failures during the 2023 Adobe Experience Cloud outage, and how LogicMonitor Digital Experience connects those perspectives to help teams identify user impact and incident ownership.
October 30, 2026
Learn more