Eine vollständige Architektur. Keine Sammlung von Optimierungsplugins.

VeloCore Suite + Runtime Engine + VeloCore-Module · Produktvergleich vom 1. November 2026

WordPress bleibt die Redaktion. VeloCore übernimmt die Produktion der Website: Inhalte, Datenabfragen, Layout, Bilder, Videos, CSS, technisches SEO und Veröffentlichung. Der Dependency-Layer verbindet diese Systeme. Der Fast-Path liefert ihr fertiges Ergebnis aus.

Eine schnelle Website entsteht aus vielen Entscheidungen: Welche Inhalte braucht eine Seite? Welche Bilder passen in ihre Spalten? Welche CSS-Regeln gehören zu ihren Komponenten? Was muss sich ändern, wenn ein Artikel bearbeitet wird? VeloCore beantwortet diese Fragen innerhalb einer gemeinsamen Architektur.

Der Pagebuilder beschreibt die Seite. Die Compiler berechnen ihre Daten, Bildvarianten und Darstellung. Der Design-Manager liefert die Gestaltungsgrundlage. Der Dependency-Layer kennt die Beziehungen zwischen Quellen und Ergebnissen. Aus dieser Zusammenarbeit entstehen vorbereitete Artefakte und schließlich die vollständige Website.

VeloCore geht auf einen frühen Full-Headless-Ansatz zurück: Inhalte verwalten, benötigte Daten vorbereiten und die öffentliche Darstellung vom Redaktionssystem entkoppeln. Diese Architektur wurde im Publishing mit großen Archiven und produktiven Verlagsplattformen weiterentwickelt. Heute steht dieses Prinzip direkt in WordPress zur Verfügung – mit integrierter Gestaltung und ohne ein zusätzlich zu entwickelndes JavaScript-Frontend.[1][2]

Der Betrieb ohne zusätzliche Fremdplugins ist dabei gelebte Praxis: Wirtschaftsverlag, Fleisch & Co und ÖGVH setzen ihre VeloCore-Websites mit VeloCore und den eigenen Modulen um. Die integrierte Architektur ist die Grundlage dieses Betriebsmodells.

Das Inhaltsartefakt führt diese Ergebnisse zusammen: Neben Text und Metadaten enthält es unter anderem Bild-, Video-, DOM- und Query-Manifeste. Die einzelnen Fachsysteme liefern ihre Ergebnisse in dieselbe Produktionskette.

Dadurch entsteht mehr als eine schnell gespeicherte Seite: Es entsteht eine Seite, deren Datenbedarf, Medien, Struktur und Darstellung bereits vor ihrer Auslieferung aufeinander abgestimmt sind.

Im Rebuild werden die benötigten Informationen zusammengeführt: Text, Anriss, Titel, Veröffentlichungs- und Änderungsdatum, URL, Autor, Kategorien, Schlagworte, Beitragsbild, Bildabmessungen, Bildunterschrift, Kommentare und Übersetzungen. Hinzu kommen die Ergebnisse der spezialisierten Compiler. Damit steht der weiteren Seitenerzeugung ein gemeinsamer, vorbereiteter Datensatz zur Verfügung.

Die Informationen werden nicht für jede Disziplin getrennt erfunden. Der Artikel, seine Nachrichtenkarte, seine strukturierten Daten und seine responsive Bildausgabe greifen auf die jeweils veröffentlichten Inhaltsinformationen zurück. Diese gemeinsame Grundlage reduziert Abstimmungsarbeit zwischen Darstellung, Daten und Medien.

Der Speicherprozess schreibt den veröffentlichten Inhaltsdatensatz, erzeugt die dazugehörigen Stil-Artefakte und veröffentlicht die erfassten Query-Abhängigkeiten. Slug- und Kategoriedaten werden im vorgesehenen Ablauf mitgeführt. Bei CSS wird zuerst die Datei geschrieben und anschließend das Manifest, das auf diese Datei verweist.

Versionen und Signaturen machen die Zugehörigkeit nachvollziehbar. Eine Inhaltsrevision bezeichnet den Stand einer Seite; eine Designrevision den verwendeten Gestaltungsstand. Eine aus dem Dateiinhalt berechnete Kennung identifiziert das konkrete Ergebnis. Für die IT entsteht damit eine klare Verbindung zwischen Quelle, Verarbeitung und Veröffentlichung. Für die Redaktion bleibt es der bekannte Vorgang: Inhalt bearbeiten und veröffentlichen.

