How the web works, in 5 minutes
A friendly plain-English story of what actually happens from the moment you type a web address to the moment the page appears on your screen.
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.
Four hops, all of them in milliseconds. The resolver is the one that remembers, which is why a record you changed this morning can still be invisible to some visitors this afternoon, until its TTL expires.
Read this as text
When somebody types your domain, their browser does not know where your site is. It asks a DNS resolver, run by their internet provider, or by a service like Cloudflare or Google.
If the resolver does not already know the answer, it asks your domain’s authoritative nameservers, which hold the official records for your domain. They reply with the IP address, for example 185.199.108.153.
The browser then connects straight to that address and your site loads. The nameservers are not involved again.
The resolver keeps that answer for a set period, the TTL. Until it expires, that resolver keeps handing out the old answer without asking your nameservers again, which is the whole reason a DNS change can take minutes for one person and hours for another.
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 filesThe instructions for how everything should look (colors, fonts, layout)
- JavaScript filesCode that will add interactivity
- ImagesThe photos and graphics
- FontsThe 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 pays a round-trip delay for every file, simply because the data has to cross the Pacific and back. 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.
Each of these sits at a different point on the same path, and a request travels only as far down as the first layer that already has what it is asking for. Not every site has all of them. You do not need to manage them, but it helps to know they exist.
Read this as text
Three of the types of caching described above sit at different points on one path: the path a request takes from a visitor down to the content your pages are built from. The fourth, object caching, is not on this path: it works inside the site’s own work, saving the results of database queries so they do not have to be repeated.
Closest to the visitor is the browser cache, which keeps images, stylesheets and fonts on the visitor’s own computer. Next is the CDN cache, which keeps copies of your pages and files in data centers around the world, so content comes from the server closest to the visitor. Then the server-side page cache (run by your host or platform, or a plugin), which saves a complete HTML copy of each page.
Only when none of those has a copy does the request reach your website’s software (WordPress, Shopify, Squarespace or whatever your site runs on), which looks the page up, fetches the content and assembles the HTML.
Not every site has all of these. There are several layers where caching can happen, and you do not need to manage all of them, but it helps to know they exist.
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 a couple of seconds. Google's own benchmark for a good experience is that a page's main content should appear within 2.5 seconds of the page starting to load. See Core Web Vitals explained.
Every click you make on the page triggers a smaller version of this same process.
The full journey at a glance
The relay race, summarized
- You enter a URL
- DNS translates the domain name to an IP address
- Your browser connects to the server at that IP
- HTTPS encryption is established
- Your browser requests the page
- The server generates and sends the HTML
- Your browser fetches CSS, images, and JavaScript
- The browser renders the visual page
- JavaScript runs to add interactivity
- You see the finished page
Step through one page visit
Press Start to follow a request from your address bar to the server and back.
Read this as text
- You enter a URL. You type chykalophia.com and press Enter. The browser needs an IP address, not a name.
- The browser asks DNS. “What is the IP address for chykalophia.com?” If the resolver looked it up recently, it answers from its cache.
- DNS answers with an IP address. Something like 104.21.55.32. This typically takes milliseconds.
- The browser connects to the server. A TCP handshake: a SYN, a SYN-ACK and an ACK.
- HTTPS encryption is set up. The two sides agree on a secret code so nobody can read what passes between them.
- The browser requests the page. “Please give me the page at / (the homepage).”
- The server sends back the HTML. A static site sends files directly. A dynamic site, like most WordPress sites, builds the page first, unless a cached copy is ready.
- The browser asks for CSS, images, fonts and JavaScript. Often several at once. With a CDN, some of these come from a server closer to you instead.
- The browser renders the page. It builds the page from the HTML and applies the CSS. You may see it appear in parts.
- JavaScript runs and the page is ready. Menus, forms and other interactive parts start working. Usually all within a couple of seconds.
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. How long it takes depends on the record's TTL: the length of time other servers were told to keep their copy. Registrars commonly tell you to allow 24 to 48 hours for a nameserver change. 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
Where does my website actually 'live'?
On a web server: a computer in a data center, connected to the internet 24/7. Your hosting provider manages that server. When someone visits your site, their browser connects to that server and requests your files.
What is a web server, exactly?
A web server is both hardware (the physical computer) and software (a program like Apache or Nginx) that listens for browser requests and sends back web pages. Your hosting plan provides access to web server software running on a physical machine.
Why do some websites load instantly and others take forever?
Speed depends on: how fast the server is, how large the files are, how many files the browser needs to request, whether a CDN is used, and the visitor's own internet speed. See What slows websites down.
Does everything I type into a website get sent to the server?
Yes, form inputs, login details, search queries all get sent to the server as HTTP requests. HTTPS encrypts this data so nobody can intercept it in transit. This is why using HTTPS is essential for any site with forms or logins.
Related guides
Learn more
Was this page helpful?
Go deeper on chykalophia.com
Done for you
Rather not do this yourself?
This is everyday work for our team. Book a free discovery call and we'll tell you honestly whether it's worth paying someone for.
Already a client? Email support@chykalophia.com.
Last updated