How the Web Actually Works

Demystify the web — understand what's actually happening when you visit a website and what the code you're generating actually does.

INFO

• Time: ~45 minutes
• Difficulty: Beginner
• What you'll learn: How websites work, HTML/CSS/JS basics, frontend vs backend

---

This Page Covers

• How websites work (requests, responses, rendering)
• The three languages of the web: HTML, CSS, JavaScript
• Frontend vs backend: what runs where
• URLs, domains, and DNS basics

---

How Websites Work

Remember that website you just made in Module 0? When you shared that Lovable link with someone, something happened behind the scenes. Let's understand what.

The Request-Response Cycle

Think of visiting a website like ordering food at a restaurant:

1. You (the customer) look at the menu and tell the waiter what you want
2. The waiter takes your order to the kitchen
3. The kitchen prepares your food
4. The waiter brings the food back to your table
5. You enjoy your meal

Websites work the same way:

1. Your browser is the customer
2. The internet is the waiter
3. The server is the kitchen
4. The website files are the food
5. Your screen is where you "enjoy" the result

When you typed your Lovable URL into a new browser tab, your browser sent a request to Lovable's servers saying "Hey, can I have the files for this website?" The server responded by sending back all the code you created — the HTML, CSS, and JavaScript. Your browser then turned that code into the visual page you saw.

What Happens When You Visit a URL

Let's break down exactly what happens when someone types your website URL into their browser:

Step 1: You type the URL You enter https://your-project.lovable.app in the address bar and press Enter.

Step 2: DNS lookup (finding the address) Your browser needs to find where that website lives. It asks a DNS server, "What's the actual address for lovable.app?" The DNS server responds with an IP address — something like 104.21.32.15. (More on DNS later.)

Step 3: Browser sends a request Now that your browser knows where to go, it sends a request to that address: "Please send me the files for this website."

Step 4: Server processes and responds The server finds all the files for your website and sends them back to your browser.

Step 5: Browser renders the page Your browser receives the files and starts building the page. It reads the HTML (structure), applies the CSS (styling), and runs the JavaScript (behavior). This process is called rendering.

Step 6: You see the website Within milliseconds, you see your landing page exactly as you designed it.

This entire process happens every time someone visits your site. And it usually takes less than a second.

How Browsers Render Pages

When your browser receives the files from a server, it doesn't just display them immediately. It has to parse (read and understand) them first.

Think of it like receiving IKEA furniture:

1. First, you open the box and look at all the pieces (browser downloads files)
2. Then, you read the instructions (browser parses the code)
3. Then, you assemble the furniture (browser renders the page)
4. Finally, you have a bookshelf (you see the website)

The browser reads through the HTML to understand the structure, then applies CSS to make it look right, then runs JavaScript to add interactivity. If any of these files are missing or broken, the page might look wrong or not work properly.

Why do some pages load slowly?

• Large image files take longer to download
• Lots of JavaScript takes longer to run
• The server might be far away (physically)
• The server might be overloaded with requests

That simple landing page you built loads fast because it's just a few small files. Complex websites like Facebook have thousands of files and billions of users, which is why they sometimes feel slow.

---

The Three Languages of Web

Remember in Module 0, you saw code appearing on the side while Lovable built your site? That code was made up of three different "languages." Let's understand what each one does.

HTML: Structure

HTML stands for HyperText Markup Language. It's the skeleton of every webpage — it defines what content exists and how it's organized.

Think of HTML like the blueprint of a house. It says "there's a bedroom here, a bathroom there, and the kitchen is over here." It doesn't say what color the walls are or what furniture goes inside — it just defines the structure.

Here's what some of the HTML for your landing page might look like:

<h1>Alex Johnson</h1>
<p>I help small businesses grow through digital marketing</p>
<a href="https://linkedin.com/in/alex">LinkedIn</a>
<a href="https://twitter.com/alex">Twitter</a>
<a href="mailto:alex@example.com">Email me</a>

Let's break this down piece by piece:

• <h1>Alex Johnson</h1> — This is a heading (the biggest kind). The text between <h1> and </h1> appears as the main title. Your name shows up large and bold because it's in an h1 tag.

• <p>I help small businesses...</p> — This is a paragraph. The p stands for paragraph. Regular text goes inside <p> tags.

• <a href="https://linkedin.com/in/alex">LinkedIn</a> — This is a link (the a stands for "anchor"). The href part tells the browser where to go when clicked. The text between the tags is what people see and click on.

