What is the difference between HTTP and HTTPS?

HTTPS is HTTP with encryption (TLS). With HTTP, anyone on your network can read the data flowing between your browser and the server. With HTTPS, the data is encrypted so only your browser and the server can read it. All modern websites should use HTTPS.

Why do some websites load faster than others?

Speed depends on many factors: the physical distance between you and the server, how much data the page loads (images, scripts, fonts), whether a CDN caches the content nearby, how optimized the server code is, and your own internet connection speed.

Is this the same process for mobile apps?

Yes. Mobile apps make HTTP requests to backend servers just like browsers do. The difference is that a browser renders HTML into a visual page, while a mobile app typically receives JSON data from an API and displays it using native UI components.

Why does this matter for developers?

Every web application you build involves these same steps. Understanding the flow helps you debug issues (is it a DNS problem? A slow server? A rendering bug?), optimize performance, and make informed decisions about hosting and architecture.

How the Internet Works: From Typing a URL to Seeing a Page

Step 1: DNS lookup, finding the address

You type www.safaricom.co.ke into your browser. But computers do not understand domain names. They need an IP address, a set of numbers like 197.232.10.35.

Your browser asks a DNS (Domain Name System) server: "What is the IP address for www.safaricom.co.ke?" Think of DNS as the contacts app on your phone. You search for "Mama Wanjiku" and the phone returns her number. DNS does the same thing for domain names.

The lookup process:

Browser cache: The browser checks if it already looked up this domain recently. If yes, it skips ahead.
Operating system cache: Your computer keeps its own DNS cache. The browser asks the OS.
Recursive resolver: If neither cache has the answer, the request goes to your ISP's DNS server (or a public one like Google's 8.8.8.8).
Root, TLD, and authoritative servers: The resolver asks a chain of DNS servers until it gets the final IP address from the domain's authoritative nameserver.

You can see this yourself. Open your terminal and run:

nslookup www.safaricom.co.ke
# Answer: 197.232.10.35 (example, actual IP may differ)

Step 2: TCP handshake, establishing a connection

Now your browser knows the server's IP address. Before sending any data, it needs to establish a reliable connection using TCP (Transmission Control Protocol).

TCP uses a three-step handshake:

SYN: Your browser sends a "synchronize" packet to the server. "I want to connect."
SYN-ACK: The server replies with a "synchronize-acknowledge" packet. "I hear you, let's connect."
ACK: Your browser sends an "acknowledge" packet. "Confirmed. We are connected."

This is like walking up to a counter at a Safaricom shop. You say hello, the attendant acknowledges you, and then you start your transaction. Both sides agree the conversation is happening before any real data flows.

For HTTPS websites (almost all modern sites), there is an extra step: the TLS handshake. This sets up encryption so that nobody watching your network traffic (like someone on the same public Wi-Fi at a cafe in the CBD) can read what you send or receive.

Step 3: HTTP request, asking for the page

With the connection open, your browser sends an HTTP request. It looks something like this:

GET / HTTP/1.1
Host: www.safaricom.co.ke
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html
Accept-Language: en-US,sw;q=0.5
Connection: keep-alive

The request has three key parts:

Method: GET means "give me this page." POST would mean "here is some data to process."
Path: / is the homepage. /about would be the about page.
Headers: Extra information about the browser, what formats it accepts, and what language the user prefers.

The server receives this request, processes it (maybe querying a database, running some server-side code), and builds a response.

Step 4: HTTP response, sending back the page

The server sends back an HTTP response:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 48230

<!DOCTYPE html>
<html>
  <head>
    <title>Safaricom</title>
    <link rel="stylesheet" href="/styles.css">
  </head>
  <body>
    ...
  </body>
</html>

The response includes:

Status code: 200 OK means success. 404 means not found. 500 means the server had an error.
Headers: Tell the browser the content type, caching rules, and other metadata.
Body: The actual HTML content of the page.

Step 5: Rendering, painting the page on your screen

Your browser receives the HTML and starts rendering. But the HTML file alone is not enough. It references other resources: CSS files for styling, JavaScript files for interactivity, images, and fonts.

The browser makes additional HTTP requests for each resource it discovers:

Parse HTML: The browser reads the HTML from top to bottom, building the DOM (Document Object Model), a tree structure representing every element on the page.
Fetch CSS: When it encounters a <link> tag, it fetches the CSS file and builds the CSSOM (CSS Object Model).
Fetch JavaScript: When it encounters a <script> tag, it fetches and executes the JavaScript. This can modify the DOM.
Render tree: The browser combines the DOM and CSSOM into a render tree that represents what actually needs to be painted.
Layout: The browser calculates the position and size of every element.
Paint: The browser draws pixels to your screen.

A typical webpage makes 50 to 100 HTTP requests to load all its resources. Modern browsers make many of these requests in parallel to speed things up.

The physical infrastructure underneath

All of this runs on physical hardware. When you load a website from your phone in Nairobi, here is the physical path your data might take:

Your phone connects to a cell tower via radio waves.
The cell tower connects to your ISP's network via fiber optic cables.
If the server is hosted in the US or Europe, the data travels through undersea fiber cables. Kenya connects to the global internet through several submarine cables landing in Mombasa, including SEACOM and The East African Marine System (TEAMS).
The data reaches the server in a data center, which is just a building full of computers.
The response travels back the same path in reverse.

CDNs (Content Delivery Networks) like Cloudflare reduce this distance by caching copies of websites on servers around the world. If there is a CDN server in Nairobi, your request might never leave the country, which is why some sites load faster than others.

Understanding this physical layer helps you reason about latency. A server in Cape Town will respond faster to a user in Nairobi than a server in Virginia, which is why where you deploy your app matters.