FlyingPress ist das leistungsstärkste Caching Plugin für WordPress! Diese Schritt für Schritt Anleitung mit Bildern, Videos und Erörterungen, zeigt die besten Einstellungen 2025.
Flying Press bietet Page Caching, verbessert die Ladezeiten und kann WordPress Seiten mit hohem Traffic deutlich schneller machen!
Sowohl das Caching als auch die Performance optimierenden Einstellungen von Flying Press, führen bei den meisten WordPress Websites zu besseren Page-Speed Ergebnissen, als die anderer Caching Plugins.
Offen gestanden gelingt es mir mit keinem anderen Caching Plugin für WordPress, so gute Performance-Ergebnisse zu erzielen wie mit FlyingPress.
Darum ist Caching so wichtig für eine WordPress Website
Caching ist aus mehreren Gründen entscheidend für die Leistung und Effizienz einer WordPress-Website. Hier sind die wichtigsten Punkte:
1. Erstreaktionszeit des Servers verringern

Verbesserte Ladezeiten durch Page Caching: WordPress generiert alle Seiteninhalte dynamisch, indem es PHP-Skripte ausführt und Daten aus der Datenbank abruft. Caching speichert diese Inhalte als statische Dateien, die ohne erneute Verarbeitung an Besucher ausgeliefert werden können.
Das Laden dieser statischen Inhalte (gecachte Dateien), geht deutlich schneller, als das dynamische Generieren von Inhalten. Durch Page Caching kann das Problem „Erstreaktionszeit des Servers verringern“ gelöst werden.
Statische Inhalte mit einer effizienten Cache-Richtlinie bereitstellen

Das Einrichten von Page Caching sorgt für schnellere Ladezeiten und das wirkt sich positiv auf die Suchmaschinenoptimierung (SEO) der Website aus. Google und andere Suchmaschinen berücksichtigen Ladezeiten als Ranking-Faktor. Eine schnellere Website kann daher zu besseren Suchmaschinenrankings führen.
Bessere Benutzererfahrung durch schnelle Ladeiten
Schnelle Ladezeiten sind entscheidend für eine positive Benutzererfahrung. Langsame Websites führen oft dazu, dass Besucher abspringen, bevor sie sich mit den Inhalten befassen.
Flying Press Preise – Die passende Lizenz erwerben
Die Preise von FlyingPress sind in vier Tarife unterteilt. Je nach dem, wieviele Websites man mit dem Plugin ausstatten möchte, kann der entsprechende Tarif gewählt werden.

Plugin runterladen, bei WP installieren und aktivieren
1.
FlyingPress Plugin runteralden
Einfach im FlyingPress Account anmelden und im Dashboard unter Downloads den Downloadfile anklicken.

Im Anschluss den Download Button anklicken.

2.
Plugin bei WordPress installieren
Gehe im WordPress Admin-Menü auf Plugins -> Neues Plugin hinzufügen -> Plugin hochladen. Wähle dann die heruntergeladene zip-Datei aus und klicke auf Jetzt installieren. Im Anschluss muss das Plugin nur noch aktiviert werden.

3.
Lizenz bei WordPress aktivieren
Klickt ma in seinem FlyingPress Account unter Licenses die Lizenz an, wird einem direkt der Lizenzschlüssel angezeigt, der dann auch kopiert werden kann.

Zum Aktivieren der Flying Press Lizenz klickst du im WP Admin-Menü einfach auf FlyingPress und dann klickst dann auf das Settings-Tab. Nun kann unter Activate license der Lizenzschlüssel eingefügt und aktiviert werden.

FlyingPress Einstellungen
Die folgenden Einstellungen für das FlyingPress Plugin sind für die meisten Websites optimal. Dennoch ist jede WordPress Installatioin verschieden, daher ist es wichtig, den Erfolg dieser Optimiereungen mit Hilfe eines Speed-Testing-Tools zu prüfen.
Da keines dieser Testing-Tools die tatsächliche Performance einer Website genau messen kann, sollten die Ladezeiten zusätzlich im Inkognito-Modus live gestestet werden.
Dashboard
Hier werden zunächst die Anzahl der gecachten Seiten und der Lizenz-Status angezeigt. Interessanter sind jedoch die Quick Actions:

Weiterhin gibt es hier einen direkten Zugriff zum einrichten des FlyingCDN, einer Documentation zu allen Einstellungen, der Facebook Community und am allerwichitgsten, die Contact Support Option um den Plugin Support zu kontaktieren.
Cache Settings
Das Caching von FlyingPress ist nun automatisch aktiv. Zusätzlich kann hier unter den Cache Settings das Cache-Verhalten spezifiziert werden.

Beispiel auf Desktops:
Wenn ein Besucher den Cursor in die Nähe eines Links bewegt, erkennt das Plugin diese Bewegung und lädt dann im Hintergrund die verlinkte Seite, bevor der Besucher tatsächlich auf den Link klickt.
Ergebnis: Wenn der Besucher dann tatsächlich klickt, erscheint die neue Seite deutlich schneller, da sie bereits vorab geladen wurde.
Beispiel auf Mobilgeräten:
Auf mobilen Geräten gibt es keinen Cursor, daher wird die Logik an die viewport-basierte Navigation angepasst. Das Plugin lädt Links, die im sichtbaren Bereich (Viewport) des Bildschirms erscheinen, proaktiv vor. Wenn ein Besucher scrollt und Links sichtbar werden, beginnt das Plugin, die entsprechenden Seiteninhalte im Hintergrund zu laden.
Hinweis:
Der Preload-Prozess kann Serverressourcen beanspruchen. Auf Shared-Hosting-Umgebungen sollte darauf geachtet werden, dass der Server genügend Kapazität hat, um das Preloading durchzuführen. Ggf. muss auf das Vorladen bestimmter Assets vertzichtet werden.
Für die meisten Websites sollte die Option „Geplantes Vorladen“ auf „Niemals“ eingestellt sein, kommt es jedoch zu Problemen mit der „Nonce“-Validierung (wp_verify_nonce
), müsste ggf. ein zeitlicher Intervall bestimmt werden.
CSS Settings

Reduziere nicht verwendete CSS – Lösung