Die Compiler führen die fachliche Aufbereitung im Schreib- und Rebuild-Ablauf durch. Die vorbereitete Ausgabe steht anschließend zum Lesen bereit. Dieser klare Übergang ist ein wesentliches Architekturmerkmal: Eine Bildgrößenliste, ein Query-Ergebnis oder ein CSS-Plan wird als Ergebnis veröffentlicht und von den nachfolgenden Schritten verwendet. Für ein Redaktionsteam bedeutet das weniger technische Einzelentscheidungen pro Veröffentlichung. Für die Entwicklung entsteht ein nachvollziehbarer Ort für jede Aufgabe: Der Medien-Compiler berechnet Medien, der Query-Compiler bereitet Daten auf, der Stil-Compiler erzeugt die Gestaltungsausgabe und die Runtime veröffentlicht das fertige Dokument.

In einem Verlag steht ein Artikel selten allein. Seine Überschrift erscheint in Nachrichtenlisten. Sein Bild steht auf der Startseite. Sein Autor gehört zu einem Profil. Andere Artikel empfehlen ihn. VeloCore bildet diese Beziehungen ab.

Die Suite verzeichnet die Quellen vorbereiteter Sektionen: Beiträge, Bilder, Autoren, Kategorien, Schlagworte, Taxonomien und gelesene Einstellungen. Der Rückwärtsindex verbindet diese Quellen mit den jeweiligen Abfrageergebnissen und deren Abnehmern.

Der Compiler berücksichtigt sowohl konkrete Treffer als auch die Filter einer Ergebnisfläche. Neue Veröffentlichungen gelangen dadurch in die zugehörigen Nachrichtenlisten. Bei einer Umkategorisierung werden alte und neue Zuordnung berücksichtigt: Der Artikel verschwindet aus der bisherigen Liste und erscheint in der neuen.

Die Runtime kennt zusätzlich die Abhängigkeiten der fertigen Dokumente. Dazu gehören beispielsweise Artikel, Autoren, konkrete Menüs, Design, Header, Footer und gespeicherte Empfehlungen. Eine Änderung lässt sich damit bis zur vorbereiteten HTML-Ausgabe verfolgen.

Wenn Artikel A den Artikel B in seinen gespeicherten Empfehlungen enthält, kennt VeloCore diese Beziehung. Ein weiterer Artikel C wird nicht automatisch zum Abnehmer von B, bloß weil beide derselben Kategorie angehören. So bildet der Graph tatsächliche Empfehlungen ab, statt ganze Ressorts als gegenseitig abhängig zu behandeln.

Der normale speichergetriebene Aktualisierungsweg wartet weder auf den nächsten Leser noch auf den nächsten Cron-Tick. Die Veröffentlichung stößt die vorgesehene Verarbeitung an. Globale Gestaltung und gemeinsame Konfiguration haben ebenfalls eigene Aktualisierungspfade.

Eine Redaktion ändert bei einem bestehenden Artikel die Überschrift, ersetzt das Beitragsbild und verschiebt ihn von „Wirtschaft“ nach „Automotive“. Derselbe Artikel erscheint auf einer Ressortseite, in einem Tab auf der Startseite und als Empfehlung unter einem weiteren Beitrag. VeloCore behandelt diese Änderung als zusammenhängenden Vorgang.

Der Unterschied liegt im Wissen über die Beziehungen. VeloCore merkt sich nicht allein, dass eine URL vorhanden ist. Es hält fest, welche Quellen und gemeinsamen Seitenteile zur jeweiligen Ausgabe gehören.

Während der Query-Produktion werden Datenzugriffe erfasst: verwendete Beitragstypen und Taxonomien, gelesene Beitragsmetadaten, Optionen und Termabfragen. Dadurch erhält der Graph auch Beziehungen zu Daten, die während der Erstellung tatsächlich benötigt wurden. Ein geändertes Autorenprofil oder eine gelesene Einstellung lässt sich mit den registrierten Abnehmern verbinden.

Im Index sind beide Richtungen vorhanden: Welche Quellen verwendet ein Ergebnis? Welche Ergebnisse verwenden diese Quelle? Die Query-Ebene verknüpft Quellen mit geteilten Datenflächen; die Dokumentebene verknüpft Inhalte und gemeinsame Bestandteile mit der fertigen HTML-Ausgabe. Das macht Änderungen systematisch verfolgbar.

Eine Liste „Neueste Artikel aus Automotive“ hängt nicht ausschließlich an den derzeit angezeigten Artikel-IDs. Ihr Kategorienfilter gehört ebenfalls zur Abhängigkeit. Ein neuer passender Beitrag wird dadurch Teil des Aktualisierungswissens. Ungefilterte Latest-Flächen führen den jeweiligen Beitragstyp als Quelle. VeloCore verbindet also vorhandene Datensätze und die Regel, nach der eine Datenfläche ihren Inhalt erhält.

