Perfmatters – Optimale Einstellungen 2024

Perfmatters ist aus meiner Sicht, das beste Performance Plugin, wenn es um die Optimierung der Ladezeiten einer WordPress Website geht.

Außer Caching und Bildoptimierung bietet das Plugin alle Maßnahmen der Optimierung an, um die Leistung von WordPress Webseiten zu steigern. Perfmatters kann wunderbar neben jedem Caching Plugin wie; WP Rocket, Flying Press und LiteSpeed Cache etc. eingesetzt werden. 

Ich nutze Perfmatters schon lange auf all meinen Websites und auch auf denen meiner Kunden. Daher werde ich in diesem Beitrag genau beschreiben, wie man das Plugin einrichtet und welche Einstellungen für die meisten Websites am besten sind.

Videoanleitung zu Perfmatters:

Lizenz – Perfmatters Preise & 20% Rabatt

Um Perfamtters nutzen zu können benötigen wir zunächst die entsprechende Lizenz. Hier kann man zwischen folgenden Optionen wählen:

1. Personal – Eine Website = $24.95 pro Jahr
2. Unlimited Sites – Beliebig viele Websites = $124.95 pro Jahr
3. Business – Drei Websites = $54.95 pro Jahr

Zu diesen Preisen kommt noch die Umsatzsteuer hinzu, in Deutschland aktuell 19%. Ich habe mit Brett, dem Co-Founder von Perfmatters, einen Rabatt von 20% auf alle Tarife vereinbart. Der Rabatt-Code lautet WEBGENERAL.

Dieser Rabatt-Code kann eingegeben werden, indem man im Bestellvorgang auf Enter a discount code klickt. Im Anschluss schmälert sich der Betrag automatisch um 20%.

Perfmatters Rabatt-Code für Lizenz-Verlängerung (Renewals)

Dieser Rabatt-Code funktioniert auch zum Verlängern einer bestehenden Perfatters Lizenz! Wenn man in seinem Account eingeloggt ist, geht man einfach auf Pricing -> dann den Tarif auswählen -> Enter a discount code -> WEBGENERAL -> Renew An Existing Licence -> Lizenz-Schlüssel einfügen -> Apply Licence Renewal.

Perfmatters bei WordPress einrichten

Sobald man eine Lizenz erworben hat, muss zunächst das Perfmatters Plugin heruntergeladen werden. Den Download findet man in seinem Account unter View Details and Downloads -> ganz unten links.

Im Anschluss kann das Plugin bei WordPress hochgeladen und aktiviert werden.

Den Lizenz-Schlüssel findet man in seinem Perfmatters Account unter View Licenses -> Manage Sites. Hier kann der Lizenz-Schlüssel kopiert werden, um ihn dann bei WordpPress einzufügen.

Auch die Domain der entsprechenden Website muss hier eingetragen werden. Einfach nach ganz unten scrollen, die Domain eintragen, auf der Perfmatters genutzt werden soll und auf Add Site klicken.

Zum Einfügen der Lizenz klickt man einfach in der Admin-Top-Bar auf Perfmatters und dann im Sidebar-Menü auf Lizenz. Hier kann der Lizenzschlüssel eingefügt und gespeichert werden.

Allgemein – Performance Einstellungen

Emojis deaktivieren: Ein – Die JS-Datei für Emojis (wp-emoji-release.min.js) deaktiviere ich grundsätzlich, da sie sonst auf jeder Seite der Website geladen würde. Außerdem sind moderne Browser in der Lage, Emojis zu auch ohne diese unnötige Anfrage zu generieren, wie man sieht… 😎

Dashicons deaktivieren: Ein – Diese Funktion bezieht sich ausschließlich auf Dashicons im Frontend und für nicht eingelogte Benutzer. Moderne Themes und Plugins nutzen das Stylesheet dashicons.min.css jedoch nicht, somit beansprucht es unnötige Ladezeit und kann daher deaktiviert werden.

Um sowohl den First Contentful Paint (FCP) als auch den Largest Contentful Paint (LCP) zu verbessern, sollte die Funktion aktiv sein.

Embeds deaktivieren: Ein – Das Deaktivieren von Embeds (Einbettungen) auf der WordPress-Website bewirkt Folgendes:

• 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. Diese Funktion bezieht sich nur auf das Einbetten von Websites.

XML-RPC deaktivieren: Ein – XML-RPC ermöglicht Remote-Verbindungen, z.B. um Inhalte von einem Mobil-Gerät bei WordPress zu veröffentlichen. Diese Funktion zu deaktivieren schützt die Website in erster Linie vor verschiedenen Sicherheitsrisiken und steigert zusätzlich die Performance.

jQuery-Migrate entfernen: Ein – Die meisten modernen Themes und Plugins benötigen jquery-migrate.min.js-Datei nicht. Diese Datei hilft besonders älteren Applikationen, mit dem neuem Code zu kommunizieren

WordPress-Version verbergen: Ein – Auf jeden Fall deaktivieren, damit folgendes Tag aus der <head> Sektion entfernt wird: <meta name="generator" content="WordPress 6.1.2" />. Die aktuell verwendete Version von WordPress anzuzeigen, sollte aus zwei Gründen deaktiviert werden:

1. Im Sinne der Sicherheit ist es ratsam diese Information zu verbergen. Sollte z.B. eine WordPress Version genutzt werden, die nicht 100 prozentig sicher ist, da die Plugin-Update-Testings noch nicht abgeschlossen sind, möchte man das ja nicht an die große Glocke hängen.
2. Da die Info über die WP-Version eh keinen Nutzen hat, kann die Website von dieser Codezeile befreit werden, um somit ein klein wenig zur Performance-Steigerung beizutragen.

RSD-Link entfernen: Ein – Offen gesagt habe ich den exakten Sinn dieses Links nie richtig verstanden. Ich weiß nur, dass er von XML-RPC-Clients verwendet wird und daher sowohl die Sicherheit, als auch die Ladezeit der Seite negativ beeinträchtigt. Also weg damit.

Shortlink entfernen: Ein – Erstellt einen kurzen Link zu Seiten und Beiträgen. Wenn man unter Einstellungen -> Permalinks die Link-Struktur auf Beitragsname gestellt hat, kann der Shortlink (<link rel='shortlink' href='https://domain.com?p=712'/>) getrost entfernt werden.

RSS-Feeds deaktivieren: Ein – WordPress generiert standardmäßig alle Arten von RSS-Feeds für deine Website. Diese sind nur dann nützlich, wenn man einen Blog auf der Website betreibt.

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

