DEV Community: René

A .docx file is just a ZIP. Word documents in the browser with zero dependencies

René — Sun, 30 Aug 2026 08:33:00 +0000

I needed a "Download as Word" button for a free legal-text generator I built. The obvious route is a library like docx (~500 KB) or server-side generation. But the documents I produce are dead simple. A heading, some bold sub-headings, lines of text. Shipping half a megabyte of dependency for that felt wrong.

So I looked into what a .docx actually is. It turns out to be a ZIP archive containing a handful of XML files. And if you accept two constraints, you can build one in about 50 lines of vanilla TypeScript.

The two constraints that make it easy

1. Store, don't compress. The ZIP format supports an uncompressed "store" mode (method 0). Your text gets a bit bigger, but you skip implementing DEFLATE entirely. For a two-page document nobody cares about 8 KB vs 3 KB.

2. Minimal OOXML. Word is surprisingly forgiving. A valid .docx needs exactly three files.

[Content_Types].xml — declares what's in the package
_rels/.rels — points to the main document part
word/document.xml — your actual content

No styles.xml, no fontTable.xml, no theme. Word, LibreOffice and Google Docs all open it fine and apply their defaults.

The ZIP writer

The only non-trivial part of the ZIP spec is the CRC-32 checksum. That's a well-known 8-line bit-twiddling loop.

function crc32(data: Uint8Array) {
  let crc = 0xffffffff;
  for (let i = 0; i < data.length; i++) {
    crc ^= data[i];
    for (let k = 0; k < 8; k++) crc = (crc >>> 1) ^ (0xedb88320 & -(crc & 1));
  }
  return (crc ^ 0xffffffff) >>> 0;
}

The rest is writing three record types with the right magic numbers. A local file header (0x04034b50) followed by the raw bytes comes first for each file, then one central directory entry (0x02014b50) per file, then a single end-of-central-directory record (0x06054b50). With store mode, compressed size equals uncompressed size, and all the "advanced" fields stay zero.

function makeZip(files: [string, string][]) {
  const enc = new TextEncoder();
  const u16 = (n: number) => [n & 255, (n >>> 8) & 255];
  const u32 = (n: number) => [...u16(n), ...u16(n >>> 16)];
  const body: number[] = [], central: number[] = [];
  for (const [name, content] of files) {
    const nameB = [...enc.encode(name)], data = [...enc.encode(content)];
    const common = [...u32(crc32(new Uint8Array(data))), ...u32(data.length),
                    ...u32(data.length), ...u16(nameB.length), ...u16(0)];
    central.push(...u32(0x02014b50), ...u16(20), ...u16(20), ...u16(0), ...u16(0),
                 ...u16(0), ...u16(0), ...common, ...u16(0), ...u16(0), ...u16(0),
                 ...u32(0), ...u32(body.length), ...nameB);
    body.push(...u32(0x04034b50), ...u16(20), ...u16(0), ...u16(0), ...u16(0),
              ...u16(0), ...common, ...nameB, ...data);
  }
  return new Uint8Array([...body, ...central, ...u32(0x06054b50), ...u16(0),
    ...u16(0), ...u16(files.length), ...u16(files.length),
    ...u32(central.length), ...u32(body.length), ...u16(0)]);
}

That's the entire "ZIP library".

The Word part

word/document.xml is WordprocessingML. A paragraph is <w:p>, a run is <w:r>, text is <w:t>. Three gotchas cost me the most time.

Half-points. Font sizes in <w:sz w:val="36"/> are half-points, so 36 means 18 pt. Everyone hits this once.
xml:space="preserve". Without it, Word trims leading and trailing whitespace in your <w:t> elements, which silently eats spaces around line breaks.
Escape everything. You're concatenating XML, so &, <, > and quotes in user data must be escaped or the file won't open at all. Word's error message ("unreadable content") tells you nothing.

Line breaks within a paragraph are <w:br/> between <w:t> elements, no need for separate paragraphs per line.

