How Do Websites Work

What happens between typing a URL and seeing a page

A website is a set of 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 sends back HTML, CSS, JavaScript and images, and the browser draws the page. Nothing is stored on your phone; each visit is a fresh request.

• The browser — the client. It asks, then renders what comes back.
• DNS — the address book that maps a name like example.com to a number such as 203.0.113.10.
• The server — a computer that stays online and answers requests for that address.
• HTTP or HTTPS — the language of the request and the reply. HTTPS is the same language inside an encrypted tunnel.

Four steps happen in well under a second on a good connection. Each one is a place where a site can be slow, and knowing which step failed is most of the work of fixing it.

Step 1: the domain name becomes an IP address

Computers route by number, people remember words, so something has to translate. Your browser asks a DNS resolver, usually run by your broadband provider or a public service, which walks from the root servers down to the nameservers that hold your zone file.

The zone file holds records. An A record points a name at an IPv4 address, AAAA at IPv6, CNAME points one name at another, and MX says where mail goes. If the answer is cached, the lookup takes milliseconds; if not, it may take a tenth of a second or more. The DNS records guide covers each type.

This is why a new domain can look broken for a few hours. The files may be in place while resolvers still hold the old answer until the record's TTL expires.

Step 2: the browser asks the server for a page

With an address in hand, the browser opens a connection: TCP on port 80 for HTTP, or port 443 for HTTPS. An HTTPS connection adds a TLS handshake first, where the server proves it holds a certificate for that domain and both sides agree on keys. After that, everything is encrypted, including the page you asked for.

The request is a short text message: a method such as GET, a path such as /about/, a host name, and headers that say what the browser accepts. The reply starts with a status code.

On port 443 the certificate is what puts the padlock in the address bar. A paid certificate and a free one do the same job for a browser; the difference is the warranty and the company name on it.

Step 3: the server decides what to send back

A static site is simple: the web server reads the file that matches the path and sends it. A brochure site of ten pages can run this way for years with no database at all.

A dynamic site is a program. WordPress, for example, receives the request, starts PHP, connects to a MySQL database, assembles the page from posts and settings, and only then returns HTML. That work is what makes a dynamic page slower than a static one, and why caching exists: the finished HTML is stored and reused for the next visitor.

Hosting quality shows up here. A shared plan with little CPU spends longer in PHP and the database, so the first byte of the page arrives late even when the network is fast.

Step 4: the browser builds the page you see

The reply is not a picture. It is HTML with links to other files: stylesheets, scripts, fonts and images. The browser parses the HTML into a tree, applies the CSS, runs the JavaScript, and paints the result. Each extra file is another request, which is why one heavy script can delay a page that arrived quickly.

Three practical consequences follow. Images should be compressed and sized, because a 4 MB photo costs the same as a page of text plus a wait. CSS and JavaScript should be few and deferred where possible. And a page can be fully downloaded 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 with the status code and the server log.

Where a CDN changes that journey

A content delivery network keeps copies of your files on servers in many cities. When a reader in Delhi asks for an image that is already cached at a Delhi edge, the reply comes from there instead of your origin server, so the distance shrinks and the origin does less work.

• Cache hit — the edge answers immediately. Fast, cheap, and your server never sees the request.
• Cache miss — the edge fetches from your server once, then keeps a copy until the cache header expires.
• What it does not fix — a slow database query or a plugin that takes two seconds to run. The first visitor still waits.

A CDN is worth it when readers are spread across countries or when images dominate the page weight. For a five-page site with Indian visitors and a server in Mumbai, it is optional.

What this means when you choose hosting

Now the marketing claims can be read properly. Disk space is where files sit. Bandwidth is how much data leaves. CPU and memory decide how fast PHP and the database answer, which is the part a visitor feels.

Location decides the round trip. A server in India answers an Indian reader in a few tens of milliseconds; one in the United States adds a few hundred. Uptime is whether the answer arrives at all.

Our shared hosting plans in India cover a brochure site or a blog from ₹300 a month before 18% GST, and the hosting FAQ answers the plan questions that follow. A VPS is the next step when PHP, not disk, is the limit.