This site ships no JavaScript
Thirty pages in three languages, under 30 KB each, with accessibility and SEO enforced by CI. The decisions behind this site and what they cost.
The page you are reading sends no JavaScript to your browser. Not a framework, not a hydration shim, not an analytics beacon. The whole page is under 30 KB and the fonts are the largest thing on it.
That is a defensible choice for a personal site with a blog, and it is also a work sample. I sell performance and accessibility work. It would be awkward to sell that from a page that takes three seconds to become useful.
Static, because the content is static
The site is Astro: markdown in a git repository, rendered to HTML at build time. Thirty pages build in about half a second. There is no server to patch, no database to back up, no admin panel to secure, and writing a post means opening my editor, which is where I already am.
I spent three years at ConsumerAffairs, a site with seven million visits a month, where page speed was tracked like a business metric because it behaved like one. The lesson from that period is dull and holds up: the fastest request is the one that never happens.
The single exception is the contact form, which composes an email in your own mail client. Twelve lines of inline script. Everything else on the site works with scripting disabled.
Three languages, deliberately unequal
English lives at the root, Portuguese and Spanish each get the full site. The URLs are translated too, so the Portuguese about page is /pt/sobre and the Spanish one is /es/sobre-mi.
Each version is written, not translated. The Spanish is Argentine, with the voseo I picked up over eight years in Buenos Aires, because a Buenos Aires reader can tell within a sentence whether a page was written for them or run through a translator. The Portuguese sounds like how I actually talk to a Brazilian client.
Two Portuguese pages exist only for search: one for consulting in Brasília, one for Goiânia. They are not in the navigation. They are there because someone in Goiânia typing “consultoria de tecnologia” should find a page written for them rather than a generic one.
The parts that took the longest
Colour, of all things. The design used a warm orange for accents, and it failed WCAG contrast at small sizes: 3.31:1 against the card background where 4.5:1 is required. The fix was a second, deeper orange for anything under 24px, and it cost a full pass over every view. The muted grey had the same problem at 4.44:1.
I would not have caught either by looking. Both came from measuring.
The mobile menu is a checkbox and a label, no JavaScript. My first attempt hid the checkbox from screen readers and removed it from the tab order at the same time, which made the entire navigation unreachable by keyboard below 768px. An automated scan said the page was clean. Pressing Tab three times said otherwise.
What the build enforces
Every push runs four gates. A content check fails the build on titles over 60 characters, duplicate metadata, missing canonicals, more than one h1, and em dashes, because I do not want them in my writing and a rule I have to remember is a rule I will forget. An axe scan covers ten pages at two widths and fails on any WCAG 2.2 AA violation. Lighthouse holds 100 in all four categories, with budgets on LCP, CLS and blocking time. Knip removes code and dependencies nobody imports.
Current numbers: LCP 0.4s, CLS 0, blocking time 0ms.
The CLS was 0.04 until I preloaded the two fonts that render above the fold. That is the kind of detail nobody notices when it is right and everybody feels when it is wrong.
Was it worth it
A page builder would have produced something in an afternoon. This took longer, and the difference is not visible in a screenshot.
It shows up when a recruiter opens the site on hotel wifi, when a screen reader user tabs through the contact form, and when Google renders the Portuguese pages and finds the keywords in the URL. Those are the three cases I built for.