Skip to content
DevelopmentBeginner8 min read

How Websites Work

What actually happens between typing an address and seeing a page, DNS, servers, HTML, and the round trip in between.

Written by Daksh BathlaFounder, Technology, Product & Business
Published 27 May 2026 · Updated 1 August 2026

WHAT YOU’LL LEARN

  • Trace a page load from address bar to rendered screen
  • Explain DNS, hosting, and HTTP in plain language
  • Know which part is failing when a site is slow or broken
  • Read a URL and understand every piece of it

PART OF A PATH

Start a Business

By the end you can explain what you're building, who it's for, why they'd pay, and how they'll find it.

The whole trip, in six steps

A website is a conversation between two computers. Yours asks for a document; another one sends it. Everything else is detail on top of that exchange.

  1. You type an addressnavitallabs.com is a name for humans. Computers route by numbers, so the name has to be translated first.
  2. DNS translates the name to a numberYour browser asks the Domain Name System for the IP address behind that name, the internet's phone book. The answer is cached, which is why the second visit starts faster.
  3. Your browser opens a connectionIt connects to that address and, on HTTPS, negotiates encryption so nobody between you and the server can read what follows.
  4. It sends an HTTP requestA short text message: the method (GET), the path (/learning), and headers describing what your browser accepts.
  5. The server respondsA status code (200 for fine, 404 for not found, 500 for the server broke) plus the HTML document.
  6. The browser builds the pageIt reads the HTML, discovers it needs CSS, images, and JavaScript, requests each of those, and assembles the result on screen.

Reading a URL

url-anatomy.txt
https://learning.navitallabs.com/lessons/what-is-an-api?ref=nav#steps\___/   \______/\____________/\_____________________/\_____/\____/  |         |          |                |                |     |scheme  subdomain    domain           path            query  fragment
  • Scheme, https means encrypted. Plain http is readable by anything on the path between you and the server
  • Subdomain, a label in front of the domain, often pointed at a different service entirely
  • Domain, the name you registered and pay for annually
  • Path, which document or route on that server
  • Query, parameters after ?, usually filters or tracking
  • Fragment, after #, handled entirely in the browser; the server never sees it

The three pieces of a page

What each language does
LanguageJobIf it's missing
HTMLContent and structure, headings, text, links, formsThere is no page
CSSAppearance, colour, spacing, layout, typeUnstyled black text on white; still readable
JavaScriptBehaviour, reacting to clicks, fetching data, changing the pageStatic page; forms and links still work if built well

The order in that table is also the order of importance for reliability. A page whose content lives in HTML works for search engines, screen readers, slow connections, and browsers where a script failed to load. A page whose content only appears after JavaScript runs is one failed request away from being blank.

Static, dynamic, and the middle

A static page is a file that already exists, the server hands over the same document to everyone. Fast, cheap, hard to break. A dynamic page is built when requested, usually because it depends on who's asking or on data that changes.

Most modern sites are a mix: the marketing pages and documentation are pre-built files, and only the account area is generated per request. This site is largely the former, which is why it can be served from locations close to the reader without asking a server to think.

Which part is broken

Symptom to suspect
What you seeLikely cause
Site not found / can't resolveDNS, the name isn't pointing anywhere yet
Connection refused or times outServer is down or not listening
404Reached the right server, wrong path
500Reached the right place; the code threw an error
Page loads unstyledThe CSS request failed
Content flashes then disappearsJavaScript is replacing what HTML delivered

Common mistakes

  • Assuming a DNS change is instant, caches mean it can take hours to propagate everywhere
  • Putting essential content behind JavaScript that must run before anything is visible
  • Confusing the domain registrar with the host; they're separate services and often separate companies
  • Treating a 500 as a network problem when it means your code raised an error

Key takeaways

  • A page load is: name to address, connection, request, response, then assembly
  • HTML carries content, CSS carries appearance, JavaScript carries behaviour, in that order of importance
  • Static files are the fastest and most reliable thing you can serve
  • The status code tells you which part of the chain failed

Try it yourself

Open your browser's Network tab and reload any site you use daily. Count the requests and find the largest one. On most sites it's an image or a font, and that single file usually explains most of the load time.

CHECK YOUR UNDERSTANDING

1. What does DNS actually do in the page-load sequence?
2. A site shows "connection refused" when you try to load it. What's the most likely cause per the lesson's debugging table?
3. Why does the lesson warn against putting essential content behind JavaScript that must run before anything is visible?
4. A DNS record was just updated to point to a new server. According to the lesson, what should you expect?
5. In the URL https://learning.navitallabs.com/lessons/what-is-an-api?ref=nav#steps, which part does the server never see?

Pass the quiz below to unlock this.

TERMS USED HERE

RELATED LESSONS