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 should be able to use a browser and create a folder. Think about the last website you visited: did its files already exist on your computer, or did your browser obtain them from elsewhere? What changed when you followed a link? Keep those observations available.

Terminology

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

The Internet is the road and delivery network. The Web is one service using that network. A URL is a precise delivery address. DNS is like an address directory: it helps turn a human-friendly hostname into a network location. HTTP is the shared format for an order and its reply. The browser is the customer and reader; the server is the library desk.

This analogy has limits. DNS does not fetch the page, one physical server may host many sites, and a page normally needs several requests. It is nevertheless a useful first model.

The Internet existed before the Web and supports other services. Email, for example, can travel over the Internet without being a web page. Conversely, a local HTML file can open in a browser without crossing the Internet. Therefore “Internet” and “Web” are related, not interchangeable.

URL anatomy

Consider:

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

https says which scheme/protocol is used.
www.example.com is the hostname.
443 is an explicit port; HTTPS normally uses 443, so it 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 interpreted by the client to locate part of the returned document. It is not sent in the HTTP request.

Not every URL contains every part. A relative URL such as about.html is resolved using the current document's URL; you will practise that on 004.

Request and response

At a conceptual level, entering an HTTPS URL causes this flow:

text
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. If it discovers references to images, CSS, JavaScript, fonts, or media, it may make more requests. It constructs an internal document tree, applies styling, runs permitted scripts, lays out the result, and paints pixels. Caches, service workers, proxies, and redirects can change the route, but not the central request/response idea.

For interview diagnosis, separate the stages rather than saying “the browser renders.” HTML parsing builds the DOM; CSS parsing builds the CSSOM; the browser combines them into the render tree, calculates layout (geometry), and paints pixels. A stylesheet normally blocks the first render because the browser needs its rules, while a classic script can pause HTML parsing unless it is defer or async. defer preserves document order and runs after parsing; async runs as soon as it is ready and does not guarantee order. These are scheduling facts, not guarantees that a page is fully interactive or that every image has finished decoding.

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

HTML, CSS, and JavaScript

Imagine a personal portfolio:

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

The boundaries matter. A heading should be HTML, not a large generic box created only by CSS. A normal link needs no JavaScript. Start with meaningful HTML, enhance its appearance with CSS, and add JavaScript only when behavior requires it. If CSS fails, content should remain understandable; if JavaScript fails, core navigation should ideally still work.

Browsers, hosting, caches, and CDNs

A browser is not only a viewer. It is also an HTTP client, an HTML parser, a storage/cache manager, and a runtime for CSS and JavaScript. Different browser engines can make slightly different implementation choices, but valid HTML is designed to produce interoperable results across them.

A public website also needs hosting: somewhere the site's files or generated responses are made available to HTTP clients. Hosting can be a single 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 the distance and load on the origin server.

Caching can happen in several places:

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

A cached response is still part of the HTTP model. The browser may validate whether its cached copy is fresh rather than downloading the whole resource again.

HTTP methods and status-code families

GET is the method you will see most often while learning HTML because following a normal link requests a resource. Forms later introduce POST. Other methods such as PUT, PATCH, and DELETE are commonly used by web applications and APIs, but HTML forms natively submit only with GET or POST.

Status codes are easier to reason about 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.

Do not memorize every code at once. Learn to read the family first, then inspect the specific code when debugging.

Guided example: trace one request

You enter https://portfolio.example/about.html#skills.

The browser parses the URL. The scheme is HTTPS, hostname is portfolio.example, path is /about.html, and fragment is skills.
If it lacks a usable cached result, the browser asks DNS for an address associated with portfolio.example.
The browser establishes a connection 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
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 any 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.

Checkpoint: review the trace and try to recreate it in your own words using client, DNS, request, response, and render. Accuracy matters more than memorizing implementation details.

Intermediate example: read a network conversation

Suppose the first response is:

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

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

http
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 according to the cache policy. The HTML references /images/profile.webp, producing another request. If that response is 404 Not Found, the document can still render, but the image fails. One page load is therefore a graph of requests, not one indivisible download.

Open browser developer tools, select Network, reload a public page, and identify the document request. Observe the 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 two page plans:

text
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 every byte must be delivered, decoded, and perhaps executed. A fast personal site begins with small, necessary resources, compressed images, sensible caching, and little blocking work.

Now separate three claims:

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 claim 3. Browsers isolate and restrict content, servers set security headers, and developers must still 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 only describes request success at the HTTP level.
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, then look for long scripting, layout, paint, or image-decode tasks. Do not infer the cause from a blank screenshot alone. A fast server response can still be followed by slow parsing or main-thread work.

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. Do not make essential content 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 all network input as untrusted. Performance begins with asking whether a resource is necessary and appropriately sized; browser caching reduces repeated transfer but must be configured by the server.

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:

text
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 presentation, and JavaScript 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

Everything above stays abstract until you trace a request that matters to you, so run this once before moving on.

Imagine you are about to build a website for a friend who runs a small bakery, "Rina's Kitchen." Before you write a single tag, picture what happens the moment a customer types https://rinaskitchen.example/menu.html into their phone:

You open your browser's Network panel (DevTools) on any live site right now, not a demo — reload the page, and watch the first row appear. That row is the document request you will soon be creating yourself.
Notice the Status column. A 200 means "here is your page"; if you ever see a 404 while building Rina's site later this week, you will already know it means the browser asked for a file that was not where it expected.
Notice the Type column. The first request is document; everything below it — images, fonts, stylesheets — are resources that your HTML will soon reference.

You are not building a demo site in this course; you are rehearsing exactly what will happen when Rina's customers load the real thing. Keep that DevTools tab open — you will return to it in almost every lesson to check your own work, not just read about someone else's.

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.