Auch übergeordnete Kategoriebezüge fließen in die Quellzuordnung ein. Der Rückwärtsindex verknüpft ein Ergebnis mit seinen registrierten Quellen und den konsumierenden Seiten. Die Dokumentebene verwendet dafür konkrete Schlüssel, etwa für einen Autor oder eine Menü-ID. Die Datenbank hält diese Zuordnungen indexiert vor. So wird aus einer Änderung eine gezielt adressierbare Aufgabe. Gerade bei großen Artikelbeständen ist diese ausdrückliche Beziehung zwischen Quelle und Abnehmer ein wichtiger Bestandteil der Betriebsarchitektur.

Die Frage lautet nicht allein, ob eine JPEG-Datei auch als WebP vorliegt. Entscheidend ist, wie breit das Bild in seiner Sektion verwendet wird, welche Varianten gebraucht werden und wie der Browser daraus die passende Datei auswählen kann.

VeloCore liest dafür die tatsächliche Seitenkonfiguration: Sektionstyp, Bildrolle, eingestellte Bildbreite, Spaltenverhältnis, Raster und verschachtelte Sektionen. Daraus leitet der Compiler die Zielbreiten ab.

Bei einer Einzelbild-Sektion mit 50 % Bildbreite entstehen im Berechnungsschema des vorliegenden Codes folgende Zielbreiten:

Die Zielwerte entstehen direkt aus dem Seitenmodell. Diese Layoutinformation verbindet VeloCore mit dem vorhandenen Bildbestand. Die Pipeline verwendet passende vorhandene Varianten und erzeugt zusätzliche Größen. Signaturen beziehen Quelle, Dateistand, benötigte Breiten, Qualität und Zuschnitt ein. Unveränderte Ergebnisse werden wiederverwendet.

Bildoptimierer übernehmen Bildkompression und Formatkonvertierung; je nach Produkt kommen Skalierung, CDN und responsive Funktionen hinzu. Imagify optimiert auch Thumbnailgrößen. Die Verwendung dieser Größen im Layout überlässt es Theme und WordPress.

VeloCore verbindet die Bildproduktion direkt mit dem System, das das Layout erzeugt. Ein zusätzlicher Bildoptimierer wird für diese Verarbeitungskette nicht benötigt. Die Größenberechnung, Bilddateien und Ausgabe sind bereits miteinander verbunden.

Bei einem On-Demand-Dienst wie ShortPixel Adaptive Images kann die erstmalige Verarbeitung einer Bildvariante beim Abruf stattfinden. VeloCore legt die vorbereiteten Varianten in seiner Produktionskette an; die veröffentlichte Seite verweist auf vorhandene Dateien.

Bei der Einzelbild-Sektion verwendet der Compiler die konfigurierte Bildbreite als Prozentfaktor und übernimmt den Faktor der umgebenden Spalte. Für die große Referenzvariante lautet der relevante Ansatz: 1.200 Pixel × Bildanteil × Spaltenanteil. Bei 50 % Bildanteil über die normale Sektionsbreite ergeben sich 600 Pixel. Innerhalb einer halben Spalte ergeben dieselben 50 % einen Referenzwert von 300 Pixeln. Die zusätzliche hochauflösende Variante wird entsprechend mitgeführt.

Galerien und Kachelraster verwenden ihre Spaltenzahl für die Größenrolle. Eine dreispaltige Galerie wird damit anders eingeordnet als ein Fullscreen-Hero. Verschachtelte Zweispaltenbereiche geben ihren Breitenfaktor an die enthaltene Sektion weiter. Die Berechnung folgt dem Aufbau, den der Redakteur tatsächlich angelegt hat.

Der Compiler durchsucht den vorbereiteten Bildbestand nach geeigneten Kandidaten. Dabei wird das Seitenverhältnis berücksichtigt: Ein deutlich anders zugeschnittener Thumbnail soll nicht versehentlich die Rolle eines proportionalen Inhaltsbilds übernehmen. Für die Wiederverwendung einer vorhandenen Größenvariante prüft die Auswahl außerdem deren Abstand zur berechneten Zielbreite.

