Die günstigste Datenbankabfrage ist die, die einmal läuft und danach eine Million Besucher aus einer fertigen Datei bedient. Genau das macht eine statische Website. Während eine klassische dynamische Seite bei jedem Aufruf erneut die Datenbank fragt, die Seite zusammenbaut und ausliefert, hat Hugo diese Arbeit längst erledigt – einmal beim Build. Die Frage „Wie oft aktualisiere ich meine Daten?" beantwortet die Architektur damit schon zur Hälfte.
Das Erfolgskriterium von Guideline 4.7 (meine Übersetzung des Originals):
Aktualisierungsrate: Lege die Aktualisierungsraten des Caches auf Grundlage der Nutzerbedürfnisse, der geforderten Genauigkeit und der Ressourceneffizienz fest, um zu bestimmen, wann Daten aktualisiert werden.
Meine Einordnung
Für eine statische Seite verschiebt sich dieses Kriterium an eine ungewohnte Stelle. Es geht nicht mehr um die Frage, wie oft pro Sekunde eine Datenbank antwortet, sondern nur noch darum, wie oft überhaupt neu gebaut wird. Meine Aktualisierungsrate ist also im Grunde meine Build-Frequenz. Und die halte ich bewusst schlank: Es wird gebaut, wenn tatsächlich neuer Inhalt fällig ist, nicht auf Verdacht. Bilder erzeuge ich dabei genau einmal – die WebP-Konvertierung läuft im Build, danach liegt die Datei fertig da und wird nicht bei jedem Besuch neu berechnet.
Ganz entkomme ich der Frage aber nicht, und das ist auch richtig so. Überall, wo Daten von außen kommen, muss ich eine Rate festlegen. Mein KGMID-Werkzeug fragt eine externe API und legt die Antwort für einige Minuten in den Cache, statt sie für jeden Besucher frisch abzurufen. Der RSS-Feed, den ich an anderer Stelle einbinde, wird für ein paar Stunden zwischengespeichert, nicht bei jedem Seitenaufruf neu geholt. Jedes dieser Intervalle ist eine bewusste Entscheidung – genau das, was das Kriterium verlangt.
Die eigentliche Frage dahinter ist immer dieselbe: Wie frisch muss diese Information wirklich sein? Ein Beispiel macht die Größenordnung klar. Ein Widget, das alle fünf Sekunden nachlädt, erzeugt pro geöffnetem Tab über 17.000 Anfragen am Tag. Reicht Aktualität im Minutentakt, sind es 12 pro Stunde – dieselbe Information für den Nutzer, ein Sechzigstel der Last.
Wo ich weiter gehe
Hier setzt mein Grundsatz an: Stelle jede Aktualisierung so langsam ein, wie der Zweck es gerade noch verträgt – nicht so schnell, wie die Technik es erlaubt. „Echtzeit" ist fast nie eine Anforderung, sondern eine Designentscheidung, die selten hinterfragt wird.
Und noch eine Ebene tiefer gilt dasselbe Prinzip wie beim Caching: Die nachhaltigste Aktualisierung ist die, die ausbleibt, weil sich nichts geändert hat. Ein System, das erkennt, dass die Quelle unverändert ist, und deshalb gar nicht erst neu lädt, schlägt jedes noch so clevere Intervall.
Dein erster Schritt heute
Du findest die Kandidaten schnell, wenn Du gezielt nach allem suchst, was sich „von selbst" bewegt.
Die nachhaltigste Aktualisierung ist die, die ausbleibt, weil sich nichts geändert hat. Die zweitbeste ist die, die nur so oft läuft, wie es der Zweck wirklich verlangt.
Quellen: W3C-Fassung von Guideline 4.7 · Interpretation bei Sustainable Web Design