DEV Community: Timi

It's a good day to learn more about CDNs

Timi — Mon, 23 Mar 2026 10:24:47 +0000

Timi

Mar 17

Understanding CDNs (Content Delivery Networks)

#performance #webdev #cdn #frontend

Comments 10

5 min read

How CDNs have improved how we get data from the internet

Timi — Thu, 19 Mar 2026 08:09:38 +0000

Understanding CDNs (Content Delivery Networks)

Timi ・ Mar 17

#performance #webdev #cdn #frontend

Understanding CDNs

Timi — Tue, 17 Mar 2026 07:54:04 +0000

Understanding CDNs (Content Delivery Networks)

Timi ・ Mar 17

Understanding CDNs (Content Delivery Networks)

Timi — Tue, 17 Mar 2026 07:53:40 +0000

I said I'd be writing about concepts I've frequently come across but never really stopped to properly understand. Today it's CDNs(Content Delivery Networks)

This one is interesting because it's not just something I've seen in everyday SPAs. I keep running it across tools and services I actually work with, and at some point I had to sit down and figure out what exactly is going on here.

So what is even a CDN?

At a high level, it's a system that makes sure your content gets to users faster, no matter where in the world they're requesting from.

Here's the version I had in my head before digging in:

It has something to do with caching. Data is being served from the edge of a network. Some technologies take advantage of CDNs to deliver their content faster

That's... not wrong. But it was pretty vague. Let me break it down properly.

The problem CDNs Solve

Let's say you deploy a web app and your server is sitting somewhere in the United States, Frankfurt, or wherever Vercel spins things up.

Now a user in Lagos, Nigeria opens your app.

Without a CDN, their request has to travel all the way from Lagos, across the Atlantic, to that server in the US, back across the Atlantic, back to Lagos. Every single time.

That round trip adds latency. And Latency is just the time it takes for data to travel from point A to point B and back again.

WITHOUT CDN

Now here's the part that really made me wonder, If it's all over the internet, why does distance matter?

It matters because the Internet is not magic. It runs on physical infrastructure: fiber optic cables, routers, submarine cables under the ocean, data centers. And even though signals travel as the speed of light through those cables, light still takes time to cross an ocean. Add in routers, the hops between networks, the processing at each stop and it all adds up.

Milliseconds, yes. But milliseconds matter when you're trying to build software that feels fast.

How a CDN fixes this

CDN providers have servers distributed all over the world, what are called edge servers. Instead of every request going back to your main server(the origin server),users get served from the closest edge server to them.

WITH CDN

Here's how it actually plays out. A user in Lagos, Nigeria requests your website. Instead of that request flying across the Atlantic, it hits an edge server somewhere nearby, If the provider has a presence in Lagos, It could be served right there. If not, the next closest option maybe somewhere else in West Africa. The point is it stays regional, not transatlantic.

If it's a cache hit, the content is already sitting on that edge server. It returns immediately. The origin server in the US doesn't even know the request happened.

If it's a cache miss, the edge server doesn't have it yet. It goes back to the origin, fetches the content, returns it to the user, and stores a copy so the next person requesting from that region gets it instantly.

That's the loop. Origin server holds the actual content. Edge servers hold cached copies and serve them to whoever is closest.

Worth noting here: What gets cached on edge servers is generic content, your HTML pages, images, JS bundles, stuff that looks the same for every user, User- Specific data like dashboards, auth states, or anything behind a login doesn't go through this path. That's a distinction CDNs and the developers configuring them are very deliberate about.

Each edge location serves the users closest to it. The origin only gets hit when and edge server needs to refresh its cache or sees content for the first time.

How this shows up in the tools we actually use

This is where it got relatable for me. CDNs aren't just a infrastructure concept. They are baked into services I use daily as a developer.

Cloudfare is probably the most obvious one. A huge part of what Cloudfare does is sit in front of your origin server and intercept requests. They have edge servers in cities all over the world, Lagos Included. When someone requests your site. Cloudfare serves cached content from the nearest location. Your origin doesn't really have to bother returning it.

