How Do Websites Work
A website is files on a server that a browser asks for by IP address. DNS turns the domain into that address, HTTPS carries the request, the server answers with HTML, CSS and images, and the browser draws the page. Nothing is stored on your phone; every visit is a fresh request.
A plain-language walkthrough of the DNS-to-render pipeline, for site owners who want to know which step is slow.
knowledge
- Read time
- 5 min
- Sections
- 7
- Updated
- 14 Nov 2026
- Written by
- WebJi® team
Last editorial update: 15 November 2026.
What happens between typing a URL and seeing a page?
Four things happen in well under a second: DNS turns the domain into an IP address, the browser opens a connection and asks for the page, the server decides what to send, and the browser draws the result from HTML, CSS and JavaScript. Nothing is "opened" from a shelf on your phone — every visit is a fresh request, and each step in the chain is a place a site can be slow or break.
- The browser (client): it asks, then renders whatever comes back.
- DNS: the internet's address book, mapping a name like example.com to a number like 203.0.113.10.
- The server: a computer that stays online in a data centre and answers requests for that address.
- HTTP/HTTPS: the request-and-reply language; HTTPS is the same language inside an encrypted tunnel on port 443.
Knowing which of the four steps failed is most of the work of fixing a broken site — that is why this guide walks them one at a time.
Step 1: how does a domain name become an IP address?
Computers route traffic by number and people remember words, so the browser first asks a DNS resolver — run by your broadband provider or a public service — to translate the domain into an IP address. The resolver walks from the root servers down to the nameservers that hold your domain's zone file, unless it already has a cached answer, in which case the lookup takes milliseconds.
The zone file is where the records live: an A record points a name at an IPv4 address, AAAA at IPv6, a CNAME points one name at another, and MX says where mail for the domain goes — the DNS records guide covers each type. The cache is also why a brand-new domain can look broken for a few hours: the files may already be perfect while resolvers keep handing out the old answer until the record's TTL expires.
Step 2: how does the browser ask the server for a page?
With an address in hand, the browser opens a TCP connection — port 80 for plain HTTP, port 443 for HTTPS — and for HTTPS a TLS handshake runs first, in which the server proves it holds a certificate for that domain and both sides agree on encryption keys. The request itself is a short text message: a method like GET, a path like /about/, the host name, and headers saying what the browser accepts. The reply begins with a status code.
| Status | What it means for the visitor |
|---|---|
| 200 | Found and sent — the page is coming. |
| 301 / 302 | The page moved; the browser follows the new address. |
| 401 / 403 | The server refused — a password or permission problem. |
| 404 | No file at that path — a broken link or a deleted page. |
| 500 | The server started the work and failed; the error log names why. |
That certificate on port 443 is what puts the padlock in the address bar. A free certificate and a paid SSL certificate do the same job in the browser; the difference is the warranty and the organisation name printed on it.
Step 3: what does the server decide to send back?
On a static site the web server simply reads the file matching the path and sends it; on a dynamic site the server runs a program to build the page first. A ten-page brochure site of plain HTML files can run the static way for years without a database. WordPress is the other kind: each request starts PHP, queries MySQL, assembles the page from posts and settings, and only then returns HTML.
That program work is why a dynamic page is slower than a static one, and why caching exists — the finished HTML is stored and reused for the next visitor. Hosting quality shows up exactly here: a starved shared plan spends longer inside PHP and the database, so even the first byte of the page arrives late on a fast network.
Step 4: how does the browser build the page you see?
The reply is not a picture — it is HTML with links to further files, and the browser parses that HTML into a tree, applies the CSS, runs the JavaScript, and paints the result. Every stylesheet, script, font and image is another request, which is why a single heavy script can delay a page that arrived quickly.
Three practical consequences follow. Compress and size images, because a 4 MB photo costs the visitor a wait that a page of text never does. Keep CSS and JavaScript few, and defer what can be deferred. And remember that a page can finish downloading yet still look wrong while a font or script is pending — when a page renders but a button does nothing, the fault is JavaScript, not hosting; when nothing renders at all, start from the status code and the server log.
Where does a CDN change that journey?
A content delivery network keeps copies of your static files on servers in many cities, so a reader in Delhi is answered from a Delhi edge instead of your origin server — less distance, and less work for the origin. The mechanics are simple from the outside:
- Cache hit: the edge answers immediately; your server never sees the request.
- Cache miss: the edge fetches from your origin once, then keeps a copy until the cache header expires.
- What it does not fix: a slow database query or a plugin that runs two seconds — the first visitor still waits, because only the finished output is cached.
A CDN earns its keep when readers are spread across countries or images dominate the page weight. For a five-page site with Indian readers and a nearby server it is optional, not mandatory. The mechanics of trimming the files themselves are in the CSS/JS minification guide.
What does this pipeline mean when you choose hosting?
Read the marketing words against the pipeline: disk is where files sit, bandwidth is how much data leaves, and CPU plus memory decide how fast PHP and the database answer — which is the part a visitor actually feels. Location sets the round trip: a server in India answers an Indian reader in tens of milliseconds, one in the United States adds hundreds. Uptime is simply whether the answer arrives at all.
For a brochure site or a blog, shared hosting in India starts at ₹299 a month — WebJi® Linux shared Launch, read from billing on 15 November 2026, before 18% GST — and the hosting FAQ answers the plan questions that follow. When PHP, not disk, becomes the limit, the next step is a VPS.
Frequently asked questions
How does a website actually work, in one sentence?
A website is files on a server that stays online; your browser resolves the domain to an IP address, asks that server for the page over HTTP or HTTPS, and renders the HTML, CSS, JavaScript and images that come back. Every visit repeats the whole request — nothing is stored on the visitor's device.
What is DNS in simple words?
DNS is the internet's address book. It maps a name people remember, like example.com, to the numeric address a computer needs, like 203.0.113.10. Your resolver caches the answer, so repeat visits skip the full lookup; a wrong or stale entry is why a moved site can look broken until the TTL expires.
Do websites need a server to work?
Yes. Even a site built on a website builder lives on that company's servers. The only variations are who runs the server and how the page is produced — read from a file for a static site, or assembled by a program and database for a dynamic one. Something must always answer the request.
What is the difference between a browser and a server?
The browser is the client on your device: it sends requests and draws the pages that come back. The server is the machine in a data centre that holds the files (or runs the program) and answers requests, usually for many sites at once. Neither can do the other's job.
What do HTTP and HTTPS mean?
HTTP is the request-and-reply language the browser and server speak. HTTPS is the same language inside a TLS tunnel on port 443, so the page and anything typed into forms cannot be read in transit. The padlock in the address bar means the certificate for that domain checked out.
Last editorial update: 15 November 2026. Prices follow the dated sources on this page; checkout confirms current charges.
Ready to get started with WebJi®?
Join 12,000+ businesses across India and overseas. INR pricing, 18% GST shown before payment and 24/7 email support in Hindi and English — average first reply under 60 minutes.