FlyingPress entfernt das ungenutzte CSS automatisch und lädt das genutzte CSS in einer separaten Datei, was aus meiner Sicht auch das optimale Verfahren ist!
WP-Rocket hingegen, lädt das genuzte CSS ausschließlich inline, in der <head>
Sektion der Website. Das CSS in einer separaten Datei zu laden hat mehrere Vorteile. Z.B. kann die Datei im Cache gespeichert werden, Inline CSS hingegen kann nicht gecacht werden!
Außerdem bläht Inline CSS das HTML unnötig auf, das kann den FCP-Wert (First Contentful Paint) verschlechtern.
Tools wie Google PageSpeed Insights honorieren inline geladenes CSS häufig mit besseren Scores, da eine zusätzliche Anfrage (HTTP-Request) vermieden wird. Für den realen Benutzer lädt die Seite jedoch schneller, wenn das CSS in einer separaten Datei geladen wird. Da seit HTTP/2 und inzwischen HTTP/3, Serveranfragen deutlich schneller verarbeitet werden können!
- Asynchronously: Alle Original-CSS-Stylesheets (ungenutzte CSS) werden per
async
geladen. Diese Methode kann für einige Websites vorteilhaft sein, da durch das asynchrone Laden der Stylesheets, alle Elemente im Above-The-Fold Bereich geschmeidig geladen werden. - On user interaction: Alle ursprünglichen CSS-Stylesheets (nicht verwendete CSS) werden verzögert und erst bei Benutzerinteraktion geladen. Ich nutze diese Option bei allen Websites.
- Remove: Alle ursprünglichen CSS-Stylesheets (nicht verwendete CSS) werden entfernt. Dies ist die aggressivste Methode und sehr wahrscheinlich müssen Ausnahmen eingerichtet werden. Ich empfehle diese Methode nicht.
Für die meisten Websites ist das Verzögern der Stylesheets bis zur Benutzer-Interaktion die beste Option. Sofern es im Above-The-Fold Bereich zu einem Pop-in Effekt kommt, nachdem der Benutzer mit der Seite interagiert, sollte eine Ausnahme für die Stylesheets der entsprechenden Elemente eingerichtet werden.
Wer es genau wissen möchte, kann die Leistungsunterschiede zwischen Asynchronously und On user interaction durch A/B-Testing ermitteln. Logischerweise müssten diese Tests durchgeführt werden, nachdem alle Ausnahmen eingerichtet wurden.
Das Entfernen (Remove) der Stylesheets kann schnell das Design zerstören, ich würde niemandem raten diese Option zu nutzen, der nicht ganz genau weiß was er tut!
Beispiel:
/wp-content/themes/kadence/assets/css/content.min.css
/wp-content/plugins/kadence-blocks/dist/style
Beispiel:
#ID-xyz
.class-xyz
CSS Optimierungen von FlyingPress testen
FlyingPress bietet die Möglichkeit, CSS-Optimierungen zu deaktivieren, indem man /?flyingpresscssoff
an die URL einer Seite anhängt. Dies ist besonders nützlich, wenn man überprüfen möchte, ob bestimmte CSS-Optimierungen Probleme verursachen. Diese Funktion kann folgendermaßen genutzt werden:
1.
Website auf korrekte Darstellung testen
CSS Optimierungen speichern. Wenn man nun in der Admin Top-Bar über FlyingPress hovert, klickt man im Anschluss auf Purge all, damit die aktuelle Version der Seite angezeigt wird. Nun kann die Website im Inkognito-Modus geöffnet werden, um sie fehelerhafte Darstellung zu prüfen.
2.
FlyingPress Test-Modus nutzen
Sollte es Probleme bei der Darstellung der Website geben, kann die Seite mit deaktivierten CSS-Optimierungen von FlyingPress erneut geladen werden. Dazu muss nur das Query-Parameter /?flyingpresscssoff
an die URL der Website angehängt, und die Seite aktualisiert werden.
https://deine-domein.de/?flyingpresscssoff
Jetzt wird die Seite zum Vergleich, ohne die CSS-Optimierungen von FlyingPress geladen.
3.
Optimierung anpassen und Fehler beheben
Nun können die CSS-Optimierungen angepasst werden, um dann das Test-Verfahren erneut zu nutzen, bis die Seite, ink. aller CSS-Optimierungen, korrekt dargestellt wird.
JavaScript Settings


Beispiel:
/wp-content/plugins/calculated-fields-form/
jquery.min.js
/elementor/assets/js/frontend.min.js
Da Tools wie Google PSI nicht mit einer Website interagieren, sind die JS-Dateien für das Tool auch nicht sichtbar. Man versteckt sie sozusagen.