The pattern: Most HTML uses opening tags <tagname> and closing tags </tagname> with content in between. The tag name tells the browser what kind of content it is.

Common HTML tags you'll see:

• <h1> through <h6> — Headings (h1 is biggest, h6 is smallest)
• <p> — Paragraphs of text
• <a> — Links to other pages
• <img> — Images
• <div> — A generic container (like a box to group things)
• <button> — Clickable buttons

CSS: Styling

CSS stands for Cascading Style Sheets. If HTML is the skeleton, CSS is the skin and clothes — it controls how everything looks.

CSS answers questions like:

• What color is the text?
• How big is the font?
• How much space is between elements?
• What color is the background?
• How wide is this box?

Here's what the CSS for your heading might look like:

h1 {
  color: blue;
  font-size: 48px;
  text-align: center;
}

Let's break this down:

• h1 — This is the selector. It tells the browser "apply these styles to all h1 elements."

• { } — Everything inside the curly braces are the style rules for that selector.

• color: blue; — This makes the text color blue. The part before the colon (:) is the property (what you're changing). The part after is the value (what you're changing it to). The semicolon (;) ends the line.

• font-size: 48px; — This makes the text 48 pixels tall. Pixels (px) are a unit of measurement on screens.

• text-align: center; — This centers the text horizontally.

The pattern: CSS follows the format property: value; to define styles. You group multiple styles inside curly braces and apply them to elements using selectors.

Try it yourself: Right-click anywhere on a webpage and select "Inspect" (or "Inspect Element"). You'll see a panel showing the HTML structure on the left and CSS styles on the right. This is how developers peek under the hood of any website. Try clicking on different elements to see their styles.

JavaScript: Behavior

JavaScript (often called JS) is the muscles and brain of a webpage. It makes things happen.

HTML is static — it just sits there. JavaScript can:

• Respond when you click a button
• Show or hide elements
• Fetch new data without reloading the page
• Validate forms before you submit them
• Create animations and effects

Here's a simple example:

document.querySelector('button').addEventListener('click', () => {
  alert('You clicked the button!');
});

This looks more complex, so let's break it down in plain English:

• document — This refers to the entire webpage
• .querySelector('button') — Find the first button on the page
• .addEventListener('click', ...) — When someone clicks it...
• alert('You clicked the button!') — ...show a popup with this message

Translation: "Find a button on the page, and when someone clicks it, show a popup that says 'You clicked the button!'"

JavaScript is more complex than HTML or CSS, but you don't need to master it. AI tools like Lovable write JavaScript for you. You just need to understand that when things move, change, or respond to your actions — JavaScript is making that happen.

How They Work Together

These three languages always work together. Think of building a person:

Language	Role	Human Analogy
HTML	Structure	Skeleton — defines the shape and what parts exist
CSS	Styling	Skin and clothes — controls appearance
JavaScript	Behavior	Muscles and brain — enables actions and responses

When Lovable generated your landing page, it created:

• HTML to define your name, bio, and links
• CSS to make it blue, centered, and nicely spaced
• JavaScript to handle any interactive features

Your browser receives all three, combines them, and displays the result. Change the HTML, and the content changes. Change the CSS, and the look changes. Change the JavaScript, and the behavior changes.

---

Frontend vs Backend

You'll hear developers talk about "frontend" and "backend." Let's demystify these terms.

What Runs in the Browser (Frontend)

The frontend is everything that runs in YOUR browser — everything you can see and interact with directly.

When you visit a website:

• The HTML, CSS, and JavaScript files are downloaded to your computer
• Your browser runs them locally (on your machine)
• Everything you see is rendered on your screen

The frontend is sometimes called the "client side" because your browser is the "client" requesting files.

Frontend includes:

• The text and images you see
• The colors and layout
• Buttons, forms, and menus
• Animations and effects
• Anything you can click, scroll, or interact with

The landing page you built in Module 0 is entirely frontend. All the code runs in the visitor's browser.

What Runs on the Server (Backend)

The backend is everything that runs on the SERVER — the hidden parts that do the heavy lifting.

Think about Instagram:

• You can see posts and photos (frontend)
• But where do those photos come from? They're stored on Instagram's servers (backend)
• When you post a photo, it gets uploaded to their servers (backend)
• When you like a post, that information is saved in their database (backend)

Backend handles:

• Storing data in databases
• User accounts and passwords
• Processing payments
• Sending emails
• Anything that requires storing or retrieving information

The restaurant analogy:

• Frontend = The dining room (what customers see)
• Backend = The kitchen (where food is prepared, hidden from view)

Customers interact with the dining room. They don't see the kitchen, but without it, there's no food.

Static vs Dynamic Sites

Static sites are pre-made pages that look the same for everyone. Like a printed brochure — once it's made, it doesn't change.

Your Lovable landing page is a static site. It's the same for every visitor. There's no database, no user accounts, no changing content.

Dynamic sites change based on who's visiting or what data exists. Like a social media feed — everyone sees different content based on who they follow.

Static Site	Dynamic Site
Same content for everyone	Different content per user
No database needed	Requires database
Very fast to load	May be slower
Easy to deploy	More complex to set up
Good for: portfolios, landing pages, blogs	Good for: social media, e-commerce, apps

For most projects you'll build as an AI-Enabled Builder, static sites are perfect. They're simpler, faster, and easier to deploy. You'll learn to deploy one yourself in Module 9.

---

URLs, Domains, and DNS

Let's decode that thing you type in the address bar.

Anatomy of a URL

URL stands for Uniform Resource Locator. It's the address of a specific page on the internet.

Let's break down this URL: https://example.com/products?category=shoes

https://example.com/products?category=shoes
|_____|  |_________|  |______|  |___________|
   |         |           |           |
Protocol  Domain      Path     Query Parameters

https:// — The Protocol

• This tells the browser HOW to connect
• https means "secure" — data is encrypted (look for the padlock icon)
• http (without the s) is older and not secure — avoid entering passwords on http sites

example.com — The Domain

• This is the human-readable name of the website
• Like a street address for a building
• You can buy domains (like yourname.com) — we'll cover this in Module 9

/products — The Path

• This is the specific page within the website
• Like a room number inside a building
• / by itself means the homepage

?category=shoes — Query Parameters

• Extra information sent to the page
• The ? marks the start of parameters
• category=shoes means "show me the shoes category"
• Multiple parameters are separated by & (like ?category=shoes&color=red)

So when you share your Lovable URL like https://myproject.lovable.app, you're sharing:

• https — Connect securely
• myproject.lovable.app — To Lovable's servers, specifically your project
• (No path means the homepage)

How DNS Works

DNS stands for Domain Name System. It's the phone book of the internet.

Computers don't understand names like google.com. They only understand numbers called IP addresses, like 142.250.191.46.

DNS translates human-friendly names into computer-friendly numbers:

1. You type google.com
2. Your browser asks a DNS server: "What's the IP address for google.com?"
3. DNS responds: "It's 142.250.191.46"
4. Your browser connects to that number

Why do we need DNS?

• Imagine having to remember 142.250.191.46 instead of google.com
• Now imagine memorizing IP addresses for every website you visit
• DNS lets us use easy names while computers use numbers behind the scenes

It's like your phone's contacts. You tap "Mom" instead of dialing 555-123-4567 every time. DNS does this translation for website names.

Domains vs Hosting

These two things are often confused, but they're different:

Domain = The name (your address)

• Like: yourname.com
• You rent this from a domain registrar (like Namecheap, Google Domains, or GoDaddy)
• It's just a name — it doesn't store your website

Hosting = The space (the actual building)

• This is where your website files actually live
• It's a server (computer) that's always online
• You get this from hosting providers (like Netlify, Vercel, or GitHub Pages)

Analogy: A domain is like a street address. Hosting is the actual house. You need both — an address so people can find you, and a house to live in.

When you deployed on Lovable, they provided both for free:

• Hosting on their servers
• A domain like yourproject.lovable.app

In Module 9, you'll learn to get your own domain and set up your own hosting — so you're not dependent on Lovable.

---

Plain English Glossary

Here's a quick reference for all the terms we covered. Bookmark this page — you'll refer back to it.