Sanity is one I also noticed more recently. Sanity's main servers aren't in Nigeria, but when someone here requests content from sanity. It doesn't travel across the world. It comes from Sanity's CDN edge server, which is much closer. although sanity even does something interesting by exposing a flag know as useCDN:true/false, As an engineer I can either opt to fetch content straight from the origin or edge, Cool right?

Vercel and Netlify(popular host providers) have this built in too. When you deploy a static site or use edge functions, you're not really deploying to one server. You're deploying to their edge network. That's partly why deploys feels like magic; your content is already near you before the first request even lands.

As a developer, what does this actually mean for you?

Now that I have a better mental model of how this works, a few things I've run into as an engineer started clicking:

Cache invalidation is a real thing. When I update content, edge servers might still be serving the old cached version. Some platforms handle this automatically on deploy, others require explicitly purging the cache. I've pushed updates using a Content management system and wondered why users were still seeing the old version. Turns out the edge servers just hadn't caught up yet.

Another thing worth understanding is Cache-Control headers. The server can include instructions on how long content should be cached when it sends a response. For content that changes often, short cache times or none at all. For static assets like images, fonts, and JS bundles, cache aggressively. Getting this right means the CDN works with the app, not against it.

And not everything should be cached, this one is easy to miss. User-specific data, auth responses, anything that varies per person. None of that should be sitting on and edge server. CDNs shine brightest with static assets and content that looks the same regardless of who is asking for it.

Wrapping Up

CDNs exist because the internet, while fast, is still physical and distance adds latency. Instead of every user talking to one origin server far away, CDNs distribute copies of your content across edge servers worldwide so users get it from somewhere close to them.

You're almost certainly using a CDN if you're deploying on modern infrastructure. But understanding how it works helps you make smarter decisions about caching, about content structure, about why your users in one region are having a different experience than users somewhere else.

Let me know if you add have anything to add in the comments or any push back, would love to discuss it. And when I find something else I use every day but never really understood, I'll be back. Soon. Very soon. Byeeeeee

Nice read

Timi — Mon, 09 Mar 2026 17:29:50 +0000

How to Optimize SEO with Next.js in 2026

Suraj Vishwakarma for Texavor ・ Mar 5

#webdev #javascript #react #beginners

[Boost]

Timi — Mon, 02 Mar 2026 12:13:54 +0000

Client Side Rendering vs Server Side Rendering

Timi ・ Mar 2

#react #nextjs #webdev #learning

Client Side Rendering vs Server Side Rendering

Timi — Mon, 02 Mar 2026 11:00:00 +0000

Lately I've decided to keep mental notes of everyday concepts I use in my work. Most times I have a good overview of what a concept does but I never really understood what goes on under the hood. I mean, it works innit. But I'm taking a step further with some of those concepts, and today's subject is all about Client Side Rendering(CSR) and Server Side Rendering(SSR).

Before SSR was a thing

We all know how wonderful Single Page Applications(SPAs) are, but to really appreciate SSR, we need to go back a little.

So basically, the traditional way of displaying content on the internet is this little relationship that happens between the client, which is your browser and the server, whatever web hosting platform your content lives on.

The browser asks the server for a page, the server returns an index.html with a <script> tag at the bottom pointing to a main.js file, the browser then makes another request to fetch that main.js and executes it.

<!-- index.html -->
<div id="root"></div>
<script src="/main.js"></script>

If you look closely at that main.js, you will find something like this

ReactDOM.createRoot(document.getElementById("root")).render(<App />);

This is where React takes over. It runs your components, converts JSX(JavaScript XML) into JavaScript objects, what we call the Virtual DOM, and then converts those JavaScript objects into actual DOM nodes the browser can display.

So your JSX that looks like this:

jsx
`<h1 className="title">Hello World</h1>`

