Does a small website need a CDN?

In theory, every page gets faster with a CDN. In practice the gain ranges from huge to unnoticeable, and it depends on three things: where your visitors are, how heavy the page is, and whether the content changes on every request.

The criteria below let you decide with numbers instead of habit. If you are not sure what a CDN is yet, start with what a CDN is and how it speeds up your site and come back.

Which criteria decide if it is worth it?#

Ask four questions, in this order:

1. Where is your audience? If the server sits in one region and visitors are in others, each request crosses a long distance. If everyone lives in the same city as the server, there is almost no latency to save.
2. How heavy is the page? A page with 40 files pays the distance cost many times. A text page with one small CSS file pays very little.
3. Is the content the same for everyone? Images, CSS, JavaScript, fonts and static sites are great cache candidates. Dashboards and per-user responses are not.
4. Does traffic spike? The CDN answers in place of the origin, so a burst of visits (a viral post, a launch) puts less pressure on your server.

To measure instead of guess, use two Google metrics. TTFB (time to first byte) is rated good at 0.8 s or less and poor above 1.8 s. LCP (time until the largest element renders) is good at 2.5 s or less and poor above 4 s, measured at the 75th percentile of visits, split by mobile and desktop. If TTFB for distant visitors is above 0.8 s, or LCP is above 2.5 s because of images and scripts, a CDN with caching is likely to help.

When does a CDN make a real difference?#

• A spread-out audience: a US site with visitors in Europe and Asia.
• Lots of images or video: the file comes from the nearest PoP (point of presence), not from the origin.
• Static or generated sites (SSG): the HTML is also the same for everyone, so the CDN can serve nearly everything without touching the origin.
• A small server: if the origin has little RAM, letting the CDN absorb repeated requests keeps it from falling over during spikes.
• Extra protection: CDNs often include DDoS mitigation and a WAF, and hide the origin address.

When can you skip one?#

• A local audience and a light page: a neighborhood blog, a clinic's website, a portfolio with few files. Load time is already low.
• A fully dynamic, authenticated app: a dashboard where each response depends on the user barely uses the cache.
• An internal tool: something used by one team on the same network.

Even then, if your host already includes a CDN, leave it on: it only acts where a valid cached copy exists.

What are the options?#

There is no universal winner. The right question is which one fixes your bottleneck with the least complexity.

What does a CDN cache by default?#

It depends on the provider. As an example, Cloudflare caches by file extension, not by content type, and its default list covers images (JPG, PNG, WEBP, SVG), CSS, JS, fonts (WOFF2, TTF), audio, video and archives. According to the documentation, HTML and JSON are not cached by default: to store them you create a cache rule.

That explains a common mistake: the site "has a CDN", yet the main page and the API never come from cache. To see what happened, Cloudflare's cf-cache-status header shows HIT (served from cache), MISS (eligible, but fetched from the origin), DYNAMIC (not eligible) or BYPASS (eligible, but the origin response could not be stored). Other CDNs use other header names.

How do you configure caching for a small site?#

Your application's Cache-Control header decides how long things are cached. Files with a hash in the name get a new URL when their content changes, so they can be cached for a year. In Node.js with Express:

import express from "express";

const app = express();

// /assets/app.3f9a1c.js, /assets/logo.8d2e.png: the name changes when the file changes
app.use(
  "/assets",
  express.static("public/assets", { maxAge: "1y", immutable: true }),
);

// HTML: the browser keeps it for 1 minute; the CDN may keep it for 5 minutes
app.get("/", (req, res) => {
  res.set("Cache-Control", "public, max-age=60, s-maxage=300");
  res.sendFile("index.html", { root: "public" });
});

// Per-user response: never in a shared cache
app.get("/dashboard", (req, res) => {
  res.set("Cache-Control", "private, no-store");
  res.send("User dashboard");
});

app.listen(process.env.PORT ?? 80);

s-maxage applies only to shared caches such as a CDN and takes priority over max-age there. Remember that on Cloudflare, HTML only enters the cache with a cache rule. private stops the CDN from storing the response, and no-store forbids any cache, per MDN. Each directive is covered in what Cache-Control is.

How do you confirm caching works?#

Run it twice and compare:

curl -sI https://www.example.com/assets/app.3f9a1c.js

On the second call, look for an Age header greater than zero and your provider's HIT indicator. If the response never comes from cache, review Cache-Control and make sure the response has no Set-Cookie, because Cloudflare does not cache responses with Set-Cookie (the status may show as BYPASS).

Which option fits each scenario?#

• A local blog or portfolio, few pages: a CDN is optional. If your host has one, use it; otherwise optimize images first (see how to speed up a website).
• A landing page or store with a nationwide audience: use a CDN with caching for assets and static HTML.
• A site with visitors on several continents: a CDN with caching is close to mandatory.
• An authenticated app (SaaS, dashboard): use the CDN for assets and mark per-user routes private or no-store.
• Lots of video or downloads: put the files in object storage with a CDN instead of serving them from the app.

How to do this on Square Cloud#

Every Square Cloud plan includes a global CDN, unlimited traffic (no charge per bandwidth or per request, subject to a fair-use policy), automatic TLS, a WAF and L3/L4/L7 DDoS protection. For a small site, that means no separate CDN to buy or configure.

The network is an Anycast CDN based on Cloudflare, with more than 200 points of presence, HTTP/3 and WebSockets. Your web application gets a *.squareweb.app subdomain with HTTPS, and from the Standard plan you can use a custom domain by creating, at your registrar, the DNS records the dashboard shows. The domain stays registered in your name.

The CDN caches according to the Cache-Control your application sends, so sending the right headers, as in the example above, is still your application's job. Details are in Square Cloud network and CDN.