Web Perf

It is 9:58 AM and Tatkal booking opens on IRCTC in two minutes. You refresh the page. The train-search screen appears almost instantly — but the moment you hit "Book Now," the page freezes for what feels like forever while a spinner turns. Two days later, during an India vs Pakistan T20 match, you open a live-score website and the score updates the instant a six is hit, no lag at all. Both pages ran over the exact same 4G connection on the exact same phone. So why did one feel instant and the other feel broken?

The honest answer is not "the internet was slow." Your internet connection was identical in both cases. What differed was how much work each webpage asked your phone and the network to do before it could show you something useful. That is the entire subject of this chapter: web performance — the study of why webpages take the time they take to load, and the concrete techniques engineers use to make that time shorter. This is not a vague "make things fast" topic; it has precise, measurable causes, and every one of them can be calculated with the arithmetic and algebra you already know.

What "loading a page" actually means

Before you can talk about making something faster, you need to know exactly what happens between typing a web address and seeing the page. Think of visiting a website like ordering at a restaurant counter instead of a full-service restaurant:

• You tell the counter your order (this is your browser sending a request for a web address).
• The kitchen sends back a menu card first — a short document describing what the full meal will contain (this is the HTML file: the skeleton of the page, listing which images, style rules, and scripts it needs).
• Only after reading the menu card does the counter start bringing the actual dishes — the curry, the rice, the pickle — one tray at a time (these are the CSS stylesheets, JavaScript scripts, images, and fonts the HTML referred to).
• You cannot properly "see" the meal until enough of these trays have arrived and been arranged on your table (the browser rendering the page — turning downloaded files into pixels on your screen).

Every one of those steps takes real, measurable time, and a slow page is almost always slow because one or more of these steps is doing far more work than it needs to.

The browser's step-by-step recipe

More precisely, here is what your browser does, in order, the moment you open a page:

1. DNS lookup: your browser doesn't know the numeric address (IP address) of, say, cricbuzz.com, so it asks a directory service (DNS) to translate the human-readable name into an address — like looking up a name in a phone directory to find the number to dial.
2. Connect: the browser opens a connection to that address, and for secure sites (the little padlock, HTTPS) it also performs a security handshake to set up encryption.
3. Download the HTML: the browser requests the page and receives the HTML file.
4. Parse the HTML and discover more resources: as the browser reads the HTML top to bottom, it finds tags like <link rel="stylesheet"> and <script> and <img>, and immediately requests each one — often several at the same time, not strictly one after another.
5. Build the page and paint it: once enough CSS has arrived, the browser combines it with the HTML structure to work out where everything goes (this step is called layout), and then draws the actual pixels (called paint).

Two rules inside this sequence matter enormously for speed, and they are the source of a very common misunderstanding, so let's name that misconception directly.

Misconception to correct: "The browser downloads the page's files one at a time, in the exact order they appear in the HTML." This is false. Modern browsers open several connections at once and download many files in parallel. What is true, and what actually causes slowdowns, is that some resources are render-blocking: the browser refuses to paint anything on screen until all the CSS has arrived, because CSS can completely change how the page should look, and painting the "wrong" version first would cause an ugly flash. Similarly, a plain <script> tag (without special attributes) pauses HTML parsing entirely until that script has been downloaded and run, because the script might use JavaScript to rewrite the page. Images, by contrast, are not render-blocking — the page can appear with blank boxes where images will soon pop in. So the real bottleneck for "time until you see something" is usually CSS and blocking JavaScript, not the total number of files.

Here is a simplified timeline (a "waterfall," which is exactly what the Network tab in browser developer tools shows you) for a typical news or score page:

Notice the shape: the page cannot be painted until the CSS has fully arrived and the blocking JavaScript has finished downloading and running — that is why "first paint" happens at roughly 340ms in this example, not at 170ms when the HTML itself finished downloading. The images keep streaming in afterward without holding up the rest of the page. This single diagram explains why a page stuffed with blocking scripts before the visible content feels slow even when its images are small, and why moving scripts to the end of the page (or marking them defer) is one of the single most effective speed fixes a developer can make.

Measuring speed with a formula you already know

Once the browser is actually downloading a file, how long does that take? This part is genuinely simple arithmetic:

Time = Data Size ÷ Connection Speed

The catch that trips up almost everyone the first time is units. File sizes are measured in bytes (kilobytes, KB; megabytes, MB), but internet speeds advertised by Jio, Airtel, or your Wi-Fi router are almost always given in bits per second (kilobits, Kbps; megabits, Mbps). One byte equals 8 bits, so a "20 Mbps" connection can move at most 20 ÷ 8 = 2.5 megabytes per second — not 20 megabytes. Mixing these up is probably the single most common web-performance misconception, and it is worth naming explicitly:

Misconception to correct: "My plan says 20 Mbps, so a 20 MB file downloads in 1 second." It does not — it takes about 8 seconds, because Mbps counts bits, while MB counts bytes, and there are 8 bits in a byte.

Let's work a full example the way you would see it stated in an exam question. Suppose a live cricket-score webpage has a total page weight (the sum of its HTML + CSS + JavaScript + images, all added together) of 2,400 KB, and your phone is connected to 4G at a fairly typical speed of 8 Mbps.

