Seite 2: VeloCore - Architekturvergleich für WordPress

Für einen Publisher zählt am Ende das Produkt: Leser erreichen den Artikel, Bilder passen zur Darstellung, Inhalte werden korrekt ausgezeichnet und Änderungen erscheinen an den richtigen Stellen. VeloCore übernimmt dafür die technische Produktionskette. Der Nutzen wird dort sichtbar, wo im Alltag sonst mehrere getrennte Einstellungen, Werkzeuge und Zuständigkeiten zusammenlaufen.

Von der technischen Funktion zum konkreten Nutzen

Die Architektur wirkt bis in die redaktionellen und gestalterischen Details. Viele Aufgaben, für die andernorts eine zusätzliche Erweiterung ausgewählt und eingerichtet wird, sind in der VeloCore-Suite bereits vorhanden.

Eine Nachrichtenkarte benötigt Überschrift, Bild, Datumsangabe und gegebenenfalls weitere redaktionelle Informationen. Eine Autorenübersicht benötigt dieselbe verlässliche Inhaltsgrundlage in einem anderen Zusammenhang. VeloCore führt diese Informationen im veröffentlichten Datensatz und verwendet sie für die Darstellung weiter. So wird die Website als zusammengehöriges Produkt entwickelt, statt jede Inhaltsfläche als separates technisches Kleinprojekt zu behandeln.

Für die Gestaltung bedeutet das kurze Wege: Das Design wird an der vorgesehenen Stelle gepflegt, die Sektionen verwenden die gemeinsame Grundlage, und die technische Produktion berücksichtigt ihren Aufbau. Für die Redaktion bedeutet es einen vertrauten Veröffentlichungsablauf mit vorbereiteter Ausgabe im Hintergrund.

VeloCore integriert die Website-Technik, während WordPress die redaktionelle Grundlage bleibt. Standardartikel, Medien und Benutzer verbleiben im CMS. Die veröffentlichte Ausgabe besteht aus üblichen Webdateien. Für die direkte HTML-Auslieferung wird keine zusätzliche Frontend-Cloud benötigt.

Das ist die praktische Bedeutung des Betriebsmodells: Ihre Inhalte werden nicht erst durch einen externen Optimierungsdienst nutzbar. Ihre Infrastrukturentscheidung bleibt bei Ihnen. Die technische Produktion liegt in einem System, dessen Ergebnisse als Dateien vorliegen und dessen Inhaltsgrundlage WordPress bleibt.

Ein Pluginpreis ist schnell verglichen. Wiederkehrende Abstimmung ist oft schwerer sichtbar: Einstellungen pflegen, Änderungen prüfen, Zuständigkeiten klären und die beteiligten Produkte miteinander koordinieren. Diese Arbeit gehört genauso in die Jahresrechnung wie Hosting und Lizenzen.

Jährlicher Zeitwert = monatlich eingesparte Arbeitsstunden × 12 × interner Stundensatz

Ein Kalkulationsbeispiel: Zwei eingesparte Arbeitsstunden pro Monat bei einem angesetzten Stundensatz von 100 Euro ergeben 2.400 Euro im Jahr. Bei acht gleich kalkulierten Portalen sind es 19.200 Euro. Diese Rechnung setzt keine bestimmten Pluginpreise voraus; sie macht die Größenordnung wiederkehrender Arbeitszeit sichtbar.

Für eine konkrete Entscheidung werden die tatsächlichen Werte beider Systeme eingesetzt: Lizenz- und Modulkosten, Hosting, Einrichtung und laufende Betreuung. Entscheidend ist, wie viele getrennte technische Aufgaben Ihre Organisation Monat für Monat selbst koordinieren muss.

Gerade bei mehreren Publikationen wird dieser Unterschied relevant. Ein zusätzlicher Abstimmungsschritt wiederholt sich pro Portal, pro Änderung oder pro Veröffentlichungszyklus. Eine gemeinsame technische Grundlage reduziert die Zahl separat zu pflegender Lösungswege. Das schafft eine klarere Zuständigkeit für das öffentliche Website-Produkt: Darstellung, Datenaufbereitung, Medien und Auslieferung werden gemeinsam betrachtet.

Jede Arbeit, die bei jeder dynamischen Erzeugung erneut läuft, wächst mit der Zahl dieser Erzeugungen. Ein vorbereitetes Ergebnis kann dagegen über viele Leseraufrufe und mehrere Abnehmer wiederverwendet werden.

