How the web works, in 5 minutes

You type an address. A page appears. It feels instant. But behind those few seconds, an intricate relay race happens across the globe. This is the story of that race.

Chapter 1: You type an address

Imagine you want to visit chykalophia.com. You type it into your browser — Chrome, Safari, Firefox, whatever you use — and press Enter.

Your browser now faces its first problem: it doesn't know where chykalophia.com lives. The internet doesn't run on names. It runs on numbers called IP addresses — things like 104.21.55.32. Your browser needs to find the IP address that corresponds to this name.

Chapter 2: The address book of the internet (DNS)

Your browser turns to the Domain Name System (DNS) — the internet's address book. DNS is a global network of servers that store these name-to-number translations.

Your browser asks your DNS resolver (usually provided by your internet service provider, or by a service like Cloudflare's 1.1.1.1):

"What is the IP address for chykalophia.com?"

The DNS resolver checks its memory. If it recently looked this up, it answers instantly from its cache. If not, it asks a series of DNS servers — root servers, then top-level domain servers, then the authoritative nameserver for chykalophia.com — until it gets an answer.

The whole process typically takes milliseconds.

The DNS resolver returns an IP address. Your browser now knows exactly where to go.

Chapter 3: Knocking on the door (TCP/IP)

Now your browser needs to connect to the server at that IP address. It does this using TCP/IP — the fundamental communication protocols of the internet.

Think of it like establishing a phone call. Your browser and the server exchange a short handshake to confirm they can hear each other. This is called a TCP three-way handshake (a SYN, a SYN-ACK, and an ACK, if you want to impress someone at a party).

Once connected, your browser is ready to make its request.

Chapter 4: Asking for the page (HTTP/HTTPS)

Your browser sends the server an HTTP request — essentially a formal note that says:

"Please give me the page at / (the homepage)."

If the site uses HTTPS (which all modern sites should), there's an extra step first: establishing an SSL/TLS encrypted connection. Think of it as agreeing on a secret code before the conversation starts — so nobody can eavesdrop on what passes between your browser and the server.

The encryption happens automatically. You see a padlock icon in the browser bar. You never have to think about it.

Chapter 5: The server does its work

The web server receives your request. What happens next depends on the type of site.

For a static site (pure HTML, CSS, JavaScript), the server just sends the files directly. Simple and fast.

For a dynamic site — like most WordPress sites — there's more to do. The server runs PHP code, which queries the database for the page content, assembles the HTML, and sends it back. This process can be made much faster with caching — storing a pre-built copy of the page so the server doesn't have to rebuild it from scratch every time someone asks for it.

The server sends back a response — the HTML document for the page.

Chapter 6: Your browser builds the page

Your browser receives the HTML. It starts reading through it, and discovers references to other files it needs:

• CSS files — the instructions for how everything should look (colors, fonts, layout)
• JavaScript files — code that will add interactivity
• Images — the photos and graphics
• Fonts — the typefaces used in the design

Your browser sends new requests for each of these files, often in parallel. This is why page speed matters so much — every extra file, every large image, every slow script adds time before the visitor sees a complete page.

As the browser receives files, it begins rendering — building the visual page from the HTML structure and applying the CSS styles. You might see the page appear partially, then fully, as everything loads.

Chapter 7: JavaScript runs

Once the core page is rendered, the browser runs any JavaScript. This is the layer that makes pages interactive: menus that open and close, forms that validate your input before submission, images that load as you scroll, pop-ups that appear.

JavaScript can also fetch more data after the initial load — this is how social media feeds, live stock tickers, and chat widgets work. The page loads, and then JavaScript quietly fetches fresh content in the background.

Chapter 8: A CDN makes it faster

If the site uses a Content Delivery Network (CDN), some of the files — particularly images, CSS, and JavaScript — might not come from the main server at all. Instead, they come from a CDN server that's geographically closer to you.

A user in Tokyo visiting a site whose server is in New York would normally experience a round-trip delay of hundreds of milliseconds. A CDN stores copies of static files on servers around the world, so the Tokyo user gets them from a server in Tokyo instead. Much faster.

Chapter 9: The page is ready

The browser finishes loading and rendering. The page appears fully in front of you.

All of this — the DNS lookup, the TCP handshake, the HTTPS encryption, the server generating the page, the browser downloading and rendering dozens of files — typically happens in under two seconds. Under one second for a well-optimized site.

Every click you make on the page triggers a smaller version of this same process.

The full journey at a glance

Why this matters for your website

Understanding this process helps explain a few things you'll encounter as a website owner.

Why DNS changes take time: When you update a DNS record (like pointing your domain to a new host), every DNS resolver around the world needs to refresh its cache. This is called DNS propagation. It can take anywhere from a few minutes to 48 hours. See DNS propagation: why changes take time.

Why page speed matters: Every step in the chain above takes time. Slow servers, uncompressed images, too many JavaScript files — each one adds milliseconds. Those milliseconds add up, and visitors leave slow sites. See Why website speed matters.

Why HTTPS matters: Without the SSL/TLS encryption layer, anyone on the same network could read the data passing between your visitors and your site — including form submissions and login details. See What is SSL & HTTPS?.

Why caching speeds things up: If your server can send a pre-built copy of a page instead of generating it fresh every time, pages load much faster. Managed WordPress hosts like Flywheel, WP Engine, and Kinsta all include caching. See Caching explained.

Common questions

Related guides

• Web basics: terms A–Z
• The web acronyms cheat sheet
• What is DNS?
• What is SSL & HTTPS?
• Why website speed matters
• What is a CDN?

Learn more

• How the Internet works — Mozilla MDN
• HTTP overview — Mozilla MDN