A few months back, my internet at home started acting weird. Pages would sit there loading for three or four seconds before anything showed up, then suddenly snap into place all at once. My first instinct was to blame my ISP and call them to complain. But before doing that, I opened up Chrome DevTools out of habit — I do a lot of freelance web work — and watched the Network tab while loading a simple news site.
What I saw kind of blew my mind, honestly. Even though I've "known" how the internet works for years, actually watching a single page load broken down into dozens of tiny steps made me realize how much invisible travel happens before a webpage ever shows up on your screen. That one afternoon of poking around turned into a rabbit hole, and I ended up learning more about networking in a weekend than I had in years of just using the internet passively.
So I wanted to write this down the way I wish someone had explained it to me — not textbook style, just a walkthrough of what's actually happening when you type a URL and hit enter.
It starts before you even see anything
Here's the thing nobody tells you: typing a web address doesn't send anything to a website directly. Your computer doesn't even know where that website "lives" yet.
The first stop is something called DNS — think of it like your phone's contacts list, except instead of matching a name to a phone number, it matches a website name (like amazon.com) to a numeric address called an IP address. Computers don't understand "amazon.com." They only understand strings of numbers.
When I ran a DNS lookup using a free tool called nslookup in my terminal, I saw the domain get translated into an IP address that looked something like 192.0.2.44 (not the real one, obviously). That number is basically the "house address" of the server that stores the website.
This step alone can add delay if your DNS server is slow. I switched my router's DNS settings from my ISP's default to Cloudflare's public DNS (1.1.1.1) after reading that it's generally faster and more privacy-focused, and I genuinely noticed page loads feeling snappier. Google's public DNS (8.8.8.8) is another common option people use.
Then comes the actual "conversation"
Once your device knows the IP address, it needs to actually talk to that server. This is where something called TCP comes in — it's basically a handshake process. Your computer says "hey, I want to connect," the server says "okay, go ahead," and then your computer confirms "great, let's start."
This handshake happens in milliseconds, but it's not instant — it depends on how far away the server physically is. This is something I didn't fully appreciate until I hosted a small WordPress site on a server based in Singapore while my main audience was in the US. Pages loaded noticeably slower for my American visitors, and after digging around, I realized it was because every single request had to physically travel across the ocean and back — twice, once for the handshake and once for the actual data.
Moving the hosting to a US-based server (I used DigitalOcean at the time) cut my load times significantly. Distance really does matter in networking, way more than people assume.
HTTPS adds another layer
If the site uses HTTPS (which almost every legitimate site does now, and browsers actively warn you if it doesn't), there's an additional step where your browser and the server agree on an encryption method before any real data gets exchanged. This is called an SSL/TLS handshake.
I remember setting up an SSL certificate for a client's site using Let's Encrypt (a free certificate authority) and being surprised at how much backend negotiation happens just to make that little padlock icon show up in the address bar. It's not just cosmetic — it's actually encrypting everything between the browser and server so nobody snooping on the network can read your data.
Also Read: What Is a SOC? A Look Inside the Security Operations Center
The actual request and response
After all that setup, your browser finally sends the real request — basically saying "please send me the homepage." The server processes this, pulls together the HTML, CSS, JavaScript, images, and whatever else the page needs, and sends it all back.
This is where things get interesting on media-heavy sites. When I was troubleshooting a slow-loading portfolio site for a photographer client, the Network tab in DevTools showed me that a single uncompressed image was 8MB. Eight megabytes. For one photo. That one file was single-handedly responsible for most of the page's load time.
The fix was compressing images using a tool called TinyPNG before uploading them, and enabling a system called lazy loading, which delays loading images until the user actually scrolls near them. Page load time dropped from around 9 seconds to under 2 seconds. That was honestly one of those "oh, THAT'S why it was slow" moments.
The whole journey, laid out in one table
After going through all this, I actually made myself a little cheat sheet so I could explain it to clients without losing them halfway through. Here's a simplified version of it:
| Step | What's Actually Happening | Tool to Check It | Typical Time |
|---|---|---|---|
| 1. DNS Lookup | Your device asks "what's the IP address for this domain?" | nslookup, whatsmydns.net | 20–120 ms |
| 2. TCP Handshake | Your device and the server agree to connect | DevTools → Network tab | 20–100 ms (depends on distance) |
| 3. TLS/SSL Handshake | Browser and server agree on encryption (only on HTTPS sites) | Padlock icon, SSL Labs test | 50–200 ms |
| 4. Request Sent | Browser asks the server for the actual page | DevTools → Network tab | Near-instant |
| 5. Server Processing (TTFB) | Server builds the page and starts sending a response | DevTools → "Waiting (TTFB)" | 100 ms–2+ sec |
| 6. Content Download | Images, CSS, JS, and text actually transfer to your browser | DevTools → file sizes | Varies a lot (this is where bloated images hurt) |
| 7. Page Render | Browser draws everything on screen | DevTools → "Load" event | Depends on how heavy the page is |
Seeing it laid out like this made something click for me: most of the "invisible" delay people blame on their internet connection is actually happening in steps 1, 3, and 5 — not the actual download. That's exactly why my Singapore-hosted site felt sluggish even though my home WiFi was perfectly fine.
Step-by-step: how to see this journey yourself
If you want to actually watch this process happen instead of just reading about it, here's what I'd suggest doing:
Open any website in Chrome or Firefox.
Right-click anywhere on the page and choose "Inspect" (or press F12).
Click on the "Network" tab in the panel that opens.
Refresh the page while the Network tab is open.
Watch the list populate — you'll see every single file, request, and response, along with how long each one took.
Click on any single row to see detailed timing, including DNS lookup time, connection time, and how long the server took to respond.
Doing this once on your own site (or even your favorite blog) makes everything click in a way that reading an explanation never quite does.
Also Read: Edge Computing: Bringing the Cloud Closer to You
Real mistakes I made along the way
I want to be honest about a couple of things I got wrong, because I think it's more useful than pretending I figured everything out perfectly.
Mistake one: I assumed a slow website was always a hosting problem. Sometimes it's genuinely just unoptimized images or too many third-party scripts (think embedded fonts, ad trackers, chat widgets) all loading at once and fighting for bandwidth.
Mistake two: I once switched hosting providers thinking it would fix speed issues, without checking DNS propagation time first. For about 24 hours, some visitors saw the old site and some saw the new one, depending on which DNS server their device happened to check. That taught me to always check propagation using a free tool like whatsmydns.net before assuming a migration is fully complete.
Mistake three: I ignored something called "Time to First Byte" (TTFB) for way too long. This measures how long the server takes to even start responding, before any content shows up. A slow TTFB usually points to server-side issues — bad hosting, unoptimized database queries, or an overloaded server — rather than anything on the front end.
Common mistakes people make with this stuff
Blaming the ISP first, before actually checking DNS speed or server response time.
Not compressing images before uploading them to a website.
Ignoring third-party scripts that quietly load in the background and slow everything down.
Assuming HTTPS is "automatic" and not renewing SSL certificates on time, which can break a site entirely.
Never actually opening DevTools to see what's happening, and just guessing at fixes instead.
Why any of this actually matters to a regular person
You don't need to become a network engineer to benefit from understanding this. If you run a blog, a small business site, or even just want your own internet browsing to feel faster, knowing where the bottlenecks usually hide gives you actual, actionable places to look — DNS, server location, image size, and script bloat — instead of just shrugging and assuming "the internet is slow today."
The next time a page takes forever to load, pop open that Network tab before getting frustrated. There's a decent chance you'll spot exactly where the delay is hiding, the same way I did with that 8MB photo that had no business being that large.