Finally, wrap the bytes in a Blob with the right MIME type and trigger the download.

const blob = new Blob([bytes], {
  type: 'application/vnd.openxmlformats-officedocument.wordprocessingml.document'
});
const url = URL.createObjectURL(blob);
const a = document.createElement('a');
a.href = url;
a.download = 'document.docx';
a.click();
setTimeout(() => URL.revokeObjectURL(url), 10_000);

Verifying without opening Word

Two command-line tricks saved me a lot of clicking. unzip -l file.docx confirms the archive structure is valid, and on macOS textutil -convert txt file.docx round-trips the document through Apple's own OOXML parser, so if that prints your text, Word will open it. xmllint catches malformed XML before you even zip it.

Where it runs in production

The whole thing powers the Word export of a free legal-notice generator for Austrian websites I built. It pulls company data from public registers and outputs the mandatory site imprint, and you can try it at https://webgaudi.at/impressum-generator-oesterreich/

The export feature adds about 1.5 KB minified to the bundle. The docx npm package would have been ~300x that, for documents this simple.

Would I recommend this for reports with tables, images and headers? No, take the library. But for "text with some bold lines as a .docx download", the format is far less scary than it looks. It's just a ZIP.

Firmenbuch, GISA, VIES: die APIs hinter unserem Impressum-Generator für Österreich

René — Thu, 20 Aug 2026 10:57:11 +0000

Die meisten Impressum-Generatoren sind im Kern ein Formular mit Textbausteinen: Du tippst alles selbst ein, der Generator klebt es zusammen. Ob die Angaben stimmen, ist dein Problem. Dabei liegen die relevanten Daten für österreichische Unternehmen längst in öffentlichen Registern, und die haben APIs.

Genau darauf haben wir unseren Impressum-Generator für Österreich gebaut. Du suchst dein Unternehmen, der Generator holt die Pflichtangaben aus den offiziellen Quellen und sagt dir, wenn etwas nicht zusammenpasst. In diesem Artikel zeige ich, welche APIs dahinterstecken und was wir aus den Antworten ableiten.

Register 1: das Firmenbuch

Für Kapitalgesellschaften und eingetragene Unternehmen ist das Firmenbuch die zentrale Quelle. Die Justiz bietet dafür über JustizOnline eine offizielle Abfrage-Schnittstelle an (eine SOAP-API mit API-Schlüssel). Wir nutzen zwei Operationen: die Firmensuche nach Wortlaut oder Firmenbuchnummer und den Auszug in der Stufe „Kurzinformation" zum aktuellen Stichtag.

Aus dem Auszug kommt alles, was das Impressum an Registerdaten braucht: exakter Firmenwortlaut, Rechtsform, Sitz und Geschäftsanschrift. Der Punkt dabei ist nicht Bequemlichkeit, sondern Korrektheit. Ins Impressum gehört der Wortlaut, wie er im Register steht, nicht die Schreibweise, die man im Alltag verwendet. Ein „e.U." oder ein ausgeschriebenes „Gesellschaft m.b.H." macht da einen Unterschied, und beim Selbst-Eintippen geht genau so etwas verloren.

Ein Detail aus der Praxis: Die Auszugsdaten enthalten historische Einträge mit einem Aufrecht-Flag. Wir nehmen konsequent den aufrechten Eintrag, sonst landet nach einer Sitzverlegung die alte Adresse im Impressum.

Register 2: GISA, das Gewerberegister

Gewerbetreibende brauchen im Impressum zusätzlich den Gewerbewortlaut und die zuständige Gewerbebehörde. Beides liefert das GISA (Gewerbeinformationssystem Austria) über eine öffentliche XML-Schnittstelle: Suche nach natürlichen Personen, nach Unternehmen oder direkt per GISA-Zahl.

Zwei Dinge daran finde ich richtig gut gelöst:

Die Verknüpfung zum Firmenbuch. Jeder GISA-Eintrag einer eingetragenen Gesellschaft trägt die Firmenbuchnummer. Wählst du im Generator also deine GmbH aus dem Firmenbuch, suchen wir mit der Firmenbuchnummer automatisch die zugehörigen Gewerbeberechtigungen. Du musst deine GISA-Zahl gar nicht kennen (die kennt erfahrungsgemäß fast niemand auswendig).

Die phonetische Suche als Fallback. Findet die exakte Namenssuche nichts, wiederholen wir die Abfrage phonetisch. Das fängt Tippfehler und Schreibvarianten ab, ohne dass die exakte Suche darunter leidet.

Außerdem verrät der GISA-Eintrag, ob eine Berechtigung ruhend gemeldet ist. Auch so ein Fall, den ein reines Textbaustein-Formular nie bemerken würde.

Register 3: VIES für die UID-Nummer

Bei der UID-Nummer prüfen wir zweistufig. Zuerst rechnen wir die Prüfziffer der ATU-Nummer direkt im Browser nach, ganz ohne API-Call. Ein Zahlendreher fliegt so sofort auf, noch während du tippst.

Ist die Prüfziffer plausibel, fragen wir das VIES-System der EU-Kommission ab (die REST-Schnittstelle zur Mehrwertsteuer-Validierung). VIES bestätigt aber nicht nur, dass die UID existiert. Für österreichische Nummern liefert es auch den hinterlegten Namen und die Adresse zurück, und damit kommen wir zum spannendsten Teil.

Widersprüche erkennen statt still zusammenkleben

Sobald Daten aus mehreren Quellen kommen, kann sich widersprechen, was eigentlich zusammengehören sollte. Genau das gleichen wir ab: Die Adresse aus dem UID-Register wird normalisiert (Groß/Klein, ß/ss, Satzzeichen, Abkürzungspunkte) und mit der Anschrift im Formular verglichen. Weicht sie ab, zeigt der Generator einen Hinweis. Meist steckt dahinter eine Übersiedlung, die zwar dem Firmenbuch, aber nie dem Finanzamt gemeldet wurde, oder umgekehrt. Für den Betroffenen ist das Gold wert, weil so eine Inkonsistenz sonst erst auffällt, wenn es unangenehm wird.

Dazu kommen die Ableitungen aus statischen Datentabellen, die keine API brauchen: Aus der Postleitzahl leiten wir Ort, Bundesland und das zuständige Gericht ab. Klingt trivial, ist es aber nicht überall. Klosterneuburg liegt in Niederösterreich, gehört gerichtlich aber zu Wien. Solche Sonderfälle haben wir einzeln recherchiert und hinterlegt, weil eine simple PLZ-Bereichs-Logik hier falsche Impressen erzeugen würde.

Noch ein Wort zur Architektur: Alle Register-Abfragen laufen über unsere eigenen Server-Endpoints, nicht direkt aus dem Browser. Die API-Schlüssel bleiben so am Server, und wir können Rate-Limits durchsetzen, damit die Behörden-APIs nicht von unserer Seite aus geflutet werden.

Probier es aus

Der Generator ist kostenlos und ohne Anmeldung nutzbar, vom Einzelunternehmer bis zum Verein. Unternehmen suchen, Angaben prüfen, Impressum kopieren oder als Word-Datei herunterladen. Wenn du eine österreichische Website betreibst, wirf einfach mal deinen Firmennamen rein. Und wenn der Generator bei dir eine Abweichung findet, freu dich: Das ist genau der Moment, für den wir ihn gebaut haben.

Ich bin René und betreibe webgaudi, eine Webdesign-Agentur in Wien. Wir bauen individuell programmierte Websites für Selbstständige und KMU, ohne Baukasten, zum Fixpreis ab 1.500 €.

Your CI stack ships four YAML parsers and half of them are still on the 2009 spec

René — Thu, 20 Aug 2026 10:37:09 +0000

Everyone knows the Norway problem. country: NO becomes false, ha ha, quote your strings.

