How a website actually works

You type the address and hit enter; what happens next?

It is a round trip, not a live broadcast. Your browser sends a request, another computer answers, and the connection ends there. Every image, every CSS file and every font the page needs has its own separate request, so a simple looking page usually has dozens of round trips behind it.

The order is fixed. First the domain name has to be translated into a numeric address. Then an encrypted connection opens between the browser and that address, which is what the padlock beside the address bar is showing you. Then the browser says which page it wants. And the other side hands back a block of text.

What comes back is not a picture of the page, it is text. That same text becomes one shape on a phone and a different one on a monitor, and for someone using a screen reader it has no shape at all and is read aloud. The difference looks small and it explains the whole job of web design: you do not send the final look, you send the instructions for building it.

If you want to see it right now, right click on any site and choose view source. What opens is exactly the text your browser received.

The domain is a name and the IP is an address; who translates?

Computers do not work with names, they work with numbers. DNS is the phone book of the internet: you ask where rgb.ir is and you get back a numeric address. That question and answer takes a few hundredths of a second, and the answer is then stored for a while on your own machine and on the servers along the way, which is the main reason for that familiar sentence: it opens for me but not for you.

You can watch the translation yourself. In a Linux or Mac terminal:

dig +short A rgb.ir
dig +short NS rgb.ir

The first command gives the numeric address and the second says who is responsible for answering questions about that domain. On Windows the same job is done by nslookup rgb.ir.

One thing that confuses beginners: the address that comes back is not necessarily the address of the real server. Many sites sit behind a content delivery network, so what DNS hands you is the nearest station of that network and the real server stays one layer further back. Our own site is exactly like that, and the numbers are in the section on what we did ourselves.

Do not confuse the domain with the hosting either: the domain is only a name and it is rented yearly, while hosting is where the files live. If that split is still fuzzy, the explanation of domains starts right there.

What is sitting at the other end of the line?

A computer that never gets switched off. What separates a server from your laptop is not the kind of parts inside it; it is that the machine is always on, sits on a fast connection and runs software that waits for requests.

Three things usually work side by side on it. First the web server, a program such as nginx or Apache that takes the request and hands back the answer. Second the site application, which may be PHP or any other language, whose job is producing HTML. Third the database, where the text of posts, the users and the orders are kept.

A simple page that is only a few lines of text can work without the last two. But the moment the site wants to receive a form, have users, or let content change from an admin panel, the application and the database come into play. WordPress is exactly that: a PHP application that reads content from a database and builds HTML out of it.

When you read about shared hosting, a virtual server or a dedicated server, the argument is about this same computer: how many sites sit on one machine and how its resources are divided. We have that on the hosting page with prices and specifications, though you do not need to decide anything now to follow this lesson.

Why are some pages ready and others built on every visit?

There are two models and both are correct. In the first, the HTML file is already sitting on the server and the web server simply hands it over: fast, cheap, no drama. In the second, the page is built at that moment: the application runs, asks the database, produces HTML and sends it. WordPress, online shops and anything that answers differently per user belong here.

The second model buys flexibility and it costs. Each visit means a handful of database queries and a few hundred milliseconds of processor work. The old and simple answer is the cache: the result is built once, stored as a ready file, and the next visitor gets that file. In other words, the dynamic site is temporarily turned into a static one.

That is what answers the perennial question: why is the change I made in the panel not showing on the site? Because the visitor is still being handed the previously stored copy. Until that copy is cleared or expires, your change is visible only to you, because you are logged in.

And there is one more layer above all of this: a content delivery network keeps a copy of the page near the user, so sometimes the request never reaches your server at all. For whoever builds the site that is good news, right up until the day they need to work out why the old version is still on screen.

Where does this chain break, and which piece do you see?

The good news is that the error message usually names the link that broke; you only have to know how to read it.

If the browser says the site cannot be found or the server name was not resolved, the request never reached your server and the problem is in name translation: a wrong DNS record or an expired domain. If you see a security warning, translation worked and the connection opened, but the SSL certificate is broken or expired. If you get a blank page or a 500 error, the request arrived and the site application failed midway; here you read the server error log, not the browser. And if everything opens but the content is old, nothing is broken at all: the cache is handing over the previous copy.

There is another category that is not a failure and looks like one: the site opens, but slowly. There the chain has not broken, one of its links is simply taking its time, and tracking that down is a separate job which the site speed path takes on.

One habit makes all of this easier: before guessing, look at the response headers. A short command tells you where the answer came from, which code it carried and whether a cache was involved:

curl -I https://example.com/

That single line separates the site is down from the site is fine and the cache is serving yesterday copy.