Ein einfaches Modell: Eine Million HTML-Aufrufe und 5.000 notwendige Dokumenterzeugungen im Monat. Abhängige Dokumente sind in den 5.000 bereits enthalten.

VeloCore verschiebt dabei nicht allein den letzten HTML-Schritt. Bildberechnung, vorbereitete Datenflächen und CSS-Produktion sind bereits Teil des vorgelagerten Systems.

Angenommen, ein Profiler misst in einer konkreten Installation zusammen 15 Millisekunden für einen bestimmten wiederholten Ausgabeschritt. Dann ergibt sich:

1.000.000 Erzeugungen × 0,015 s = 15.000 s = 4 Std. 10 Min.

5.000 Erzeugungen × 0,015 s = 75 s = 1 Min. 15 Sek.

Die 15 Millisekunden sind eine Modellannahme, keine Messung eines bestimmten Plugins. Das Beispiel zeigt den Hebel: Ausführungshäufigkeit und Wiederverwendung sind ebenso wichtig wie die Geschwindigkeit des einzelnen Arbeitsschritts.

Verwenden zwanzig Seiten denselben normalisierten Queryplan, liefert ein gemeinsames Ergebnis die Datenbasis für alle zwanzig Seiten. Gegenüber zwanzig getrennten Zusammenstellungen wird die identische Datenarbeit geteilt. Die individuellen HTML-Seiten behalten ihren eigenen Aufbau.

Dasselbe Prinzip zeigt sich bei Medien: Eine Bildquelle mit mehreren Verwendungen führt ihre Zielgrößen zusammen. Vorhandene geeignete Varianten werden berücksichtigt. Signaturen erlauben die Wiederverwendung unveränderter Ergebnisse.

Für ein weiteres Modell setzen wir 200 Millisekunden PHP-Prozessbelegung je dynamischer Dokumenterzeugung an. Ein vorbereiteter Build benötigt angenommene 240 Millisekunden summierte Belegung aller beteiligten PHP-Prozesse einschließlich internem Renderaufruf.

Dynamische Erzeugung bei jedem Aufruf:
1.000.000 × 0,200 s = 200.000 s = 55 Std. 33 Min. 20 Sek.

5.000 vorbereitete Builds:
5.000 × 0,240 s = 1.200 s = 20 Min.

PHP-Prozessbelegung für die direkte Fast-Path-HTML-Auslieferung: 0 s.

Gegenüber vollständiger dynamischer Erzeugung sind das in diesem Modell 99,4 % weniger PHP-Prozessbelegung. Netzwerk, Webserver und Browserdarstellung werden damit nicht zu null; die Rechnung betrachtet ausschließlich die bezeichnete PHP-Arbeit.

Ein direkter Fullpage-Cache-Treffer vermeidet ebenfalls erneute PHP-Erzeugung. Deshalb entscheidet ein Vergleich der letzten HTML-Auslieferungsstufe allein noch nicht über die Architektur. Relevant sind zusätzlich Datenproduktion, Bild-/CSS-Erzeugung, Abhängigkeiten, Buildumfang und notwendige Zusatzprodukte.

Ein kleinerer Bildbedarf spart mehr als eine neue Dateiendung. Ein Bild mit 2.400 × 1.600 Pixeln enthält 3,84 Millionen Pixel. Wird dieselbe Darstellung mit 600 × 400 Pixeln benötigt, sind es 240.000 Pixel. Die größere Datei enthält damit die sechzehnfache Pixelmenge.

Pixelmengen bei gleichem Seitenverhältnis - ein geometrisches Beispiel

Der Browser erhält mit srcset die verfügbaren Varianten und mit sizes die Information zur vorgesehenen Darstellungsbreite. So lässt sich eine passende Datei unter Berücksichtigung der Pixeldichte auswählen. VeloCore verbindet dafür Layoutwissen, erzeugte Bilddateien und Browserausgabe. Das Bild wird zuerst bedarfsgerecht dimensioniert und anschließend im passenden Format bereitgestellt.

Die Tabelle vergleicht Pixelmengen. Die konkrete Dateigröße hängt zusätzlich von Motiv, Format und Qualität ab. Der geometrische Vorteil bleibt: Ein Bild mit einem Viertel der Kantenlänge besitzt nur ein Sechzehntel der Pixel.

