Follow one page visit from the address bar to the pixels on your screen.
Tutorials in Web Development come first when available.
Press Enter on devloom.dev.
Less than a second later, you are looking at a page with words, images, colours, and buttons. It can feel like your browser already knew where Devloom was and what to show you.
It did not. Your browser started a short conversation with another computer. It found that computer, asked for a page, received instructions, and drew those instructions on your screen.
That is the web. Not one giant mysterious thing. A small sequence of jobs, done in order.
For this tutorial, imagine you visit:
https://devloom.dev/tutorials/how-the-web-works
That address already gives your browser three useful instructions:
https:// says, "Use a protected conversation."devloom.dev says, "Find this website."/tutorials/how-the-web-works says, "Ask for this particular page."The first part tells the browser how to talk. The middle part names the destination. The last part, called the path, identifies what you want from that destination. Think of it as a building name and a room number in the same address.
Your browser has five jobs:
You type an address
↓
Find where that address lives
↓
Open a protected conversation
↓
Ask for one page
↓
Receive instructions and draw the screen
Keep that picture in your head. Every detail you meet later belongs to one of these jobs.
Here is a quick prediction. If you type an address that does not belong to any website, can the website's application code run?
No. Your browser first has to find a destination. If it cannot find one, there is nobody to ask for a page. This seems obvious once you see the journey as a sequence. It is also the first useful clue when a site does not load.
You remember a friend by their name. Your phone uses their phone number to call them. Website names work in the same way.
devloom.dev is a name people can remember. Computers send information to a numbered network address called an IP address. One format looks like this:
76.76.21.21
Your browser needs the number before it can send a request. It asks a directory service called DNS, short for Domain Name System.
devloom.dev
│
│ "Where should I send this?"
▼
DNS
│
│ "Use this network address."
▼
The computer serving Devloom
DNS does not fetch the page. It only helps your browser find the right destination. That distinction matters.
Try this on your own machine if you have a terminal:
nslookup devloom.dev
You will see an address returned for the domain. The exact address can change over time. That is normal. A site may move between machines without asking everyone to learn a new number. The name stays the same, and DNS points visitors to the current place.
When a developer says, "DNS is broken," they mean this first job failed. The browser could not turn a name into somewhere to go.
Once your browser knows where to go, it opens a connection to that computer. The https at the beginning of the address means the connection is protected.
Browser ⇄ protected connection ⇄ Devloom's server
The browser checks that the server is allowed to use the name devloom.dev. Then the browser and server agree on a way to scramble their messages. Someone watching the Wi-Fi connection cannot read your password, change a response on the way, or pretend to be Devloom.
Engineers call this protection HTTPS. The security protocol underneath it is called TLS. You do not need to memorise those names yet. Remember the job: before private information moves, the browser makes sure it is talking to the intended website through a protected connection.
There is one important limit. A padlock means the trip is protected. It does not mean the owner of a website is kind, accurate, or safe to trust with your money. A scam website can also use HTTPS. The padlock protects the conversation, not the character of the person running the site.
Now your browser can ask for the page.
The request is much simpler than its name makes it sound. It is a structured message that says which page the browser wants. This is a simplified version:
GET /tutorials/how-the-web-works HTTP/1.1
Host: devloom.dev
Read it like a short note:
GET means "please send me this."/tutorials/how-the-web-works identifies the page.Host: devloom.dev identifies the website.This language is called HTTP. In plain words, it is the request-and-reply format used by browsers and servers.
The server receives the request, works out what it needs to do, and sends a response back. A response might begin like this:
HTTP/1.1 200 OK
Content-Type: text/html
<html>...</html>
200 OK means the request worked. text/html tells the browser that the response contains a web page. The rest of the response contains the page instructions.
Sometimes the server can reply immediately because the requested file already exists. An image, a stylesheet, or a simple HTML page can be ready to send. Other requests need the server to do work first.
Imagine you open your Devloom profile. The server may need to check who you are, fetch your profile details from a database, decide which page you are allowed to see, and then create the response. The browser still sees the same basic shape:
Browser asks for /profile
↓
Server runs the application's code
↓
Application may read data from a database
↓
Server sends a response back
This is why a slow database can make a page feel slow. The browser is waiting for the server to finish its work before it can receive an answer. It is also why a website can return an error even when your internet connection is perfectly fine. Your message arrived. Something inside the application failed while preparing the reply.
Here is another prediction. You ask for /tutorials/not-a-real-page. The server is working, but that page does not exist. Should you expect a 200 or a 404?
You should expect 404 Not Found. The journey reached the website successfully. The problem is only that the requested page is missing. A 404 is different from a broken internet connection, because it proves the earlier parts of the journey already worked.
The server does not send a finished picture of the page to your browser. It sends files that tell the browser what to build.
Three kinds of instructions appear again and again:
HTML what exists on the page
CSS how it should look
JavaScript how it should behave
HTML might say, "there is a heading, a paragraph, and a button." CSS decides the font, spacing, colour, and layout. JavaScript can make the button respond when you click it.
The first response often tells the browser to fetch more files. A normal page visit can look like this:
1. Ask for the page HTML
2. Read the HTML
3. Ask for a stylesheet, images, and JavaScript
4. Put the pieces together
5. Draw the page you can use
That is why a website can partly appear and then become more complete a moment later. Your browser is still receiving and assembling the pieces.
The browser can request several of these extra files at the same time. This is useful because waiting for one image, then one stylesheet, then one font would make every page feel much slower. But the page still has an order: it cannot show a heading until it has received enough HTML to know that the heading exists, and it cannot show the final design until it has the styles that describe it.
If you ever see a page load with plain-looking text for a moment and then snap into its intended design, you are seeing that assembly process. The content arrived before every visual instruction was ready.
At this point, you have the full useful model:
Name → DNS finds the destination
Protection→ HTTPS protects the conversation
Question → HTTP asks for a page or data
Reply → the server sends files or an error
Screen → the browser turns those files into pixels
You can see a real version of this without writing any code.
Open Devloom in Chrome, then open Developer Tools:
Command + Option + IF12Choose the Network tab. Reload the page. You will see a list of requests appear.
Click the first request, usually the document. Look for only three things:
Request URL Which address did the browser ask for?
Request Method Was it GET?
Status Code Did the server reply with 200, 404, or something else?
Then look at the requests below it. You should recognise why they exist. They are the CSS, JavaScript, images, and fonts the browser needed after it received the main page.
Do not try to understand every row. Your first win is seeing that the diagram above is real. A browser is not guessing. It is making visible requests, receiving visible responses, and following a clear order.
This model changes how you debug.
If a page shows 404, the browser reached the website and received an answer. You should inspect the URL or route, not your Wi-Fi.
If the browser says it cannot find the site, start with the name and DNS. There may be no destination yet.
If the page appears but a button does nothing, the page instructions arrived and were drawn. The problem is more likely in the JavaScript behaviour than in DNS.
You do not need to guess at every layer at once. Ask one calm question: what is the last part of the journey that definitely worked? That answer narrows the next place to look.
The next time you press Enter, picture two computers having this conversation. Your browser finds a destination, protects the trip, asks for instructions, receives a reply, and turns that reply into the page in front of you. You are no longer looking at an instant miracle. You are looking at a system you can follow.