WordPress Core - PageSpeedPlus/wp-code-snippets GitHub Wiki
- Header Links - Emojis - Xmlrpc - Kommentare - Suche - Feed - Css/js versionisierung - Font, icon - Post revision - Links - CSS Combine, Minify & Above the fold - IMG Minify (exakt cut) oder doppelt bei Retina - Webp - Lazy load - Css sprite - Minify - Base64 - JAVASCRIPT Combine - Async / defer / footer - jQuery meiden
WordPress generiert einen Haufen unnötiger Links im Head und diese lassen sich mit folgendem Snippet schnell und einfach entfernen. Keine Sorge, alles wichtige bleibt weiterhin erhalten. Solltet ihr eine der unteren Funktionen noch nutzen oder benötigen, entfernt einfach die entsprechende Zeile aus dem Snippet. Meine Empfehlung ist aber ganz klar: Alles was unten im Snippet vorhanden ist, ist meist auch überflüssig und sollte dementsprechend auch deaktiviert bzw. aus dem Head entfernt werden. WordPress ist schon aufgebläht genug und so etwas kostet Leistung.
Die sogenannte WordPress Heartbeat API funktioniert wie eine Art Puls bzw. Herz, was in regelmäßigen Abständen schlägt. Immer wieder kontrolliert WordPress sich so selbst und prüft was genau sich geändert hat. Dieser Vorgang frisst unfassbar viel Leistung und ist eigentlich komplett überflüssig. Wer die WordPress Heartbeat API deaktiviert, kann allerdings auch kein Autosave etc. mehr nutzen. Mehr dazu im entsprechenden Artikel. Mit dem Code dort wird die Heartbeat API von WordPress jedenfalls komplett deaktiviert, was eine Menge Performance einbringt und den eigenen Server spürbar entlastet.
Der Inline-Style vom Comment Widget ist eine Sache, die ständige Einbindung und der beständige Support von Emojis eine ganz andere. Dieser Code wird nämlich dauerhaft und vollautomatisiert eingefügt, ohne dass sich die Emojis im Admin von WordPress deaktivieren lassen. Ziemlich nervig und vor allem richtig schlecht für die Performance. Also weg mit der Emoji-Unterstützung, zumindest wenn ihr die albernen Symbole nicht benötigt. Der normale Blogger benötigt so einen Quatsch jedenfalls nicht.
Wo wir gerade so fleißig beim deaktivieren sind, fallen mir auch gleich die Embeds und Responsive Images auf, welche mit WordPress 4.4 integriert wurden. Die Embeds benötigt so gut wie niemand, die Responsive Images ebenfalls nicht. Zumindest im normalen Einsatz ist ersteres nämlich ein vollkommen sinnloser Performance-Fresser und letzteres kaum anzuraten, es sei denn ihr integriert Bilder gigantischer Ausmaße. Da genau das aber eher selten der Fall sein dürfte, gehören die Embeds und Responsive Images von WordPress deaktiviert.
Die XML-RPC Schnittstelle von WordPress war schon des Öfteren mal ein echtes Problem. So diente selbige als Angriffsfläche und war lange Zeit eine Sicherheitslücke, wurde sogar für erfolgreiche DDoS-Attacken missbraucht. Nicht zuletzt deshalb, aber auch weil sie so gut wie niemand benötigt, sollte die XML-RPC Schnittstelle von WordPress komplett und restlos deaktiviert werden. Wie genau ihr vorgehen müsst, ist im verlinkten Artikel bestens beschrieben.
WordPress Kommentare sind schon lange ein heikles Thema. Auf der einen Seite sind die statischen Kommentare einfach nicht mehr zeitgemäß, auf der anderen sind sie nicht wirklich schnell geladen. Das hat viele Gründe, zum Beispiel den Flaschenhals Datenbank, aber auch die ressourcenhungrige Abwehr von Kommentar-Spam. Inzwischen haben sich daher auch Systeme wie Disqus etabliert, wobei im Grunde alle Konkurrenten von Disqus gar nicht mehr bestehen. Wer Kommentare via externen Service nutzen möchte, setzt daher auf Disqus, auch weil dieses inzwischen wirklich weit verbreitet ist und die meisten Internetaffinen Nutzer einen Account besitzen.
Falls ihr das Recent Comments Widget von WordPress verwendet, findet ihr im Header Inline-Style von genau diesem. Der ist allerdings vollkommen überflüssig und im Bereich der Suchmaschinenoptimierung auch alles andere als gern gesehen. Außerdem bremst er den Code unnötig aus, weshalb der Inline-Style mit folgendem Snippet ganz einfach entfernt werden kann und auch entfernt werden sollte. Natürlich nur wenn ihr das entsprechende Widget im Einsatz habt.
Keine Lust mehr auf den ständigen Spam? Kein Interesse mehr daran extra ein Antispam Plugin einzusetzen, welches viel Leistung frisst, nur um schwachsinnige Kommentare auszusortieren? Kann ich verstehen, zumal viele Kommentare leider keinen Mehrwert haben bzw. sich Systeme wie Disqus und Co viel besser zum kommentieren eigenen, als das altbackene Feature von WordPress selbst. Wer seine Kommentare komplett deaktivieren möchte, findet hier nun also das passende Snippet. Da anschließend keine Spam-Anfragen mehr durchkommen, kein Antispam Plugin genutzt werden muss und auch sonst nichts in die Datenbank für Kommentare geschrieben wird, bringt das Abschalten der Kommentare eine Menge Leistung und entlastet den eigenen Server bzw. die MySQL-Datenbank enorm.
Du kannst dies tun, indem du in deinem WordPress-Dashboard unter Einstellungen in "Diskussion" klickst und dann die Option "Erlaube es Leuten, Kommentare zu neuen Artikeln zu schreiben" deaktivierst. Der Nachteil dieser Methode ist jedoch, dass sie ältere Artikel nicht betrifft, sondern nur neue.
wp post list --format=ids | xargs wp post update --comment_status=closedWer keinen Feed in seinem Blog benötigt oder will, der kann selbigen auch gleich komplett deaktivieren. Dann wird der Feed innerhalb von WordPress gar nicht erst erstellt und vor allem kann er nicht abgerufen werden, was wiederum einen Hauch mehr Performance bedeuten kann. Also einfach alle RSS Feeds in WordPress deaktivieren, wenn ihr für selbige keine Verwendung habt. Das geht ganz einfach mit dem verlinkten WordPress Snippet.
Manch eine Erweiterung telefoniert gerne einmal nach Hause. Soll heißen: Schlechte Plugins verbinden sich ständig mit fremden Websites und Diensten, lesen eventuell sogar Informationen eurer Website aus. Um dem vorzubeugen, könnt ihr mit einem Snippet solche HTTP Verbindungen von WordPress blocken. Ganz einfach und effektiv. Aber vorsicht, denn manchmal funktioniert ein Plugin danach auch nicht mehr, weil es diese Funktion zwingend voraussetzt.
Manch ein Plugin hinterlässt einen auffälligen Kommentar im HTML Code der Website. Manch ein Theme enthält HTML Kommentare und wenn ihr diese, warum auch immer, nicht von Hand entfernen wollt, dann hilft euch das folgende HTML Minify Snippet dabei. Das löscht aber nicht nur Kommentare im Quelltext, sondern minimiert auch noch sämtlichen Code. Javascript, Inline CSS, Kommentare, Leerzeichen – Alles wird vom HTML Minify Snippet reduziert und komprimiert, sodass wirklich nur das Nötigste übrig bleibt. Das Ergebnis: Eine deutlich verbesserte Ladezeit. Da das WordPress Snippet ein wenig größer ausfällt und hier nicht den ganzen Platz einnehmen soll, solltet ihr einfach den entsprechenden Artikel lese, der oben unter HTML Minify Snippet verlinkt wurde. Dort gibt es auch noch weitere Hinweise zum Thema und zur verbesserten Performance.
Schon lange wollte ich noch einmal ausführlicher über die sogenannte wp-cron.php berichten, die in WordPress für geplante bzw. immer wiederkehrende Aufgaben zuständig ist. Eigentlich ist die wp-cron.php wie ein Cronjob, der dafür sorgt, dass zu einer bestimmten Zeit, eine bestimmte Aufgabe gestartet wird. Aber nur eigentlich, denn in Wahrheit ist genau dass das Problem der Sache – die wp-cron.php ist kein echter Cronjob. Stattdessen wird die wp-cron.php bei jedem (!) Seitenaufruf abgefragt und prüft dann, ob Aufgaben vorhanden sind, etwa ob Beiträge geplant wurden, die jetzt veröffentlicht werden sollen, oder ob ein Plugin irgendwelche Arbeiten automatisiert erledigt. Das mag grundsätzlich kein Problem sein und auf die meisten kleinen WordPress Blogs kaum Auswirkungen haben, ist gerade bei größeren Seiten dann aber doch kritischer zu sehen. Performant ist das Ganze nämlich auf gar keinen Fall und so bremst es die Leistung eurer Website aus.
Das liegt schon daran, dass die Aufgaben in der Datenbank gespeichert werden, weshalb die wp-cron.php natürlich auch auf dieses zugreifen muss. Das erzeugt unnötige Anfragen und noch unnötiger ist, dass die wp-cron.php bei jedem Seitenaufruf prüft, ob geplante Aufgaben vorhanden sind, somit also auch immer einen HTML Request generiert. Immer und immer wieder. Ich brauche hier nun gar nicht so sehr in technische Details versinken, weil jedem, wirklich jedem klar sein sollte, dass ein ständiger Aufruf und eine ständige Kontrolle nach geplanten Aufgaben vollkommen sinnlos ist. Genau das soll die wp-cron.php im Kern schließlich verhindern, denn sie dient doch eigentlich dafür, bestimmte Routinen nur alle 60 Minuten etc. abzuarbeiten, statt Aufgaben andauernd zu starten. Weil das so aber eben nicht möglich ist, stellt die wp-cron.php eine permanente Belastung für die Performance da. Wie gesagt: Für kleine Blogs oft nicht von Bedeutung, mit hohen Zugriffszahlen aber schnell ein nicht zu unterschätzendes Problem. Um das alles zu optimieren, sind im wesentlichen zwei Schritte notwendig.
Im ersten Schritt wird nun zunächst die die wp-cron.php in WordPress komplett deaktiviert, sodass diese nicht bei jedem Seitenaufruf gestartet wird. Danach folgt der manuelle Aufruf nach Zeit per Cronjob, sodass die Aufgaben innerhalb der wp-cron.php weiterhin abgearbeitet werden, aber nur noch zu gewissen Zeiten und nicht mehr am laufenden Band. Wie das geht, erfahrt ihr unten.
1. Das einzige was hilft ist nun, die wp-cron.php zu deaktivieren. Das verhindert deren Aufruf und spart Ressourcen, was natürlich wieder Performance einbringt und allgemein den Server etwas entspannen lässt. Doch ohne wp-cron.php gibt es auch keine geplanten Beiträge mehr, auch automatische Aufgaben werden dann nicht mehr abgearbeitet. Doch dafür gibt es eine Lösung, wie ich im nächsten Schritt zeige. Erst einmal deaktiviert ihr nun die wp-cron.php und zwar indem ihr folgendes in die wp-config.php (befindet sich im Hauptverzeichnis) hinzufügt und zwar direkt unter das “define(‘DB_COLLATE’, ”);”, weil es sonst Probleme geben kann oder der Wert nicht korrekt erkannt wird.
define('DISABLE_WP_CRON', true);
2. Als nächste muss nun auf dem Server selbst ein vollwertiger Cronjob eingerichtet werden. Dieser Cronjob ruft die wp-cron.php dann so oft auf wie ihr möchtet. Meiner Meinung nach reichen 30 Minuten vollkommen aus. Doch mal ein kleines Beispiel, um das Ganze zu verdeutlichen. Nehmen wir mal an, ihr plant einen Beitrag für 18:00 Uhr, der Cronjob startet den Aufruf aber erst um 18:30. Das Resultat: Der Beitrag erscheint 30 Minuten zu spät. Für die meisten Blogs ist das vollkommen irrelevant, weshalb die wp-Cron.php vom Cronjob auch so selten wie möglich aufgerufen werden sollte. 30 Minuten sind hier ein guter Mittelwert, wie ich finde, mit dem wohl jeder leben kann, der nicht auf sekundengenaue Veröffentlichungen angewiesen ist. Wer nie geplante Aufgaben nutzt und auch keine Plugins einsetzt die das tun, kann die Zeit noch weiter anheben. Grundsätzlich gilt: Je seltener die wp-cron.php letztendlich aufgerufen wird, umso besser. Wie euer Cronjob genau aussehen muss, richtet sich nach dem jeweiligen Anbieter. Fragt da am besten mal euren Hoster, der gibt euch dann entsprechende Infos. Bei Host Europe zieht die Wget-Methode.
wget -q -O - http://DEINE-DOMAIN.de/wp-cron.php?doing_wp_cron >/dev/null 2>&1
Vor einiger Zeit hatte ich euch diese Möglichkeit schon einmal beiläufig vorgestellt, nämlich im Artikel über Cachify und wie das Plugin mit HDD-Cache und geplanten Beiträgen genutzt werden kann. Allerdings empfinde ich das Abschalten der wp-cron.php als recht wichtig und wollte es daher auch noch einmal einzeln und etwas umfangreicher vorstellen. Bei mir entlastet die deaktivierte wp-cron.php das System jedenfalls recht stark und somit sind Ressourcen wieder für andere Aufgaben frei, statt sie mit unsinnigen Aufrufen der wp-cron.php zu verschwenden. Ob dies bei euch schon nötig ist, oder ob ihr den Umweg über einen echten Cronjob in Kauf nehmen möchtet, solltet ihr nun selbst entscheiden. Ich kann euch das Ganze nur empfehlen, denn die wp-cron ist auf nahezu jedem Blog viel zu ineffizient, als dass sie in Verwendung bleiben sollte. Ein Cronjob wirkt da wahre Wunder und schont das Hosting bzw. den Server. Probiert es doch mal aus. Im Zuge dessen, solltet ihr auch gleich noch einmal die wp-cron.php ausmisten, um verwaiste Einträge und Aufgaben sauber zu entfernen.
WordPress nutzt für regelmäßig anfallende Aufgaben die interne wp-cron-php. In meinem Beitrag zum Thema Cachify HDD mit Cronjob nutzen, hatte ich bereits darauf hingewiesen, dass die wp-cron.php in allen Blogs deaktiviert werden, stattdessen ein echter Cronjob angelegt werden sollte. Das Problem der wp-cron.php ist nämlich, dass WordPress sie bei jedem Seitenaufruf prüft, checkt ob irgendwelche Aufgaben anstehen. Dabei handelt sich um keinen echten Cronjob, eher um einen hinterhältigen Performance-Fresser. Doch die wp-cron.php hat noch andere Nachteile, denn seine virtuellen Cronjobs legt WordPress gerne mal problemlos an, ohne sie später wieder zu löschen. Da kommt nun das Plugin WP Crontrol von Jack Blackbourn ins Spiel.
Die Erweiterung WP Crontrol checkt in WordPress die Einträge der wp-cron.php. Weil viele Plugins dort entsprechende Aufgaben hinterlegen, viele Plugins aber auch unsauber geschrieben sind und sich nicht sauber deinstallieren, müllt sich die wp-cron.php nach einer Zeit oft unnötig zu. Soll heißen: Wer oft und gerne Erweiterungen innerhalb von WordPress installiert, testet und wieder entfernt, hat dort bestimmt noch den ein oder anderen ungenutzten Eintrag. WP Crontrol erlaubt euch nun, alle Einträge anzuzeigen, neue Einträge von Hand anzulegen, oder aber alte und inzwischen nicht mehr genutzte Einträge zu entfernen bzw. Einträge zu bearbeiten. All das geschieht im Backend und in praktischen Menüs, da bedarf es kein Profi-Wissen für.
Viel mehr gibt es dann auch gar nicht mehr zu sagen. Wenn ihr die wp-cron.php unbedingt ganz normal laufen lassen wollt, vielleicht auch weil ihr keinen Cronjob anlegen könnt, dann solltet ihr zumindest dafür sorgen, dass dort auch nur die wirklich wichtigen Einträge vorhanden sind und kein unnötiger Ballast. Auch der muss nämlich jedes mal geprüft werden, selbst wenn es sich um einen verwaisten Eintrag handelt. Wie immer gilt dabei: Plugins testen, das macht ihr lieber auf einer extra dafür eingerichten Website, oder mit Software wie InstantWP, die WordPress ganz einfach und mit nur einem Klick auf dem Windows-Rechner installiert. Dort kann WordPress nämlich ruhig schlecht laufen, nur im Live-Betrieb, da solltet ihr unbedingt aufpassen. Wer das bislang nicht getan hat oder einfach auf Nummer sicher gehen will, kann mit WP Crontrol für Sauberkeit bei den wiederkehrenden Aufgaben sorgen.
WP Crontrol Download: https://href.li/?https://wordpress.org/plugins/wp-crontrol/
Minimalismus ist nicht nur in der Lebensgestaltung und beim Thema Design ein großer Trend, er gilt auch nach wie vor für besonders effektive Programmierung und damit eben auch für Blogs und Web Worker. Weniger ist mehr, heißt es so schön, doch wer alles minimiert hat, findet kaum noch Platz für weitere Kürzungen. Oft vergessen, dabei aber sehr effektiv, sind die sogenannten Relative URL’s. Mit Relative URL’s sind Links innerhalb des eigenen Blogs nicht nur deutlich effizienter, sondern eben auch minimaler. Im Quelltext spart das einiges an Platz und schlussendlich sind Relative URL’s in WordPress daher Teil der Performance-Optimierung. Mehr zum Thema gibt es jetzt hier im Artikel.
Im Grunde ist das mit den Relative URL’s ganz einfach, denn sie verzichten auf die Angabe einer Domain innerhalb des eigentlichen Links. Normalerweise würde ein Link auf die Unterseite zur Performance hier auf FastWP nämlich so aussehen.:
http://fastwp.de/wordpress-performance
Wäre dieser Link nun aber mit einer Relative URL umgesetzt, könnte ich auf die Angabe der Domain komplett verzichten. Relative URL’s gehen davon aus, dass die Domain immer die Grundlage, also das Hauptverzeichnis ist, und somit kann auf dieses Element komplett verzichtet werden. Derselbe Link sähe mit einer Relative URL also so aus:
Die Relative URL ist demnach deutlich kürzer, da dass “/” immer als Pfadangabe gilt und somit die Domain ersetzt. Das hat ein paar Vorteile und ein paar wenige Nachteile, die wir uns nun noch einmal genauer ansehen und besprechen wollen. Was können Relative URL’s im Alltag leisten und warum sollte ein Blog sie nutzen? Aber vor allem, wie lassen sich Relative URL’s in WordPress eigentlich umsetzten? Fangen wir mal ganz am Anfang an und klären die Vorteile solcher URL’s innerhalb von WordPress.
Nun gibt es bei der Verwendung von Relative URL’s ein paar nicht zu unterschätzende Vorteile. Der größte Vorteil ist und bleibt, dass die gesamte Domain fehlt, der Link deshalb deutlich kürzer, der Aufruf viel schneller wird. Relative URL’s sind also pauschal einfach mal flotter unterwegs und durch die kurze Schreibweise reduziert sich, je nach Anzahl der Links innerhalb einer Seite, noch einmal die Zeichenzahl im Quelltext. Zum Teil sogar enorm, weil verlinkte Bilder etc. ja ebenfalls relative URL’s nutzen. Alles also sehr effektiv für eine gute Performance. Ein weiterer Vorteil ist, dass die Links immer gleich bleiben und weiterhin funktionieren, auch wenn sich die Domain mal ändern sollte. Da die Adresse gar nicht angegeben ist, wird immer das Hauptverzeichnis, also die Domain selbst hinzugezogen, weshalb ein Wechsel oder Umzug von WordPress keine Probleme mehr verursacht. Wenn ich Links mit einer Relative URL innerhalb einer lokalen Testumgebung anlege, funktionieren diese auch Problemlos in der Live-Umgebung, da sie keine Domain und auch keinen Localhost oder ähnliches enthalten. Für mich persönlich ist und bleibt der größte Gewinn aber: Relative URL’s sind in WordPress einfach schneller, minimaler und verzichten auf überflüssige Zeichen. So wenig wie möglich, so viel wie nötig. Wenn ich reduzieren kann, dann möchte ich das auch sehr gerne.
Doch wie können Relative URL’s auch in WordPress genutzt werden? Super einfach! Dazu müsst ihr nur entsprechende Parameter setzten, um die Links wiederum automatisch zu bearbeiten. Mit einem Snippet für euer WordPress Theme ist das problemlos realisierbar. Das kürzt den Domainnamen heraus, macht aus den Absolute URL’s ganz schnell Relative URL’s, setzt Filter in allen Bereichen ein, damit auch wirklich alle Links umgewandelt werden. Natürlich nur temporär, denn wer das Snippet deaktiviert hat wieder die alten URL’s. Zu den einzelnen Filtern lest ihr weiter unten noch ein paar Hinweise, jetzt gibt es erst einmal den Code für Relative URL’s in WordPress.
Folgendes in die functions.php einfügen:
function make_href_root_relative($input) { return preg_replace('!http(s)?://' . $_SERVER['SERVER_NAME'] . '/!', '/', $input); } function root_relative_permalinks($input) { return make_href_root_relative($input); }
add_filter( 'day_link', 'root_relative_permalinks'); add_filter( 'year_link', 'root_relative_permalinks'); add_filter( 'post_link', 'root_relative_permalinks'); add_filter( 'page_link', 'root_relative_permalinks'); add_filter( 'term_link', 'root_relative_permalinks'); add_filter( 'month_link', 'root_relative_permalinks'); add_filter( 'search_link', 'root_relative_permalinks'); add_filter( 'the_content', 'root_relative_permalinks'); add_filter( 'the_permalink', 'root_relative_permalinks'); add_filter( 'get_shortlink', 'root_relative_permalinks'); add_filter( 'post_type_link', 'root_relative_permalinks'); add_filter( 'attachment_link', 'root_relative_permalinks'); add_filter( 'get_pagenum_link', 'root_relative_permalinks'); add_filter( 'wp_get_attachment_url', 'root_relative_permalinks'); add_filter( 'post_type_archive_link', 'root_relative_permalinks'); add_filter( 'get_comments_pagenum_link', 'root_relative_permalinks');
Nun ist aber, wie es nun einmal immer so ist, nicht alles Gold was glänzt. Relative URL’s können bei komplexen Blogs und Portalen auch Probleme verursachen und wer viele Plugins im Einsatz hat, muss den Code eventuell noch ergänzen, damit durch Plugins veränderte oder erzeugte Links ebenfalls in Relative URL’s verwandelt werden. Auf der anderen Seite können auch die Filter oben Probleme verursachen, weshalb ihr unter Umständen den ein oder anderen davon entfernen müsst. Auch könnt ihr natürlich die Filter entfernen, die auf eurem Blog gar nicht gebraucht werden. Auch der “the_content” Filter ist nicht immer angebracht, da er in manchen Themes zu viel umwandelt. Meine Empfehlung ist hier: Kopiert das Snippet, schaut ob alles funktioniert, passt es nach und nach an und entfernt alles was nicht gebraucht wird, um es möglichst minimal zu halten. Vor allem gilt es nach der Aktivierung von Relative URL’s in WordPress aber, zunächst jede Stelle des eigenen Blogs zu kontrollieren. Bitte auch nicht vergessen, dass die Relative URL nur direkt im Quelltext sichtbar ist, da der Browser im Link automatisch die Domain hinzufügt. Also nicht wundern, wenn der Link wie immer aussieht. Erst im Quelltext offenbart sich, dass die Links in WordPress nun alle Relative URL’s verwenden und damit deutlich kürzer ausfallen.
Stark angepasste Permalinks sind also ganz pauschal mal schlecht für die Performance, das lässt sich durchaus so sagen. Außerdem haben sich die Zeiten eigentlich inzwischen geändert, auch Google selbst nutzt bei den eigenen Angeboten längst nicht mehr nur sprechende Url’s, sondern benutzt bei Youtube und Google+ ebenfalls einfache Id’s ohne Keywords. Es scheint demnach, als wäre all das gar nicht mehr so wichtig für die Suchmaschinen, die sich vornehmlich immer mehr auf Benutzerfreundlichkeit, Ladezeiten und sinnvollen Inhalt konzentrieren. Alte Tricks mit Meta-Tags und optimierten Adressen scheinen nicht mehr zu wirken, zumindest sind sie aber lange nicht mehr so effektiv wie früher. Da macht es Sinn, noch einmal darüber nachzudenken die Struktur der eigenen Permalinks in WordPress zu verändern bzw. sie bei neuen Blogs direkt anders anzulegen. Das spart Performance und das wiederum erlaubt es auch zu Spitzenzeiten noch fantastische Ladezeiten zu präsentieren, selbst auf schwachen Servern oder günstigen Hosting-Paketen. Doch wie stark machen sich die Permalinks nun wirklich bemerkbar? Reden wir hier von Kleinigkeiten, oder großen Unterschieden?
Tatsächlich reden wir hier von relativ großen Unterschieden. Die Einflüsse auf die Performance sind stärker als ich selbst gedacht hätte und machen sich auch durchaus bemerkbar. Die Permalinks sind damit ein ständiger Faktor für die Performance von WordPress und ziehen selbige unter gewissen Umständen auch wirklich in den Keller. Zwar fallen die Testergebnisse je nach Größte der Datenbank und Umstände verschieden aus, doch stets ordnet sich die Performance der Permalinks in der selben Reihenfolge an. Am schnellsten sind bei WordPress die einfachen Id’s, am langsamsten die eigens eingestellten Permalinks mit Kategorie und Artikelname in der Url. Das ist äußerst interessant, denn wir reden hier von starken Abweichungen. Gemessen wurde mit PHP Microtime und nicht nur bei einem Blog, sondern gleich bei mehreren, natürlich alle mit stark unterschiedlichen Datenbankgrößen. Außerdem verfügte die WordPress Website, bei dem der Test am aufwendigsten vorgenommen wurde, über ca. 2.000 Beiträge. Wichtig zu erwähnen, denn 2.000 Beiträge sind ein schöner Durchschnitt für eine normal gefüllte Datenbank. WordPress ist bei so einem Blog nicht mehr frisch installiert, es gibt einen Haufen Beiträge, Bilder und Kommentare haben sich in der Datenbank festgesetzt und allgemein dürften Wordpress-Installationen mit 2.000 Beiträgen eine guten Vergleich bieten.
1. …de/?p=123 (ID) [0.001760005] 2. …de/Archive/123 (Numerisch) [0.001962205] 3. …de/2014/11/Beispielbeitrag/ (Monat und Name) [0.002254750] 4. …de/2014/11/27/Beispielbeitrag/ (Tag und Name) [0.002399285] 5. …de/Kategorie/Beispielbeitrag/ (Kategorie und Name) [0.002568960]
Getestet habe ich immer zehn Aufrufe der gleichen Seite. Am Ende nutzte ich dann den Durchschnittswert in Mikrosekunden und verglich diesen mit den anderen Permalinks. Die genauen Zeiten sind oben in den eckigen Klammern zu sehen und die zeigen, dass es durchaus größere Unterschiede gibt. Bei größeren Blogs waren die Werte außerdem noch einmal deutlich höher und auch der Abstand zu den normalen WordPress Permalinks mit einfachen Id’s war auch noch einmal deutlich größer als hier im Beispiel. Es schwankt also, doch klar ist, dass Permalinks in WordPress immer noch einen starken Einfluss auf die Performance haben und sich dieser auch, je nach Datenbankgröße, entsprechend bemerkbar macht. Nicht mit zwei Nutzer auf der Website, aber eben dann, wenn tausende zu Spitzenzeiten online sind, wenn Server eben gerne mal ins Stocken kommen oder in die Knie gehen. Ich werde in der nächsten Zeit definitiv mal ein wenig mit den Permalinks herumspielen und schauen wie sich die Performance im Alltag bemerkbar macht und welche Einflüsse das ändern der Url’s heute noch auf die Suchmaschinen hat. Sollte es da in irgendeiner Form interessante Ergebnisse geben, werde ich natürlich erneut einen Beitrag darüber verfassen.
Vor kurzem hatte ich in einem Artikel die Performance der Permalinks getestet und ausgewertet, Vergleiche angestellt und alles noch einmal genau überprüft. Daraufhin war ich mutig, ignorierte all die Suchmaschinenoptimierung und änderte mit einem Schlag meine WordPress Permalinks komplett. Aus den sprechenden URLs wurden so wieder statische URLs mit ID, statt wie üblich mit den wichtigsten Keywords des Beitrags. Doch warum dieser drastische Schritt? Vor allem weil FastWP sich als Testwiese und Spielplatz versteht. Hier probiere ich Dinge aus, die ich mich auf anderen Blogs nicht traue zu testen bzw. probiere ich auch Riskantes, weil es mich einfach persönlich interessiert. In diesem Fall habe ich festgestellt, dass die Permalinks allgemein ziemlich heftig an der Performance von WordPress rütteln und schlichtweg ineffektiv geworden sind. Außerdem stellte ich mir die Frage, ob sprechende URLs heutzutage überhaupt noch notwendig sind, wo Google doch beispielsweise bei Youtube auch nur noch die ID der Videos in den Adressen anzeigt, nicht aber Keywords oder gar die Namen der Clips. Nach der Änderung schrieb ich erst einmal nichts davon, denn wozu auch, es hätte ja jederzeit heftige Auswirkungen haben können. Ich musste also erst einmal abwarten was passiert und wie Google die Sache sieht. Heute ist es nun soweit, denn bereits im November letzten Jahres vollzog ich die Änderung. Jetzt, einige Monate später, möchte ich meine Erkenntnisse im Zuge der Anpassung der WordPress Permalinks gerne mit euch teilen.
Dazu sei gleich mal gesagt, dass ich kein hauptberuflicher oder professioneller SEO bin, sondern nur interessiert an der grundlegenden Thematik. Auch habe ich nicht alles mit dutzenden Reports getestet und geprüft, sondern bin meine Statistiken und SEO-Tools durchgegangen, habe allerdings kleine umfangreichen Vergleiche oder ähnliches angestellt. Mir selbst ging es bei der Umstellung aber vor allem um die Leistung, weil die WordPress Performance unter den Permalinks, je nach Einstellung, ziemlich stark leiden kann. Das Auffälligste war von Anfang an aber, dass das ändern der Permalinks wunderbar und reibungslos vonstatten ging. WordPress erstellt von selbst 301-Weiterleitungen, die Google sofort versteht und entsprechend abarbeitet. Dadurch gab es zunächst einmal keinerlei Verluste im Ranking bzw. den Statistiken und alte URLs wurden ganz einfach auf die neuen umgeleitet. Die Änderung der Permalinks hatte also zunächst keinerlei negativen Auswirkungen, es war als wäre alles wie immer, nur dass URLs jetzt mit ID ausgegeben wurden. Der erste Mut hatte sich auch gelohnt, denn die Performance war im Vergleich dann eben nicht wie immer. Genau wie im Test vorab, verbesserte sie sich, sodass ich sogar den Server etwas herunter skalieren konnte und nun auf schwächerer Hardware unterwegs bin, die aber immer noch fast die identische Anzahl an Besuchern verkraftet. Geld gespart, keine Rankings verloren, also alles super? Erst einmal schon, zumindest aus meiner Sicht.
Perfekt sogar, denn meine Vermutung ist, dass Google sprechende URLs gar nicht mehr wirklich belohnt. Warum auch? Jemand der einfach nur gute Inhalte schreibt, wird sich um die URLs nicht kümmern. Wer optimiert diese also so, dass möglichst alle Keywords enthalten sind? Genau, der typische SEO und Profi, der meist aber eben auch mit schlechten Websites und Nischenseiten auf Platz 1 sein möchte. Meine persönliche (und etwas gewagte) Theorie wäre also, dass Permalinks mit Keywords etc. längst ihren Wert/Nutzen verloren haben, sie nicht mehr wichtig sind und keine echten Vorteile mehr bieten. Im Gegenteil, denn wenn ich nur die ID im Beitrag habe, habe ich auch meist die kürzeste URL im Index. Kurze URLs waren schon immer gut, auch heute noch. Sind kurze Adressen vielleicht sogar besser, als zwei oder drei Keywords? Einige Seiten gingen nach der Umstellung jedenfalls ein wenig nach oben und für mich hatte der Wechsel von den sprechenden URLs zu den Permalinks mit ID bislang nur Vorteile. Mehr Besucher, besseres Ranking, vor allem aber wieder einmal einen Hauch mehr Performance, der sich durchaus bemerkbar macht und den Server spürbar entlasten konnte. Da beflügelte mich gleich noch weiter zu gehen.
Angespornt davon, machte ich gleich weiter. Auch wenn mod_rewrite heute keine echte Bremse mehr sein sollte, jede Regel frisst auch immer ein wenig Leistung. Also weg mit den Fixes, um bei WordPress das “category” bei den Kategorien zu entfernen. Ab heute ist es wieder da und warum auch nicht? Warum alles mit mod_rewrite umleiten, wo Google sich doch einen Dreck darum kümmert, ob in den Kategorien vorher noch ein “category” in der URL zu finden ist? Ich wette die Suchmaschine filtert das sogar schon bzw. nimmt es bei WordPress Blogs gar nicht mehr wahr, wo es doch so unendlich viele Websites auf Basis des CMS gibt und auch einige richtig große Portale immer noch das “category” anzeigen. Auch hier konnte ich nach der Änderung keinerlei negative Effekte oder Auffälligkeiten feststellen, außer der Tatsache, dass ich wieder Ballast losgeworden bin. Gnadenlos auf Performance optimieren war mein Motto zum Jahreswechsel, einfach mal ganz wild auch die radikalen Dinge ausprobieren und testen. Weniger mod_rewrite, weniger Hacks und Tricks, weniger Rumgespiele und alles möglichst reduziert halten, um schön minimalistisch und schnell zu sein. Das alles zahlte sich aus.
Bislang wurde ich für den Mut nämlich nur belohnt. Die Statistiken steigen, die SEO Tools mit ihren Kennzahlen ebenfalls, Rankingverlust gab es aus meiner Sicht keinen und allgemein läuft alles gerade besser denn je. Die Performance hat sich mit den Änderungen deutlich gesteigert, denn wie schon erwähnt, konnte ich die Hardware sogar etwas herunterstufen und spare mir damit auch noch einiges an Geld. Ich habe mit dem Artikel zu den Änderungen und Erkenntnissen, nach dem optimieren der WordPress Permalinks, extra lange gewartet und jeder SEO wird jetzt vermutlich aufschreien und mich eines besseren belehren wollen. Doch das würde gar nichts nützen. Ich teste und probiere sowieso alles selbst aus und das, was dann wirklich funktioniert, bleibt wie es ist. Die Permalinks auf Performance zu optimieren hat wunderbar funktioniert und zwar vollkommen problemlos. Es hat die WordPress Performance gesteigert und zwar spürbar. Am Ende gab es im Anschluss auch keine Nachteile, es gab eigentlich nur Vorteile. Drei Monate ist das nun her und wer mutig ist und nichts zu verlieren hat, versucht es vielleicht selbst einmal. Aber vorsichtig, denn meine Erfahrung heißt nicht, dass es bei euch genau so ablaufen wird. Grundlegendes verändern kann immer und jederzeit Probleme verursachen, wenn ihr nicht genau wisst was ihr da tut und wie ihr es im Extremfall wieder rückgängig machen oder beheben könnt.
Es gibt Fragen, die verschwinden einfach nicht. Sie tauchen immer wieder auf und werden immer wieder kontrovers diskutiert. Eine dieser Fragen, ist die Frage nach der perfekten Permalink-Struktur innerhalb von WordPress. Oft wird dies und jenes empfohlen, doch was ist nun wirklich am besten? Sind sprechende URL’s in aktuellen Zeiten wirklich noch so viel Wert wie früher, wo selbst Google bei Youtube und Co auf derartige Strukturen mittlerweile verzichtet? Was ist das beste für die Performance und wie stark haben die Permalinks in WordPress eigentlich Auswirkungen auf die Ladezeit? Zeit, dass auch ich mal meine Meinung zu dem Thema äußere, denn auch ich werde hier immer wieder nach den perfekten Permalinks gefragt. Zeit sich noch einmal das große Ganze anzuschauen.
Dem ein oder anderen wird es inzwischen bereits aufgefallen sein, dass ich in meinen Blogs durchweg auf sprechende URL’s verzichte. Das war aber nicht von Anfang an so. Damals waren sprechende URL’s, (also URL’s die Keywörter statt sinnloser Zahlen oder ID’s enthielten) regelrecht Gold wert. Damals, als Google noch “jung und dumm” war und Keywörter honorierte, je öfter sie gefunden wurden und vor allem wenn selbige in der URL enthalten waren. Doch die Zeiten sind meiner Ansicht nach längst vorbei. Nicht nur, dass Google selbst in seinen eigenen Angeboten auf sprechende URL’s verzichtet, ich sehe auch keinen echten Mehrwert mehr, da Google gar nicht mehr so stark auf solcherlei Faktoren zu achten scheint. Wozu also der Aufwand, wozu lange, sprechende URL’s generieren?
Permalinks mit ID sind im Trend Meine genau Meinung zu dem Thema hatte ich damals in einem Artikel beschrieben, der klarstellte warum ich in diesem Blog Permalinks mit ID nutze, statt der so beliebten sprechenden URL’s. Ein Hauptgrund dafür ist nicht nur, dass Google es meiner Meinung nach gar nicht mehr honoriert, sondern auch der Aspekt in Sachen Performance. Natürlich spart ihr mit optimierten WordPress Permalinks keine Sekunden an Ladezeit ein, doch bei einer Messung siegen die einfachen Permalinks durchweg und heute zählt einfach schon jeder Sekundenbruchteil. Je simpler, desto effizienter ist das ganze innerhalb von WordPress. Auch das hatte ich bereits getestet bzw. beschrieben, in meinem Artikel zum Thema Performance der WordPress Permalinks. Weniger ist also mehr, zumal es meiner Ansicht nach keinen großen Einfluss mehr auf Google und Co hat.
Unter “Einstellungen – Permalinks” finden sich innerhalb von WordPress nun verschiedene Voreinstellungen wieder. Alle mehr oder weniger sinnvoll, wobei die Permalink-Struktur von WordPress komplett anpassbar bleibt. Wer möchte, kann folgende Parameter frei einsetzten und so seine eigenen, unendlich langen URL’s generieren. Ob das Sinn macht, steht dann auf einem anderen Blatt.
%year% – Jahreszahl wird ausgeben %monthnum% – Monat wird mit zwei Zahlen dargestellt %day% – Datum des aktuellen Tages %hour% – Stunde der Veröffentlichung %minute% – Minute der Veröffentlichung %second% – Sekunde der Veröffentlichung %post_id% – ID des entsprechenden Beitrags %postname% – Name des Artikels wird ausgegeben %category% – Kategoriename wird angezeigt
%author% – Der Autor des Beitrags wird ausgegeben
So könnt ihr mit den Parametern also eure komplett eigene, endlos lange WordPress Permalink-Struktur bauen. Das untere Feld stellt euch den notwendigen Platz zur Verfügung. Ich selbst nutze das ganz einfache Schema mit den ID’s der Beiträge.
Wordpress Permalinks Post ID
Das ist natürlich extrem simpel, keine Frage, aber eben auch extrem performant. Außerdem braucht kein Nutzer mehr Namen in der URL, Datumsangaben oder Kategorien, diese Zeiten sind einfach endgültig vorbei und auch Google scheint keinen großen Wert mehr auf lange und mit Content und Keywords gefüllte URL’s zu legen. Kurz und knapp ist angesagt, alles andere wird überflüssig.
Am Ende ist die einfache Post ID also vollkommen ausreichend, wenn ihr mich fragt. Die kurze URL mit ID ist die perfekte Permalink-Struktur, auch weil Seiten innerhalb von WordPress davon unberührt bleiben. Landing Pages, Sneezing Pages und Co könnt ihr also nach wie vor mit sprechenden URL’s anlegen, was bei diesen Auch tatsächlich noch Sinn macht, nur die Artikel werden künftig lediglich mit ihrer ID gekennzeichnet. Das ist heutzutage vollkommen ausreichend, vielleicht sogar von Vorteil, weil gerade auf Twitter dann die Original-URL verlinkt werden kann, statt extra einen Kurzlink zu erzeugen. Und da Google sprechende URL’s kaum noch bevorzugt und die Leser selbst oft über das Smartphone kommen und die URL gar nicht mehr lesen, macht Performance mehr Sinn als prall gefüllte Permalinks, die schlussendlich keinen Vorteil mehr einbringen.