Der Code akzeptiert dafür eine vorhandene Variante, die mindestens die Zielbreite erreicht und höchstens 20 % darüber liegt. Das verbindet passende Qualität mit sinnvoller Wiederverwendung. Die Pipeline berücksichtigt die native Bildgröße und vermeidet künstliches Hochskalieren. Quelle, Abmessungen und Qualitätsparameter gehen in die Identität neu erzeugter Varianten ein.

Wird dasselbe Motiv als Hero, Kachelbild und Galerieelement verwendet, führt VeloCore die Verwendungen anhand der Bildquelle zusammen. Benötigte Breiten werden gesammelt und doppelte Anforderungen entfernt. Die Signatur enthält unter anderem Quelldatei, Dateistand, angeforderte Größen, Alt-Informationen, Zuschnitt und Qualitätswerte. Ein unveränderter Stand mit vorhandenen Dateien wird wiederverwendet.

Der mobile Hero erhält zusätzlich einen eigenen Hochformatplan. Bei 9:16 entsprechen beispielsweise 360 Pixel Breite einer Höhe von 640 Pixeln; 720 Pixel Breite entsprechen 1.280 Pixeln Höhe. Der Compiler berechnet den nutzbaren Zuschnitt aus der Quelle und bereitet passende Varianten vor. Die Ausgabe verbindet diese Quellen mit Media- und Orientierungsangaben.

Der Nutzen ist konkret: Das System entscheidet gemeinsam über Motiv, Größenbedarf, Wiederverwendung und Browserauswahl. Eine halbierte Bildbreite und halbierte Bildhöhe bedeuten bei gleichem Seitenverhältnis ein Viertel der Pixelmenge. Genau deshalb ist die passende Größe neben dem Dateiformat ein wesentlicher Bestandteil der Bildoptimierung.

VeloCore weiß, welche Sektionen und Varianten auf einer Seite angelegt sind. Dieses Wissen verwendet der CSS-Compiler: News als Liste, Kacheln oder Kurzmeldungen, Tabs, horizontaler oder vertikaler Slider, gemeinsame Rahmen und verschachtelte Komponenten fließen in die Auswahl ein.

Die Zuordnung endet nicht beim Namen einer Sektion. Der Compiler unterscheidet Komponentenfamilien und Varianten. Er verarbeitet strukturelle Abhängigkeiten auch innerhalb funktionaler Selektoren wie :has(), :is() und :where(). Eine ausgeschlossene Klasse in :not() wird dabei nicht fälschlich als benötigte Komponente interpretiert.

Dadurch verbindet VeloCore die Struktur der Seite mit der Auswahl ihrer Styles. Der Design-Manager bleibt die zentrale Gestaltungsgrundlage; der Compiler erzeugt daraus die zur Seite gehörende Ausgabe.

Header, aktive Sektionen und verschachtelte Komponenten werden gemeinsam berücksichtigt. Der vorgesehene Seitenanfang erhält sein kritisches CSS direkt im HTML. Im geprüften Stand bilden standardmäßig die ersten drei sichtbaren Sektionen die Grundlage dieses Plans.

Die weitere CSS-Ausgabe wird vorbereitet, minifiziert und mit einer Inhaltskennung veröffentlicht. Das Stilmanifest verbindet Theme-Version, Inhaltsrevision, Designrevision, CSS-Datei, Header-CSS und Critical CSS. Inhalt und Gestaltung erhalten damit einen nachvollziehbaren gemeinsamen Stand.

WP Rocket besitzt Remove Unused CSS; FlyingPress bietet eine cloudbasierte CSS-Analyse. Beide bearbeiten die von einem anderen System erzeugte Seite. VeloCore erzeugt die Seite und verwendet deren Struktur bereits als Grundlage für die Styles.

Der Vergleichspunkt ist die Informationsgrundlage: VeloCore verbindet Seitenerzeugung und CSS-Produktion. Ein separates Optimierungsprodukt wird dafür nicht zusätzlich benötigt.

Der CSS-Bedarf beantwortet, welche Regeln zu einer Seite gehören. Der Critical-CSS-Plan beantwortet zusätzlich, welche davon für den vorgesehenen Seitenanfang früh bereitstehen müssen. VeloCore führt beide Entscheidungen innerhalb derselben Produktion zusammen: eine passende Gesamtausgabe für die Seite und eine gezielt vorbereitete frühe Ausgabe für Header und Anfangssektionen.

Das ist im Alltag entscheidend. Eine Nachrichtenliste benötigt andere Komponentenregeln als ein Kachelraster. Eine Sektion mit Tabs benötigt außerdem die zugehörigen Tab-Strukturen. Ein horizontaler Slider hat andere Abhängigkeiten als ein vertikaler Slider. Der Compiler wertet diese Varianten aus und verbindet sie mit den jeweiligen Klassenfamilien.