What gets skipped is the part that actually costs you an afternoon: YAML 1.2 fixed this in 2009, and a large share of the parsers in your pipeline never moved. So the interesting failure is not one parser being wrong. It is two parsers in the same pipeline being right in different ways, on the same file.

Take an inventory of your parsers

Most teams have never counted. A fairly ordinary Python-and-Kubernetes shop is running at least four:

Where	Library	Spec it resolves against
Ansible playbooks and vars	PyYAML	1.1
`kubectl apply`	`sigs.k8s.io/yaml` over go-yaml v2	1.1
A Go controller or operator you wrote recently	go-yaml v3	1.2 core
Anything Node touches (config loaders, lint plugins, codegen)	`js-yaml` v4 or `yaml`	1.2 core
A Java service reading config	SnakeYAML 1.x	1.1
Ruby tooling	Psych	1.1

Note js-yaml: v3 was 1.1 and v4 is 1.2. If you have a repo old enough to still be on v3 alongside a newer package on v4, you have the split inside a single node_modules.

The values they disagree about

This is the whole list that matters in practice. Everything else is trivia.

country:   NO          # 1.1 -> false        | 1.2 -> "NO"
enabled:   off         # 1.1 -> false        | 1.2 -> "off"
mode:      0644        # 1.1 -> 420 (octal)  | 1.2 -> 644 (decimal)
timeout:   12:30       # 1.1 -> 750 (base60) | 1.2 -> "12:30"
scale:     1e5         # 1.1 -> "1e5" (str)  | 1.2 -> 100000
version:   1.10        # both -> 1.1 (float)

Three of those are silent data corruption with no error anywhere.

mode: 0644 is my favourite because it looks so safe. A 1.1 parser reads it as octal and hands you the integer 420, which is the file mode you meant. A 1.2 parser reads it as the decimal number 644, which is mode 1204 in octal, which is nothing you wanted. Same six characters, same file, and which one is correct depends entirely on which binary opened it.

12:30 as 750 is the sexagesimal type, a YAML 1.1 feature that existed so you could write durations as 1:30:00. It was removed in 1.2 for the obvious reason. Any time value, any port pair, any HH:MM in a config is exposed to it.

Two more that are not version differences but bite just as hard:

1.10 is a float in every parser, and floats do not have trailing zeros, so your version pin silently becomes 1.1. There is no spec version where this behaves.
Duplicate keys are an error under 1.2 and a silent last-one-wins under PyYAML. A 400-line values file with the same key at line 40 and line 380 is a normal Tuesday, and Python will not tell you.

Where the two parsers meet

The single-parser case is survivable, because at least the file is consistently wrong. The one that eats a day looks like this.

Ansible templates a Kubernetes ConfigMap. Someone writes:

# group_vars/prod.yml
feature_legacy_import: no

PyYAML resolves that to Python False. Jinja renders False into the manifest. The manifest now says:

data:
  feature_legacy_import: "False"

And your Go service reads the ConfigMap, gets the string "False", and does strconv.ParseBool on it, which succeeds, so nothing errors. Except upstream someone "fixed" the vars file by quoting it to "no", and now the same code path receives "no", and ParseBool("no") returns an error, which your code treats as false with a logged warning nobody reads.

The flag is off in both cases. It is off for two entirely different reasons and only one of them is the one you configured.

yamllint will not save you here

Worth being precise, because people assume this is covered. yamllint has a truthy rule and it does flag bare yes/no/on/off. Turn it on, it is free.

It does not check octal ambiguity, sexagesimals, exponent notation, version-number truncation, or the case you actually care about, which is what two specific parsers each make of this file. It is a style linter. It reads your YAML as text, not as values.

There is also a per-implementation layer under the spec version. The YAML 1.1 type repository lists bare y and n as booleans, but PyYAML's resolver deliberately leaves them alone. So "it works in my parser" is not even a claim about YAML 1.1, it is a claim about one library's resolver. That is the level at which this stuff has to be checked.

