You open your browser, type www.example.com, and hit enter. Two seconds later, the site loads. Magic? Not quite. There's a chain of invisible steps happening behind the scenes, and if you're building web apps, it's worth knowing where things can slow down or fail.

This post is part of the "You're not stuck, you just skipped the basics" series.

---

🧭 Step 1: Your browser needs an IP address

The web doesn’t work with names like example.com. It works with IP addresses like 93.184.216.34. So the first thing your browser does is ask:

“Hey DNS, what’s the IP for this domain?”

DNS (Domain Name System) is basically the phone book of the internet. Your browser sends a DNS request to a DNS resolver (usually your ISP’s or Google’s 8.8.8.8), and it responds with the IP address.

⚠️ Slow DNS equals slow first impression.

---

🚪 Step 2: Connecting to the server (TCP and Port)

Now that your browser knows the IP, it needs to open a connection. This usually happens over TCP (Transmission Control Protocol). Think of it as establishing a reliable tunnel where both sides agree on the rules.

Also, your request goes to a port, typically port 80 for HTTP or 443 for HTTPS. Ports help the server route your request to the correct service.

---

📦 Step 3: Sending and receiving packets

The actual data (your GET request, the HTML, the images) travels in packets. A packet is just a small chunk of data with some metadata (like source, destination, and order).

Your request might be broken into 20 or more packets. They can travel different routes across the internet and still arrive in the right order.

Packets can get lost, duplicated, or arrive out of order. TCP handles all of this for you.

---

⏱️ Latency, response time, and where things get slow

Here’s a breakdown of what can affect the speed of a request:

• DNS lookup time, the first network call
• TCP handshake, needs a round-trip
• TLS handshake (HTTPS), an extra handshake step
• Server response time, is your backend fast?
• Payload size, big HTML or images means more packets
• Client rendering, slow JavaScript kills performance

So if your app feels slow, it might not be your React code. It could be:

• A misconfigured DNS
• An overloaded backend
• A fat payload with 5MB hero images
• Or even a CDN edge being too far from the user

---

🧠 Why should you care?

Understanding this flow gives you better debugging instincts. If a user says “the site is slow,” your mind shouldn’t go straight to blaming React or the database. It might be a DNS cache miss, or maybe the server is in Europe and your user is in Brazil.

Next week, we’ll dive deeper into HTTP itself, including headers, methods, caching, and how to avoid breaking the internet.

---

Follow the series:

• Week 1: What does a CPU actually do?
• Week 2: Essential Memory
• Week 3: (You’re here) What happens when you type a URL
• Week 4: (coming soon...)