Eine Zweispaltensektion ist für die CSS-Produktion nicht bloß ein äußerer Container. Die enthaltenen Sektionen werden in den Komponentenbaum aufgenommen. Dadurch kennt der Plan auch den CSS-Bedarf einer Galerie, Nachrichtensektion oder Bild/Text-Fläche innerhalb dieser Spalten. Der tatsächliche Aufbau bleibt bis in die Stilauswahl sichtbar.

Auch zusammengesetzte Selektoren werden strukturell verarbeitet. Der Compiler betrachtet positive Abhängigkeiten innerhalb funktionaler Selektoren und erhält deren Zusammenhang. Klassenfamilien werden gezielt abgegrenzt, damit ähnlich beginnende Namen unterschiedlicher Komponenten nicht versehentlich gleich behandelt werden. Solche Details zeigen, dass die Verarbeitung tiefer reicht als das Entfernen von Leerzeichen oder das Zusammenführen von Dateien.

Das erzeugte Seiten-CSS erhält einen aus seinem Inhalt berechneten Hash. Der Dateiname verbindet außerdem Seitenidentität und Inhaltstyp mit der CSS-Kennung. Das Stilmanifest speichert die aktuelle Inhalts-, Design- und Theme-Zuordnung und die fertigen Critical-CSS-Ergebnisse. Eine gestalterische Änderung wird dadurch als neuer Produktionsstand nachvollziehbar.

Die Datei wird vor dem referenzierenden Manifest veröffentlicht. Der vorbereitete Lesepfad verwendet anschließend das veröffentlichte Ergebnis; er startet keine gemeinsame CSS-Reparatur für jeden Leser. Die Ressource und ihre Beschreibung gehören zum selben Ablauf.

Für die Website bedeutet das: Gestaltung bleibt zentral steuerbar, während jede Seite ihre konkrete Ausgabe erhält. Für den Betrieb bedeutet es klare Versionsbezüge zwischen Inhalt, Design und ausgeliefertem CSS. Diese Verbindung ist der eigentliche Mehrwert des integrierten Compilers.

Zur Verarbeitung gehören außerdem Selektorreihenfolge und strukturelle Zusammenhänge. Das ist wichtig, weil CSS seine Wirkung nicht allein aus einer Klassenliste bezieht: Verschachtelung, funktionale Selektoren und die Reihenfolge von Regeln gehören zur Darstellung. VeloCore behandelt die Auswahl deshalb als Compileraufgabe. Der vorbereitete Headerplan und die seitenbezogene Ausgabe entstehen aus den vorhandenen Regeln und ihren Komponentenabhängigkeiten. Der Design-Manager beschreibt die Gestaltung; die Produktion übernimmt deren Zuordnung zur jeweiligen Seite.

Der Query-Compiler verarbeitet die Konfiguration von Nachrichtenflächen: Anzahl, Offset, Sortierung, Kategorien, Schlagworte, Verknüpfungen, Ausschlüsse, Tabs und Sprache. Der normalisierte Plan erhält eine Signatur.

Identische Pläne teilen dasselbe vorbereitete Ergebnis. Verschiedene Seiten verwenden damit eine gemeinsame Datenfläche. Der Dependency-Layer verbindet den geteilten Datensatz mit seinen Quellen und den Seiten, die ihn verwenden.

Bei einer Änderung findet der Rückwärtsindex die betroffenen Signaturen und ihre Abnehmer. Auch vorbereitete Archive führen ihre Zugehörigkeiten und Ergebnisgenerationen. Der Ansatz spart Wiederholung bereits bei der Datenproduktion.

Der Struktur-Compiler erkennt benachbarte Sektionen mit passenden gemeinsamen Außenflächen. Hintergrund, Rahmen und weitere äußere Layoutmerkmale fließen in den Vergleich ein. Geeignete gemeinsame Außenflächen werden zusammengeführt.

Die einzelnen Inhalte bleiben als eigene semantische Sektionen erhalten. Ihre Abstände und Inhaltsklassen bleiben getrennt steuerbar. VeloCore bereitet damit auch die Struktur des erzeugten HTML auf – eine zusätzliche Ebene neben Kompression, Minifizierung und Caching.

Die integrierte Video-Verarbeitung bereitet Hintergrundvideo-Profile und mobile Hochformatvarianten vor. Quellen, Fokus und Loop-Einstellungen fließen in Signaturen ein. Das Ergebnis wird als Video-Manifest in den Seitendatensatz aufgenommen.