Sofern du einen Blog betreibst würde ich die RSS-Feeds nicht deaktivieren, da RSS-Feeds von einigen genutzt werden, um sich über neu veröffentlichte Inhalte informieren zu lassen.

RSS-Feed-Links entfernen: Ein – Ähnlich wie beim Erzeugen von RSS-Feeds, generiert WordPress auch RSS-Feed-Links für Seiten, Beiträge, Kommentare, Tags usw. Betreiber eines Blogs können die RSS-Feeds aktiviert lassen und trotzdem die RSS-Feed-Links entfernen, um wahrscheinlich ungenutzten Code von der Website zu entfernen.

Self-Pingbacks deaktivieren: Ein – Ein Pingback ist im Grunde ein automatisch generierter Kommentar, der erstellt wird, wenn ein anderer Blog auf den eigenen verlinkt. Ein Self-Pingback wird erstellt, wenn man selbst auf einen Artikel des eigenen Blog verlinkt. Pingbacks sind im Grunde nichts anderes als Spam und verschwenden nur Ressourcen.

REST-API deaktivieren: Deaktivieren, wenn abgemeldet – Die WordPress REST-API ist eine Schnittstelle, die z.B. von Theme- und Plugin Entwicklern genutzt wird, um mit deiner WordPress Datenbank zu kommunizieren. Perfmatters bietet hier folgende Optionen an:

• Standard (aktiviert) – Standardmäßig ist die REST-API aktiv
• Für Nicht-Administratoren deaktivieren – Deaktiviert die REST-API für alle Benutzer-Rollen außer Administratoren
• Deaktivieren, wenn abgemeldet – REST-API ist nur für angemeldete Benutzer aktiv

ACHTUNG! Diese Einstellung ist zwar sehr gut für die Performance, setzt jedoch intensives Testing voraus!

Ich nutze zum Beispiel auf all meinen Websites das Real Cookie Banner Plugin. Damit das Plugin anständig funktioniert, muss der Zugriff auf die WordPress REST-API für jeden verfügbar sein, auch für nicht eingeloggte Benutzer! Wenn das nicht der Fall ist, wird das Cookie Banner auf jeder Unterseite erneut angezeigt, auch wenn der Benutzer bereits zugestimmt hat.

Damit das Real Cookie Banner Plugin trotz dieser Einstellung anständig funktioniert, muss eine entsprechende Ausnahme eingerichtet werden.

Das geht am einfachsten, indem du diesen Codeschnipsel in die functions.php Datei deines Child Themes einfügst. Alternativ zum Child Theme empfehle ich das FluentSnippets Plugin zum Einfügen des Codeschnipsels zu nutzen.

add_filter('perfmatters_rest_api_exceptions', function($exceptions) {
  $exceptions[] = 'real-cookie-banner';
  return $exceptions;
});

Sofern du auf deiner WP-Installation weitere Applikationen nutzt, die uneingeschränkten Zugriff auf die REST-API benötigen, müssen auch für diese Dienste entsprechende Ausnahmen eingerichtet werden. Teste deine Website ausgiebig, auch auf die Funktionalität

Weitere Plugins, die auf die REST-API zugreifen sind zum Beispiel:

• Independent Analytics
• Yoast SEO
• SureCart
• Customer Reviews for WooCommerce
• Jetpack
• Wordfence
• JetMenu
• Verschiedene Formular Plugins

Eine Anleitung zum Einrichten dieser Ausnahmen, findest du in diesem Artikel von Perfmatters.

Da ich z.B. das Independent Analytics Plugin auf vielen Installationen nutze, musste ich die entsprechende Ausnahme in das Snippet aufnahmen.

Ich habe also den entsprechenden Endpoint (iawp) in das Snippet aufgenommen. Und da ich auch mit SureCart arbeite, habe ich auch dafür die entsprechende Ausnahme (surecart) eingerichtet. Am ende sah der Codeschnipsel dann so aus:

add_filter('perfmatters_rest_api_exceptions', function($exceptions) {
  $exceptions[] = 'real-cookie-banner';
  $exceptions[] = 'iawp';
  $exceptions[] = 'surecart';
  return $exceptions;
});

Auch wenn das Tracking von Independent Analytics nach dem Einrichten der Ausnahme wieder anständig funktioniert, wird weiterhin im Dashboard der Hinweis angezeigt, dass Perfmatters die REST-API blockiert.

Dummerweise wird der Warnhinweis von Independent Analytics auch noch angezeigt, nachdem der Weg zur REST-API wieder frei ist. Diesen Hinweis kann man mit folgendem Codeschnipsel verschwinden lassen:

add_action('admin_head', 'remove_dashboard_ads');
 
function remove_dashboard_ads() { echo '<style> .iawp-notices { 
display: none!important; } </style>'; 
}

REST-API-Links entfernen: Ein – Die meisten Websites benötigen diese Links nicht. Daher kann dieser unnötige Code in den meisten Fällen entfernt werden. Nach dem Aktivieren dieser Funktion solltest du deine Website im Inkognito-Modus auf ihre Funktionalität prüfen.