Wählt man diese Option aus, erscheint sofort die Warnung, dass Delay all nicht auf allen Websites kompatibel sein könnte. Allerdings würde ich in dem Fall, dass tatsächlich etwas nicht richtig funktioniert, diese Funktion nicht direkt deaktivieren, so wie es hier empfohlen wird.
Aus meiner Sicht macht es deutlich mehr Sinn, das gesamte JS zu verzögern und ggf. problematische Dateien von der Verzögerung auszuschließen, als jede JS-Datei rauszusuchen, die verzögert geladen werden soll.
Sofern relevanter Inhalt mit JS bereitgestellt wird, sollten ensprechende Dateien aus SEO-Gründen ebenfalls von von der Verzögerung ausgeschlossen werden, da die Bots der Suchmaschinen die Inhalte sonst nicht zu Gesicht bekommen.
JavaScript Optimierungen von FlyingPress testen
FlyingPress bietet die Möglichkeit, JS-Optimierungen zu deaktivieren, indem man das Parameter /?flyingpressjsoff
an die URL einer Seite anhängt. Dies ist besonders nützlich, wenn man überprüfen möchte, ob bestimmte JavaScript-Optimierungen Probleme verursachen. Diese Funktion kann folgendermaßen genutzt werden:
1.
Website auf Funktionallität testen
JavaScript Optimierungen speichern. Nun kann man in der Admin Top-Bar über FlyingPress hovern, um im Anschluss auf Purge all zu klicken, damit die aktuelle Version der Seite angezeigt wird. Nun kann die Website im Inkognito-Modus geöffnet werden, um sie Fehler zu prüfen.
2.
FlyingPress Test-Modus nutzen
Sollte es Probleme mit der Funktionalität der Website geben, kann die Seite mit deaktivierten JS-Optimierungen von FlyingPress erneut geladen werden. Dazu muss nur das Parameter /?flyingpressjsoff
an die URL der Seite angehängt, und dann die Seite aktualisiert werden.
https://deine-domein.de/?flyingpressjsoff
Jetzt wird die Seite zum Vergleich ohne die JavaScrip-Optimierungen von FlyingPress geladen.
3.
Optimierung anpassen und Fehler beheben
Nun können die JS-Optimierungen angepasst werden, um dann das Test-Verfahren erneut zu nutzen, bis die Seite, ink. aller JavaScrip-Optimierungen, korrekt funktioniert.
Für alle Plugins, die ich selbst nutze und auch regelmäßig empfehle, habe ich sämtliche Scripts vorbereitet, für die ggf. eine Ausnahme eingerichtet werden muss, sofern sie nach dieser Optimierung nicht mehr anständig funktionieren:
Calculated Fields Form:
jquery.min.js
/wp-content/plugins/calculated-fields-form/
cp_calculatedfields
Presto Player:
/presto-player/dist/components/web-components/web-components.esm.js
/presto-player/src/player/player-static.js
var player
/wp-includes/js/dist/vendor/regenerator-runtime.min.js
/wp-includes/js/dist/api-fetch.min.js
/wp-includes/js/dist/hooks.min.js
/wp-includes/js/dist/i18n.min.js
Real Cookie Banner:
jquery.js
jquery.min.js
gtm.js
analytics.js
/wp-content/plugins/vendor-banner.pro.js
/wp-content/plugins/banner.pro.js
realCookieBanner
real-cookie-banner-pro-banner-js-before
Kadence:
kadence-navigation-js-extra
/kadence-woo-extras/
kadence-pro
kadence_product_gallery-js-extra
SureCart:
jquery.min.js
surecart
hooks.min.js
i18n.min.js
url.min.js
api-fetch.min.js
a11y.min.js
dom-ready.min.js
Font Settings

Darauf achten, dass der Text während der Webfont-Ladevorgänge sichtbar bleibt – Lösung

diese Funktion sollte aktiviert werden, um Layout Shifts beim Ladevorgang der Fonts zu vermeiden und folgender Google PageSpeed Insights Meldung vorzubeugen; „Darauf achten, dass der Text während der Webfont-Ladevorgänge sichtbar bleibt„.
Beispiel:
https://deine-domain.de/wp-content/fonts/secuela-regular.woff2
https://deine-domain.de/wp-content/fonts/secuela-medium.woff2
https://deine-domain.de/wp-content/fonts/secuela-bold.woff2
Image Settings

FlyingPress verwendet das native Lazy Load Verfahren, während andere Performance Plugins w.z.B. Perfmatters JS-basiertes Lazy Load nutzen. Beides hat Vor- und Nachteile, wichtig ist, nur eins von beiden zu verwenden.
Auf meinen Seiten und Beiträgen werden meistens 2 Bilder im Above the Fold Bereich geladen. Daher gebe ich hier eine 2 ein und kümmere mich um zusätzliche Bilder manuell.

/wp-content/uploads/2024/03/above-the-fold-bild.webp
Sofern auf der Website der Service von Gravatar nicht verwendet wird, empfielt es sich aus Performance- und DSGVO-Gründen, den Dienst zu deaktivieren.
Einstellungen -> Diskussion -> Avatare

Haken aus der Option Avatare anzeigen entfernen!
iFrame Settings

CDN Einstellungen

Bloat Settings