Bilder, Videos, Datenflächen und Layoutstruktur werden damit nicht als isolierte Optimierungsprojekte behandelt. Ihre Vorbereitung gehört zum Erstellen der Seite.

Für ein geteiltes Ergebnis zählt die vollständige Konfiguration. Der normalisierte Plan berücksichtigt unter anderem Sprache, Ergebnisformat, Anzahl, Offset, Sortierung, Kategorien, Schlagworte, Verknüpfungen, Ausschlüsse und Tabs. Rekursiv geordnete Werte bilden die Grundlage der Signatur. So erhält dieselbe fachliche Abfrage dieselbe Identität.

Eine Liste mit Offset 0 und eine Liste mit Offset 8 bleiben unterschiedliche Datenflächen. Ebenso bleiben ein AND-Filter und ein OR-Filter unterscheidbar. Geteilt wird genau die identische Aufgabe. Diese Genauigkeit verbindet Wiederverwendung mit der Kontrolle, die Publisher über ihre Nachrichtenflächen benötigen.

Der vorbereitete Datensatz enthält die tatsächlichen Ergebnisse und Karteninformationen. Er ist nicht lediglich eine gespeicherte SQL-Anweisung, die bei jedem Leser erneut ausgeführt werden soll. Bei Tabs werden die zugehörigen Daten und Ergebnisinformationen im Compiler berücksichtigt. Das Seitenmodell erhält damit einen bereits aufbereiteten Datenbestand.

Der gemeinsame Query-Speicher führt Signaturen, Abnehmer und Quellenbezüge zusammen. Ändert sich eine registrierte Quelle, werden die zugehörigen Ergebnisse ungültig gemacht und ihre Abnehmer gefunden. Verschwindet der letzte Abnehmer einer gemeinsam verwendeten Signatur, kann deren Zuordnung bereinigt werden. Geteilte Ergebnisse bleiben damit Teil eines verwalteten Produktionssystems.

Die DOM-Fusion vergleicht die wirksame Außenfläche benachbarter Sektionen. Dazu werden unter anderem Layout, Breite, Hintergrundfarbe beziehungsweise Verlauf, Bild oder Video und Overlay in einer normalisierten Rahmensignatur erfasst. Passen diese Merkmale zusammen, wird die äußere Fläche gemeinsam aufgebaut.

Die Inhalte behalten ihre eigenen semantischen Sektionen. Innere Abstände, Inhaltsklassen und jeweilige Inhalte bleiben ihrer Sektion zugeordnet. Damit reduziert VeloCore doppelte äußere Strukturen und erhält die redaktionelle und gestalterische Trennung der Inhalte. Der Renderer verwendet dafür den vorbereiteten Fusionsplan.

Auch die Medienpriorisierung arbeitet mit der resultierenden Struktur zusammen: Im zusammengeführten Aufbau wird das erste relevante Bild für die bevorzugte LCP-Behandlung bestimmt. Datenvorbereitung, Strukturaufbereitung und Ladepriorität greifen damit ineinander. Genau diese Übergänge machen aus mehreren guten Einzelfunktionen eine gemeinsame Architektur.

VeloCore besitzt eine eigene technische SEO-Ausgabe. Titel, Beschreibung, Canonical, Social-Metadaten und strukturierte Daten entstehen innerhalb des Systems. Ein zusätzlicher SEO-Plugin-Layer wird dafür nicht benötigt.

Nach der HTML-Veröffentlichung stehen Metadaten und Schemas bereits im Dokument. Beim Fast-Path-Abruf muss kein SEO-Plugin dessen Head neu erzeugen. Die normalen XML-Sitemaps liegen ebenfalls vorbereitet vor und werden beim Abruf aus ihren Dateien gelesen.

Yoast verwendet selbst vorausberechnete Indexables. Rank Math bietet umfangreiche Schema-Funktionen. Die Hersteller lösen damit ihre jeweilige SEO-Aufgabe. VeloCore verbindet diese Ausgabe mit Inhalt, Medien, Seitenerzeugung und Veröffentlichung.[16][17]

„SEO ohne SEO-Kosten“ bedeutet hier: keine zusätzliche SEO-Plugin-Lizenz für die integrierten technischen Grundlagen. Themenwahl, Inhalte und redaktionelle Qualität bleiben der eigentliche Stoff, mit dem ein Publisher seine Leser erreicht.