Google Maps deaktivieren: Ein – Einige WordPress-Themes und -Plugins haben die Google Maps-API (//maps.googleapis.com/maps/api/*) integriert. Da Google Maps die Leistung einer Website stark beeinträchtigt, macht es Sinn sie zu deaktivieren.

Sofern du Google Maps auf deiner Website einbindest, kannst du einfach eine Ausnahme für die entsprechende Seite einrichten. Das geschieht anhand der Post ID (Beitrags ID). Um die Post ID zu finden, rufst du dir einfach dein WordPress Seitenverzeichnis auf und hoverst über den Seitentitel jener Seiten, bei denen Google Maps verwendet werden. Links unten erscheint daraufhin ein Link, der die Post ID beinhaltet. In meinem Beispiel post=290.

Diese ID’s müssen nun bei Beitrags-ID’s ausschließen eingegeben werden. In meinem Fall betrifft es nur eine Seite, bei mehreren Seiten müssen die ID’s mit Kommata getrennt werden.

Anzeige der Passwortstärke deaktivieren: Ein – WordPress blendet eine Anzeige zur Passwortstärke ein, wenn ein Benutzer sich ein Passwort vergibt. Einige Themes laden die entsprechenden Dateien (ca. 400KB) auf der gesamten Website. Wer auf diese Funktion verzichten kann, deaktiviert sie einfach.

Kommentare deaktivieren: Ein – Der Grund dafür, dass man auf dieser Seite keine Kommentare hinterlassen kann, ist die Tatsache, dass ich keine Lust habe mich mit dem Spam herumzuschlagen. Sofern du auch keine Kommentare zulässt, kannst du sie hier deaktivieren.

Sobald die Kommentarfunktion deaktiviert ist, verschwindet der Menüpunkt Diskussion unter den Einstellungen. Sowohl aus Gründen der Performance, als auch des Datenschutzes, empfiehlt es sich, zuvor den Haken aus der Option Avatare anzeigen zu entfernen!

Einstellungen -> Diskussion -> Avatare

Kommentar-URLs entfernen: Ein – Bei jedem WordPress Kommentar wird automatisch ein Link auf den Namen des Autors erstellt. Spammer versuchen gern durch Kommentieren einen Backlink zu erhaschen. Die Tatsache, dass es sich um nofollow Links handelt, hält sie vom Versuch nicht ab… Egal ob man Kommentare zulässt oder nicht, die Kommentar-URL können immer entfernt werden.

Leeres Favicon hinzufügen: Aus – Websites ohne favicon rufen einen 404-Error im Webbrowser hervor und das kostet Ladezeit. Nur aktivieren, sofern du kein favicon auf deiner Website verwendest. Perfmatters generiert dann eins für dich und behebt damit den 404-Error.

Globale Stile entfernen: Ein – Seit WordPress 5.9, als FSE eingeführt wurde, hat man zusätzlichen Inline-Code hinzugefügt, um Duotone-Stile (CSS- und SVG-Code) zu verbessern. Das Problem ist, dass dadurch 311 Zeilen Code zu jeder Seite der WordPress-Website hinzugefügt werden. Dieser Inline-Code kann nicht gecacht werden und die meisten Benutzer werden diese Funktion eh nicht nutzen.

Ein Großteil der 196 Zeilen CSS und 115 Zeilen SVG-Code enthalten !important; Tags, was ebenfalls nicht optimal ist!

Wenn man ein FSE Theme (Block-Theme) verwendet, sollte nach dem Deaktivieren der Globalen Stile das Design der Website auf Fehler geprüft werden.

Separate Block Styles: Ein – Standardmäßig werden die WordPress-Block-Styles im globalen Stylesheet geladen, unabhängig davon, ob sie auf einer Seite gerendert werden oder nicht. Aktiviert man diese Funktion, wird das CSS nur geladen, wenn es auch benötigt wird.

Das verbessert die Ladezeiten, da weniger CSS auf der gesamten Website geladen wird. Bei kleineren Websites hat Perfmatters festgestellt, dass dadurch die Menge des verwendeten CSS um bis zu 17 % verringert wird.

Heartbeat-API deaktivieren: Standard – WordPress sendet wie im Herzschlag-Takt regelmäßige Anfragen eine an die Datenbank, um eine Antwort mit Daten oder Anweisungen zur Aktualisierung der Seite zu erhalten. Das ist ne tolle Sache, erhöht jedoch die CPU-Auslastung und verursacht einen Haufen PHP-Aufrufe.

Perfmatters bietet uns hier folgende Möglichkeiten:

• Standard – Heartbeat bleibt aktiv
• Überall deaktivieren – Erklärt sich selbst
• Nur bei Bearbeitung von Beiträgen/Seiten zulassen

Ich würde ich die Heartbeat-API liebend gern auf Nur bei Bearbeitung von Beiträgen/Seiten zulassen stellen, um zu vermeiden, dass WordPress in regelmäßigen Abständen (alle 15 Sekunden) POST-Anfragen an diese Datei sendet, schon allein wenn ich mein Dashboard geöffnet habe.

Allerdings macht mir hier das Real Cookie Banner Plugin wieder einen Strich durch die Rechnung, da das Banner mal wieder auf jeder Unterseite erneut angezeigt wird, wenn die Heartbeat-API nicht aktiv ist.

Sofern du für das Cookie Consent eine andere Lösung nutzt, kannst du versuchen, ob du damit durch kommst, die Heartbeat-API auf das Bearbeiten von Seiten und Beiträgen zu beschränken. Website-Tests im Inkognito-Modus helfen dir dabei, das herauszufinden.

Heartbeat-API-Frequenz: 60 Sekunden – Standardmäßig schlägt das Herz von WordPress alle 15 Sekunden. Dieser Takt sollte hier auf 60 Sekunden reduziert werden, das wirkt sich deutlich auf die Server-Ressourcen aus. Positiv, versteht sich.

Limitiere Beitrags-Revisionen: 3 – Beim Bearbeiten einer Seite oder eines Beitrags erstellt WordPress automatisch Revisionen, die auf der Datenbank gespeichert werden. Auf diese Revisionen kann dann später zurückgegriffen werden.

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.

Autosave-Intervall: 5 Minuten – Beim Bearbeiten eines Beitrags, oder der Seite, speichert WordPress standardmäßig alle 60 Sekunden einen Entwurf. Um u.a. Schreibvorgänge auf der Datenbank zu reduzieren, würde ich den Autosave-Intervall auf 5 Minuten erhöhen.

Anmelde-URL

Benutzerdefinierte Anmelde-URL: DeinLink – Standardmäßig verwendet WordPress die URLs deine-domain.de/wp-admin und deine-domain.de/wp-login.php für den Login Bereich. Diese beiden URL’s werden gerne von Bots, Hackern usw. attackiert, wenn sie auf der Suche nach Schwachstellen und Einstiegspunkten zu einer WordPress Website sind.

Diese Attacken gefährden nicht nur die Sicherheit einer WordPress Website, sondern sie belasten auch ihre Leistung, da bei jedem gescheiterten Anmeldeversuch mit der Datenbank kommuniziert wird.

Dem kann man entgegenwirken, indem man die URL zur Login-Seite ändert.
Hier wird dann wp-admin durch die eigene Endung ersetzt. Selbstverständlich darf man bei der Vergabe dieser Link-Endung kreativ sein. Der neue Link führt dann ausschließlich zum Benutzer-Login.

Beispiel: https://deine-domain.de/meinlink

Wichtig! Nur Zeichen hinzufügen, keine Schräg- oder Spiegelstriche. Es empfiehlt sich, die neue Login-URL irgendwo zu vermerken!

Verhalten bei Deaktivierung: 404-Vorlage – Hier kann bestimmt werden, was einem Benutzer angezeigt wir, wenn er versucht über die alte URL zum Login zu gelangen. Die beste Option ist hier die Weiterleitung zur 404-Seite.

Nachricht: Aus – Wenn du alles richtig gemacht hast, ist dieses Feld verschwunden.

WooCommerce

Skripte deaktivieren: Ein – Wenn WooCommerce installiert ist, werden standardmäßig gewisse Skripte und Styles auf jeder Seite der WordPress-Website geladen. Das ist definitiv nicht gut für die Performance.

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, sondern der Skript Manager stattdessen genutzt werden, auf den wir später noch zu sprechen kommen werden.

Warum sage ich theoretisch? Nun, ich habe die Erfahrung gemacht, dass es abhängig vom Page Builder ist, der die Produkte auf der Startseite einbindet, ob die Skripte benötigt werden, oder nicht. Kurz gesagt, ich nutze dafür z.B. das Kadence Shop Kit Plugin und die Produkte werden auch bei deaktivierten Skripten angezeigt.

Warenkorb-Fragmentation deaktivieren: Ein – Hierbei geht es um Ajax-Anfragen, die für die Warenkorb-Anzeige im Header verantwortlich sind. Sie prüfen die Produkte und Produktmengen im Warenkorb, die Gesamtzahl aller Produkt wird angezeigt.

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.

Status-Meta-Box deaktivieren: Ein – WooCommerce lädt standardmäßig eine Status-Meta-Box (Widget) im WordPress-Dashboard. Meiner Ansicht nach, sind diese Informationen belanglos und es gibt bessere Alternativen für diese Metriken. Das Deaktivieren dieser Funktion beschleunigt den WordPress-Admin Bereich.

Widgets deaktivieren: Ein – Für das Frontend hat WooCommerce ebenfalls verschiedene Widgets im Gepäck, die jedoch nicht immer verwendet werden. Auch die entsprechenden Gutenberg Blöcke, können mit dieser Funktion global deaktiviert werden.

Beispiele:

Die meisten Page Builder verfügen über Query-Loop Elemente, mit denen sich diese Funktionen ersetzen lassen. Sofern man für diese Widgets keine Verwendung hat, können sie hier mit einem Mausklick deaktiviert werden.

Änderungen speichern klicken!

Der Skript Manager

Damit können Skripte auf einzelnen Seiten und Beiträgen deaktiviert werden. Häufig werden von verschiedenen Plugins, CSS und JS-Dateien auf Seiten geladen, wo sie gar nicht benötigt werden.

Ein klassisches Beispiel dafür ist das Formular-Plugin, dass auf jeder Seite geladen wird, obwohl es nur auf der Kontakt-Seite zum Einsatz kommt.

Skripte mit dem Skript-Manager deaktivieren

Schritt 1

• Skript-Manager aufrufen

Sobald der Skript-Manager von Perfmatters aktiv ist, kann man ihn für jede Seite oder Beitrag im entsprechenden Verzeichnis aufrufen.

Auch im Frontend von Wordpress ist der Skript-Manager für jede Seite in der Admin Tool-Bar verfügbar.

Schritt 2

• Funktionen des Skript-Managers

Der Skript-Manager von Perfmatters zeigt uns folgendes an:

1 Plugins, das Skripte einbindet

2 Die einzelnen Dateien

3 Dateityp (CSS- oder JavaScript)

4 Jeweilige Dateigröße

Schritt 3

• Einzelne Dateien deaktivieren

Betätigt man die Schaltfläche unter Status, wird die Datei auf der aktuellen Seite deaktiviert. Sofern dieses Skript auch für andere Bereiche deaktiviert werden soll, kann das hier bestimmt werden.

Zusätzlich kann die Deaktivierung des Skripts auf z.B. eingeloggte oder ausgeloggte Benutzer eingeschränkt werden. Genauso kann man das Skript auch nur für bestimmte Gerätetypen deaktivieren.

Schritt 4

• Plugin komplett deaktivieren

Mit dieser Schaltfläche kann das Laden des gesamten Plugins deaktiviert werden. Auch hier kann bestimmt werden, wo es genau deaktiviert werden soll.

Auch Benutzer und Gerätetypen können bestimmt werden.

Schritt 4

• Kontrolle

Dach dem man Skripte deaktiviert hat, sollte der Cache geleert, und dann die entsprechende Seite im Inkognito-Modus auf intaktes Design und Funktionalität geprüft werden.

JavaScript

Defer

Laden von JavaScripts aufschieben: Ein – Diese Einstellung verschiebt das JavaScript ans untere Ende der Seite. Das lässt sich dann auch mit einem Performance Testing-Tool, wie GiftOfSpeed, im Waterfall Chart prüfen.

Die JavaScript Dateien befinden sich ganz unten im Waterfall.

Include Inline Scripts: Kommt drauf an – Hier sollte getestet werden, ob das Aufschieben der Inline-Skripte die Ladezeit und den TBT-Wert (Total Blocking Time) verbessert, oder sogar verschlechtert.

Dieser Vorgang hat mit Kodierungsprozessen zu tun und kann sich daher auf verschiedenen Websites unterschiedlich auswirken.

Vom Aufschub ausschließen: Hier können JS-Dateien eingetragen werden, die nicht ans untere Ende der Seite verschoben werden sollen.

Auf meiner Seite war z.B. der Domain Check nach dem Aktivieren dieser Funktion nicht mehr sichtbar.

Dieses Problem habe ich folgendermaßen gelöst:

1.

JS-Datei mit Skript-Manager finden

Auch hier kann mit Hilfe des Skript-Managers von Perfmatters ganz leicht jene JavaScript Datei identifiziert werden, die für das Laden des Domain Checkers zuständig ist. Der Pfad zur Datei muss kopiert werden.

2.

JS-Datei vom Aufschub ausschließen

Nun muss der Pfad nur noch in dem Feld eingefügt werden.

Nachdem ich die Einstellungen gespeichert, und dann den Cache gelöscht hatte, lief alles wieder:

JavaScripts verzögert laden: Ein – Diese Funktion blockiert das Ausführen von JS-Dateien bis zu dem Zeitpunkt, zu dem der Benutzer mit der Website interagiert (z.B. Scrollen). Somit kann der restliche Code schneller geladen werden. Zudem kann es Rendering–Blocking-Ressourcen beseitigen.

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.

Verzögerungsverhalten: Alle JavaScripts verzögert laden – Um die Reihenfolge, in der jQuery geladen wird, nicht durcheinander zu bringen, verzögert man am besten alle JS-Dateien. Sofern nicht wahnsinnig viel JavaScript geladen wird, sollte das für die meisten Websites kein Problem sein.

Schnelle Ausschlüsse: Perfmatters findet automatisch die Skripte von Plugins auf deiner Installation, die gewöhnlich ausgeschlossen werden müssen. Hier müssen nur die entsprechenden Checkboxes angeklickt werden.

Von der Verzögerung ausschließen: Zusätzlich können auch hier JS-Dateien eingefügt werden, die nicht verzögert geladen werden sollen. Das kann z.B. JavaScript sein, das im Above-The-Fold Bereich ausgeführt werden soll und zwar nicht erst dann, wenn der Benutzer mit der Seite interagiert. Auch hier würde ich die Dateien mit dem Skript- Manager raussuchen.

Auch bestimmte Plugins und Page-Builder haben Skripte im Gepäck, die von dieser Optimierung ausgeschlossen werden müssen. Besonders, wenn man einen schweren Page-Builder, w.z.B. Elementor oder WP Bakery, verwendet.

Für Plugins, die ich nutze und auch bereits empfohlen habe, können folgende Scripts für die Ausnahmen genutzt werden, sollten 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

Verzögerungsverhalten: Nur bestimmte verzögert laden (Standard) – Bei technisch sehr komplexen Websites, oder bei der Verwendung eines klassischen Drittanbieter Page-Builders, die viel JavaScript benötigen, ist diese Einstellung die Alternativlösung.

Verzögerte Skripte: Hier können alle JS-Dateien eingefügt werden, die delayed geladen werden sollen. Ich würde ich mir den Pfad der entsprechenden Skripte wieder mit Hilfe des Skript-Managers raussuchen und ihn dann Zeile für Zeile in dem Feld einfügen.

Verzögerung auf 10s setzen: Optional – Hierbei werden die Skripte automatisch nach 10 Sekunden geladen, wenn keine Benutzerinteraktion festgestellt wurde.

Minify

Minify JavaScript: Ein – Das Komprimieren von JS-Dateien sollte immer aktiviert werden. Hierbei werden u.a. Leerzeichen und Kommentare aus dem Code entfernt, was natürlich die Dateigröße verringert.

CSS

Unused

Entfernen Sie nicht verwendetes CSS: Ein – Diese Anweisung hat sicherlich jeder schonmal nach einem Google-PSI Test erhalten. WordPress Themes und Plugins kommen mit großen Stylesheets daher, von denen meistens nur ein Teil benötigt wird.

Vor dem Aktivieren dieser Funktion sollte folgendes sichergestellt werden:

• Ungenutztes CSS wird mit keinem anderen Plugin bereits entfernt
• Sofern bereits CSS vorgeladen wird, sollten diese Preloads entfernt werden. (mit Ausnahme der Stylesheets von lokalen Google Fonts)
• Es wird nicht versucht CSS-Dateien zu kombinieren. Ich rate allgemein davon ab, CSS zusammenzufügen, da es seit HTTP/2 für die meisten Websites keinen Sinn mehr macht.

Verwendete CSS-Methode: Datei – Nachdem das genutzte CSS vom ungenutzten CSS getrennt wurde, sollte es auf jeden Fall in einer separaten Datei geladen werden. Auch wenn die Speed Testing-Tools das Inline-CSS besser bewerten, bläht es den HTML-Code unnötig auf und kann zudem nicht gecacht werden.

Wer einen hohen Score bei Google-PSI erzielen möchte, kann das CSS inline laden, damit Google es nicht als Render-Blocking einstuft. Für echte Benutzer der Website, ist die Seite seit HTTP/2, mit der Datei-Methode deutlich schneller!

Stylesheet-Verhalten: Verzögert – Hier wird das Verhalten des ungenutzten CSS bestimmt. Perfmatters bietet uns hier drei Methoden zum Umgang mit den Stylesheets an.

1. Verzögern (Standard): Alle ursprünglichen CSS-Stylesheets (nicht verwendete CSS) werden verzögert und erst bei Benutzerinteraktion geladen. Ich nutze diese Option bei allen Websites.
2. Asynchron: 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.
3. Entfernen: 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ögerte Laden der Stylesheets 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 Verzögert und Asynchron durch A/B-Tests ermitteln. Logischerweise müssten diese Tests durchgeführt werden, nachdem alle Ausnahmen eingerichtet wurden.

Das Entfernen der Stylesheets kann schnell das Design zerstören, ich würde niemandem raten diese Option zu nutzen, der nicht genau weiß was er tut!

Löschen Sie den derzeitig verwendeten CSS: Nach einem Redesign oder einem Wechsel des Themes, sollte das genutzte CSS aktualisiert werden, damit alle Veränderungen direkt angezeigt werden. Genau dazu dient der Button; Löschen Sie den derzeitig verwendeten CSS.

Minify

Minify CSS: Ein – Die meisten Entwickler minimieren die Dateien schon von Haus aus. Dennoch sollte das Komprimieren von CSS-Dateien immer aktiviert werden. Hierbei werden u.a. Leerzeichen und Kommentare aus dem CSS-Code entfernt, was natürlich die Dateigröße verringert.

Änderungen speichern klicken!

Vorladend – Preload Optionen

Das Vorladen bestimmter Assets ist eine sehr wirkungsvolle Methode, um vor allem den Largest Contentful Paint (LCP) zu verbessern.

Aktivieren Sie InstantPage: Ein – Wenn ein Nutzer auf der Website mit der Maus über einem Link hovert, oder ihn auf dem Smartphone berührt, wird der HTML-Code der Ziel-Seite im Hintergrund vorgeladen, sodass die Seite, sofort present ist, wenn der Nutzer den Link tatsächlich klickt.

Diese Funktion verbessert die wahrgenommene Ladezeit für einen Benutzer. Auf die Werte von Speed-Testing-Tools hat sie jedoch keine Auswirkung.

Das Vorladen der Linkziele erhöht zwar die CPU-Auslastung, trägt aber enorm zu einer guten Benutzererfahrung bei. Daher würde ich diese Option immer aktivieren!

Laden Sie wichtige Bilder vor: 2 – Diese Zahl bezieht sich immer auf die ersten Bilder der Website. Wenn z.B. das Logo und das Hero-Image grundsätzlich vorgeladen werden sollen, dann müsste hier 2 eingetragen werden. Für die meisten Websites ist das ein guter Wert.

In diesem Waterfall-Chart ist zu sehen, dass Logo und Hero-Image von Perfmatters an den Anfang des DOM’s, bzw. der Lade-Reihenfolge platziert wurden.

Da das Vorladen von Assets immer die CPU-Auslastung erhöht, würde ich es damit nicht übertreiben.

Vorladen: Diese Funktion ermöglicht es, verschiedene Ressourcen w.z.B. Bilder, Schriftarten, oder Skripte vorzuladen. Aus meiner Sicht macht keinen Sinn, hier Bilder vorzuladen. Da der spezifische Pfad eingegeben wird, können auf diesem Weg die srcset-Bildgrößen nicht berücksichtigt werden. Das bedeutet, dass die. von WordPress erstellten Versionen für kleinere Bildschirmgrößen nicht vorgeladen werden.

Abrufpriorität: Diese Funktion ist der beste Weg, spezifische Bilder vorzuladen. WordPress fügt zwar seit Version 6.3, das Attribut fetchpriority="high" jedem Featured Image hinzu, um den Largest Contentful Paint (LCP) zu verbessern, allerdings ist diese Funktion hier etwas robuster.

Hier ein kleines Beispiel:

Ich habe für meine Blog Beiträge ein Hero-Element erstellt, das über jedem Beitrag dynamisch eingebunden wird. Da ich das jeweilige Bild in dieser Hero-Sektion, global vorladen möchte, habe ich dem Bildelement die CSS-Klasse hero-image zugewiesen.

Diese CSS-Klasse habe ich bei Abrufpriorität eingetragen und die Priorität auf High gestellt. Da einige Page Builder die CSS-Klasse nicht direkt dem Bild-Element zuweisen, sondern einem Container, der das Bild beherbergt, sollte hier noch das Zahnrädchen geklickt werden, um die Checkbox Search by Parent Selector zu aktivieren.

Es ist nämlich so, dass nicht jeder Page Builder die CSS Klasse dem tatsächlichen Bild (<img> -Tag) zuordnet, sondern auch gern mal einem Container oder Wrapper, der das Bild beherbergt.

Bei Elementor z.B., findet man die CSS Klasse weder im Bild-Element (<img>), noch in dem äußeren Container (<div>), sondern erst in dem Container (<div>) dadrüber. Und damit unser hero-image auch unter diesen Umständen vorgeladen werden kann, lassen wir Perfmatters nach dem Parent Selector suchen.

Da bei diesem Verfahren alle Bilder mit der zugewiesenen CSS-Klasse vorgeladen werden, betrifft das auch die srcset-Bildgrößen.

Preconnect: Ermöglicht es dem Browser, bereits vor einer HTTP-Anfrage eine Verbindung zu einer externen Quelle aufzubauen. Dadurch werden Latenz-Zeiten vermieden und dem Benutzer steht der Dienst schneller zur Verfügung.

Die Links zu den jeweiligen Diensten können hier Zeile für Zeile eingefügt werden.

//fonts.gstatic.com

CrossOrigin – Kann beim Preconnecting in 99% aller Fälle mißachtet werden.

DNS-Prefetch: Ermöglicht es dem Browser, bereits vor einer HTTP-Anfrage eine Verbindung zu einer externen Quelle aufzubauen. Dadurch werden Latenz-Zeiten vermieden und der Benutzer Zeit spart.

Auch hier werden die Links in das Feld eingefügt. Immer ein Link pro Zeile.

<link rel="dns-prefetch" href="//fonts.googleapis.com">

<link rel="dns-prefetch" href="//www.google-analytics.com">

Änderungen speichern klicken!

Lazy-Loading

Lazy-Loading bewirkt, dass Bilder erst dann geladen werden, wenn sie im sich im sichtbaren Bereich des Bildschirms befinden. Nicht sichtbare Bilder werden vorerst nicht geladen.

Bilder: Ein – Aktiviert die Lazy Load Funktion. Das gilt auch für CSS-Background Bilder.

Bilder im Kopf der Seite ausschließen: 2 – Hier kann eine bestimmte Anzahl an Bildern vom Lazy-Load ausgeschlossen werden. Das betrifft üblicherweise die Anzahl der Bilder im Above-The-Fold Bereich. Hier sollten Bilder grundsätzlich nie lazy geladen werden, da dies den LCP erhöhen würde.

Zuvor hatten wir ja bereits mit der Funktion, Laden Sie wichtige Bilder vor, die Anzahl an Bildern bestimmt, die grundsätzlich vorgeladen werden sollen, um so den LCP zu verkürzen. Es empfiehlt sich, hier die selbe Zahl einzutragen.

iFrames und Videos: Ein – Aktivieren, um iFrames wie z.B. Google Maps und Videos im Lazy Load Verfahren zu laden.

Miniaturansichten der YouTube-Vorschau: Ein – Dabei werden die YouTube-iFrames durch ein Vorschau-Bild und einem leichten SVG-Play Button ersetzt. Das Video wird erst dann geladen, wenn der Benutzer den Play Button klickt.

Nur aktivieren, wenn für diese Funktion nicht bereits ein anderes Tool genutzt wird. Ich binde z.B. alle Videos mit dem Presto Player ein, da er noch weitere Vorteile bietet. Somit muss ich die Vorschaubilder kein zweites mal aktivieren.

Von Lazy Loading ausschließen: Sofern bestimmte Bilder vom Lazy Load ausgeschlossen werden sollen, kann hier der Pfad oder der Selector einzelner Bilder eingetragen werden.

Beispiel Pfad:

/wp-content/uploads/2024/02/logo.png
/wp-content/uploads/2024/03/above-the-fold-bild.webp

Beispiel Selector (CSS-Klasse):

profil-bild
profil-img

Grenzwert: 0px – Dieser Schwellenwert gibt vor, zu welchem Zeitpunkt die Bilder geladen werden. Standardmäßig sind hier 0 Pixel eingestellt, dass bedeutet, die Bilder werden unmittelbar, bevor sie im sichtbaren Bildschirmbereich sind geladen. Das ist auch am besten für die Leistung.

Wenn man es jedoch vorzieht, die Bilder laden zu lassen, bevor sie den sichtbaren Bereich erreichen, dann kann man hier diesen Wert erhöhen. Dadurch wirkt das Scrollen etwas flüssiger und man hat keinen Pop-In von Bildern, wenn die Seite nach unten gescrollt wird.

Der Schwellenwert kann in px oder % eingegeben werden. Ich persönlich belasse es grundsätzlich bei dem Standardwert von 0px und aktiviere den Einblend-Effekt (dazu kommen wir gleich).

DOM-Überwachung: Ein – Die DOM-Überwachung achtet auf Änderungen im DOM und lädt neu hinzugefügte Elemente dynamisch mit Verzögerung. Dies verbessert die Kompatibilität mit Plugins und Themes von Drittanbietern, die Funktionen wie unendliches Scrollen oder Galerie-Slider verwenden..

Fehlende Bildabmessungen hinzufügen: Ein – Wenn Bilder auf deiner Website keine eindeutigen Angaben zu Breite (width) und Höhe (height) haben, werden hier die fehlenden Attribute automatisch hinzugefügt. Das reduziert Layoutverschiebungen und verbessert damit nicht nur den CLS-Wert der Core Web Vitals, sondern steigert auch die Benutzererfahrung.

Allmähliches Einblenden: Ein – Erzeugt einen Fade-In Effekt beim Laden der Bilder, wenn ein Benutzer herunterscrollt. Diese Funktion hatte ich eben schon kurz erwähnt, die ist bei mir grundsätzlich aktiviert.

CSS-Hintergrundbilder: Ein – Perfmatters unterstützt das Lazy Laden von Inline-Hintergrundbildern ohne zusätzliche Konfiguration. Allerdings laden einige Page Builder, Themes und Plugins Hintergrundbilder in deren (CSS) Stylesheets. Da Perfmatters den Inhalt dieser Stylesheets nicht ändern kann, wird hiermit verhindert, dass bestimmte Container ihr Hintergrundbild sofort in den Browser laden. Somit können CSS-Hintergrundbilder in Elementen von Kadence Blocks, Elementor, Bricks, Divi, Beaver Builder, usw. Lazy geladen werden.

Hintergrundselektoren: In dieses Feld kann eine bestimmte ID oder Klasse eingetragen werden, die im Container (oder übergeordneten Element) gefunden wurde, der das Hintergrundbild enthält. Format: Eine pro Zeile, ohne das Präfix (., #).

Folgende Selektoren werden unterstützt:

• div
• section
• figure
• footer

Änderungen speichern klicken!

Schriftarten

Lokale Google-Schriftarten: Ein – Das lokale hosten der Google Fonts bewirkt nicht nur bessere Ladezeiten, sondern bietet auch DSGVO-rechtliche Vorteile. Auf jeden Fall aktivieren, sofern du die Google Fonts aktuell noch vom Google CDN einbindest.

Anzeigen als „Swap“: Ein – 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„, würde ich diese Funktion auf Swap setzen.

CDN-URL: Die Nutzung eines CDN’s ist bei Websites für den DACH (Deutschland, Österreich, Schweiz) Raum zwar eher selten, aber sofern ein CDN mit eigener URL genutzt wird, kann diese hier eingegeben werden.

Beispiel:

cdn.deine-domain.com

Lokale Schriftarten löschen: Wenn man z.B. eine Schriftart gewechselt hat, oder ein neues Theme verwendet, dann hat man hier die Möglichkeit, die lokalen Fonts zu aktualisieren.

Google Fonts deaktivieren: Aus – Nur aktivieren, wenn entweder System Fonts oder ein Premium Font verwendet wird. Wenn die Perfmatters-Funktion Lokale Google-Schriftarten aktiv ist, werden die Google Fonts automatisch deaktiviert.

Änderungen speichern klicken!

CDN

In diesem 1,5 minütigen Video erkläre ich kurz das Content Delivery Network:

CDN-Rewrite aktivieren: Aus – Nur bei Nutzung eines CDN’s aktivieren. Rewrite bedeutet, dass alle URLs der Assets automatisch so geändert werden, dass die CDN-URL verwendet wird.

CDN-URL: Die URL, die man von seinem CDN-Anbieter erhalten hat, wird hier eingegeben.

Eingeschlossene Verzeichnisse: Es kann vorkommen, dass zusätzliche Verzeichnisse in das CDN-Rewriting einbezogen werden müssen.

CDN-Ausschlüsse: Es kann vorkommen, dass Verzeichnisse oder Dateierweiterungen hinzugefügt werden müssen, die vom CDN-Rewriting ausgeschlossen werden sollen.

Änderungen speichern klicken!

Analytik

Analytics lokal aktivieren: Ein – Wenn Google Analytics auf der Website verwendet wird, macht es Sinn das Script auf dem eigenen Server zu hosten! Das lokale Hosting von Google Analytics kann beschleunigt die Website, indem zusätzliche DNS-Suchvorgänge reduziert werden. und das Problem des „Browser-Caching“ durch das Script löst.

Tracking-ID: G-XX… – Hier gehört deine Google Analytics 4 Tracking ID hinein. Diese findest du in deiner GA4-Property unter: Verwaltung -> Datenstreams (im Datenerhebung und -änderung – Widget) -> Property anklicken -> MESS-ID kopieren.

Diese ID wird dann im dem Tracking ID Feld eingefügt.

Position des Trackingscodes: Footer – Bestimmt, wo auf deiner Website das GA4-Script eingebunden werden soll. Wer meine Anleitungen kennt, der weiß, dass ich Google Analytics grundsätzlich im Footer der Website lade, obgleich Google den Header empfiehlt.

Im Footer wird das Script auch ohne Dateioptimierung später geladen als im Header. Das bedeutet zwar, dass die Datenerhebung ein paar Millisekunden später stattfindet, aber der geschmeidige Aufbau unserer Website hat nunmal Vorrang.

Skripttyp: Google Analytics 4 (Standard) – Die abgeschwächte Version von Google Analytics 4 habe ich bislang noch nie getestet. Wer jedoch Google Analytics 4 Minimal verwendet, klickt das im Dropdown Menü an.

Eingeloggten Admin tracken: Aus – Allein um das User-Tracking nicht durch eigene Seitenaufrufe zu verwässern, sollte diese Funktion aktiviert werden. Das hat sogar noch den riesigen Vorteil, dass bei Google Analytics nicht extra ein entsprechender Filter eingerichtet werden muss.

Monsterinsights verwenden: Aus – Nur bei Nutzung des Monsterinsights-Plugins aktivieren.

Aktivieren Sie die AMP-Unterstützung: Aus – In dem immer seltener werdenden Fall, dass die Website eine AMP-Version (Accelerated Mobile Pages) für Mobil-Gräte hat, sollte diese Option aktiviert werden.

Sofern Google Analytics zuvor auf dem regulären Weg mit der Website verbunden war, kann das ursprüngliche Skript von der Seite entfernt werden, nachdem das Google Analytics Skript lokal läuft. Im Anschluss am besten noch den Cache löschen.

Änderungen speichern klicken!

Kode

Auch wenn es mir nicht leicht fiel, das Wort Code mit „K“ zu schreiben, hab ich es im Sinne einer guten Zuordnung mal so übernommen…

Besonders wenn es um das Anbinden von Drittanbieter-Tools geht, kann es sein, dass man aufgefordert wird, ein Skript in der <head> Sektion seiner Website einzufügen. Ein klassisches Beispiel dafür ist Google Analytics.

Es gibt diverse Plugins, die einem diese Funktion zur Verfügung stellen, allerdings geht mit jedem zusätzlichen Plugin, auch immer ein kleiner Leistungsverlust einher. Aus diesem Grund bietet Perfmatters die Funktion direkt mit an.

Header-Code hinzufügen: Bietet die Option, Custom-Code zum <head> Bereich der Website hinzuzufügen.

Body-Code hinzufügen: Bietet die Option, Custom-Code dem <body> Bereich der Website hinzuzufügen.

Footer-Code hinzufügen: Bietet die Option, Custom-Code zum <footer> der Website hinzuzufügen.

Änderungen speichern klicken!

Werkzeuge

Saubere Deinstallation: Aus – Wenn diese Option aktiviert ist, werden bei der Deinstallation des Perfmatters-Plugins alle Daten alle damit verbundenen Daten von der Datenbank entfernt. Ich würde diese Funktion erst dann aktivieren, wenn Perfmatters auch tatsächlich gelöscht werden soll.

Barrierefreiheit-Modus: Aus – Ein Accessibility Mode für sehbeeinträchtigte Nutzer, oder auch jene, die einen Screen-Reader verwenden. Dieser Modus deaktiviert die Verwendung von visuellen UI-Elementen in den Pefmatters-Plugin-Einstellungen, wie z. B. Toggle-Boxes und Hovering Tooltips.

Accessibility Mode:

Menü in der Admin-Leiste ausblenden: Aus – Diese Funktion entfernt den Perfmatters Menü-Punkt aus der Admin Bar. Ich persönlich greife jedoch gern darüber auf die Einstellungen zu.

Erweiterte Optionen anzeigen: Kommt drauf an – Sehr versierte Anwender können hier zusätzliche Funktionen aufschalten. Nur aktivieren, wenn man weiß was man tut.

• Defer jQuery
• Disable click delay (delay JS)
• Disable core fetch (preloading)
• Enable FastClick (delay JS)
• Exclude by parent selector (lazy loading)
• Load local Google Fonts asynchronously
• Unused CSS CDN URL

Standardoptionen wiederherstellen: Setzt alle Plugin-Optionen auf ihre Standardeinstellungen zurück.

Metaoptionen löschen: Hier können folgende Meta-Optionen von der Datenbank gelöscht werden:

Einstellungen exportieren: Sofern Perfmatters mit diesen Einstellungen auf einer weiteren Installation genutzt werden soll, kann hier eine JSON-Datei ganz einfach exportiert werden.

Import-Einstellungen: Natürlich funktioniert das nur mit der entsprechenden Import-Funktion, einfach die JSON-Datei hochladen und go.

Änderungen speichern klicken!

Datenbank

Datenbank scannen: Jetzt scannen – Scannt die Datenbank deiner Installation auf die nachfolgenden Punkte.

Beitragsrevisionen: Ein – Die einzelnen Zwischenspeicherungen beim Erstellen von Seiten und Beiträgen, sind bei WordPress als Revisionen verfügbar. Im Laufe der Zeit kann sich da ganz schön was ansammeln. Hier können alle auf einen Schlag gelöscht werden.

Damit sich hier zukünftig nicht mehr so viel anhäuft, hatten wir diese Revisionen in den Allgemeinen Einstellungen bereits auf 3 pro Beitrag limitiert.

Beitragsentwürfe: Ein – Diese Entwürfe speichert WordPress beim erstellen von Seiten und Beiträgen automatisch. Sie verhindern, dass getane Arbeit verloren geht. Genau wie bei den Beitragsrevisionen, kann sich das die Datenbank ganz schön zumüllen. Da es unwahrscheinlich ist, dass diese alten Entwürfe noch veröffentlicht werden, würde eich sie löschen.

Gelöschte Beiträge: Prüfen – Ich würde mir den Papierkorb nochmal ansehen, um sicherzustellen, dass sich nicht versehentlich ein Beitrag dorthin verirrt hat, der eigentlich veröffentlicht sein sollte. Generell achte ich bei allen Beitragstypen immer auf leere Papierkörbe. Ansonsten im Anschluss hier aktivieren.

Spam-Kommentare: Ein – Dies sind Kommentare, die von dir selbst, oder einem Plugin als Spam markiert wurden. Schleunigst weg damit.

Gelöschte Kommentare: Ein – Nachdem Kommentare gelöscht wurden, verweilen sie im Papierkorb und belegen unnötig Platz. Meiner Ansicht nach, immer löschen.

Abgelaufene Transienten: Ein – Hierbei handelt es sich temporäre Optionen, die von Plugins erstellt werden und die gefahrlos entfernt werden können, da sie in regelmäßigen Abständen neu erstellt werden.

Alle Transienten: Ein – Gleiches Spiel wie bei den abgelaufenen Transienten, sie können gelöscht werden, aber aus Sicherheitsgründen sollte ein Backup vorhanden sein.

Tabellen: Ein – Aktivieren, um die Tabellen der MySQL Datenbank zu optimieren.

Datenbank optimieren: Jetzt optimieren – Startet den Optimierungsprozess.

Geplante Optimierung: Deaktiviert – Hier kann der zeitliche Intervall für automatische Optimierungen bestimmt werden. In dem Fall würden die oben aktivierten Optimierungen von Perfmatters automatisch durchgeführt.

Ich persönlich bin 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.

Änderungen speichern klicken!

Support

Der Support wird von Brian und Brett persönlich übernommen und ist herausragend gut! Die Ticket werden so gut wie immer binnen 12 Std. beantwortet und in der Regel bleibt kein Problem ungelöst.

Der daraus entstehende Erfahrungsschatz fließt direkt in die Weiterentwicklung des Perfmatters Plugin ein.

Perfmatters – Vorteile & Nachteile