How do websites work? Follow one click end to end

Websites work by sending a request and getting a response. Your browser turns a web address into a server address, asks that server for a file, and the server sends back text that your browser turns into a page. Everything else you have heard about web development is detail hanging off that one exchange.

Most explanations of how websites work start with job titles. Frontend does the visuals, backend does the data, and you are supposed to pick one. That skips the interesting part. So instead of comparing roles, this post follows a single click all the way through, and by the end you will know which piece of code lives where and what to blame when a page breaks.

The short version, in six steps:

1. You type an address and press enter.
2. Your browser looks up which computer that name belongs to (DNS).
3. Your browser opens a connection to that computer and asks for a page (HTTP).
4. A server decides what to send back, sometimes after asking a database.
5. Your browser reads the HTML, fetches the CSS and images it mentions, and draws the page.
6. JavaScript runs and makes the page react to you.

Step 1: a name becomes an address

devpuff.com is for humans. Computers on the internet find each other with IP addresses, which look like 104.18.32.7. So the first thing your browser does is ask "what address is this name?"

That question goes to the Domain Name System, usually shortened to DNS. Think of it as the internet's contacts app. Your browser asks a DNS resolver, the resolver asks around, and an address comes back. MDN's DNS overview is the short version if you want the mechanics.

Two things worth knowing now:

• Answers get cached. Your browser, your operating system, and your internet provider all remember recent lookups, which is why the second visit to a site feels faster.
• DNS is why a new site takes a while to "go live". You bought the domain instantly, but the answer has to spread.

Step 2: your browser opens a connection

Now your browser knows where to send its question. It opens a connection to that address, and for any site with https:// in front of it, that connection gets encrypted first.

The encryption step is why the padlock icon exists. It does not mean the site is trustworthy or well built. It means nobody sitting between you and the server can read what you send, which matters a great deal the moment you type a password.

Step 3: the request

Over that connection, your browser sends a short message. Stripped down, it looks like this:

GET /blog HTTP/1.1
Host: www.devpuff.com
Accept: text/html
User-Agent: Mozilla/5.0 ...

Four things are going on:

• GET is the method. It means "give me something". Submitting a form usually sends POST instead, which means "here is some data, do something with it".
• /blog is the path, the specific thing you want.
• Host says which site you meant, because one server often hosts many.
• The rest are headers, extra facts about your request.

That is the whole shape of it. Every API you will ever call is this same message with a different path.

Step 4: a server decides what to send back

A web server is just a program that listens for those messages and answers them. It is running on a computer that stays on, which is the only real difference between it and your laptop.

What happens next splits into two cases.

The simple case: a file that already exists

If you ask for a logo, the server finds logo.png on disk and sends it. Nothing is computed. This is how images, stylesheets, and simple sites work, and it is fast because there is no thinking involved.

The interesting case: a page that gets built

Ask for your dashboard and there is no dashboard.html sitting on disk, because your dashboard is not the same as anyone else's. So the server runs code. That code checks who you are, asks a database for your data, drops the results into a template, and sends the finished HTML.

The database is worth pausing on, because it is where almost all the real information lives. It answers questions written in SQL, and the answers come back as rows:

SELECT title, streak FROM users WHERE id = 42;

If that syntax is new, SQL Joins Explained is the next thing to read, since joining tables is where queries stop being obvious.

Either way, the server sends back a response with a status code on the front:

Learning to read that number saves you hours. A 404 and a 500 look identical to a user and mean completely different things to whoever has to fix it.

Step 5: the browser builds the page

Your browser now has a wall of text. Turning it into a page happens in a specific order, and that order explains a lot of everyday weirdness.

First it reads the HTML and builds a tree of elements called the DOM. A heading contains text, a section contains the heading, the body contains the section. The DOM is that nesting, held in memory.

While reading, it finds references to other files: a stylesheet, some images, a script. It requests each one. That is why one page view is rarely one request. It is normally dozens.

Then it applies the CSS, working out the final colour, size, and position of every element. Then it lays everything out, then it paints.

This ordering is why a page sometimes flashes unstyled for a moment before snapping into place. You saw the HTML land before the CSS did.

If you have wondered why a box refuses to sit in the middle of its container, that is a layout-stage question, and How to Center a Div walks through every method that works.

Step 6: JavaScript takes over

HTML and CSS give you a page. JavaScript gives you a page that responds.

It runs in the browser, it can reach into the DOM and change it, and it can send more requests without reloading anything. That last part is the whole trick behind modern web apps: you click "like", JavaScript quietly posts to the server, the count goes up, the page never blinks.

const res = await fetch("/api/streak");
const data = await res.json();
document.querySelector("#streak").textContent = data.days;

Three lines, and you have just done steps 3 through 6 again, by hand, from inside the page.

So what are frontend and backend?

Now the job titles mean something.

That last row is the one people underestimate. Anything running on your device can be changed by whoever is holding the device, which is why "we check the password in JavaScript" is not a security measure. The backend exists partly because someone has to be in charge, and it cannot be the visitor.

Full stack just means someone comfortable on both sides.

Where to look when something breaks

Because you now know the order, you can bisect a problem instead of guessing:

• Page will not load at all, no error page. DNS or the connection. Step 1 or 2.
• You get a page, but it says 404 or 500. The request arrived. Step 4, the server side.
• Content is right, page looks wrong. The CSS did not arrive or did not apply. Step 5.
• Page looks right, buttons do nothing. JavaScript failed. Open the console and read the red text. Step 6.

That fourth one is where beginners lose the most time, and the message is nearly always about a value you expected to be there and was not. Reading it beats guessing, every time.

See it for yourself in two minutes

Reading about this is fine. Watching it is better.

1. Open any website.
2. Press F12 to open developer tools, or right-click and choose Inspect.
3. Click the Network tab.
4. Reload the page.

You are now looking at every request the page made, in order, with the status code and size of each. The first row is the HTML. Everything under it is what the HTML asked for. Click any row to see the exact headers from step 3.

That list is not a simplified teaching model. It is the real thing, and every professional web developer stares at that panel most days.

What to learn first

The order that matches how the page is built is also the order that keeps you motivated, because each step is visible immediately:

1. HTML gives you structure and a page that exists.
2. CSS makes it look like something you would show a friend.
3. JavaScript makes it do things.
4. A backend language and SQL let you store data that outlives a refresh.

You do not need all four to build something real. Plenty of useful sites are steps one and two only.

Two things sit alongside that list rather than inside it. Version control is worth picking up early, because the first time you break something badly you will want a way to undo the last commit rather than a folder called project-final-v2. And the language you start with matters less than people argue about: if Python is where you are starting, looping with an index in Python is the same idea as everything above, in different syntax.

Start where the page starts. HTML Basics has you writing real markup in the browser from the first lesson, with no editor to install and no setup to get wrong, and the HTML guide shows where it leads next.

Then come back to the Network tab. It reads very differently once you have written the thing on the other end.