Ein Ressort mit 50.000 Artikeln ist kein Grund, jeden Artikel als Abnehmer jedes anderen Artikels zu behandeln. Würde man eine solche vollständige gerichtete Verbindung ohne Selbstbezüge modellieren, ergäben sich 50.000 × 49.999 = 2.499.950.000 Beziehungen.

Bei drei gespeicherten Empfehlungen pro Artikel sind es dagegen 50.000 × 3 = 150.000 Empfehlungsverbindungen. Der Unterschied liegt in der Definition einer Beziehung: gemeinsame Kategorie oder tatsächlich gespeicherte Empfehlung.

Vergleich zweier Abhängigkeitsmodelle für 50.000 Artikel

VeloCore verwendet für den Related-Bezug die konkreten IDs aus der veröffentlichten Empfehlungsliste. Bei einer Änderung werden die registrierten Abnehmer über diese Schlüssel gefunden. Das Beispiel macht den strukturellen Hebel konkreter, gespeicherter Beziehungen sichtbar.

advanced-cache.php gehört zum frühen PHP-Pfad. Ein solcher Treffer benötigt keinen vollständigen WordPress-Durchlauf. Die direkte Fast-Path-Auslieferung startet für das HTML-Dokument überhaupt keinen PHP-Prozess. Dieser Unterschied gehört zur Delivery-Ebene; VeloCores Compiler und Abhängigkeiten liefern die darüber hinausgehende Systemleistung.

Für den Betriebsvergleich zählt die Anzahl neu erzeugter Dokumente einschließlich aller Abnehmer. Hundert redaktionelle Änderungen können beispielsweise fünfhundert notwendige Dokumentaktualisierungen auslösen. Der Buildumfang beträgt dann fünfhundert, nicht hundert. Genau deshalb sind explizite Abhängigkeiten wertvoll: Sie machen sichtbar, welche vorbereiteten Ergebnisse tatsächlich zu einer Änderung gehören.

Daneben wird Wiederverwendung auf mehreren Ebenen möglich: Ein unverändertes Bildmanifest bleibt erhalten. Ein identischer Queryplan verwendet sein gemeinsames Ergebnis. Ein unveränderter CSS-Inhalt behält seine Inhaltskennung. Ein identisches HTML-Objekt wird wiederverwendet. Die Optimierung besteht damit aus mehreren konkreten Entscheidungen innerhalb der Produktion.

Der wirtschaftlich relevante Effekt: VeloCore arbeitet an der Zahl der notwendigen Wiederholungen. Das reduziert die Aufgaben, die ein Optimierungsprodukt später noch beschleunigen müsste.

VeloCore führt die Technik zusammen. WordPress bleibt dabei das Redaktionssystem. Standardartikel, Medien und Benutzer behalten ihre Grundlage in WordPress. Die öffentliche Ausgabe besteht aus üblichen Webformaten wie HTML, CSS, JavaScript, JSON und Bilddateien.

Die Fast-Path-Auslieferung benötigt keine zusätzliche geschlossene Frontend-Cloud. VeloCore läuft auf eigener beziehungsweise selbst gewählter Infrastruktur. Ihre Inhalte bleiben unter Ihrer Kontrolle.

Der Preis eines einzelnen Cache- oder SEO-Plugins bildet den Aufwand einer gesamten Publishing-Plattform nicht ab. Hinzu kommen Design, Bildverarbeitung, Einrichtung, Integration, Updates, Betrieb und die Abstimmung zwischen den eingesetzten Produkten.

Die konkrete Kalkulation verwendet die tatsächlichen Lizenzen, das Hosting, VeloCore-Kosten und die Arbeitszeit. Der architektonische Vorteil ist die reduzierte Zahl separat zu integrierender Produkte und Einstellungen.

Die VeloCore-Referenzen zeigen große Artikelarchive und produktive Verlagsplattformen. Auf der Website sind unter anderem rund 0,3 Sekunden Desktop-LCP, unter einer Sekunde mobiler LCP und Lasttestwerte von 5.500 bis 9.190 HTTP-Anfragen pro Sekunde in genannten Umgebungen veröffentlicht.

Solche Messwerte zeigen das Ergebnis der gesamten Kette: schlanke Darstellung, vorbereitete Daten, passende Medien, CSS-Produktion und direkte Auslieferung. Ein schneller Webserver allein könnte den Bildbedarf, das Layout und die strukturierten Daten einer Website nicht ersetzen.