PHP Blogger

Startseite Schreib mir ne Mail! RSS Abo Webnews

Statische Seiten mit Wordpress generieren

Mit Wordpress zu arbeiten ist angenehm: Über Themes und Plugins kann man sich “sein” Blog zusammenstellen - so wie man es benötigt und die Besucher es gut finden. Designtechnisch gesehen ist es sehr flexibel, wenn man an die vielfältigen Themes und Templates denkt.

Das einzige Manko, das sich unter anderem beim PHP Blogger herausgestellt hat, ist die Performance. Denn die leidet unter all den Plugins und damit einhergehenden Hooks und Actions. Die Fastregel lautet: Je mehr Plugins, um so schlechter die Performance.

Und der Witz ist: Es gibt Plugins, um die Performance zu steigern (Wenn sich da mal die Katze nicht selbst in den Schwanz beisst ;)

Aber was ist schon schneller geladen, als eine statische Datei? Deshalb habe ich eine Idee aufgegriffen, die sicherlich schon einige Plugin-Entwickler beschäftigt hat: Ein Wordpress-Blog in statische Dateien und Verzeichnisse zu exportieren. Welchen Blog? Keine Frage, oder? Natürlich den PHP Blogger:

Unter http://static.phpblogger.net/ kann man sich das Ergebnis anschauen. Um Duplicate Content zu verhindern, ist die URL übrigens mit einer entsprechenden robots.txt ausgestattet und sollte (hoffentlich) nicht indexiert werden.

Nachgebildet wird die komplette Permalinkstruktur - und das dynamisch: je nach dem, wie sie konfiguriert ist. Für das Generieren der knapp 1000 HTML Seiten und etwa 700 Verzeichnisse hat das Wordpress Plugin “wpStatic” im Schnitt etwa 3-4 Minuten benötigt (gesamt versteht sich :)

Das Plugin gibt es übrigens noch nicht als Download, es fehlen nämlich noch ein paar wichtige Features für den Livebetrieb: Welche (und vor allem: wieviele) HTML Seiten müssen neu generiert werden, wenn…

  • …ein neuer Beitrag veröffentlich wird?
  • …ein neuer Kommentar abgeschickt wird?
  • …eine neue Kategorie hinzukommt?
  • …eine Datei hochgeladen wird?
  • …etwas bestehendes bearbeitet und verändert wird?

Und dann noch andere quälende Fragen, wie z.B.:

  • Wohin wird das statische Kommentarformular geschickt?
  • Wie geht man mit Userlogins um?
  • Sind personalisierte Ausgaben möglich?
  • Sind alle Plugins kompatibel?

Man muss natürlich Einschränkungen in Kauf nehmen, wenn man eine eigentlich dynamische Seite statisch darstellen möchte. Der Trick liegt natürlich darin, die Einschränkungen so gering wie möglich zu halten.

Wenn Seiten auf irgendeine Art dynamisch zu halten, wird es einen Semi-Dynamik Modus geben. Was bedeutet das? Ist er ausgeschaltet, werden die Dateien als statische HTML Dateien abgelegt. Ist er eingeschaltet, werden PHP-Dateien generiert.

Über spezielle HTML-Kommentar-Tags kann man Bereiche mit oft benötigten, aber häufig änderbaren Inhalten eingrenzen: z.B. die Kategorieliste. Diese wird dann in eine seperate Datei abgelegt und an allen anderen Stellen über einen include-Befehl geladen.

Ändert sich etwas an den Kategorien, muss unter Umständen nur noch diese eine kleine Datei generiert werden! Welch ein enormer Performance-Zuwachs!

Trotzdem kann es je nach Bloggröße erforderlich ist, mehrere hundert HTML Dateien neu zu generieren. Das schreckt im ersten Moment etwas ab - aber man kann die zu generierenden HTML Dateien in verschiedene Level einteilen:

  1. Die Artikelseiten mit den Posts und Pages (Mit Abstand die wichtigsten - abgesehen von der Startseite meistens die Landingpage nach einer Suchmaschine)
  2. Die Startseite und die ersten 4 Kategorieseiten (Es ist eher selten, dass Besucher tiefer blättern)
  3. Die restlichen Kategorieseiten und verbleibende Archivseiten

