Bei der Weiterentwicklung stand für mich die Reaktionszeit von FlatPress 1.5 Stringendo mit mehreren Tausend Einträgen und Kommentaren im Mittelpunkt. FlatPress hat derzeit mit dem Mastodon-Plugin eine konkrete Fediverse-Brücke. Trotz des großen Funktionsumfangs verbiegt das FlatPress-Projekt seinen Kern nicht für die Mastodon-Integration. Das ist aus architektonischer Sicht ein großer Pluspunkt. FlatPress bleibt dem eigenen Grundsatz treu: eine einfache, leicht zu installierende Blogging-Engine, die mit Dateien statt mit einer Datenbank arbeitet.
Die Mastodon-Anbindung sitzt als Plugin daneben und nicht als Zwangslogik im Kern. Derzeit arbeite ich noch am Feinschliff. Die zentrale Herausforderung liegt weniger in fehlenden Funktionen als im requestbasierten Betriebsmodell von FlatPress. FlatPress besitzt in dieser Form keinen echten Hintergrunddienst und keinen dauerhaft laufenden Worker-Prozess. Die automatische Synchronisation des Mastodon-Plugins hängt an normalen Webanfragen. Im Code des Plugins ist klar zu erkennen: Der automatische Lauf wird nur bei regulären Requests angestoßen, nicht bei POST-Anfragen und nicht bei CLI-Ausführung. Wenn nach der geplanten Uhrzeit niemand die Seite aufruft, passiert zunächst nichts; die Synchronisation verschiebt sich auf den nächsten passenden Seitenaufruf.
Für kleine bis mittlere Blogs ist das ein pragmatischer Ansatz. Für tiefere Föderation oder stark anwachsende Kommunikationslasten ist es jedoch eine harte Grenze. Jede Kommunikation mit Mastodon, jeder Medien-Upload, jeder Import eines Antwortbaums und jeder zusätzliche Dateizugriff verbraucht Zeit innerhalb derselben PHP-Anfrage, die gleichzeitig auch noch eine Seite ausliefern soll. Auf schnellen Systemen kann das unauffällig bleiben. Auf Shared Hosting, langsamen Datenträgern oder bei instabiler externer Erreichbarkeit kann die Render- und Antwortzeit aber deutlich leiden oder an Timeout-Grenzen stoßen.
Gerade hier passt der Performance-Fokus von Stringendo gut zum Problemfeld. Wenn FlatPress heute stärker mit externen Diensten interagiert, dann werden kurze Antwortzeiten, robuste Dateioperationen, lokales Caching und sparsamer I/O nicht zum Luxus, sondern zur Voraussetzung. Die Codebasis zeigt bereits, dass ich genau dort investiert habe. Trotzdem bleibt die grundsätzliche Beschränkung bestehen: Solange Hintergrundarbeit an normale Requests gekoppelt ist, teilt sie sich Ressourcen mit der eigentlichen Seitenauslieferung.
Für Crawler, Monitoring-Systeme oder KI-Bots ist es im Zweifel egal, ob FlatPress eine Seite in 200 Millisekunden oder in deutlich längerer Zeit ausliefert. Aus Sicht von FlatPress kann aber genau ein solcher regulärer GET-Aufruf den fälligen Synchronisationslauf anstoßen. Das nutzen wir bereits im Newsletter-Plugin, um den monatlichen Newsletter zu versenden. Solange aufwendige externe Kommunikation innerhalb normaler Webanfragen stattfinden muss, wird es immer Grenzen bei Last, Reaktionszeit und Hintergrundverarbeitung geben. Für persönliche und mittlere selbstgehostete Blogs ist der jetzige Ansatz dennoch sehr praktisch. Für einen breiteren, allgemeingültigen IndieWeb-Support wären langfristig zusätzliche Protokolle und eine vom Seitenaufruf entkoppelte Hintergrundverarbeitung notwendig. Ich befürchte jedoch, FlatPress eignet sich nicht für einen allgemeingültigen IndieWeb-Support.