What actually holds

In rough order of value:

Quote every string that could be read as something else. Not every string, that is unreadable. The ambiguous ones: anything matching y|n|yes|no|on|off|true|false in any casing, anything with a leading zero, anything with a colon, anything shaped like a number that is not a number. Single quotes, since they pin it as a string under both specs.
Schema-validate the parsed result, not the file. A JSON Schema on the loaded object catches 420 where you expected "0644". Linting the text cannot, because the text is fine.
Use yaml.safe_load plus an explicit type coercion at the boundary. If a value must be a string, cast it there and stop trusting the resolver.
Pin the parser version in your lockfile and know which spec it is. The js-yaml v3 to v4 upgrade is a behaviour change in your config semantics. It is not a patch bump.
Prefer JSON for machine-generated config. No resolver, no types to guess, no Norway.

Checking a file you did not write

The gap in the tooling is that YAML validators tell you a file parses, which is never the question. The question is what it parses into, and whether two parsers agree.

I ended up building a linter for exactly that. Paste a workflow, a playbook or a manifest and every plain scalar that resolves differently under 1.1 and 1.2 comes back with both readings next to each other, plus duplicate keys, tabs and non-breaking spaces. There is a button that emits the file with every ambiguous value quoted. It runs client side, so you can paste a production values file into it without thinking about it.

The longer background on why the fix landed in 2009 and still has not reached your dependency tree is here.

Run it over your group_vars directory once. My honest expectation is that you find between two and five, and that one of them is a file mode.

Die unsichtbare Empfehlung

René — Wed, 10 Jun 2026 13:46:43 +0000

Eine Kundin erzählte uns kürzlich, wie sie ihren neuen Steuerberater gefunden hat. Nicht über Google, nicht über eine Empfehlung aus dem Bekanntenkreis. Sie hat ChatGPT gefragt: "Welcher Steuerberater in Münster kennt sich mit E-Commerce aus?" Drei Namen kamen zurück. Einen davon hat sie angerufen.

Zwei Dinge sind an dieser Geschichte bemerkenswert. Erstens: Die Kundin fand den Vorgang völlig normal. Zweitens: Die anderen Steuerberater in Münster werden nie erfahren, dass sie an diesem Tag nicht in Frage kamen. Es gab keine Suchergebnisseite, auf der sie weiter unten standen. Sie kamen schlicht nicht vor.

Eine neue Art, gefunden zu werden

Über zwei Jahrzehnte lang war die Frage klar: Wer bei Google auf Seite eins steht, bekommt die Anfragen. Diese Frage gilt weiterhin — aber sie hat Gesellschaft bekommen. ChatGPT, Perplexity, Googles KI-Übersichten: Immer häufiger spricht ein Assistent eine Empfehlung aus, statt zehn blaue Links anzuzeigen.

Der Unterschied ist größer, als er zunächst wirkt. Eine Suchergebnisseite zeigt Optionen, und der Mensch wählt. Ein Assistent wählt vor — und nennt drei Namen, manchmal nur einen. Wer nicht genannt wird, existiert für diesen Kunden nicht. Es gibt kein "weiter unten" mehr, in dem man wenigstens noch sichtbar wäre.

Warum viele Websites für KI unsichtbar sind

Die gute Nachricht zuerst: KI-Assistenten erfinden ihre Empfehlungen nicht. Sie lesen das Netz — Websites, Verzeichnisse, Bewertungen, Fachartikel. Wer dort klar und maschinenlesbar auftritt, wird gefunden. Wer nicht, bleibt stumm.

Und genau hier scheitern viele Unternehmensseiten. Die typischen Gründe kennen wir aus unseren Audits:

Die Seite sagt nicht, was sie ist. Ein Friseursalon, dessen Startseite nur "Willkommen" und ein Stimmungsbild zeigt, mag Menschen gefallen. Eine Maschine, die in Sekundenbruchteilen entscheidet, ob diese Seite die Frage "guter Friseur für Locken in Köln" beantwortet, findet darin: nichts. Was Sie anbieten, für wen, und wo — das gehört in Text, nicht nur ins Gefühl.

