CDN, serverless and the edge: a site closer to the visitor

A CDN is a network of servers that serve a site’s files from a node near the visitor. Serverless runs functions on a platform, the edge runs them on CDN nodes.

Light is not infinitely fast

You chose a host in Virginia, and in Virginia the site opens instantly. From Seattle the picture is different. A signal in an optical fiber travels about two hundred kilometers (a hundred and twenty-five miles) in a millisecond, and the straight line from Seattle to Virginia is about 3,700 kilometers (2,300 miles). Add the detours along the way. To show one page, the browser and the server exchange messages several times (the connection, the encryption, the request itself), and every exchange is a round trip. The result is a delay that neither fast markup nor a powerful server can fix: the distance is to blame.

The solution is simple in idea: put copies of the files closer to people. That is what a CDN (a content delivery network) does.

How a CDN works

A CDN is many servers in different cities (called nodes, or points of presence). Your real server, where the site lies, is called the origin in this scheme. After that it goes like this.

1. The site’s address in DNS leads to the CDN, not straight to your server.
2. The visitor arrives at the nearest node.
3. If the node has a copy of the file, that is a hit: the node answers by itself and your server isn’t disturbed.
4. If there is no copy, that is a miss: the node goes to the origin, gets the file, gives it to the visitor and keeps it for the period you set.

There are three gains at once: the nearest node answers faster, your server survives a rush of visitors, and a CDN usually also takes over HTTPS, compression, the HTTP/2 and HTTP/3 protocols and protection against some attacks. That is why the static hosting you chose in the first lesson almost always already sits behind a CDN.

Play with the distance: choose the visitor’s city and the server’s place, switch the CDN on, and see how the time changes. It’s a teaching model, not a measurement, but the shape of the picture is right: the gain is biggest for far cities, and a miss costs almost as much as having no CDN.

The visitor is in SeattleLos AngelesDenverChicagoNew YorkMiamiLondon The site’s server Ashburn, VirginiaFrankfurt

No CDN With a CDN (Los Angeles, Chicago, New York, London)

The copy is already in the cache (a hit) The first request (a miss)

The nearest node: Los Angeles, about 1546 km. The copy is on the node: the site’s server isn’t involved at all. The start of the page load (connection, encryption, the first answer): roughly 81 ms.

The model: light in a cable travels about 200 km a millisecond, a real route is about one and a half times longer than the straight line, and the start of a page takes three round trips. All the page’s other requests gain too.

A new version was published

What we cache HTML for a dayHTML for 5 minutesHTML with revalidationCSS with a hash in its name, for a yearA page with personal data The cache was purged on publishing

Minutes after publishing: 10 min

Cache-Control: public, max-age=86400

The new version is already seen by 1% of visitors. In short: fast, but an edit will only be seen tomorrow.

Check yourself: what happens on a cache miss?

The node goes to the origin, gets the file, gives it to the visitor and keeps it for the period you set. The next visitor gets the copy from the node.

What to cache, and for how long

A cache remembers an answer for as long as you allowed. The permission comes from the Cache-Control response header (you met headers in the lesson on HTTP):

• max-age=N: keep it for N seconds;
• no-cache: it may be kept, but before each showing ask the server whether it changed (if not, the server answers with a short 304 and no body);
• no-store: don’t keep it at all;
• private: it may be kept only in the person’s own browser, not by shared caches and CDNs;
• immutable: this file at this address will never change, don’t recheck it.

Three rules are enough for most sites.

1. Files with a hash in the name: a year. Images, fonts, CSS and scripts that a bundler builds get a fingerprint of their content in the name (app.3f9a1c.css). Editing the file changes the name, and the old copy bothers no one. So public, max-age=31536000, immutable suits them.
2. HTML: short, or with revalidation. A page is what you edit most often, and it links to the files with hashes. If you cache HTML for long, visitors will see neither your edits nor the new files. So no-cache, or a few minutes.
3. Anything personal: never in a shared cache. A page with a signed-in person’s name, a form’s answer, a cart: private, no-store. The well-known mishap where a cache showed one person another’s page starts with a forgotten header on a personal page.

If you need the new version to appear for everyone at once, there is the purge: a CDN command that means “forget this”. A good deploy purges the cache by itself (the lesson on CI/CD covers it).