Diese ständigen Anfragen können der Leistung der Website ganz schön zu schaffen machen. Ich habe Waterfall Charts gesehen, die einen einzigen riesigen Balken neben dem ?wc-ajax=get_refreshed_fragments
Request anzeigten.
Daher würde ich diese Cart-Fragmente immer deaktivieren. Sofern es Probleme mit dem Theme gibt, besteht eine Alternative darin, das Skript cart-fragments.min.js
einfach zu verzögern, zu dieser Funktion kommen wir später noch.
Mit dieser Funktion können die Skripte auf allen Seiten deaktiviert werden, mit folgenden Ausnahmen:
- Product Pages
- Cart Page
- Checkout Page
Sofern du WooCommerce Produkte auf deiner Startseite anzeigst, sollte diese Funktion theoretisch nicht aktiviert werden. Praktisch sollte es dennoch getestet werden, da es auch vom Page Builder abhängen kann, der die Woo-Elemente einbindet, ob die Skripte tatsächlich benötigt werden, oder nicht.
https://deine-domain/feed/
https://deine-domain/feed/rss
https://deine-domain/feed/rss2
https://deine-domain/feed/rdf
https://deine-domain/feed/atom
https://deine-domain/comments/feed
- Es verhindert, dass andere die Website einbetten können und dass man selbst Websites einbetten kann
- oEmbed-spezifisches JavaScript wird entfernt
- Das Filtern von oEmbed-Ergebnissen wird deaktiviert
- Entfernt oEmbed-discovery links
- Schaltet die automatische Erkennung von oEmbed aus
- Entfernt alle Rewrite-Regeln für die Einbettung
Das bedeutet nicht, dass man keine YouTube Videos oder andere iFrames mehr einbinden kann. Lediglich das Einbetten durch Einfügen eines Links im Editor wird deaktiviert.
Diese Einstellung fügt zum Deaktivieren von WP Cron die folgende Zeile in die wp-config.php
Datei ein, sodass man es nicht selbst manuell durchführen muss:
define('DISABLE_WP_CRON', true);
Alle Details zum Deaktivieren der wp-cron.php
Datei und dem Einrichten eines echten Cron Jobs auf dem Server, erkläre ich in diesem Video:
Achtung:
Wenn Page Builder wie Divi, Elementor, Thrive Architect oder WP Bakery auf der Website verwendet werden, sollte jQuery Migrate aktiv bleiben. Die meisten klassischen Page Builder benötigen jQuery-Migrate immer noch.

Das Problem ist, dass es für die Anzahl erstellter Revisionen kein Limit nach oben gibt und man als Benutzer gar nicht mitbekommt, wieviele dieser Dinger WordPress bereits erstellt hat…
Beim Optimieren der Datenbank, stellt man dann mit Erschrecken fest, welch hohe Zahl an Beitrags-Revisionen sich hier angesammelt hat. Ich würde daher die Beitrags-Revisionen auf 3, oder max. 5 limitieren.
Database
Das Optimieren der Datenbank ist bei jeder Performance-Optimierung einer Website eine Selbstverständlichkeit. Ich persönlich bevorzuge für diesen Job jedoch das WP-Optimize Plugin (kostenlos) oder das Advanced Database Cleaner Pro Plugin (kostenpflichtig).
Beide Plugins verfügen über die Funktion, Tabelleneinträge alter Plugins und Themes zu entfernen, anstatt sie nur zu optimieren. Das ist deutlich effizienter!
Außerdem bin ich kein Freund von automatisierten Optimierungen der Datenbank. Für mehr Kontrolle ziehe ich es vor, den Vorgang regelmäßig (ca. 1x pro Monat) manuell durchzuführen.
Achtung:
Bereinigungen und Optimierungen der Datenbank sind nach der Ausführung nicht mehr rückgängig zu machen. Bevor man diese Aktionen durchführt, sollte in jedem Fall ein Backup der Datenbank erstellt werden!
In den FlyingPress Datenbank Einstellungen kann man die Datenbank bereinigen und hat außerdem die Möglichkeit, eine automatische Bereinigung zu planen, die in regelmäßigen Abständen das Optimieren der Datenbank durchführt.

