Cost and Performance: Keeping Your Site Fast and Your Azure Bill Tiny

Part 6 of 6 in the series “Hand-Code Your CV: From Empty Folder to Live on Azure”

Your CV is live. In Part 5 we deployed it two ways. This last post asks two practical questions: what does it cost to keep it running, and how do we make it fast? The two are more connected than they look, because on a static site, making pages smaller and cacheable is also what keeps your bill down.

As in Part 4, prices here come from Microsoft’s documentation as checked in September 2026. They change, so use the Azure pricing calculator for anything you’re budgeting against.

The cost model in one paragraph

For a static site, you pay for three things: storing the files, serving requests for them, and the data going out to visitors. Some hosts fold all of that into a flat fee or a free plan, and others meter each part separately. Which one you’re on decides whether a surge in visitors costs you nothing, a few pence, or a nasty surprise.

Worked example: how big is a CV, really?

Let’s put some numbers on it. Suppose your finished CV, with HTML, CSS, JavaScript and a small photo, weighs about 500 KB per visit. Suppose it’s popular, and gets 10,000 visits in a month.

Data out: 500 KB × 10,000 = about 5 GB.

Now the same traffic on each option.

Static Web Apps, Free plan. $0. Five gigabytes is a twentieth of the 100 GB monthly bandwidth included. And because the Free plan doesn’t let you buy overage, there is no way to be billed for going over. If the site had a wildly viral month, it would hit the limit rather than running up a bill. For a personal site, that’s a feature.

Azure Storage static website. The storage itself is trivial. Hot-tier storage is priced at roughly $0.018 per GB per month (LRS), and your site is well under a megabyte, so that’s a fraction of a penny. You also pay small charges for read operations, and for data transfer out. Azure has typically included a monthly free allowance of outbound internet data, and 5 GB is likely to fall inside it, but check the current bandwidth pricing for your region. Either way, you’d expect the total to be pennies.

Storage plus Front Door Standard (the route to HTTPS on a custom domain). The base fee is $35 per month, whatever your traffic. On top of that, 5 GB at about $0.083 per GB in North America or Europe is roughly $0.42, plus request charges. So around $35 to $36 a month, of which about 99 per cent is the fixed fee.

App Service Basic (B1). You pay hourly for the plan whether or not anyone visits, and it’s a good deal more than the first two options.

The lesson is that for small sites, fixed monthly fees dominate everything else. Traffic-based costs are tiny until you’re serving many gigabytes. This is why the free plan of a purpose-built service beats a bundle of separately-priced components, even though each component looks cheap in isolation.

When does the bill start to matter?

The Static Web Apps Standard plan includes 100 GB and charges $0.20 per GB above that. So if your 500 KB CV somehow went to 400 GB of traffic in a month (about 800,000 visits), you’d pay for 300 GB of overage: $60, plus the plan’s own monthly fee. That’s a lot of visitors for a CV, and if it happens, you probably have other problems to enjoy first.

Compare that with Front Door, where the per-GB rate of $0.083 is lower than Standard’s overage rate, but you’re always paying the $35 base. There’s a crossover point somewhere in the hundreds of gigabytes a month where the two approaches cost about the same. Below it, the free or cheap plans win easily. Above it, it’s worth doing the sums again, and possibly reaching for a proper CDN.

Keeping costs under control

A few habits that apply well beyond this project:

Set a budget alert. In the Azure portal, open Cost Management, create a budget for your subscription (even £5 a month), and add an email alert. It takes two minutes and is the closest thing to a safety net.
Use resource groups. Put each project in its own group so you can delete it in one command, as we did in Part 5.
Look before you leave. Check the Cost Management view after a few days on any new project. Forgotten resources are the most common source of surprise bills.
Prefer plans with hard caps for hobby projects. The Static Web Apps Free plan is a good example: it can’t bill you for overage.

Performance: what actually makes a static site fast

Once the files are served, the time a page takes to load depends on three things: how far the bytes travel, how many bytes there are, and how the browser handles them.

1. Distance: where the files live

Light in fibre takes time. A visitor in Sydney requesting files from a data centre in London will wait longer than one in London, and each request-response round trip adds up. The fixes are:

Choose a region near your audience, which is why we picked UK South in Part 5.
Serve from a distributed network. This is the big advantage of Static Web Apps and of putting a CDN or Front Door in front of Storage. Content is cached at locations near visitors. A single-region Storage account has no such advantage on its own.

For a CV whose audience is mostly recruiters in one country, single-region hosting may be perfectly fine. For a global audience, distribution matters more.

2. Weight: send fewer bytes

This is where you can make the most difference, and it’s entirely in your control:

Optimise images. A photo straight from your phone can be 4 MB or more, which by itself could be ten times bigger than the rest of the site combined. Resize it to the size it’s actually displayed at, and save it in an efficient format such as WebP or AVIF.
Keep your code lean. Our three hand-written files are a few kilobytes in total. That is a benefit of not using a framework: there’s no large JavaScript bundle to download and run. It’s worth keeping in mind when you later decide whether a framework is worth its weight.
Avoid unnecessary dependencies. Every font, script or icon library you pull in is another request and more bytes.
Use compression. Text files like HTML, CSS and JavaScript compress dramatically with gzip or Brotli. Many hosts and CDNs do this automatically, but check the response headers in your browser’s developer tools (the Network tab) to see whether yours does. Look for a content-encoding header.

3. Caching: don’t send it twice

A browser can keep a copy of your files and reuse it on the next visit, but only if the server says that’s allowed. That’s controlled by the Cache-Control response header.

This is one of the places the hosting choices differ. Plain Azure Storage static website hosting doesn’t let you set custom headers; per Microsoft’s documentation you need a CDN or Front Door for that. Static Web Apps does let you set them, through a staticwebapp.config.json file in your site’s root folder:

{
  "globalHeaders": {
    "cache-control": "public, max-age=3600"
  }
}

That tells browsers they can reuse files for an hour. Longer is faster for repeat visitors but means changes take longer to show up. A common approach for larger sites is to give files unique names whenever their content changes (style.abc123.css) and cache them for a year. For a hand-coded CV, an hour or a day is a sensible middle ground. Check the Static Web Apps documentation for how these settings interact with the platform’s own defaults.

Measure, don’t guess

Performance advice is only worth acting on if you can measure the result. Two free tools:

Lighthouse, built into Chrome’s developer tools. Open the Lighthouse tab, run a report, and it scores performance, accessibility, best practices and SEO, with specific suggestions.
The Network tab in developer tools, which shows every file the page loaded, its size, and how long it took. Sort by size and you’ll see what to shrink first.

Run Lighthouse on your deployed site rather than your local copy, since the network is part of what you’re testing. Try it against the Storage version and the Static Web Apps version and compare. It’s a good way to feel the difference between a single-region origin and a distributed one for yourself.

The series in review

Over six posts, we’ve gone from an empty folder to a live website:

HTML gave the page its structure and meaning.
CSS gave it appearance, layout and responsiveness.
JavaScript gave it behaviour, and showed the principle behind every UI framework: the page is a function of your data.
Hosting options showed how Azure’s choices trade off cost, HTTPS, and performance.
Deployment put the same files live, two ways.
Cost and performance showed that for small sites, fixed fees and page weight matter far more than traffic.

The point of doing it by hand was never that you should hand-code every site for ever. It’s that you can now look at any framework, build tool or hosting platform and ask a sharper question: what is this doing that my three files and a folder weren’t? Sometimes the answer is “a lot, and it’s worth it” (state management for a complex application, say, or a build step that optimises images). Sometimes the answer is “not much, for this job”. Knowing the difference is the skill.

If you want to keep going, some natural next steps are: adding a contact form with an Azure Function behind it, setting up the GitHub deployment route from Part 5, learning a framework and comparing what it generates to what you wrote, or improving your Lighthouse scores. Whichever you pick, you’ll be starting from understanding rather than from magic.

Thanks for following along.

Sources for the figures in this post: Microsoft Learn (Static Web Apps plans and quotas; static website hosting in Azure Storage) and the Azure pricing pages for Static Web Apps, Blob Storage and Front Door. Worked examples are illustrative calculations, not quotes. Prices were checked in September 2026.