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.
- You type an addressnavitallabs.com is a name for humans. Computers route by numbers, so the name has to be translated first.
- 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.
- 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.
- It sends an HTTP requestA short text message: the method (GET), the path (/learning), and headers describing what your browser accepts.
- The server respondsA status code (200 for fine, 404 for not found, 500 for the server broke) plus the HTML document.
- 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
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
| Language | Job | If it's missing |
|---|---|---|
| HTML | Content and structure — headings, text, links, forms | There is no page |
| CSS | Appearance — colour, spacing, layout, type | Unstyled black text on white; still readable |
| JavaScript | Behaviour — reacting to clicks, fetching data, changing the page | Static 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
| What you see | Likely cause |
|---|---|
| Site not found / can't resolve | DNS — the name isn't pointing anywhere yet |
| Connection refused or times out | Server is down or not listening |
| 404 | Reached the right server, wrong path |
| 500 | Reached the right place; the code threw an error |
| Page loads unstyled | The CSS request failed |
| Content flashes then disappears | JavaScript 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.