Für die Datenbank Optimierung mit FlyingPress würde ich folgende Einstellungen wählen:
Advanced Settings

Klassische Beispiele dafür sind Login-Seiten und E-Commerce relevante Seiten:
/my-account/
/cart/
/checkout/
Abfrageparameter sind Teile einer URL, die typischerweise nach einem ?
erscheinen:
Beispiel:
https://webgeneral.de/tools/performance/?2931251027=46
Auf der Seite wird ein Filter verwendet, um gewisse Inhalte abzufragen und anzuzeigen.

Genau wie andere Caching Plugins behandelt FlyingPress URLs mit unterschiedlichen Abfrageparametern als eigenständige Seiten, die separat gecacht werden. In dem Beispiel des Filters, ist das auch vollkommen korrekt und wichtig!
Sofern Query-Parameter jedoch keine Inhalte auf einer Seite ausgeben, müssen sie logischerweise auch nicht gecacht werden und sollten ignoriert werden.
Beispiel:
https://meine-domain.com/landing-page?utm_source=google
Auf der Seite wird ein Trackingcode verwendet, um bestimmte Marketing-Campagnen auswerten zu können.
Für solch ein Query Parameter als separate Seite zu chachen hätte diverse Nachteile:
- Verschwendung von Speicherkapazitäten
- Erhöhter Aufwand zum Generieren des Caches
- Verschwendung von Server-Recourssen
Daher können wir FlyingPress mit dieser Funktion anweisen, gewisse Abgrageparameter beim Caching zu ignorieren. Einer Liste jener Abfrageparameter, die von FlyingPress standartmäßig ignoriert werden, findet man in den Docs. des Plugins.
Die entsprechenden Query Parameter können hier gelistet werden:
?aff_id=12345
?session_id=abc123
?sourceid=google_ads
Beispiel:
Die Ergebnisse einer On-Page-Suche werden gewöhnlich mit folgendem Query-Parameter-Format ausgegeben:
https://example.com/?s=cat
Daher reicht es das „s
“ in die Liste aufzunehmen, um die Ergebisse separat zu cachen.
Beispiel:
wordpress_logged_in_*
wp-settings-*
Wie funkioniert Lazy Rendering?
Beim ersten Laden einer Seite werden Elemente, die für „Lazy Rendering“ markiert sind, nicht sofort vom Browser gerendert. Stattdessen werden Platzhalter (z. B. leere div
-Tags) geladen, die weniger Verarbeitung erfordern.
Das vollständige Rendering dieser Elemente wird aufgeschoben, bis der Benutzer das Element in den sichtbaren Bereich des Bildaschirms scrollt.
Übermäßige DOM-Größe vermeiden

Mit dier Optimierungsmaßnahme lässt sich die Google PSI Diagnose „Übermäßige DOM-Größe vermeiden“ für WordPress beheben.
Um Lazy Rendering für bestimmte Elemente auf der Website anzuwenden, bearbeitet man einfach die ensprechende Seite und wählt das Element aus, das von FlyingPress verzögert gerendert werden soll. In den Einstellungen seines Page Builders lässt sich nun die die Lazy Render Funktion für das Element aktivieren.

Folgende Page Builder haben eine Integration für die Lazy Render Funktion:
- Gutenberg
- Elementor
- Bricks
- Divi
- Oxygen
- Breakdance
Sollte der eigene Page Builder diese Funtion nicht unterstützen, kann dem entsprechenden Element auch einfach die CSS-Klasse lazy-render
hinzugefügt werden, damit es von FlyingPress verzögert gerendert wird.
Sollte der eigene Page Builder diese Funtion nicht unterstützen, kann dem entsprechenden Element auch einfach die CSS-Klasse lazy-render
hinzugefügt werden, damit es von FlyingPress verzögert gerendert wird.
footer
#comments
.container-xyz
Beinflusst Lazy Render SEO?
Lazy Render ist vollständig SEO-optimiert mit noscript
-Tags, die sicherstellen, dass der Inhalt auch ohne JavaScript zugänglich ist.