How this site is built
I wanted a space where I can drop my thoughts or ideas, later on execute on them, and share them with other people in case they come up with the same problems. This site is that space, and this post is how it’s built.
What I built
A small static site: an About page and this blog. No JavaScript at all, no analytics, no webfonts, just HTML and one hand-written stylesheet.
Two requirements shaped the stack. It had to be cheap or free and low maintenance, so it keeps running without me looking after it. And it had to leave space to grow, in case I want to start adding demos or anything else I think about. Right now, all of it runs on free plans.
- Astro generates plain HTML at build time. Nothing renders in the browser, and there’s no server to patch or keep running. It also leaves room to grow: if I want a demo, Astro can add an interactive component to a single page while the rest of the site stays static.
- Cloudflare Pages is the origin. Pushing to
mainbuilds and deploys it, and there’s nothing else to operate. If a demo ever needs a backend, Pages can run server-side functions too. - Fastly sits in front and does the caching.
- Every cache header is set at the origin, in one file. Nothing is configured in a CDN dashboard, so the whole cache policy can be read, reviewed and versioned in the repo: short in the browser, long at the edge, and a purge on every deploy.
- Automated checks keep maintenance low. The live site is checked after every deploy and once a week, so if something breaks, I get an email instead of having to remember to look.
The blog follows a fixed format for anything I build with AI: a post before building (the idea, the constraints, what I expect to be hard, and how I’ll know it worked) and a post after, which reports back against it.
The execution
What’s been done
- Design: a style guide with colour, type and spacing tokens, readable text contrast in light and dark mode, a print stylesheet, and styling for everything Markdown produces.
- Caching: every cache header set in one file at the origin, with short browser lifetimes, long ones at the edge, and a purge on every deploy.
- Fastly in front: the service, the certificate, a zero-downtime DNS switch, and an automatic soft purge after each deploy, which waits until the new version is live.
- Monitoring: the live site checked automatically after every deploy and every week. That covers cache and security headers, certificate expiry, real 404s and HTTPS.
- Search: indexed in Google, since I want it to come up when someone searches for Rodrigo Salgado. That meant Google Search Console, a sitemap, structured data describing me (with “Rodrigo Salgado” as an alternate name), my posts and the site, and a proper 404 page.
- Blog format: before and after templates, an at-a-glance box, an index on every post, and a build that refuses posts missing a section.
- Tooling: a Claude Code skill that drafts these posts, with a privacy check so it only runs on personal projects.
- Result: Lighthouse scores of 100 for performance, accessibility, best practices and SEO, with no JavaScript on the site at all.