Die strukturierte Artikelausgabe verbindet den Artikel mit seiner URL, seinem Autor und dem Publisher. Titel, Beschreibung, Veröffentlichungs- und Änderungsdatum, Bildinformationen und redaktionelle Eigenschaften stammen aus dem Inhaltsmodell. Ergänzende Angaben wie Artikeltext und Wortzahl werden innerhalb der Ausgabe verarbeitet.

Autoreninformationen umfassen Name, Profilbezug und vorhandene Beschreibungs-, Bild- und Social-Daten. Das Publisher-Verhältnis verweist auf die zentrale Identität der Website. Die Breadcrumb-Ausgabe ergänzt den Navigationszusammenhang. Der Artikel wird dadurch als Inhalt innerhalb einer redaktionellen Plattform beschrieben.

Für den Verlag ist das ein praktischer Vorteil: Die sichtbare Seite, ihre Autorenzuordnung und ihre strukturierte Beschreibung werden innerhalb derselben Produktion zusammengeführt. Ein zusätzliches Schema-Ausgabesystem wird für diese Informationen nicht benötigt.

Open Graph enthält neben Titel, URL und Beschreibung auch die zugehörigen Bildinformationen. Vorhandene Abmessungen, Bildtyp und Alt-Informationen fließen in die Ausgabe ein. Artikelbezogene Social-Metadaten berücksichtigen Veröffentlichungs- und Änderungsdaten sowie redaktionelle Zuordnungen. Die Bilddaten sind damit nicht ausschließlich ein Thema der sichtbaren Darstellung.

Bei FAQ-Inhalten entsteht die strukturierte Ausgabe aus den dafür vorgesehenen sichtbaren Frage-/Antwort-Inhalten. Das verbindet den Inhalt, den Besucher lesen, mit dessen maschinenlesbarer Beschreibung. Seitentyp und Unternehmensdaten werden zentral konfiguriert und in den jeweiligen Graphen eingebunden.

Die Sitemap-Produktion bildet Beiträge, Seiten, Kategorien und Autoren in vorbereiteten XML-Artefakten ab. Größere Bestände werden auf Teil-Sitemaps verteilt und über Indexdateien zusammengeführt. Aktualisierungen werden in den dafür vorgesehenen Synchronisationswegen veröffentlicht.

Die Dateien werden über vorbereitete temporäre Ergebnisse atomar ersetzt. Damit gehört auch die technische Auffindbarkeit der Inhalte zum Produktionsmodell. Der Sitemap-Abruf liest die vorhandene XML-Datei, statt dafür erst den gesamten redaktionellen Bestand zusammenzustellen. Für große Archive verbindet VeloCore so den veröffentlichten Inhaltsstand mit einer skalierbaren Sitemap-Struktur.

Nach der Daten-, Medien-, Design- und SEO-Produktion entsteht die vollständige HTML-Seite. Die Runtime speichert das Ergebnis, verzeichnet seine Abhängigkeiten und veröffentlicht die Datei für die direkte Auslieferung.

Beim Fast-Path-Treffer liefert Apache diese HTML-Datei aus. Für diesen Dokumentabruf starten weder PHP noch WordPress; es ist keine SQL-Abfrage zur Erzeugung des HTML erforderlich.

Ein Cacheprodukt kann ebenfalls fertige HTML-Dateien direkt ausliefern. Das ist eine Eigenschaft der letzten Auslieferungsstufe. VeloCores Produktleistung umfasst zusätzlich die vorgelagerte Erzeugung dieses HTML samt Daten, Medien und Styles.

Die Dokumentproduktion berechnet eine SHA-256-Kennung des erzeugten HTML. Diese Kennung bestimmt den Objektpfad des gespeicherten Ergebnisses. Ist das identische Ergebnis bereits vorhanden, wird es wiederverwendet. Die gespeicherten Bytes werden gegen die berechnete Kennung geprüft. So gehört die Integrität der Datei zur Veröffentlichung selbst.

Ein Dokument ist damit nicht bloß eine Datei mit zufälligem Namen. Sein konkreter Inhalt ist identifizierbar. Manifestinformationen halten Dateigröße, Kennungen, Compilerbezug und Generation zusammen. Das erleichtert die nachvollziehbare Zuordnung zwischen Erzeugung und veröffentlichtem Ergebnis.

Die Runtime teilt den Routenindex anhand von Hash-Präfixen in Buckets. Eine neue Generation übernimmt vorhandene Routendaten; geänderte Bereiche werden fortgeschrieben. Vorhandene Dateien und Datenbereiche werden über Hardlinks oder Kopien weiterverwendet. Dadurch muss ein neuer Produktionsstand nicht jede unveränderte Information vollständig neu duplizieren.

