001: How the Web Works

Learning outcomes

By the end of this lesson, you can:

distinguish the Internet from the Web;
identify the browser/client, server, DNS, URL, HTTP, and response in a page load;
break a URL into scheme, host, port, path, query, and fragment;
trace what happens after someone enters a URL without diving into network internals; and
explain the different jobs of HTML, CSS, and JavaScript.

Prerequisites and retrieval

No coding experience is required. You need to be comfortable using a browser and creating a folder. Think about the last website you opened. Were its files already on your computer, or did the browser obtain them from somewhere else? What changed after you followed a link? Those observations are enough to start separating what the browser does from what the network does.

Terminology

These terms will recur throughout the course. They are worth having in one place, even though the useful understanding comes from seeing how they interact during a page load.

Internet: The global network of interconnected computer networks that carries the Web, email, and other services. — Source: MDN: Glossary — Internet
Web: “The World Wide Web is an information space where documents and resources are identified by URIs and linked by hyperlinks.” — Source: MDN: Glossary — World Wide Web
Client: The software side of HTTP that sends requests and receives responses, usually a browser. — Source: MDN: Overview of HTTP
Browser: A software application used to access and display web pages and other web resources. — Source: MDN: Glossary — Browser
Server: A computer or program that provides services to clients, such as responding to web requests. — Source: MDN: Glossary — Server
URL: An address specifying both the location of a resource and how to retrieve it. — Source: MDN: Glossary — URL
DNS: The system that translates human-readable domain names into the IP addresses computers use. — Source: MDN: Glossary — DNS
HTTP: The application protocol defining how clients and servers format and exchange messages on the Web. — Source: MDN: Glossary — HTTP
Resource: Any addressable item delivered over the Web — HTML documents, images, stylesheets, videos. — Source: MDN: What is a URL?
Status code: A three-digit code a server returns indicating the result of an HTTP request (200, 404, 301…). — Source: MDN: HTTP response status codes
HTML: “HTML is the markup language that describes the structure and semantics of web documents.” — Source: WHATWG HTML Living Standard: Introduction
CSS: “CSS (Cascading Style Sheets) is the language used to describe the presentation of a document written in HTML.” — Source: MDN: What is CSS?
JavaScript: “JavaScript is a programming language that allows you to implement complex features on web pages.” — Source: MDN: What is JavaScript?
HyperText: “Hypertext is text containing hyperlinks to other resources.” — Source: MDN: Glossary — Hypertext
IP address: “A numeric address (e.g., 192.0.2.172) assigned to each device on an IP network.” — Source: MDN: What is a URL?
TLS: “Transport Layer Security, the cryptographic protocol that provides end-to-end security for HTTPS.” — Source: MDN: Glossary — TLS

Mental model: a library delivery service

When a page appears, several jobs have happened in sequence. Picture the Internet as the road and delivery network, and the Web as one service that uses it. The URL is a precise delivery address. DNS is the address directory that turns a human-friendly hostname into a network location. HTTP is the shared format for the order and its reply. The browser is both the customer and the reader; the server is the library desk that supplies the requested material.

The comparison stops being accurate if pushed too far. DNS does not fetch a page. One physical server can host many sites, and a page usually requires several requests rather than one delivery. The model is still useful because it gives each part of a page load a separate job.

The Internet existed before the Web and carries other services. Email can use the Internet without being a web page. A local HTML file can also open in a browser without crossing the Internet at all. “Internet” and “Web” therefore describe related layers, not interchangeable names.

URL anatomy

Start with the address the browser must interpret:

https://www.example.com:443/projects/index.html?year=2026#contact
|---|   |-------------| |-| |------------------| |-------| |------|
scheme       host      port         path             query   fragment

https identifies the scheme/protocol.
www.example.com is the hostname.
443 is an explicit port. HTTPS normally uses 443, so the port is usually omitted.
/projects/index.html is the resource path.
?year=2026 is a query sent to the server as part of the request target.
#contact is a fragment the client uses to locate part of the returned document. It is not sent in the HTTP request.

URLs do not always contain every part. A relative URL such as about.html is resolved against the current document's URL; you will practise that on 004.

Request and response

At a conceptual level, entering an HTTPS URL produces this sequence:

Person -> browser -> DNS lookup -> server address
Person <- browser <=============> server
                     HTTPS request: GET /index.html
                     HTTPS response: 200 + headers + HTML bytes

The browser parses the HTML. References to images, CSS, JavaScript, fonts, or media can trigger more requests. It builds an internal document tree, applies styles, runs permitted scripts, calculates layout, and paints pixels. Caches, service workers, proxies, and redirects can alter the route, but the request/response relationship remains the useful center of the model.

