Wenn Sie so viele Jahre mit Neos CMS arbeiten wie ich, kennen Sie normalerweise die Tricks auswendig, wie man eine schnelle Neos CMS Website erstellt. Aber ich sehe und höre regelmäßig Diskussionen über dieses Thema, und wenn ich einem bestehenden Neos-Projekt beitrete, sehe ich oft einige leicht zu behebende Fehler bezüglich der Leistung.
Als ich kürzlich eine bestehende Website um den Faktor 10x beschleunigt habe, beschloss ich, einige Hinweise in diesem Blogbeitrag zu schreiben, um anderen zu helfen. Vielleicht können sogar einige Neos-Experten ein oder zwei Dinge lernen.
Auch wenn Ihre Website so schnell wie eine Rakete sein wird, ist es keine Raketenwissenschaft, dies zu tun.
Dieser Text wurde teils automatisiert ins Deutsche übersetzt.
Was Sie von diesem Leitfaden erwarten können
Wenn Sie dieses Rezept befolgen, sollten Sie am Ende eine viel schnellere Neos-Website haben.
Die meisten Hinweise in diesem Beitrag gelten für kleine, mittlere und große Websites.
Einige Optimierungen machen nur bei größeren Websites einen nennenswerten Unterschied, aber ich werde das für jede einzelne hervorheben.
Ich werde nicht jede Funktion und Konfiguration in allen Details erklären, und auch nicht, wie man die notwendige Software installiert, da es dafür viel bessere Tutorials im Web gibt und diesen Beitrag viel zu lang machen würde. Aber ich werde einige Links bereitstellen, die Ihnen den Einstieg erleichtern sollten.
Für die meisten Hosting-Umgebungen sollten Sie von Ihrer Website eine Antwortzeit zwischen 60-200ms für zwischengespeicherte Anfragen erwarten können, je nach Komplexität Ihrer Website und Ihres Hostings.
Basiszutaten
Für eine schnelle Neos CMS-Website sollten Sie die folgenden Zutaten zur Verfügung haben:
- Webserver (NGINX or Apache)
- PHP 7+
- MySQL oder MariaDB
- Eine laufende Neos CMS-Website natürlich
Optionale erweiterte Zutaten:
- Redis
- Varnish
- Cloud CDN provider
- ElasticSearch
Der Webserver
Der Webserver ist der wichtigste Einstiegspunkt in die Möglichkeit, beliebige Inhalte auszuliefern. Sie können NGINX oder Apache verwenden, aber meistens ist der Unterschied nicht so groß.
Ich persönlich bevorzuge NGINX, da die Konfiguration für mich leichter zu lesen ist und es bei der Auslieferung statischer Inhalte wie Bilder schneller arbeitet. Sie können auch einen Proxy-Cache für Ihr html aktivieren, aber das erfordert eine etwas fortgeschrittenere Konfiguration. Zu diesem Thema komme ich etwas später in diesem Beitrag. Sie finden hier eine Beispielkonfiguration, die mit PHP-FPM verwendet werden kann.
Apache andererseits funktioniert auch gut und Neos enthält standardmäßig eine funktionierende .htaccess-Datei im Web-Ordner mit der notwendigen Konfiguration, um zu beginnen.
Performance Empfehlung 1: Der Anwendungskontext
Neos CMS arbeitet mit einem Anwendungskontext namens "FLOW_CONTEXT". Dieser Kontext ist im Grunde eine Umgebungsvariable, die Neos mitteilt, in welchem Modus es laufen soll.
Standardmäßig ist diese auf "Development" eingestellt. Das bedeutet für Neos, dass Sie daran arbeiten, Sie erhalten eine bessere Fehlerrückmeldung und es scannt bei jeder Anfrage, ob Sie Dateien geändert haben.
Dies macht das ganze System natürlich langsamer, ist aber notwendig, wenn Sie aktiv an der Entwicklung Ihrer Website arbeiten.
Wenn Sie Ihre Produktionswebsite einrichten, die die tatsächlichen Besucher bedienen soll, sollten Sie diese Kontextvariable unbedingt auf "Production" setzen. Dies können Sie z.B. in der .htaccess für Apache oder in der NGINX-Konfiguration tun. Es gibt auch andere Möglichkeiten, dies zu tun, aber dies ist die gebräuchlichste Methode.
Wie Sie dies für Apache ändern können:
In der mitgelieferten .htaccess-Datei im Neos CMS-Ordner "Web" finden Sie eine Zeile wie:
SetEnv FLOW_CONTEXT ProductionStellen Sie sicher, dass diese Zeile kein Kommentar ist, was bedeutet, dass sie nicht mit einem "#" beginnt.
Wie man dies für NGINX anpasst:
Sie sollten eine Zeile wie diese in Ihrem Ortsblock für PHP haben, wenn Sie fastCGI verwenden:
fastcgi_param FLOW_CONTEXT Development/Local;Diese Änderung sollte Ihre Website bereits um den Faktor 2 oder 3 beschleunigen und dauert nur eine Minute. Besonders im Backend von Neos macht dies einen noch größeren Unterschied als im Frontend, da das Backend mehr Anfragen an den Server sendet, als eine einzige Seitenansicht im Frontend.
PHP
Da Neos CMS und das ihm zugrundeliegende Flow Framework in PHP geschrieben sind, hängen sie stark von der Performance der verwendeten PHP-Version ab.
Neos CMS 2.3 LTS unterstützt PHP 5.6 bis 7.1. Und die neueren Neos CMS Versionen 3.3 LTS und 4.3 LTS unterstützen PHP bis 7.3.
Ich verwende normalerweise PHP in seiner FPM-Variante und verbinde mich vom Webserver aus über einen Socket. Aber das sollte in den meisten Fällen nicht so wichtig sein. Das Laden von PHP als Apache-Modul oder auf andere Weise wird also ähnliche Ergebnisse liefern. PHP-FPM mit einem Socket sollte weniger Overhead haben, wenn der Webserver sich mit ihm verbindet und die Ressourcen besser verwaltet.
Performance Empfehlung 2: Die PHP Version
Ich empfehle unbedingt, die neueste PHP-Version zu verwenden, die Ihre installierte Neos-Version unterstützt, da der Leistungsgewinn von PHP 7.1 gegenüber 5.6 etwa den Faktor 1,5 - 2 beträgt.
Wenn Sie die Version auf einer laufenden Seite wechseln, sollten Sie danach die Caches von Neos löschen, indem Sie folgenden Befehl ausführen:
./flow flow:cache:flush —forceIch neige auch dazu, die PHP-Zielversion zur Datei composer.json hinzuzufügen, um zu verhindern, dass Composer Abhängigkeiten installiert, die möglicherweise nicht mit der PHP-Umgebungsversion funktionieren, und um Fehler anzuzeigen, wenn es keine kompatiblen Versionen gibt.
Sie können dies tun, indem Sie die "platform"- und "php"-Einstellungen zu Ihrer composer.json im bestehenden "config"-Block hinzufügen:
"config": {
"vendor-dir": "Packages/Libraries",
"bin-dir": "bin",
"platform": {
"php": "7.1.28"
}
}Performance Empfehlung 3: Aktivieren des OPCache Moduls
Dieser Vorteil kommt aber nur dann voll zur Geltung, wenn das OPCache-Modul von PHP aktiviert ist, das die neuesten kompilierten PHP-Dateien zwischenspeichert und somit dem Server weniger Arbeit macht, wenn die gleichen Dateien wieder für die Darstellung einer Site benötigt werden.
Ich habe gesehen, dass einige verwaltete Server dieses Modul nicht standardmäßig aktiviert haben.
Es könnte auch eine gute Idee sein, den Speicher, den das Modul verwenden darf, auf 128 oder 256 MB in der PHP-Konfiguration zu erhöhen.
Die Datenbank
Neos CMS unterstützt eine Reihe von Datenbanken. Dazu gehören MySQL und sein kompatibler Open Source Fork MariaDB und auch PostgreSQL.
Ich habe nur Erfahrung mit MySQL und MariaDB, aber soweit ich weiß, verhalten sie sich meist alle gleich. Es sollte einige theoretische Performance-Gewinne (~20% für bestimmte Abfragen) mit MariaDB im Vergleich zu MySQL geben, aber ich habe nie beide mit der gleichen großen Website getestet, um den tatsächlichen Unterschied zu sehen. Normalerweise neige ich dazu, MariaDB zu benutzen, da ich deren Herangehensweise unterstütze.
Sie können einige Erklärungen zu den Unterschieden hier finden.
Ich musste nie andere Standardeinstellungen in meinen Projekten ändern, aber dies könnte für größere Sites oder abhängig von Ihrem Hosting notwendig sein, da die Standardeinstellungen unterschiedlich sein können.
Das CMS
Natürlich hat Neos selbst auch einige Einstellungen, die für die Leistung einer Website wichtig sind.
Da Neos den zuvor erwähnten "FLOW_CONTEXT" verwendet, um die meisten Dinge bereits korrekt einzustellen, gibt es einige andere Einstellungen, die Sie vielleicht anpassen möchten.
Das Caching Backend
Standardmäßig erstellt Neos eine Menge Caches, um die Auslieferung von Inhalten für nachfolgende Anfragen zu beschleunigen. Diese zwischengespeicherten Dateien werden im Dateisystem (normalerweise in Data/Temporary) gespeichert und enthalten Routing-Informationen, gerenderte HTML-Teile, modifizierte PHP-Dateien, Lokalisierungen usw.. Da die Menge der Dateien und Anfragen an diese Dateien immer größer werden kann, wenn Ihre Site und ihr Code wachsen, kann der Server viel Zeit damit verbringen, sie zu lesen.
Performance Empfehlung 4: Ändern Sie das Caching-Backend auf Redis
Das empfohlene Caching-Backend ist Redis, ein speicherinterner Schlüssel-/Wertspeicher. Der Dienst muss auf Ihrem Server (oder irgendwo in Ihrem Stack) laufen und das Redis-Modul für PHP muss aktiviert sein. Die Cache-Konfiguration sollte in einer Datei namens "Caches.yaml" erfolgen, die Sie neben Ihrer "Settings.yaml" ablegen sollten. Ich benutze Redis auch während der Entwicklung, aber Sie können diese Datei natürlich nur in den Ordner "Configuration/Production" legen (oder es so machen, dass es zu Ihrem Deployment-Prozess passt).
Eine "Caches.yaml" mit Redis für Neos 3.0 oder neuer:
Flow_Mvc_Routing_Route:
backend: Neos\Cache\Backend\RedisBackend
backendOptions:
database: 0
Flow_Mvc_Routing_Resolve:
backend: Neos\Cache\Backend\RedisBackend
backendOptions:
database: 0
Neos_Fusion_Content:
backend: Neos\Cache\Backend\RedisBackend
backendOptions:
database: 0
Neos_Neos_Fusion:
backend: Neos\Cache\Backend\RedisBackend
backendOptions:
database: 0In der Regel habe ich mit dieser Konfiguration eine Leistungssteigerung von ~30% erreicht, und sie könnte sogar noch größer sein, wenn Ihre Website von vielen Anfragen betroffen ist.
Für Shared & Managed Hosting steht oft kein Redis zur Verfügung, so dass Sie stattdessen einige Alternativen nutzen können, die weniger leistungsfähig sind, aber auch Hilfe für kleine und mittlere Websites bieten.
Wenn Sie mehrere Websites auf demselben Server betreiben, müssen Sie die Datenbanknummer für jede Website ändern, damit sie sich nicht gegenseitig stören.
Alternative: Verwenden Sie das PDO-Backend
Das PDO-Backend verwendet eine normale Datenbank zur Speicherung der zwischengespeicherten Informationen. Am einfachsten ist es, SQLite zu verwenden, das Ihr Server und PHP unterstützen muss. Aber auch andere Datenbanken wie MySQL werden unterstützt, benötigen aber ein wenig Konfiguration. Alle Server, mit denen ich zu tun hatte und denen Redis fehlte, hatten normalerweise SQLite-Unterstützung. Lesen Sie mehr über dieses Thema und noch mehr Cache-Backends hier.
Eine grundlegende Cache-Konfiguration mit dem PDO-Backend und SQLite würde so aussehen:
Flow_Mvc_Routing_Route:
backend: Neos\Cache\Backend\PdoBackend
backendOptions:
defaultLifetime: 0
dataSourceName: 'sqlite:/var/www/example.org/shared/sqlite.db'
Flow_Mvc_Routing_Resolve:
backend: Neos\Cache\Backend\PdoBackend
backendOptions:
defaultLifetime: 0
dataSourceName: 'sqlite:/var/www/example.org/shared/sqlite.db'
Neos_Fusion_Content:
backend: Neos\Cache\Backend\PdoBackend
backendOptions:
defaultLifetime: 0
dataSourceName: 'sqlite:/var/www/example.org/shared/sqlite.db'
Neos_Neos_Fusion:
backend: Neos\Cache\Backend\PdoBackend
backendOptions:
defaultLifetime: 0
dataSourceName: 'sqlite:/var/www/example.org/shared/sqlite.db'Diese Konfiguration sollte auch bei kleinen und mittleren Websites gut funktionieren. Aber ich würde empfehlen, auf Redis zu wechseln, wenn Ihre Sites größer werden, da es für diese Aufgabe optimiert ist.
Die Konfiguration des Content Caches
Neos CMS ermöglicht Ihnen eine sehr feinkörnige Kontrolle darüber, was und wie Ihre Inhaltsteile zwischengespeichert werden. Sie definieren diese Konfigurationen in Fusion zusammen mit Ihren Rendering-Definitionen Ihrer Node-Typen. Neos CMS speichert standardmäßig meist nur komplette Seiten, aber Sie können dies auch weiter optimieren, indem Sie kleinere Teile zwischenspeichern, die beim Rendern anderer Seiten wiederverwendet werden.
Performance Empfehlung 5: Häufig verwendete Fusion-Objekte zwischenspeichern
Es gibt Teile Ihrer Website, die in der Regel für alle Unterseiten gleich sind. Meistens handelt es sich dabei um die Kopfzeile der Website (mit einigen Einschränkungen), die Fußzeile und die enthaltenen Skripte und Stile.
Durch die Definition einer Cache-Konfiguration (lesen Sie mehr darüber hier) muss Neos diese Teile nicht für jede Unterseite immer wieder neu aufbauen. Wenn Sie also ein komplexes Menü in Ihrer Kopf- und Fußzeile haben, werden diese Berechnungen im besten Fall nur einmal durchgeführt. Dies kann natürlich unterschiedlich sein, je komplexer Ihre Seite wird, aber es ist normalerweise die Mühe wert.
Zum Beispiel könnte eine Fußzeile in Fusion die folgende Cache-Konfiguration erhalten:
@cache {
mode = 'cached'
entryIdentifier {
identifier = 'footer'
site = ${site}
}
entryTags {
site = ${Neos.Caching.nodeTag(site)}
footerContent = ${Neos.Caching.descendantOfTag(q(site).children('footer'))}
metamenu = ${Neos.Caching.nodeTag(q(site).property('metamenu'))}
metamenuChildren = ${Neos.Caching.descendantOfTag(q(site).property('metamenu'))}
}
}Der wichtige Teil hier ist der "entryIdentifier", da es sich um eine statische Zeichenfolge handelt und Neos dieses Objekt nur einmal erstellt und dann die gecachte Version wiederverwendet.
Die "entryTags" werden verwendet, um die gecachte Fußzeile zu löschen, wenn ihr Inhalt oder verwandte Menüeinträge zwischengespeichert werden. Diese Tags könnten in Ihrem Setup völlig anders aussehen und Sie könnten sogar keine der im Beispiel genannten Tags benötigen.
Dies gilt auch für andere Fusion-Objekte. Ich tue dies besonders gerne für den Site-Header, da er die komplexesten Menüs enthält. Aber durch das Zwischenspeichern von Menüs verlieren Sie deren Elementstatus wie "aktuell" und "aktiv". Dies kann je nach Ihren Anforderungen gelöst werden, indem Sie entweder das Menü in mehrere Objekte mit ihrer individuellen Cache-Konfiguration aufteilen oder die aktuell ausgewählten Menüpunkte per Javascript markieren.
Sie können auch Cache-Konfigurationen zum Fusion-Code von Inhalten hinzufügen, die an mehreren Stellen erscheinen werden. Zum Beispiel Teaser oder Autoren-Widgets, die unter Ihrem Hauptinhalt auf vielen Seiten und in den Suchergebnissen angezeigt werden können.
Diese Optimierungen verbessern möglicherweise nicht die Leistung Ihrer Homepage, aber andere Unterseiten werden viel schneller generiert, wenn sie nicht bereits im Cache gespeichert sind.
Hinweis: wenn Sie Neos.Caching.nodeTypeTag in Ihren entryTags verwenden, stellen Sie sicher, dass Sie den aktuellen Knoten als zweiten Parameter angeben. Dadurch wird das Flushen von Caches in anderen Workspaces verhindert.
Hinweis: Es gibt einen "geheimen" entryIdentifier der vom Content-Cache zu Ihren eigenen entryidentifiers hinzufügt wird, bevor das gecachte Segment gespeichert wird. Dieses Geheimnis ist der fusionPath des aktuell gerenderten Elements. Für unser Beispiel wäre der fusionPath also derselbe, wenn Sie die Fußzeile an der gleichen Stelle für den gleichen Seitentyp rendern. Aber für verschiedene Seitentypen wäre dieser fusionPath unterschiedlich und würde daher zu einem separaten Cache-Eintrag führen. Ich werde in einem anderen Blog-Beitrag zeigen, wie Sie dies lösen können.
Proxy caching (Fortgeschritten)
Mittlerweile ist Ihre Website viel schneller, aber Sie möchten vielleicht eine bessere Leistung haben, wenn es viele Besucher gibt oder wenn auf Ihre Website von überall auf der Welt zugegriffen wird.
Performance Empfehlung 6: Use the Varnish http cache
Um die Serverlast zu reduzieren und konsistente und schnelle Antwortzeiten zu erhalten, können Sie den Varnish HTTP Cache Service (https://varnish-cache.org) verwenden.
In den meisten Hosting-Umgebungen ist Varnish nicht ohne weiteres verfügbar, daher sollten Sie sich bei Ihrem Hoster erkundigen, ob Sie es verwenden können, oder es nach Möglichkeit selbst installieren.
Wenn Sie Varnish auf Ihrem Server verfügbar haben, ist die Einrichtung recht einfach. Im Grunde installieren Sie das Varnish-Paket und befolgen die Dokumentation zur Einrichtung des Pakets. In den meisten Fällen ist dies die einzige Konfiguration, die Sie benötigen.
Nachdem Sie dies getan haben, wird Varnish alle Ihre gerenderten Seiten zwischenspeichern und ausliefern, und für die meisten Anfragen muss Neos nichts mehr tun. Für dynamische Inhalte wie Formulare und Suchergebnisseiten sollten Sie eine Cache-Konfiguration in Fusion haben, die dem System mitteilt, dass der Inhalt nicht immer derselbe ist. Dann wird auch Varnish diesen Regeln folgen.
Alternative: NGINX proxy caching
Wenn Sie Varnish nicht verwenden können oder nicht verwenden wollen, gibt es auch die Alternative, NGINX als Proxy-Cache-Dienst zu verwenden. Dieser Cache hat weniger Funktionen als Varnish, kann aber tatsächlich schneller arbeiten, und Sie benötigen dafür keine komplexe Konfiguration, da die Konfiguration einfach zu Ihrem bestehenden virtuellen Host hinzugefügt wird (wenn Sie bereits NGINX verwenden).
Die Konfiguration ist kurz und ich habe ein Paket für Neos implementiert, das eine bessere Integration ermöglicht. Prüfen Sie unbedingt die aktuellen Einschränkungen.
Performance Empfehlung 7: Verwendung eines Content-Delivery-Netzwerks
Inzwischen ist Ihre Website superschnell, aber nur in dem Bereich, in dem Ihr Server gehostet wird. Wenn Ihr Server in Europa steht, sind Ihre Besucher aus Australien möglicherweise nicht mit der zusätzlichen Verzögerung zufrieden. Sie können dies in mehreren Schritten lösen, indem Sie ein CDN wie Cloudflare oder KeyCDN verwenden.
Wenn Sie das einfache und kostenlose Cloudflare-Konto auf Ihrer Website einrichten, haben Sie bereits den Vorteil, dass Ihre statischen Assets wie Bilder optimiert, zwischengespeichert und von Servern geliefert werden, die so nah wie möglich an der Herkunft Ihrer Besucher liegen. Dies hilft bereits bei bildlastigen Websites, die recht häufig sind.
Cloudflare wird nicht standardmäßig Ihr HTML zwischenspeichern und ausliefern, da es nicht weiß, ob Sie Ihren Inhalt geändert haben.
Mit bezahlten CDN-Accounts haben Sie viel mehr Möglichkeiten für Optimierungen und Sie können sogar Ihr HTML zwischenspeichern. Aber damit dies gut funktioniert, benötigen Sie ein Neos-Paket, das dem CDN mitteilt, was und wann es zwischenspeichern soll.
Sie können einen Blick auf das experimentelle Paket für Cloudflare werfen.
Performance Empfehlung 8: Verwenden Sie den Flowpack FullPageCache
Neos selbst benötigt die Datenbank noch, um zu bestimmen, welche Cache-Einträge an den Besucher gesendet werden sollen. Selbst wenn der Cache vollständig aufgewärmt und optimal konfiguriert ist, sind noch einige Abfragen auszuführen.
Bei Verwendung eines Proxy-Caches wird Neos nicht geladen, aber wir benötigen einen zusätzlichen Dienst und eine zusätzliche Konfiguration, damit es gut funktioniert.
Aber mit der Veröffentlichung von Neos 5.1 wurde ein neues Plugin vom Neos-Kernteam veröffentlicht, das auch Neos 4.3 unterstützt und einen Cache für komplette Seiten bietet, der nicht unbedingt die Datenbank benötigt.
Das Plugin Flowpack.FullPageCache speichert die vollständig gerenderten Seiten basierend auf der Neos eigenen Caching-Konfiguration. So weiß es auch genau, wann die Caches abgelaufen sind oder Seiten nicht zwischengespeichert werden können. Das Tolle daran: Wenn ein Cache-Eintrag vorhanden ist, müssen keine Daten aus dem Content-Repository geholt werden. Deshalb muss oft gar keine Datenbankabfrage durchgeführt werden.
Das reduziert die Antwortzeit immens. In meinen Projekten auf etwa 25-40ms von 60-180ms. Bisher hatte ich damit nur kleinere Probleme, die bereits im Plugin behoben wurden.
Die Funktion war noch nicht vollständig in den Neos-Kern integriert, da wir noch mehr Tests in der realen Welt benötigen, um alle Spezialfälle abzudecken. Es gibt einige Projekte, die ein spezielles Setup haben, das Probleme mit diesem Cache verursacht. Daher ist es im Moment sicherer, es als optionales Plugin zu verwenden.
Probieren Sie es also aus und vielleicht brauchen Sie keinen Proxy-Cache mehr!
Schnellere Node-Abfragen
Wenn Ihre Website wächst, könnten Ihre Abfragen in Fusion langsam werden, da PHP 100.000 Knoten filtern und durchsuchen muss.
Performance Empfehlung 8: Elasticsearch für Node-Abfragen verwenden
Neos CMS hat eine großartige Unterstützung für Elasticsearch, das im Grunde eine Suchmaschine ist. Meistens würden Sie diese verwenden, um eine Suchfunktion für Ihre Website zu erstellen, aber Sie können sie auch verwenden, um Ihre Anfragen zu beschleunigen.
Wie bei Varnish müssen Sie den Elasticsearch-Dienst auf Ihrem Server oder in Ihrem Stack laufen lassen und das Paket für Neos installiert haben.
Danach können Sie zusätzliche Fusionfunktionen verwenden, um Nodes mit Elasticsearch abzufragen, anstatt die internen langsameren PHP-Methoden von Neos zu verwenden.
Ein Anwendungsfall kann die Auflistung aller Blog-Posts mit bestimmten Kategorien auf einer Übersichtsseite sein. Wenn Sie hunderte von Posts haben, kann dies viel schneller sein.
Ich habe Elasticsearch sogar in einigen weiteren Anwendungsfällen verwendet, in denen ich auf Leistungsengpässe gestoßen bin, wie z.B. bei der Überprüfung, ob ein Benutzer bestimmte Inhalte sehen darf, oder zur Beschleunigung bestimmter Backend-Operationen oder Datenquellen.
Beispiel: Wenn Sie in Fusion so etwas wie das Folgende tun, um eine Fußnavigation zu rendern:
footerMenuItems = ${q(site).find('[instanceof Neos.Neos:Document]').filter('[showInFooterMenu = true]')}Dies wird sehr langsam, wenn Ihre Website wächst, da jede Seite auf eine Eigenschaft überprüft werden muss. Da die Nodeeigenschaften nicht in der Datenbank indiziert sind, dauert diese Abfrage sehr lange.
Machen Sie stattdessen dasselbe mit Elasticesearch, um die Liste der Fußzeilenelemente viel schneller zu erhalten:
footerMenuItems = ${Search.query(site).nodeType('Neos.Neos:Document').exactMatch('showInFooterMenu', true).limit(20).execute()}Abschließende Worte
Ich hoffe, diese Leistungshinweise haben Ihnen geholfen, eine schnellere Neos CMS-Website zu erstellen. Ihre Besucher & Redakteure werden eine bessere Benutzererfahrung haben!
Neos CMS mag es, schnell zu sein und braucht nur eine gemütliche Umgebung, um seine Leistungsfähigkeit zu zeigen!
Wenn Sie Fragen oder Anmerkungen zu diesen Themen haben, zögern Sie nicht, mich zu kontaktieren, oder Sie können mich sogar beauftragen, wenn Sie Hilfe bei der Verbesserung der Leistung Ihrer Websites benötigen.
Aktualisiert 11.6.2019: Hinweise zum NGINX-Proxy-Caching hinzugefügt
Aktualisiert 17.6.2019: Aktualisiertes PDOBackend-Beispiel zur Deaktivierung des Cache-Timeout nach einer Stunde
Aktualisiert 17.10.2019: Die zwischengespeicherte Fußzeile wurde angepasst, um den Kontext der Site-Nodes zu berücksichtigen
Aktualisiert 12.11.2019: Beispiel für die Fußnavigation mit Elasticsearch hinzugefügt
Aktualisiert 07.02.2020: Informationen über Flowpack.FullPageCache hinzugefügt