Es fehlen strukturierte Daten. Schema.org-Auszeichnungen (LocalBusiness, Öffnungszeiten, Leistungen, Bewertungen) sind das Vokabular, in dem Maschinen Unternehmen verstehen. Sie kosten nichts, sind unsichtbar für Besucher — und werden von den meisten Baukasten-Seiten schlicht weggelassen. Warum Vorlagen-Websites auch darüber hinaus an ihre Grenzen stoßen, haben wir im Beitrag Tausend Betriebe, eine Vorlage beschrieben.

Die Seite ist technisch schwer lesbar. Was sich nur per JavaScript zusammensetzt, in Sekunden lädt statt in Millisekunden, oder hinter Pop-ups versteckt, wird von Crawlern ungern und unvollständig gelesen. Schnelle, statisch ausgelieferte Seiten haben hier denselben Vorteil, den sie bei Google schon immer hatten — nur dass er jetzt doppelt zählt.

Das Unternehmen existiert nur auf der eigenen Website. KI-Modelle gewichten, was an mehreren Stellen übereinstimmend steht. Ein gepflegtes Google-Unternehmensprofil, Einträge in seriösen Branchenverzeichnissen, echte Bewertungen, vielleicht eine Erwähnung in der Lokalpresse — jedes dieser Signale bestätigt: Dieses Unternehmen gibt es wirklich, und es ist das, was es behauptet.

Was sich für Sie nicht ändert

Man könnte nun in Hektik verfallen und nach "KI-Optimierung" suchen wie 2005 nach Meta-Keywords. Unnötig. Denn das Bemerkenswerte ist: Fast alles, was eine Website für KI-Assistenten sichtbar macht, ist seit Jahren guter Handwerksstandard. Klare Inhalte, die Fragen Ihrer Kunden beantworten. Saubere Technik. Strukturierte Daten. Konsistente Einträge. Schnelle Ladezeiten — genau die Punkte, auf die wir bei Tinte&Pixel bei jedem Projekt von Beginn an achten.

Wer seine Website in den letzten Jahren ordentlich gebaut hat, ist bereits gut aufgestellt. Wer sie als digitale Visitenkarte ohne Substanz betreibt, war schon bei Google im Nachteil — jetzt wird aus dem Nachteil Unsichtbarkeit.

Unsere Schwesteragentur Webgaudi in Wien hat schon vor Jahren beschrieben, was sich an der Suchmaschinenoptimierung durch KI verändert hat — die Kernaussage gilt unverändert: Es gewinnt nicht, wer trickst, sondern wer verständlich ist. Für Menschen wie für Maschinen.

Ein einfacher Selbsttest

Fragen Sie heute Abend ChatGPT, was es über Ihr Unternehmen weiß. Fragen Sie es, wen es für Ihre Leistung in Ihrer Stadt empfehlen würde. Die Antwort ist ein ehrlicher Spiegel Ihrer digitalen Präsenz — ehrlicher als jedes Ranking, weil es kein "Platz 8" gibt, mit dem man sich trösten könnte.

Wenn Ihr Name fällt: gut gemacht. Wenn nicht, wissen Sie jetzt, woran es liegt. Und dass es sich beheben lässt. Erzählen Sie uns einfach kurz von Ihrem Vorhaben — wir geben Ihnen eine ehrliche Einschätzung.

How We Ship 100/100 PageSpeed Sites for Small-Business Clients (Without a CMS)

René — Wed, 10 Jun 2026 13:41:07 +0000

Most small-business websites are slow. Not because the businesses don't care, but because the default stack they get sold — a heavyweight CMS, a page builder, twelve plugins — fights against performance from day one.