Check yourself: why can a file with a hash in its name be cached for a year?

Because when the content changes, the name changes, and the browser simply won’t find the old copy under the new name. The old copy is harmless.

A function without a server

Say a static site needs a request form (your project’s main action). A program has to receive the data, and you have no server. This is where serverless helps: “computing without a server”.

The name doesn’t mean there are no servers. They exist, but the platform looks after them, and you upload a small function. The platform runs it when a request comes in, starts as many copies as needed, and bills you per call. If there are no requests, the function “sleeps” and costs nothing. Such platforms exist at the big clouds (the first was AWS Lambda, in 2014), at Cloudflare (Workers), at Vercel and Netlify, and elsewhere.

In return there are limits worth knowing in advance.

• The time of one call is limited, so long jobs aren’t for functions.
• There is no state: what a function remembered in one call may be missing in the next. Data goes into a database or a queue, or is passed on.
• A cold start: after a pause, the first call takes longer to start.
• Being tied to a platform: every provider has its own way of running things.

Code at the edge of the network

If a function runs not in one data center but right on the CDN’s nodes, that is called the edge. The code ends up next to the visitor and answers almost at once. What it is convenient for: redirects, checking whether a person is signed in, choosing a version of a page, swapping headers, a quick answer to a simple request.

The price is hard limits (little memory and time) and the distance to your data: if the database sits in Virginia, a function on a node in Seattle still goes to Virginia for it, and the gain disappears. So the edge keeps decisions that need no data, and work with data stays next to the data.

Here is such a function for a request form (in the style of Cloudflare Workers, though the idea is the same on any platform):

export default {
  async fetch(request, env) {
    if (request.method !== 'POST') {
      return new Response('POST only', { status: 405 });
    }
    const data = await request.formData();
    const name = String(data.get('name') ?? '').trim();
    const phone = String(data.get('phone') ?? '').trim();
    if (!name || !/^[+0-9 ()-]{6,20}$/.test(phone)) {
      return new Response('Check the fields', { status: 400 });
    }
    await fetch(env.WEBHOOK_URL, {
      method: 'POST',
      headers: { 'content-type': 'application/json' },
      body: JSON.stringify({ name, phone })
    });
    return new Response('Received', { status: 200 });
  }
};

What matters in it. It checks what arrives (data from a visitor can’t be assumed honest: you read about this in the lesson on forms). It keeps no secrets in the code: the receiver’s address comes from env, the service’s settings, and isn’t written into a page that everyone sees. And it answers with clear statuses: 405, 400, 200.

One more consideration, a non-technical one. The form takes a name and a phone number, and that is personal data. When you choose a platform for the function, you also choose where that data first lands, and privacy law (the GDPR for people in the EU, state laws in the US) follows the people, not the platform. So choose the function’s region on purpose, near your visitors, and make sure the service you forward the data to says where it keeps it. A note on the Russian market: there the law goes further and requires the first recording of Russian citizens’ data to be made in Russia, so such a form’s function runs in a Russian data center and the convenience of the edge doesn’t outweigh it (the last lesson of the part compares the rules).

Honestly: when you don’t need any of this

A CDN is almost always on by default, and you needn’t think about it if you publish to static hosting. You don’t need functions if a ready-made service receives the form. You don’t need the edge until you’ve found that the distance is what’s slow. Don’t add mechanisms ahead of time: each is one more thing that can break.

Practice

In this lesson you write down two decisions for your site. First: what to cache, for how long and how to purge it. Second: which function receives the project’s main action (a request, a booking, a calculation), and you finish its code. The code checks three things: the request method, a 400 answer for bad data, and the receiver’s address from the settings. There must be no keys or passwords in the page’s code.

The check reads the page’s text. The function itself can’t be run in this sandbox, since there is no network here, so reading the code with your own eyes remains your job.

What was wrong before

In 2010 the usual answer to a slow site was to buy a “stronger” server and hope it would do. The cache was set up in one place on the server, and after a CSS edit half the visitors saw the old look until you cleared the browser cache. Receiving a form without a server was impossible: you needed hosting with PHP even if there was only one form. Now a static site with a function in place of a server is cheaper and more reliable, but the same question remains: where is the copy of a person’s data, and who has access to it?