Lesson 0.3 · 10 min read
Here's something you already know in your body, even if you've never put words to it.
You've abandoned a website because it was slow. Not broken. Not ugly. Just slow. It sat there with a spinner, and after a couple of seconds something in you gave up and hit back. You've done it hundreds of times, and hundreds of millions of people do it every day. Slowness is one of the most powerful forces in all of product design, and it is almost entirely invisible in a Figma file, where everything is instant and nothing ever has to travel anywhere.
But in a real product, everything has to travel. Every piece of content on your screen made a physical journey to get there, and that journey took time, and that time is something your users feel whether or not they can name it. This post is about that journey and that time. By the end, you'll understand speed not as a vague quality but as a specific, measurable thing with specific causes, which means it becomes something you can actually design and engineer, instead of something you just hope turns out fine.
Let's kill a myth first, because it quietly distorts how people think.
The internet is not a cloud. It's not floating. When your data goes "to the cloud," it goes to a warehouse full of computers in a specific city, and it gets there through actual cables buried in actual ground and lying across the actual ocean floor. There are physical fiber optic cables running along the bottom of the Atlantic and Pacific, thousands of kilometers long, carrying almost all of the world's internet traffic between continents as pulses of light. When you load a website hosted in another country, your request physically travels through those cables and back.
This matters for one reason that shapes everything else: physical distance takes time. Light is fast, unimaginably fast, but it is not instant, and the internet's cables don't run in perfectly straight lines. So a request from a user in Mumbai to a server in Virginia has to physically cross the planet and come back, and no amount of clever code can beat the speed of light across that distance. The moment you accept that the internet is a physical place with real distances, speed stops being mysterious. It has a geography.
Now, how does the data itself move? Not all at once, and this is a genuinely clever piece of design worth understanding.
When you send or receive something over the internet, a photo, a video, a page, it doesn't travel as one big blob. It gets broken into many small pieces called packets. Each packet is wrapped with information about where it's going and which piece of the whole it represents, then sent off on its own. The packets can even take different routes across the network, and they often arrive out of order. At the destination, they're reassembled back into the original thing, in the right sequence, using the labels they carry.
Imagine mailing a thick book to a friend, but instead of one heavy parcel, you tear out every page, put each in its own envelope numbered "page 1 of 400," "page 2 of 400," and drop them all in the post. They travel separately, maybe by different trucks, and arrive in a jumble. Your friend sorts them by number and rebuilds the book. It sounds absurd for a book, but for data it's brilliant, because it means the network doesn't need one clear uninterrupted path for your whole file. It just needs to get lots of little pieces through, however they can travel, and reassemble at the end.
This also quietly explains a daily experience. When a download stalls at 80% and then resumes, it didn't restart. The packets that already arrived are safe. It just needed the missing ones. And when a video call gets briefly blocky, that's a handful of packets that got lost or delayed, and the call carried on without waiting for them, because for a live call, "keep going" beats "wait for every piece."
Now we get to the heart of it. When people say a connection is "fast," they almost always blur together two completely different things. Pulling them apart is one of those small pieces of knowledge that instantly makes you sharper than most people talking about performance, including many developers.
The first number is bandwidth. This is how much data can move through the connection at once. It's the width of the pipe, or better, the number of lanes on a highway. High bandwidth means many lanes, so a lot of cars can travel side by side. This is what matters for big things: streaming a 4K movie, downloading a large file, loading a page heavy with images. More bandwidth, more data flowing in parallel.
The second number is latency, and this is the one that quietly rules user experience. Latency is the delay before data starts arriving. It's not about how much can flow; it's about how long you wait for the first thing to show up. On the highway, latency isn't the number of lanes, it's how long it takes a single car to drive from one city to the other. You can add a hundred lanes and the drive still takes the same time. Latency is about distance and the number of stops along the way, not width.
Here's why this distinction is the whole game. People obsess over bandwidth, the "how many megabits" number in an internet plan, but most of what makes an app feel slow is latency. When you tap a button and the app hesitates before responding, that's usually not bandwidth. The amount of data is tiny. It's latency: the little round trip to the server and back, the wait for the first response. An app can be on a blazing fast connection and still feel sluggish if it makes too many high-latency trips. Understanding this saves you from the most common performance mistake there is: throwing bandwidth at a problem that was actually about latency.
Let's connect this back to the journey from the first post, because now you can see the cost of it.
Remember the round trip: the client sends a request, it travels to the server, the server works, the response travels back. Every one of those round trips costs latency. And here's the trap that catches so many products: a single screen often doesn't make one trip. It makes many. It asks for your profile, then your settings, then your feed, then the images in the feed, then the notification count, each potentially its own round trip to the server. If each trip costs, say, 100 milliseconds of latency, and they happen one after another, the delays stack into something the user absolutely feels as a slow, janky load.
This is why so much of real engineering is about respecting the cost of a trip. Making fewer, smarter requests instead of many chatty ones. Asking for everything you need in one go rather than in ten separate conversations. Fetching things in parallel, all at once, instead of one after another, so their latencies overlap instead of adding up. These aren't obscure optimizations. They're the difference between an app that feels instant and one that feels like wading through mud, and they all come from taking latency seriously as a real, accumulating cost.
So if physical distance causes latency, and a user in Sydney is genuinely far from a server in London, what do you do? You can't move the user, and you can't beat the speed of light. There's one obvious answer left: move the content closer to the user.
This is exactly what a CDN, a Content Delivery Network, does, and it's one of the most important pieces of infrastructure on the modern internet. A CDN keeps copies of your content, your images, videos, and other unchanging files, on servers scattered all over the world, in dozens or hundreds of cities. When someone in Sydney asks for an image, they don't reach across the planet to London. They get it from a copy already sitting in a server in Sydney, a few milliseconds away. The distance collapses, and the latency with it.
Think of a popular book. If there were only one copy, in one library in one country, everyone on Earth would have to wait for it to be shipped to them, slowly, from far away. Instead, we print copies and stock them in local libraries everywhere, so almost everyone has one nearby. A CDN does that for the internet's content: it stocks local copies of your files close to your users so nobody has to reach across the world for something that could be sitting around the corner. This is why a well-built global product can feel fast whether you're in Toronto or Jakarta, and it's a genuine architectural decision someone made on purpose, not luck.
Notice, too, that a CDN works best for the static content from the last post. The unchanging files, the ones that are the same for everyone, are exactly the ones you can safely copy and stock all over the world. The dynamic, personal content still has to be built fresh by the server. See how the ideas are already stacking on each other? Static versus dynamic wasn't just a concept. It directly shapes what you can and can't make fast this way.
I've saved the most important point for last, because it's the one that turns all of this from engineering trivia into your actual job.
Speed is not a technical detail that happens after design. Speed is design. It is one of the most emotionally powerful properties of any product you'll ever build, and it's decided by exactly the things we just covered: how far the data travels, how many trips you make, how much you send, and how cleverly you bring things closer. The research on this is brutal and consistent. As a page's load time climbs from one second to three, the share of people who give up and leave rises sharply. Every added second of delay measurably costs engagement, conversions, and money. Users don't file a complaint about latency. They just quietly leave, and you often never even know why.
Here's what that means for you as a design engineer, and why understanding this puts you ahead of a designer who only works in Figma. You can now anticipate slowness before it exists. When you're designing a screen that needs data from five different places, you know, right then, that this is five potential round trips and a real risk to how the screen will feel, and you can design around it: ask for less, show something immediately while the rest loads, combine the requests. When you choose to fill a page with enormous high-resolution images, you know you're spending bandwidth and can decide if it's worth it. You're no longer designing pictures of products that happen to be instant because Figma is a fantasy where nothing travels. You're designing real experiences with a real, physical cost, and you're accounting for that cost while you design, which is precisely what an engineer does.
That instinct, feeling the weight of data as you design, is one of the most valuable things you'll take from this entire module. Speed was always a design decision. Now you know enough to actually make it.
Do this before the next post
Go back to that Network tab from the first post. Open any website, open the inspector, go to Network, and reload.
This time, look for two specific things. First, near the bottom or top of the panel, find the total load time and the number of requests. You'll often see a page you thought of as one thing quietly made forty or fifty separate requests. That's forty or fifty little journeys, each with its own latency. Second, find the column that shows how long each request took, and notice how they vary. Some finished in a blink. Some took a surprisingly long time. You're looking directly at latency and bandwidth playing out, request by request, on a real page.
Now reload the page a second time and watch it get faster. That's caching, content that was fetched once and kept close, so it didn't have to travel again. You just watched, with your own eyes, nearly every idea in this post happen in under two seconds. That panel has quietly become one of the most educational tools you have.