At webgaudi.at, our small web studio in Vienna, we build sites for therapists, lawyers, electricians and restaurants. Tiny budgets, no dev team on the client side, and one hard promise we make: 100/100 on PageSpeed Insights, mobile and desktop. Here's the actual playbook — no secrets, just decisions that compound.

1. Static-first with Astro: ship zero JS by default

The single biggest lever is architectural. A brochure site for a psychotherapist has maybe one interactive element (a contact form, an FAQ accordion). It does not need a client-side framework, and it definitely doesn't need a database rendering pages on every request.

We use Astro because its islands architecture makes "zero JavaScript" the default instead of an optimization:

---
// FaqSection.astro — pure HTML/CSS, no JS shipped
const faqs = await getCollection('faq');
---
{faqs.map((faq) => (
  <details>
    <summary>{faq.data.question}</summary>
    <div set:html={faq.rendered.html} />
  </details>
))}

Native <details>/<summary> gives you an accessible accordion for free. The temptation to reach for a React component here is real — resist it. Every island you don't ship is hydration cost you never pay.

When we do need interactivity, we scope it:

<ContactForm client:visible />

client:visible means the form's JS only loads when it scrolls into view. On a typical landing page, that's the difference between 0 KB and 40 KB of JS on initial load.

2. Images: the 80% problem

Almost every failing Lighthouse audit we inherit comes down to images. Our rules:

Author in highest quality, let the build optimize. Astro's <Image /> component generates AVIF/WebP, correct srcset, and explicit dimensions (no layout shift):

import { Image } from 'astro:assets';
import hero from '../assets/hero.jpg';

<Image src={hero} alt="..." widths={[400, 800, 1200]} format="avif" />

The LCP image gets loading="eager" and fetchpriority="high". Everything below the fold gets lazy-loaded. Getting this one attribute right is often worth 0.5–1s of LCP.
No icon libraries. Inline the 6 SVGs you actually use. A 200 KB icon font for a hamburger menu is how good scores die.

3. Fonts without the FOIT (and without the GDPR headache)

We self-host fonts as subsetted WOFF2 with font-display: swap and preload only the body font:

<link rel="preload" href="/fonts/inter-latin.woff2" as="font" type="font/woff2" crossorigin>

Side note for anyone building for EU clients: loading fonts from Google's CDN has been a legal problem since a 2022 German court ruling (LG München) — a visitor's IP gets transmitted to Google without consent. Self-hosting fixes performance and compliance in one move. Two birds.

4. Edge delivery instead of a single origin server

Static output means the whole site can live on a CDN. We deploy to an edge network so a site for a Viennese client loads just as fast for someone visiting from a hotel WiFi in Lisbon. TTFB consistently lands under 100ms — something a shared-hosting PHP origin can't match no matter how much you cache.

5. The boring checklist that protects the score

Performance regresses through a thousand small additions. Before every go-live:

Lighthouse CI run on throttled mobile (the real-world case), not desktop
No third-party scripts above the fold; analytics loads deferred and only after consent
One critical CSS file under ~50 KB, no unused framework CSS (we purge aggressively)
viewport meta, explicit width/height on all media, no render-blocking resources
Accessibility pass: semantic landmarks, contrast, focus states — Lighthouse's a11y score is part of the 100/100 promise, not an afterthought

What this means for clients (the part nobody measures)

The interesting outcome isn't the green circle — it's behavior. Average load time across our portfolio is ~0.8s, and the bounce-rate difference compared to the WordPress sites we replace is dramatic. Studies keep showing mobile users abandon pages after roughly 4 seconds; for a small business where the website is the sales funnel, that's lost revenue, not a vanity metric.

If you're a freelancer or studio serving small businesses, my honest pitch: static-first isn't a constraint, it's a feature you can sell. Faster sites, lower hosting costs, smaller attack surface, no plugin update treadmill.

I run webgaudi.at, a small web studio in Vienna building fast, GDPR-compliant sites for SMBs in Austria, Germany and Switzerland. Happy to answer questions about the stack in the comments — especially if you're fighting your own PageSpeed battles.