Performance

Der Replacer ist so ausgelegt, dass er günstig genug ist, um auf jeder Anfrage ohne messbaren Einfluss zu laufen. Einige Dinge helfen dabei.

Request-Cache

Variablendefinitionen werden einmal pro Request geladen, mit Schlüssel Verkaufskanal + Bereich. Nachfolgende Inhalts-Scans im selben Request verwenden die gecachten Daten wieder. Eine Seite mit 50 CMS-Blöcken und 10 unterschiedlichen Variablen lädt die Variablenliste nur einmal.

Frühzeitige Abbrüche

Bevor irgendeine String-Arbeit gemacht wird, prüft der Replacer:

1. Den Plugin-Schalter für den aktuellen Bereich — wenn aus, kehrt sofort zurück.
2. Scannt den Inhalt nach dem wörtlichen {-Zeichen — falls nicht vorhanden, kehrt sofort zurück.
3. Lädt Variablen nur, wenn es mindestens einen Kandidaten-Platzhalter gibt.

Seiten ohne {...}-Platzhalter zahlen fast nichts.

Was Zyklen kostet

• Lange Inhalte mit vielen Platzhaltern. Jeder Platzhalter ist eine Hash-Map-Suche — schnell, aber linear.
• Verschachtelte Variablen. Jede verschachtelte Referenz ist eine weitere Suche und Ersetzung. Halten Sie die Verschachtelung flach (eine Ebene per Design, siehe Verschachtelte Variablen).
• Große CSS- / JS-Payloads pro Variable. Die Injektion selbst ist konstanter Aufwand, aber ein schwerer CSS- / JS-Block landet im Seiten-HTML und der Browser zahlt dafür.

Empfehlungen

• Nutzen Sie Bereiche, um die Variablenliste pro Bereich kurz zu halten. Eine Variable, die auf Category beschränkt ist, wird auf reinen CMS-Anfragen nicht geladen.
• Begrenzen Sie die Verschachtelungstiefe — die Engine stoppt sowieso bei einer Ebene. Wenn Sie tiefere Verschachtelung wollen, strukturieren Sie Ihre Variablen um.
• Halten Sie CSS / JS klein. Wenige Regeln und wenige Zeilen Init-Code sind ideal.
• Cache nach Inhaltsänderungen leeren. Cache-Invalidierung ist der langsamste Teil des Lebenszyklus — bauen Sie das Cache-Flush in Ihren Redaktionsablauf ein.

Profiling

Wenn Sie vermuten, dass das Plugin in einem Profil heiß ist:

• Setzen Sie im Symfony-Profiler / Blackfire Spans um das Storefront-Rendering einer Beispielseite.
• Vergleichen Sie mit derselben Seite, wenn die CMS-Ersetzung aus ist — der Unterschied ist der Beitrag des Plugins.
• Reproduzieren Sie in einer sauberen Umgebung, bevor Sie optimieren; viele „langsame” Fälle sind eigentlich langsames CMS-Rendering, nicht die Ersetzung.