Der aktuelle Generationsbezug wird atomar veröffentlicht. Anschließend werden die tatsächlichen Live-Dokumente je Route bereitgestellt. Auch der einzelne Dateiaustausch arbeitet mit einer vorbereiteten temporären Datei und anschließendem Umbenennen. Leser erhalten eine fertige Datei statt des Zwischenstands eines laufenden Schreibvorgangs.

Für die Dokumenterzeugung wird die vollständige Ausgabe erfasst. Dazu gehören Inhalt, Navigation, CSS-Verweise, Critical CSS, Bildausgabe, Metadaten und Schemas. Der Fast-Path liefert genau dieses veröffentlichte Ergebnis. Der Leser muss die vorgelagerten Produktionsschritte nicht erneut auslösen.

Diese Trennung ist für Publisher besonders wertvoll: Die anspruchsvolle Arbeit orientiert sich an redaktionellen Änderungen und notwendigen Dokumentständen. Viele Abrufe verwenden anschließend dasselbe vorbereitete Ergebnis. Der Dependency-Layer verbindet spätere Änderungen wieder mit den zugehörigen Dokumenten.

Die Architektur endet deshalb nicht beim schnellen Treffer. Sie umfasst den Weg vom geänderten Inhalt über seine abhängigen Daten und Ressourcen bis zur überprüften, veröffentlichten Datei. Der Fast-Path macht diese Vorarbeit im Auslieferungspfad nutzbar.

Ein Cache speichert eine Ausgabe. Ein Bildoptimierer verarbeitet Medien. Ein SEO-Plugin erzeugt Metadaten. VeloCore verbindet diese Disziplinen mit dem System, das die Website selbst erzeugt.

Vergleichen Sie den gesamten Weg vom redaktionellen Inhalt bis zum veröffentlichten Ergebnis. Ein zusätzlicher Produktname auf der Plugin-Liste beantwortet noch nicht, wer Bildbedarf, Seitenstruktur und Aktualisierung gemeinsam organisiert. VeloCore übernimmt diese Verantwortung innerhalb einer durchgängigen Plattform und verbindet die einzelnen Verarbeitungsschritte mit dem täglichen Publishing.

VeloCore ist darauf ausgelegt, die Website mit der Suite, der Runtime Engine und eigenen Modulen zu betreiben. Für die folgende Aufgabenverteilung wird kein zusätzlicher Fremdplugin-Stack benötigt.

Diese 22 Aufgaben sind keine Behauptung, dass eine klassische Website 22 Plugins gleichzeitig installieren muss. Viele Produkte bündeln mehrere Aufgaben. Der Systemvorteil besteht darin, dass VeloCore diese Aufgaben bereits in seiner Architektur zusammenführt und Sie keines der o.g. Plugins benötigen.

Ein Beispielstack aus Yoast SEO, WP Rocket, Imagify, OMGF, YARPP, Simple Local Avatars, Contact Form 7 und MetaSlider enthält acht eigenständige Zusatzplugins. Für die oben beschriebenen technischen SEO-, Medien-, Font-, Empfehlungs-, Autorenbild-, Anfrage- und Darstellungsaufgaben übernimmt VeloCore deren Rolle.

Damit entfallen in diesem Beispiel acht Fremdplugins. Hinzu kommen die eigenständigen VeloCore-Leistungen, für die es in dieser Liste noch gar kein entsprechendes Einzelprodukt gibt: geteilte Query-Artefakte, zwei Dependency-Ebenen, integrierte Manifestproduktion und strukturelle DOM-Aufbereitung.

Für Publisher gehören mehr als Artikel zur Website: Anzeigen, Branchenverzeichnisse, Jobs, Veranstaltungen, Paywalls oder weitere Geschäftsfunktionen. Das VeloCore-Prinzip sieht dafür eigene Module vor.

Diese Erweiterungen werden als Teil des VeloCore-Systems entwickelt. Gemeinsame Gestaltung, vorbereitete Daten und Integrationspunkte stehen für ihre Umsetzung bereit. Die Plattform wächst dadurch fachlich weiter, ohne dass grundlegende SEO-, Medien- und Performance-Aufgaben wieder als unabhängige Fremdplugin-Kette zusammengesetzt werden müssen.

Bereits in der Suite stehen außerdem zahlreiche redaktionelle und gestalterische Bausteine bereit: News-Sektionen, Tabellen, Preisübersichten, FAQ, Tabs, Testimonials, Teamdarstellungen, Bilder, Galerien, Slider, Kommentare, Anzeigenpositionen und Aufrufzähler.