gets converted into a Javascript object like this:

js
{
type: "h1",
props:{
className: "title",
children:"Hello World"
}
}

That's your virtual DOM right there, just a plain JavaScript object describing what the UI should look like. React then takes that object and creates an actual DOM node from it:

js
HTMLHeadingElement: node.textContent = "Hello World"`

And appends it to the #root div. Boom, the browser displays it. That's basically CSR.

State updates and reconciliation

Now a huge part of any UI is state: counter, cart items, form inputs, all of that. When state updates, React doesn't re-download main.js and redo everything from scratch; that would be crazy expensive.

What React actually does is look at the component where the update happened, build a new virtual DOM, compare it to the previous one, find what changed, and update only those nodes in the actual DOM. The process is called reconciliation and it's honestly wild how all of this happens without a full page refresh.
And that whole process I just described, the browser downloading JS, React building the virtual DOM, reconciliation and all — that's Client Side Rendering.

Then SSR came along

SSR is so beautiful because it offloads a huge chunk of this work from the browser and just does it on the server instead.

Now "the server" can sound confusing, but here is the thing, JavaScript can run in two primary environments: the browser and Node.js. So in SSR, it's Node.js doing all the heavy lifting.

Here's what happens when you request a page:
The Node.js server runs React, calls your component function, parses JSX, builds the virtual DOM and converts everything into readable HTML, then sends that fully structured HTML straight to the browser. The browser receives real HTML and can display it immediately, no waiting for JS to build everything from scratch.

html
<div id="root">
<h1>Hello</h1>
<p>This came from the server</p>
</div>

But that's not the end of it. In the background the JavaScript bundle also loads, and once it does, hydration happens.

Okay but what even is hydration?

Hydration is basically the process of attaching interactivity, specifically event listeners, to the HTML the server already sent. Think of it like the server sending you a fully built house, and hydration is the electrician coming in afterwards to wire everything up.

In CSR, React uses createRoot which builds everything from scratch. In SSR, React uses hydrateRoot which assumes the DOM already exists, all it does is recreate the virtual DOM and attach event handlers to the right elements.

js// CSR - builds from scratch
ReactDOM.createRoot(document.getElementById("root")).render(<App />);

// SSR - assumes HTML exists, just wires it up
ReactDOM.hydrateRoot(document.getElementById("root"), <App />)

So How does this affect how I write Next.js Code

Next.js does SSR by default. Every component runs on the server first, even ones marked with "use client" directive. The difference is that "use client" tells the compiler that this component needs to be hydrated on the client so it can handle interactivity.

So the rule is simple, anywhere you need state, effects, browser APIs like document.querySelector or even event listeners, add "use client" at the top of the file. If you don't, your code will be trying to access browser APIs that don't exist on the server and you will be staring at errors wondering what went wrong.

"use client";

import { useState } from "react";

export default function Counter() {
  const [count, setCount] = useState(0);
  return <button onClick={() => setCount(count + 1)}>{count}</button>;
}

So what does this mean for how I build components

Honestly this is the part that changed how I think at work. Once you understand CSR and SSR, you stop throwing use client everywhere and start asking, does this component actually need to run on the client?

The mistake I made early on was throwing use client at the top of every component. It just felt like the thing to do coming from plain React. But once I understood what was actually happening under the hood, I realized I was basically opting out of SSR everywhere and losing all the performance benefits for free.

A good rule of thumb, if a component just displays data with no clicks, no state, no user interaction, leave it as a server component. Only reach for use client when the component actually needs to respond to the user. That way the browser only handles what it truly needs to.

Wrapping up

It's honestly crazy how much is happening under the hood every time a page loads. Understanding this whole flow — CSR, virtual DOM, reconciliation, SSR, hydration — really changed how I think about building components and where I put my logic.

Let me know what part clicked for you or if there's anything you'd push back on — I'd really love to hear it.
See you next time. Byeeee