Performance Vergleich: WordPress vs. statische Webseite

Mit diesem Beitrag möchte ich klären, welchen Einfluss WordPress auf die Web-Performance einer Webseite hat. Und ich mache auch noch einen Verbesserungsvorschlag. ;-)

Hintergrund

Letzte Woche hatte das Smashing Magazine eine Preview der neuen Website veröffentlicht. Dabei wurde bekannt gegeben, dass es eine Abkehr von WordPress geben soll. Was mich überraschte, war die Begründung: Es geht – neben der Zusammenführung von unterschiedlichen Plattformen – um die Verbesserung der Performance.

Das führte mich zur Frage:

Gibt es einen Unterschied in der Performance zwischen WordPress getriebenen Webseiten und statischen Webseiten?

Methode

Um der obigen Frage nachzukommen, hatte ich mir folgende Methode überlegt: Ich vergleiche die Web-Performance von identischen Webseiten, die mit und ohne WordPress angetrieben werden.

Natürlich ist klar, dass eine dynamisch generierte Webseite – wie es z.B. bei WordPress – von Hause aus langsamer sein muss als eine statische Webseite. Denn die Seiten werden erst beim Seiten Aufruf generiert. Die Generierung benötigt Zeit und kostet Performance. Darum kommen sinnvollerweise Caching Plugins zum Einsatz, die generierte Seiten archivieren. So dass sie nicht bei jedem Aufruf neu erzeugt werden müssen. Entsprechend habe ich auch das Page Caching berücksichtigt.

Versuchsaufbau

  • Server: Varying Vagrant Vagrants in der Standardkonfiguration.
  • WordPress
    • Plugins
    • Theme: Twenty Seventeen
      • Header-Image
      • Google Fonts entfernt, um Ladzeiten von externen Dateien auszuschliessen
    • Permalinks: Post name
  • Statische Seite
    • 1:1 Kopie der WordPress Startseite als HTML Dokument in einem eigenen Verzeichnis
    • Alle Assets ebenfalls in eigenes Verzeichnis kopiert und die entsprechenden Links auf die Assets im HTML Dokument angepasst.

Ich hatte eine exakt gleiche Dummy Webseite auf drei verschiedene Arten generiert und gemessen. Sie sahen alle so aus:

image-582141

Screenshot der Dummy Webseite

Ergebnisse

Gemessen hatte ich mit dem Developer Tool von Chrome. Hier die Screenshots der Ergebnisse:

1) Webseite mit WordPress

image-582142

2) Webseite mit WordPress und Page Caching

image-582143

3) Statische Webseite

image-582144

Auswertung

Die Ladezeiten für die Assets liegen bei allen drei Seiten auf dem selben Niveau und können somit vernachlässigt werden. Sie haben keinen Einfluss auf die Unterschiede in der Performance.

Die drei Messungen unterscheiden sich lediglich bei den Ladezeiten für das Document. Wie zu erwarten ist die Ladezeit der Webseite mit WordPress am höchsten: 63 ms. Wenn diese Seite im Page Cache vorgeladen wird, gibt es schon eine ordentliche Performance Verbesserung: 15 ms. Aber diese Zeit liegt trotzdem noch deutlich hinter der Ladezeit für die statische Webseite: 8 ms.

Woher kommt der Unterschied beim Caching vs. Statisch?

Page Caching bedeutet, dass die Webseite als statische HTML Datei generiert wird. Webseite 2) und 3) sind also identisch. Trotzdem wird 2) von WordPress langsamer ausgeliefert. Der Grund ist klar: anders als bei 3) liegt die vom Cashing Plugin vorgenerierte Datei nicht an dem Ort, der in der URL angegeben ist. Der URL Aufruf muss erstmal auf das Caching-Archiv umgeleitet werden. Dieser Prozess dauert seine Zeit und dass macht den Unterschied zwischen 2) und 3).

Zusammengefasst: Der Unterschied in der Performance zwischen mit WordPress gecachten und statischen Webseiten ergibt sich aus der Charakteristik der Cache-Archivierung und des Mappings. Dem geschuldet ist der kleine Verlust in der Performance.

Schlussfolgerung

Aus den obigen Messungen lässt sich schließen, dass WordPress generierte Webseiten tatsächlich langsamer sind als Ihre statischen Pendants.

ABER ! ! !

Allerdings sind die Performance Einbussen durch WordPress relativ gering, wenn Page Caching zum Einsatz kommt. Und selbst diese relativ geringe Performance Einbusse ließe sich noch weg bekommen, …

Verbesserungsvorschlag

…wenn das Page Caching anders gelöst würde. Indem die generierten Seiten nicht irgendwo in einem Cache Archiv umgeleitet werden, wäre der kleine Performance Nachteil zu den rein statischen Webseiten aufgehoben.

Prinzip des Page Cachings, wie es mit den WordPress Plugins bisher umgesetzt wird:

/
- index.php
- wordpress/
            - cache-archive/
                             - index.html
                             - blog.html
                             - products.html
                             - portfolio.html
                             - contact.html
                             - about-us.html
            - wp-admin/
            - wp-content/
            - wp-includes/
            - etc...

Der Seitenaufruf muss erst in das Cache Archiv weitergeleitet werden. Das kostet Zeit.

Neuer Ansatz für ein Page Caching mit „echten“ Seiten, deren HTML-Dokumente vom Caching Plugin direkt in die Root gelegt werden:

/
- index.html
- blog.html
- products.html
- portfolio.html
- contact.html
- about-us.html
- index.php
- wordpress/
            - wp-admin/
            - wp-content/
            - wp-includes/
            - etc...

Hier würde der Seitenaufruf direkt bei der Seite landen, weil sie schon dort liegt. Eine Weiterleitung erübrigt sich. Mit diesem Ansatz gäbe es keine Nachteile.

 

This entry was posted on by .

Heiko Mamerow

Buddhist, Vater, Freund, Internetseitenbauer, Sportler, Musikliebhaber & Verkehrsteilnehmer ;-)

3 Gedanken zu „Performance Vergleich: WordPress vs. statische Webseite

  1. Gino Cremer

    Hallo Heiko, spannender Ansatz auf die Umleitungen zu verzichten. Dafür müsste dann aber zum Beispiel mit /blog/index.html gearbeitet werden statt mit blog.html – Sonst braucht dein Webserver wieder eine Umleitung. So spannend wie der Ansatz ist, so schwierig ist er aber in der Umsetzung. Legt jemand eine Seite „wp-content“ an und eine Unterseite „plugins“ (zum Beispiel), müsste das umgebogene Caching-Plugin umgehend meckern und das verhindern. Anderenfalls – möchte man denn auf Umleitungen verzichten – müsste folgendes im Dateisystem passieren: /wp-content/plugins/index.php – kennen wir ja von irgendwo?
    Ebenfalls nicht zu unterschätzen ist – fernab von Kollisionsrisiken – dass potentiell an allen Orten (und nicht nur in einem speziell abgesicherten Cache-Ordner) Datei und Ordner erstellt werden könnten. Das Chaos und Sicherheitsproblem kannst du dir ja denken :) Fazit: Trotzdem spannender Ansatz, in der Praxis ergeben sich für ein paar Millisekunden aber viel zu viele Probleme und Risiken.

  2. Vlad

    Hallo Heiko,

    Allerdings sind die Performance Einbussen durch WordPress relativ gering, wenn Page Caching zum Einsatz kommt.

    Bei deinem Setting sind die Unterschiede minimal. Wenn man allerdings ein Hosting-Paket hat und auch bei einem gemanagten Server schaut es u.U. anders aus.

    Ich habe jetzt auf die Schnelle mal die Startseite von perun.net getestet. Einmal von WP (gecacht) und einmal gegen einer HTML-Datei (Quelltext 1:1 übernommen). Je nach Tool ergibt sich folgendes:

    Firefox Developer: 580ms vs. 120ms
    Pingdom: 913ms vs. 549ms

    Ich denke, je nach Setting und je nach der eingesetzten Hardware kann das u.U. sogar noch deutlicher sein. Daher kann ich den Schritt bei Smashing Magazine schon nachvollziehen. Zumal die ganz andere Aufrufzahlen und Inhaltsmengen haben, daher summieren sich auch vergleichsweise kleine Unterschiede bzw. Entlastungen an der Hardware.

  3. David

    Interessanter Einblick, verfolge den Relaunch des Smashing Magazines auch gespannt. Über das Design (so viel rot!) kann man sich streiten, aber der technische Ansatz ist interessant. Bei einer Seite mit vielen zehntausend (vermute ich) Visits pro Tag, aus der ganzen Welt, sieht die Performance vielleicht noch mal anders aus. Wenn man dann noch ein paar Plugins aktiv hat, die alle in die Datenbank schreiben… ich finde es ein interessantes Experiment, seine Seite absolut optimieren zu wollen. Man verzichtet natürlich auch auf viele bequeme Vorteile von WordPress.

    Wie sieht denn die Performance aus, wenn man z.B. ein Datei-basiertes CMS wie kirby benutzt? In dem Fall müssen die statischen Dateien ja auch wieder erzeugt werden. Nun ja… bei einer bilderlastigen Seite wie dem Smashing Magazine gibt es vielleicht eh ganz andere Engpässe, aber ich hoffe einfach mal, dass sie sich was dabei gedacht haben. Finde den ganzen Relaunch sehr mutig und bin gespannt, wie es ankommen wird. Als Besucher ist mir die Ladezeit fast egal, solange ich nicht 10 Sekunden auf den Seitenaufbau warten muss.

Kommentare sind geschlossen.