Das Generieren der Level 1 und 2 HTML Dateien hat natürlich Priorätät - kann aber ohne Bedenken direkt erfolgen. HTML Dateien aus Level 4 können im Hintergrund aktualisiert werden.

Um im Hintergrund zu aktualisieren sind verschiedene Varianten denkbar:

  • Server-Cronjob: Der echte Cronjob kann gemütlich im Hintegrund vielleicht pro Minute eine HTML Seite generieren, das wären pro Stunde 60 Dateien, am Tag 1440 - das bedeutet keine Serverlast und nur minimale Abweichungen auf den HTML Seiten. Je nach Serverperformance kann man die Generierungsgeschwindigkeit dynamisch einstellen. Allerdings ein Problem für Betreiber eines Blogs auf Sharedhosting-Maschinen bei 1und1 oder Strato etwa.
  • wp_cron: Während Besucher auf der Seite surfen werden im Hintergrund HTML-Dateien generiert. (Natürlich nicht zu viele auf einmal, sonst ist der Performancegewinn wieder flöten *zwinker*) Diese Variante wäre auch für den typischen Webspace-Hoster denkbar.
  • MisterWong
  • del.icio.us
  • Technorati
  • Digg
  • Slashdot
  • YahooMyWeb
  • Furl
  • Ma.gnolia
  • Spurl
  • Netscape
  • StumbleUpon
  • MyShare
  • blogmarks

Dennis Morhardt meint dazu:

8. November 2007 um 17:29

Ich bin ja eher dafür, eine Light Version anzubieten, für bestimmte Menschen, die die Webseite mit speziellen Geräten lesen, für Textbrowser oder für Handys. Ein simples Design nur CSS, dort wird alles als HTML gespeichert. Außerdem würde ich vorschlagen, nur bei neuen Einträgen und Kommentaren upzudaten, sonst nur einmal täglich abgleichen. Bei den Kommentar würde ich eine zusätzliche post-comment.php anlegen, die 1. Kommentar in die Datenbank packt 2. Die Eintragsseite updatet. Wäre eine saubere Lösung.

Gruß Dennis

timi meint dazu:

8. November 2007 um 17:37

Hi Dennis,

generell gebe ich Dir Recht. Allerdings ist eine Lightversion unbrauchbar, wenn man auf einem Handy Texte mit über 1000 Worten lesen möchte. (Zum Vergleich: der Artikel hier hat knapp 700 Worte - Kommentare nicht mitgerechnet)

Danke für Deine Idee mit dem täglich Abgleich - was meinen die anderen dazu? Einmal täglich ein riesen Update oder lieber permanent im Hintergrund?

Frank meint dazu:

8. November 2007 um 18:09

Grundlegend finde ich die Idee gut. Ich habe mal ein Plugin erstellt, welches nur den Inhalt statisch ausgibt zum speichern als HTML und ich war eigentlich verblüfft, dass es so schnell geht.
Dementsprechend denke ich, dass man die Dateien mit Funktion ändern, veröffentlichen von Beiträgen und Seiten knüpfen sollte. Über die Aktualisierung der Kommentare kann man eventuell per Option dem Nutzer die Entscheidung überlassen.

LG Frank

latita meint dazu:

8. November 2007 um 18:18

hm ich weiß nicht, ich wäre eher dafür, sich mit plugins zurückzuhalten. oder braucht man jeden schnickschnack?

vielleicht hab ich aber auch nur keine ahnung *g*

Christian meint dazu:

9. November 2007 um 00:49

Erst kürzlich habe ich mich mit Typo3 beschäftigen dürfen, dort ist es von Seite zu Seite konfigurierbar in welcher häufigkeit die Inhalte erneuert werden sollen.