For debugging, “the browser renders it” is too compressed to explain a failure. HTML parsing builds the DOM. CSS parsing builds the CSSOM. The browser combines them into a render tree, calculates layout (geometry), and paints pixels. A stylesheet normally blocks the first render because its rules are needed. A classic script can pause HTML parsing unless it uses defer or async: defer preserves document order and runs after parsing, while async runs as soon as it is ready and does not guarantee order. Neither attribute means that the page is fully interactive or that every image has finished decoding.

An HTTP message carries more than a body. Request headers can describe accepted formats and language preferences. Response headers can provide the content type, caching policy, and security policy. HTTPS protects messages in transit and helps authenticate the site, but it does not establish that the site's content or owner is trustworthy.

HTML, CSS, and JavaScript

Imagine a personal portfolio arriving as a collection of resources:

HTML identifies content and meaning: a heading, navigation, paragraph, image, project, or contact form.
CSS controls presentation and layout: spacing, type, colors, responsive columns, and focus appearance.
JavaScript adds behavior that HTML alone cannot express, such as fetching new project data or opening a custom interaction.

Those boundaries are practical, not academic. A heading belongs in HTML rather than being a large generic box made to look like one with CSS. A normal link does not need JavaScript. Start with meaningful HTML, enhance it with CSS, and add JavaScript when behavior actually requires it. If CSS fails, the content should remain understandable; if JavaScript fails, core navigation should ideally still work.

Browsers, hosting, caches, and CDNs

A browser is more than a viewer. It is an HTTP client, an HTML parser, a storage and cache manager, and a runtime for CSS and JavaScript. Browser engines make some implementation choices differently, but valid HTML is intended to produce interoperable results across them.

A public website needs hosting: a place where its files or generated responses are available to HTTP clients. That place might be one server, a managed platform, object storage, or a distributed service. A CDN (Content Delivery Network) can keep copies of static resources closer to visitors, reducing distance and load on the origin server.

Caching can occur at several points:

the browser can reuse a response it already downloaded;
an intermediary or CDN can reuse a cacheable response; and
the server can cache expensive work before producing a response.

A cached response still belongs to the HTTP model. The browser may validate whether its copy is fresh instead of downloading the complete resource again.

HTTP methods and status-code families

GET is the method seen most often while learning HTML because following a normal link requests a resource. Forms introduce POST later. Web applications and APIs commonly use PUT, PATCH, and DELETE as well, although HTML forms natively submit only with GET or POST.

Status codes are easier to diagnose by family:

1xx — informational;
2xx — success, such as 200 OK;
3xx — redirection, such as 301 Moved Permanently or 302 Found;
4xx — a problem with the request or requested resource, such as 404 Not Found;
5xx — a server-side failure, such as 500 Internal Server Error.

The family gives you the first useful clue; the specific code and response details explain the rest.

Guided example: trace one request

Suppose you enter https://portfolio.example/about.html#skills.

The browser parses the URL. The scheme is HTTPS, the hostname is portfolio.example, the path is /about.html, and the fragment is skills.
If it has no usable cached result, the browser asks DNS for an address associated with portfolio.example.
The browser connects to that address and negotiates TLS for HTTPS. The transport details are deliberately outside today's scope.
It sends an HTTP request conceptually like:
http
```
GET /about.html HTTP/1.1
Host: portfolio.example
```
Actual HTTP versions may encode the message differently, but method, target, headers, and response semantics remain useful concepts.

The server finds or generates the resource and replies conceptually:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

<!doctype html>...

The browser interprets the bytes as HTML because of the response metadata, parses the document, and discovers linked resources.
It requests those resources as needed.
It finds the element whose id is skills and scrolls to it. The fragment was used in the browser, not sent to the server.

If you can recreate this trace in your own words with client, DNS, request, response, and render, you can already describe the path without memorizing implementation details. The order also gives you a debugging strategy: identify the address, find the request, inspect the response, and then inspect what the browser did with the returned bytes.

Intermediate example: read a network conversation

Suppose the first response is:

HTTP/1.1 301 Moved Permanently
Location: https://www.portfolio.example/

The browser has not received the final HTML. 301 says the resource has a permanent new URL, so the browser follows Location with another request. The next response is:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: max-age=3600

The browser can interpret the body as UTF-8 HTML and may reuse the response for an hour under that cache policy. The HTML references /images/profile.webp, which creates another request. If that response is 404 Not Found, the document can still render while the image fails. A page load is a graph of requests, not one indivisible download.

Open browser developer tools, select Network, and reload a public page. Find the document request, then inspect its URL, method, status, response Content-Type, and later image requests. Do not send private headers, cookies, or tokens to anyone: network tools can expose them.

Advanced optional extension: performance and trust

Compare these two page plans:

A: HTML 20 KB + image 80 KB
B: HTML 20 KB + twelve images of 1 MB each + five scripts

Plan B requires much more transfer and processing. More resources are not automatically bad, but each byte may need to be delivered, decoded, and, for scripts, executed. A fast personal site starts with small necessary resources, compressed images, sensible caching, and little blocking work.

Keep these claims separate:

HTTPS encrypts traffic in transit.
DNS helps locate the host.
The returned HTML is safe and honest.

Only the first two follow from this trace; neither guarantees the third. Browsers isolate and restrict content, servers set security headers, and developers still have to handle untrusted input safely. Never paste unknown JavaScript into developer tools.

Common mistakes and debugging

Calling the Web the Internet: ask whether email or a local network can use the Internet without a web page.
Saying DNS downloads HTML: DNS returns addressing information; HTTP retrieves the resource.
Saying the server “sends a website”: it responds with resources. The browser combines and presents them.
Sending the fragment to the server: #skills normally stays client-side.
Assuming 200 means the page is correct: it describes request success at the HTTP level, not whether the content is correct.
Treating HTTPS as a trust guarantee: it protects the connection, not every business or claim behind it.
Debugging only the screen: inspect the address, Network status, response type, and Console. A 404 suggests a URL/path problem; a blocked or mixed-content request suggests a security policy issue.

When a page is slow, use Network and Performance together. Identify the document and render-blocking resources, check response sizes and timing, and then look for long scripting, layout, paint, or image-decode tasks. A blank screenshot does not identify the cause. A fast server response can still be followed by slow parsing or main-thread work.

There is also a useful boundary between failures: a DNS failure means the browser could not locate an address, so there is no HTTP request or HTTP response to inspect. An HTTP 404 means a server answered the request but could not provide that resource. Those cases lead to different next checks.

Accessibility, security, and performance

The request process affects people differently. Slow connections, expensive data, old devices, and assistive technology all benefit from small, semantic pages. HTML gives browsers and assistive technologies machine-readable meaning before styling or scripting. Essential content should not depend unnecessarily on a large image or script.

Use HTTPS for deployed forms and pages. URLs can appear in history, logs, analytics, and referrer information, so never put passwords or sensitive personal data in a URL query. Treat every network input as untrusted. Performance starts by asking whether a resource is necessary and appropriately sized; browser caching reduces repeated transfer, but the server must configure the policy.

Tiered exercises

Level 1: identify

Label the parts of https://example.org/work/?tag=html#latest. Then assign each job to browser, DNS, or server: resolve hostname; request resource; return response; render HTML.

Level 2: explain

Draw a request/response diagram for that URL. Include one successful document request and one image request that fails with 404. Explain why the document can still appear.

Level 3: investigate

Use the Network panel on a non-sensitive public site. Record the document URL, status, content type, and three resource types. Explain one likely performance improvement without claiming that request count alone proves poor performance.

Level 1: scheme: https; host: example.org; path: /work/; query: tag=html; fragment: latest. DNS resolves the hostname. The browser requests and renders. The server returns the response.

Level 2:

User -> Browser: https://example.org/work/?tag=html#latest
Browser -> DNS: address for example.org?
DNS -> Browser: server address
Browser -> Server: GET /work/?tag=html
Server -> Browser: 200 OK, HTML
Browser -> Server: GET /images/profile.webp
Server -> Browser: 404 Not Found
Browser -> User: rendered HTML, missing image; scroll to latest

The HTML response succeeded independently. The browser can render its text and structure even though a later image resource failed.

Level 3: results vary. A sound report might say: “The document returned 200 and text/html. Image, stylesheet, and script resources followed. The largest image appears much bigger than its displayed purpose, so resizing/compressing it may reduce transfer. I would measure before and after.” Never include cookies or authorization values in the report.

Recap and exit questions

The Internet is infrastructure; the Web is a linked-resource system using it. A browser resolves a URL, sends HTTP requests, receives responses, and interprets resources. HTML supplies structure and meaning, CSS supplies presentation, and JavaScript supplies behavior.

What does DNS do, and what does it not do?
Which URL part is not normally sent in an HTTP request?
Why can one page generate many requests?
What is the difference between a 404 and a DNS failure?
Why is HTML the foundation rather than merely “text before CSS”?
What is the practical difference between defer and async for two dependent scripts?

Try it with your own example

The model becomes more useful when you trace a request that matters to you. Run this once before moving on.

Imagine building a website for a friend who runs a small bakery, “Rina's Kitchen.” Before writing a single tag, follow what happens when a customer types https://rinaskitchen.example/menu.html into their phone:

Open your browser's Network panel (DevTools) on any live site, not a demo. Reload the page and watch the first row appear. That row is the document request you will soon be creating yourself.
Inspect the Status column. A 200 means “here is your page.” If you see a 404 while building Rina's site later this week, it means the browser asked for a file that was not where it expected.
Inspect the Type column. The first request is document; the rows below it, including images, fonts, and stylesheets, are resources your HTML will soon reference.

You are not building a demo site in this course. You are rehearsing what will happen when Rina's customers load the real thing. Keep that DevTools tab open and return to it in later lessons to check your own work.

Further reading on this exact workflow: MDN — Inspecting network requests explains what each Network-panel column means in more detail than this lesson has room for.