Term	Plain English Definition
Browser	The app you use to view websites (Chrome, Safari, Firefox, Edge)
Server	A computer that stores website files and sends them when requested
Request	When your browser asks a server for files
Response	When the server sends files back to your browser
Render	When your browser turns code into a visual page
HTML	The code that defines page structure (skeleton)
CSS	The code that defines how things look (skin and clothes)
JavaScript	The code that makes things interactive (muscles and brain)
Frontend	Code that runs in your browser (what you see)
Backend	Code that runs on the server (hidden, stores data)
Client	The browser (it requests things from servers)
Static Site	A website that's the same for everyone
Dynamic Site	A website that changes based on users or data
URL	The full address of a webpage
Domain	The human-readable name of a website (like example.com)
DNS	The system that converts domain names to IP addresses
IP Address	The numerical address of a computer on the internet
Hosting	Where your website files live (the server)
Deploy	Putting your website on the internet so people can visit it
Parse	When a browser reads and understands code
Protocol	The rules for how to communicate (http, https)
HTTPS	Secure protocol — data is encrypted (look for the padlock)

---

Web Accessibility Basics

Making your website accessible means ensuring people with disabilities can use it. This is not just the right thing to do — it is also a legal requirement in many places.

Why Accessibility Matters

Legal reasons: Many countries have laws requiring websites to be accessible. The Americans with Disabilities Act (ADA) in the US and similar laws in Europe apply to many websites. Lawsuits over inaccessible websites are increasingly common.

Ethical reasons: About 15% of the world's population has some form of disability. Building inaccessible websites excludes millions of potential users.

Practical reasons: Accessibility improvements often benefit everyone. Captions help people in noisy environments. High contrast helps in bright sunlight. Keyboard navigation is faster for power users.

Alt Text for Images

When you add an image to a webpage, screen readers (software that reads pages aloud for blind users) cannot "see" the image. They need a text description instead.

<!-- Bad: No alt text -->
<img src="chart.png">

<!-- Better: Descriptive alt text -->
<img src="chart.png" alt="Bar chart showing sales increased 40% from Q1 to Q4">

Good alt text:

• Describes what the image shows, not just "image of..."
• Keeps it concise but informative (usually under 125 characters)
• For decorative images that add no information, use empty alt: alt=""

Color Contrast

Text needs sufficient contrast against its background to be readable. Low contrast text (like light gray on white) is hard to read for anyone, and impossible for users with low vision.

The 4.5:1 rule: Normal text should have a contrast ratio of at least 4.5:1 against its background. Large text (18pt or larger) can use 3:1.

How to check: Free tools like WebAIM Contrast Checker let you enter two colors and see if they pass.

Semantic HTML

Using the right HTML elements (not just <div> for everything) helps screen readers understand your page structure.

<!-- Bad: Everything is divs -->
<div class="nav">...</div>
<div class="main">...</div>

<!-- Better: Semantic elements -->
<nav>...</nav>
<main>...</main>

Key semantic elements:

• <nav> for navigation menus
• <main> for the main content area
• <header> and <footer> for page headers/footers
• <article> for self-contained content
• <button> for clickable actions (not <div onclick>)
• <h1> through <h6> for headings (in order, do not skip levels)

Quick Accessibility Checklist

Before shipping any project, check these basics:

• [ ] All images have descriptive alt text
• [ ] Text has sufficient contrast against backgrounds
• [ ] Headings follow a logical order (h1, then h2, etc.)
• [ ] Interactive elements (buttons, links, forms) are keyboard accessible
• [ ] Page has a descriptive <title> tag
• [ ] Forms have labels associated with their inputs
• [ ] No information is conveyed by color alone

Quick test: Try navigating your site using only the Tab key. Can you reach all buttons and links? Can you tell where you are on the page?

This is just the basics. Accessibility is a deep topic, but starting with these fundamentals will make your sites better for everyone.

---

Key Takeaways

• Websites are files (HTML, CSS, JS) sent from servers to browsers
• HTML provides structure (what exists), CSS provides style (how it looks), JavaScript provides behavior (what it does)
• Frontend runs in your browser (what you see); backend runs on servers (hidden, stores data)
• URLs are addresses that tell browsers where to go
• DNS is the phone book that translates names to numbers
• Domains are names you rent; hosting is space where files live

The landing page you built in Module 0? Now you understand what happened:

1. Lovable's AI wrote HTML (structure), CSS (styling), and JavaScript (behavior)
2. Those files were uploaded to Lovable's servers (hosting)
3. You got a URL (domain) pointing to those files
4. When visitors go to that URL, their browser requests the files, receives them, and renders your page

You went from "magic happened" to "I understand what happened." That's progress.

---

What's Next?

Now that you understand how the web works, it's time to set up your own development environment — the tools you'll use to build, test, and modify code yourself.