Vorab, Typo3 ist trotz alledem aus meiner Sicht ein grauen, besonders im Bereich Performance.

Statische Seiten sind aus meiner Sicht sehr stark davon abhängig wie grundsätzlich die Seite aufgebaut ist.
Ist eine Navigation vorhanden wo immer alles ersichtlich ist, oder baut sich die navi von click zu click auf.
Beinhaltet die Seite ein Affiliate Partner System wo grundsätzlich werte ausgelesen werden müssen.
Wo bei Buchung, Download oder versand der User auf die Servicenr hingewiesen werden muß.

Die Idee mit Level 1 - 4, ist aus meiner Sicht ein interressanter ansatz.

Optimal wäre natürlich statisch an dynamisch klatschen und ausgeben.
Problematik ist in der Sicht wohl die Umsetzung.
Aber dazu kann man wohl nur sagen: “wo keine Herausforderung ist, ist auch kein Erfolgsgefühl!”..

Ich werde aufjedenfall in kürze mal reinschauen was an neuen Ideen hinzugekommen ist.

timi meint dazu:

9. November 2007 um 13:19

Vielen Dank für das viele Feedback!

@Frank: Ich denke auch, dass die meisten Features über Optionen vom jeweiligen Benutzer eingestellt werden sollten.

@Christian: Der Betrieb von statischen Webseiten kommt mit Sicherheit nicht für jeden Blogbetreiber in Betracht und das Blogtemplate muss natürlich auf den Einsatz als statische Datei angepasst werden.

Insgesamt denke ich wird die Erfahrung mit den unterschiedlichen Plugins und Affiliate- bzw. Werbesystemen zeigen, wie gut alles zusammen spielt…

Christian meint dazu:

9. November 2007 um 15:43

Wir haben bis jetzt immer nur von Statischen Seiten gesprochen um Performance einzusparen…
Wie sieht es den aus mit:
1. Statische Beitragsseiten [Beinhaltet jedoch keine Kommentare sondern eine Div Box die via ID angesteuert werden kann]
2. Wir der arbeitsaufwand verlagert vom Server zum Client.
- Es existiert ein Kommentar Controller der folgende Aufgaben erfüllt.
+-Validieren
+-Fehlerfall xml feed zurücksendet, javascript hebt die Elemente hervor.
+-Daten korrekt, sie in die Datenbank einträgt & in eine XML-Datei abspeichern (speziell nur für den Beitrag)…
-Es existiert eine javascript Datei die bei window.onload aufgerufen wird.
+-Die XML-Datei wird via ajax ausgelesen.
+-Keine Daten vorhanden geschieht nichts.
+-Daten vorhanden, werden via javascript in die Div BOX eingetragen, welche via ID angesteuert werden kann.

Problem:
1. Datenvolumen, der XML-Datei womöglich zu groß bei x Kommentaren.
2. Javascriptunterstützung notwendig.
3. Anzahl der möglichen XML-Dateien…
4. Suchmaschinen, sind die Kommentare von bedeutung werden sie von den Suchmaschinen erfaßt….

timi meint dazu:

9. November 2007 um 17:17

Interessanter Ansatz. Aber die Speicheransteuerung mit Javascript zu kapseln ist bei einer Webseite keine gute Idee. Die Gefahr ist einfach zu groß, das JS ausgeschaltet ist…

Bei einer reinen Ajax-Applikation wäre es kein Problem, die startet ja ohnehin nicht, wenns keine JS Unterstützung gibt.

Die Kommentare auszulagern finde ich generell nicht gut, wenn man ohnehin eine datei schreibt, kann man gleich die ganze Artikelseite rausschreiben…

güzel resimler meint dazu:

18. Mai 2008 um 04:46

Thanks very good information.Danke.

RSS für Kommentare zu diesem Artikel · TrackBack URI

Schreib Deine Meinung