Step 1 — convert the speed to bytes per second. 8 Mbps ÷ 8 = 1 megabyte per second (1 MBps), ignoring the small overhead of headers and protocol handshakes for now.

Step 2 — convert page weight to megabytes. 2,400 KB ÷ 1,024 ≈ 2.34 MB (using 1 MB = 1,024 KB, the standard binary conversion used by operating systems and browsers).

Step 3 — apply the formula. Time = 2.34 MB ÷ 1 MBps = about 2.3 seconds.

Now suppose the site's engineers compress and optimize their images and scripts, cutting the total page weight down to 800 KB (about 0.78 MB). The same calculation gives Time = 0.78 ÷ 1 = about 0.78 seconds — nearly three times faster, on the exact same 4G connection, with zero change to the network. This is the core lesson of web performance: the size of what you send matters just as much as the speed of the pipe it travels through, and it is the one variable a web developer, not a telecom company, actually controls.

Bandwidth is not the same thing as latency

There is a second, separate quantity hiding inside every page load, and confusing it with speed is another common mistake. Imagine a water pipe: its bandwidth is how wide it is — how many litres per second it can carry once water is flowing. Its latency is completely different: it's how long you wait after opening the tap before any water arrives at all, which depends on the length of the pipe, not its width. A garden hose 2 metres long and a garden hose 200 metres long can have the exact same width (same bandwidth), but water reaches the end of the short one far sooner (much lower latency).

On the internet, latency is dominated by physical distance, because signals in fibre-optic cable travel at roughly 200,000 kilometres per second (about two-thirds of the speed of light in a vacuum, slowed down by the glass). That number lets you calculate something surprising with nothing more than the "distance ÷ speed = time" formula from your physics chapters.

Say a website's main server sits in a data centre in the eastern United States (a common hosting location for global websites), roughly 13,000 km from Mumbai by fibre route. One round trip — your request going out, the reply coming back — covers about 26,000 km. Time = 26,000 km ÷ 200,000 km/s = 0.13 seconds, or 130 milliseconds, and that is the theoretical minimum: real measurements are usually higher, often 200–250 ms, because signals don't travel in a perfectly straight line and pass through many routers along the way. And a single page load needs several round trips in sequence — DNS lookup, connection setup, the HTTPS security handshake, then the actual request — so this 200ms-ish delay can easily repeat three or four times before a single byte of the actual page arrives, even before the Time = Size ÷ Speed calculation from the previous section even begins.

This is exactly the problem a Content Delivery Network (CDN) solves. A CDN keeps copies of a website's files on servers scattered across many cities, so instead of every Indian visitor's request travelling all the way to the US, it is served from a nearby edge server — say, one in Mumbai or Chennai, roughly 1,300 km from a user in Delhi. Redo the same calculation: round trip distance about 2,600 km, Time = 2,600 ÷ 200,000 = 0.013 s, about 13 milliseconds at minimum, realistically perhaps 20–40 ms in practice. That is roughly five to ten times less delay than reaching the US directly — which is precisely why large Indian platforms serving live cricket scores, exam results, or festival-sale traffic route their static files through CDN edge servers inside or near India rather than a single distant origin server.

Why many small files can be worse than a few larger ones

Every new request a browser makes — even for a tiny 2 KB icon — pays some of that round-trip latency cost before the file itself even starts arriving. Modern browsers reduce this pain by opening several connections at once (commonly around six per website) and by using a newer protocol, HTTP/2, that can carry many requests over a single connection simultaneously (called multiplexing). But even multiplexed requests still each carry a small fixed overhead in server processing and protocol bookkeeping. This is why professional web developers often combine many tiny files into fewer, larger ones — for example, merging dozens of small icons into a single "sprite sheet" image, or bundling twenty small JavaScript files into one — rather than assuming "the total number of bytes is all that matters." It is not a story of a single request being disastrous today the way it might have been a decade ago; it's a smaller, cumulative tax that still adds up across a page with hundreds of tiny files.

Shrinking the files themselves: minification and compression

The most direct lever a developer has is simply making files smaller before sending them. Minification strips out everything a computer doesn't need but a human reading the source code finds convenient — extra spaces, line breaks, comments, and long variable names. Consider this small CSS rule, written the way a person would naturally format it:

.header {
  background-color: #003366;
  padding: 20px;
}

Counted character by character, including every space and line break, that snippet is 57 characters. A minifier removes the formatting a browser never needed in the first place:

.header{background-color:#003366;padding:20px}

This version is 46 characters — a saving of 11 characters, or about 19%, on this one tiny rule alone. A real stylesheet contains thousands of such rules, so the same percentage-scale saving applies across the whole file. On top of minification, servers typically also apply gzip compression, an algorithm that finds repeated patterns in text (and CSS, HTML, and JavaScript are extremely repetitive — the words background-color, padding, and punctuation like { } : ; appear over and over) and replaces repeats with short references. Because of this repetition, text-based web files typically compress very well, commonly shrinking by roughly 60–80% of their original size, whereas an already-compressed file like a JPEG photo barely shrinks further under gzip, because it has little repetition left to exploit.

Images: usually the single biggest cost on a page

On most real websites, images make up the majority of total page weight — often more than everything else combined. Three separate, additive habits control image cost:

Choosing the right format. JPEG uses lossy compression well suited to photographs (it throws away detail the human eye barely notices), while PNG uses lossless compression better suited to graphics with sharp edges, text, or transparency, and typically produces a larger file for a photo than JPEG would. Newer formats such as WebP generally compress photographic images noticeably smaller than JPEG at similar visual quality, which is why many Indian shopping and news sites have switched to serving WebP images to phones that support it.

Sending images at the size they'll actually be displayed. A photo captured at 4000 by 3000 pixels but shown in a 300-pixel-wide thumbnail is wasting almost all of its data — the browser downloads the full high-resolution file and then shrinks it, when the server could have resized it once and sent the smaller version to every visitor.

Lazy loading. Instead of downloading every image on a long page immediately, the browser can wait until an image is about to scroll into view before requesting it. Consider a page with 30 product photos, each 200 KB, for a total of 6,000 KB. A visitor on a limited prepaid data pack who scrolls through only the first 5 photos before leaving downloads just 5 × 200 = 1,000 KB with lazy loading, instead of all 6,000 KB — a saving of 5,000 KB, or about 83% of that page's image data, for a visitor who never even looked at the rest.

Remembering repeat visitors: caching

The very first time you open a website, the browser must download everything. But most files — a site's logo, its CSS, its script bundle — don't change from one visit to the next. Servers can attach instructions (called cache headers) telling the browser "store this file locally and don't ask for it again for the next 30 days." On your second visit, the browser skips the network entirely for those files and reads them straight from your phone's storage, which is essentially instant compared to a network round trip.

Returning to our earlier numbers: a first visit downloading the full 2,400 KB page took about 2.3 seconds. If 2,350 KB of that (the logo, CSS, JS, and images) is now served from cache and only 50 KB of genuinely new content (say, the day's updated headlines) must be downloaded, the second visit's time becomes roughly 50 ÷ 1,024 MB ÷ 1 MBps ≈ 0.05 seconds — about 50 milliseconds, nearly 45 times faster than the first visit. This is exactly why a news site you check every morning feels almost instantaneous after the first load of the day, even on a modest connection.

Practice: test yourself

1. A webpage weighs 3,600 KB in total. Your connection speed is 12 Mbps. First convert the speed to megabytes per second, then calculate the download time in seconds.
2. After optimization, the same page is reduced to 900 KB. What is the new download time on the same connection, and by what percentage did the load time improve?
3. A student says, "My plan is 40 Mbps, so a 40 MB file should download in exactly 1 second." Explain precisely why this reasoning is wrong, and calculate the correct approximate time.
4. Explain, using the pipe analogy, why a site hosted very close to you can still load slowly if the server itself is overloaded — that is, why low latency does not guarantee high bandwidth.
5. A page loads a render-blocking CSS file and a render-blocking script one after another before any content appears. Suggest one concrete change (referencing what you learned about the loading pipeline) that would let the visible content appear sooner.

Answers: (1) 12 Mbps ÷ 8 = 1.5 MBps; 3,600 KB ÷ 1,024 ≈ 3.52 MB; 3.52 ÷ 1.5 ≈ 2.3 seconds. (2) 900 KB ÷ 1,024 ≈ 0.88 MB; 0.88 ÷ 1.5 ≈ 0.59 seconds; improvement = (2.3 − 0.59) ÷ 2.3 ≈ 74% faster. (3) The student confused bits with bytes: 40 Mbps is 40 megabits per second, and a megabyte is 8 megabits, so the true speed is 40 ÷ 8 = 5 MBps, giving a time of 40 ÷ 5 = about 8 seconds, not 1. (4) The pipe (bandwidth) analogy: distance controls only how long before the first drop of water arrives (latency); it says nothing about how much water the pipe can carry per second once flowing. A nearby but overloaded server can respond quickly at first yet still have a "narrow pipe" — limited bandwidth or slow processing — making the actual transfer or the server's own response generation slow regardless of the short distance. (5) Move the script to the end of the HTML (or mark it with defer/async) so it no longer pauses HTML parsing, and/or reduce or split the CSS so the render-blocking portion needed for the first visible screen is smaller and arrives sooner.

Summary

A webpage's speed is not a single mysterious number handed down by your internet provider — it is the sum of several separate, calculable quantities you now know how to work with. Page weight (measured in KB/MB) divided by bandwidth (measured in Mbps, remembering the 8-bits-per-byte conversion) gives raw transfer time. Latency, driven by physical distance and the finite speed of light in fibre, adds a fixed delay per round trip that a CDN can shrink by moving servers physically closer to users. The browser's loading pipeline treats CSS and unmarked scripts as render-blocking, so what a page shows first depends on the order and blocking behaviour of its resources, not just their total size. And developers actively fight page weight and request count using minification, compression, correctly-sized and correctly-formatted images, lazy loading, and caching — each of which you can now quantify yourself with nothing more than division and percentages.