WordPress hat viele tolle Funktionen, die standardmäßig eingebaute Suche gehört leider nicht dazu. Die ins Suchfeld eingetragenen Begriffe werden zwar gefunden, aber die Ausgabe erfolgt leider nur chronologisch, der neueste Beitrag zuerst, der älteste am Schluss. Damit muss man sich aber nicht abfinden, denn Google bietet die Möglichkeit, seine Suchfunktion in jede Website einzubauen. Allerdings muss man dann damit leben, dass Werbung eingeblendet wird. Wen das nicht stört oder wer es sogar wünscht, weil er sich damit noch ein paar Euro dazu verdienen will, kann die Google-Suche bedenkenlos verwenden. Allerdings gibt es beim Einbau der Google-Suche in WordPress einiges zu beachten.

Wer einen AdSense-Account hat, geht auf “Anzeigen abrufen” und wählt dort “AdSense für Suchergebnisseiten”. Auf dem dann folgenden Bildschirm gebt ihr dann an, ob ihr nur auf eurem Blog suchen oder das gesamte Web durchsuchen wollt. Bei einem Blog ist es sicher sinnvoll, nur diesen zu durchsuchen. Dann müsst ihr im nächsten Feld noch eure Blogadresse eintragen und im folgenden Feld noch einige sinnvolle Keywords, die zu eurem Blog passen. Die folgenden Einstellungen sind selbsterklärend, nur bei der Codierung müsst ihr aufpassen. Dort solltet ihr auf alle Fälle die Option “UTF-8″ anwählen, sonst werden nämlich von Google die Umlaute nicht richtig kodiert und Suchbegriffe, die einen Umlaut oder ein “ß” enthalten, nicht gefunden.

Bei der nächsten Maske sucht ihr euch noch ein Suchfeld aus, das euch gefällt und gebt die Länge des Textfeldes ein. Ich habe bei mir “28″ eingetragen, weil bei der vorgegebenen Einstellung von “31″ bei meinem Theme (Twenty Ten von WordPress 3.0) das Suchfeld zu lang wird und abgeschnitten wird.

Da ihr ja wahrscheinlich die Suchergebnisse nicht bei Google, sondern auf eurem eigenen Blog anzeigen lassen wollt, wählt ihr in der dritten Maske bei “Öffnen der Suchergebnisseite” den dritten Eintrag “Ergebnisse auf meiner eigenen Website öffnen” an und tragt eure URL ein. Als nächstes muss noch die Breite des Suchergebnisbereiches und der Anzeigenstandort angegeben werden. Wenn ihr beim Standort “Oben und rechts” anwählt, braucht ihr eine Mindestbreite von 795px. Da das bei den meisten WordPressthemes nicht passt, ist es sinnvoller “Oben und unten” anzugeben. Dafür braucht man dann nur eine Mindestbreite von 600 px. Ich habe bei mir 660px eingestellt. Dann braucht ihr eurer Google-Suche nur noch einen Namen zu geben und erhaltet zwei Codefragmente.

Da der Einbau dieser Codefragmente nicht gerade einfach ist, verwendet ihr dafür am besten das Plugin Google Custom Search. Nach der Installation geht ihr dann auf “Einstellungen/Google Search” und kopiert dort eure beiden Codes in die entsprechenden Felder rein. Bei den Settings braucht ihr normalerweise nichts zu ändern.

Allerdings gab es bei mir nach dem Einbau noch ein Problem. Die Sidebar wurde nämlich unter statt neben den Sucheinträgen angezeigt. Im WordPress-Forum fand ich aber einen netten Menschen, der mir weiterhelfen konnte und mir den Tipp gab, folgenden Code an die style.css im Verzeichnis wp-content/themes/twentyten anzuhängen:

#cse-search-results iframe { width:80%; margin-bottom:30px; float:left; }
.error404 #content.narrowcolumn form#searchform div { float:left; }
.error404 #primary { margin-top:-30px; }

Das hat dann auch prima funktioniert. Ich hätte nicht gedacht, dass es so schwierig sein würde, die Google-Suche in WordPress einzubauen. Aber letztendlich hat es dann doch hingehauen. Die Suche kann man sich hier angucken -> Weltrangliste. In diesen Blog hier habe ich sie nämlich (noch) nicht eingebaut.

© S. Hofschlaeger / Pixelio

Ich hoste meine Webseiten jetzt schon seit ungefähr einem Jahr bei all-inkl.com und bin bis auf Kleinigkeiten auch recht zufrieden mit diesem Anbieter. Vor 3 Tagen wollte ich nun einen neuen Blog aufsetzen und habe zufällig gesehen, dass es im KAS, dem Admin-Tool für all-inkl.com-Kunden, eine fertige Vorinstallation für WordPress gibt. Ganz spontan habe ich mich entschlossen, diese fertige Installation mal auszuprobieren anstatt WordPress selbst zu installieren.

Schnelle Vorinstallation

Das Gute an solch einer fertigen Installation ist ja, dass es viel schneller geht. Normalerweise dauert es schon 10-15 Minuten, bis alle WordPressdateien auf dem Webspace hochgeladen sind. Da bei einer Vorinstallation die Dateien ja nur innerhalb des Rechenzentrums kopiert werden, ging der ganze Vorgang natürlich wesentlich schneller als über das Internet und schon nach einer Minute waren alle Daten im Verzeichnis und WordPress war installiert.

Erstes Problem: Kubrick lacht mich an

Ich habe dann ein Theme installiert, den “Hallo Welt”-Artikel gelöscht, meinen ersten Artikel geschrieben und kurz überprüft ob alles in Ordnung war. Am nächsten Tag, als ich die Startseite aufgerufen habe, lachte mich plötzlich das Kubrick-Theme an und der “Hallo Welt”-Artikel wurde mir als einziger Eintrag angezeigt. Nachdem ich mich vom ersten Schock erholt hatte, meldete ich mich als Admin an und ging ins Dashboard. Dort war alles in Ordnung. Da stand nur mein erster Artikel und von “Hallo Welt” war nix zu sehen. Ich bin dann nochmal auf die Startseite gegangen und da war auf einmal auch wieder alles in Ordnung. Es war kein Kubrick-Theme und kein “Hallo Welt”-Artikel mehr zu sehen. Okay, dachte ich mir, wahrscheinlich lag das vorhin am Browsercache, der mir noch die alten Daten angezeigt hatte.

Irgendwie kam mir das Ganze dann aber doch komisch vor, deshalb loggte ich mich aus, löschte den Browsercache und startete Firefox nochmal neu. Als ich die Startseite dann wieder aufrief, präsentierte mir Kubrick wieder den “Hallo Welt”-Artikel Und das Seltsame war, dass das nur auf der Startseite so war. Wenn ich meinen Artikel direkt aufrief, wurde er einwandfrei mit dem richtigen Theme angezeigt. Allerdings lieferten mir dort die Kategorie- und die Archiv-Links einen Error 404.

Scheinbar war bei der Installation wohl etwas schief gelaufen. Ich wollte dann WordPress nochmal neu installieren, warf aber vorher noch einen Blick ins Plugin-Verzeichnis und was sah ich da? Da war das Plugin WP Super Cache vorinstalliert. Sollten die Probleme vielleicht daher kommen? Also deaktivierte ich das Plugin und siehe da, auf einmal funktionierte wieder alles

Zweites Problem: Google ignoriert den Blog

Allerdings war das leider nicht das einzige Problem, das ich mit der Vorinstallation von all-inkl.com hatte. Mein erster Artikel war ja schon über 24 h im Netz, da müsste er doch inzwischen bei Google zu finden sein. Aber so viel ich auch suchte, ich konnte ihn nicht finden. Okay, dachte ich mir, das lag vielleicht an dem Problem mit Super Cache, das ich ja gerade erst gelöst hatte.

Aber ein paar Stunden später war er immer noch nicht über Google zu finden. Und das, obwohl ich ihn in der Zwischenzeit bei einigen Social Networks eingetragen hatte. Normalerweise ist das dann nur eine Sache von wenigen Minuten, bis Google sich einen Artikel einverleibt hat. Ich habe dann mal im WordPress-Verzeichnis nach einer robots.txt gesucht, ob da vielleicht etwas gesperrt ist. Aber da war nix zu finden. Danach habe ich die Startseite aufgerufen und mir den Source-Code angesehen. Und was sehe ich da? <meta name="robots" content="noindex,nofollow" /> Wo kommt das denn her? Wieso ist der Blog denn für Suchmaschinen gesperrt? Ich hatte direkt die Plugins im Verdacht und deaktivierte die vorhandenen Plugins dann eins nach dem anderen. Aber selbst nach dem Abschalten aller Plugins war der falsche robots-Metatag immer noch im Code.

Ich sah mir dann die WordPresseinstellungen mal genauer an und bin bei Einstellungen/Privatsphäre fündig geworden. All-inkl.com hatte tatsächlich die WordPress-Voreinstellung “Ich möchte, dass mein Blog für jeden sichtbar ist, auch für Suchmaschinen” geändert auf “Ich möchte Suchmaschinen blockieren, aber normale Besucher zulassen.”

Antwort des Supports von all-inkl.com

Da mir völlig unbegreiflich war, wieso man solch eine Voreinstellung vornehmen kann, habe ich mal den Support von all-inkl.com angeschrieben und dabei auch das Problem mit Super-Cache angesprochen. Kurz darauf kam dann folgende Antwort:

Da WordPress im CGI-Modus einen sehr hohen Ressourcenverbrauch hat, sind die Einstellungen von WordPress auf optimale Performance ausgelegt.

Hmmm, unter optimaler Performance verstehe ich aber, dass die installierten Plugins dann auch einwandfrei funktionieren. Und auf meine Frage, wieso Suchmaschinen standardmäßig vom Blog ausgeschlossen werden, erhielt ich gar keine Antwort. Anstatt dem Problem nachzugehen und zu überprüfen, ob meine Bedenken vielleicht berechtigt sind, gibt es nur eine solche Larifari-Antwort. Normalerweise bin ich mit dem Support von all-inkl.com ja zufrieden, aber diesmal kann ich es wirklich nicht sein.

Fazit: Wenn man sich mit einem Skript gut auskennt und es schon mehrfach selbst installiert hat, sollte man auf die fertige Vorinstallation, die einem der Hoster (egal ob all-inkl.com oder ein anderer) anbietet, lieber verzichten. Die Überprüfung der ganzen Voreinstellungen dauert auf alle Fälle länger, als WordPress selbst hochzuladen und zu installieren.

Erfahrungen mit Vorinstallationen?

Habt ihr auch schon Vorinstallationen ausprobiert, die von eurem Hoster angeboten wurden? Gab es dabei auch Probleme? Schreibt doch bitte in den Kommentaren etwas dazu.

Gestern habe ich im Artikel Seitenaufbau beschleunigen 3 – Parallele Downloads ja erklärt, wieso es besser ist, die Ressourcen, die eine Webseite benötigt, auf mehrere Domains bzw. Subdomains zu verteilen. Der theoretische Hintergrund dürfte damit klar sein und wie man dies auf statischen Webseiten praktisch umsetzt, habe ich in dem Artikel ja auch beschrieben.

© Stephanie Hofschlaeger / Pixelio

Auch bei WordPress ist es möglich, die Ressourcen auf mehrere Domains zu verteilen. Allerdings kann man hier nicht so einfach ohne Rücksicht auf Verluste die Dateien verschieben und die Pfadangaben ändern. Schließlich greifen ja auch Plugins auf diese Dateien zu und es kommt natürlich zu Problemen, wenn diese nicht gefunden werden.

Deshalb habe ich mich auf die Themes-Grafiken und die Uploads beschränkt, da diese Dateien meiner Erfahrung nach problemlos umgelenkt werden können.

Themes-Grafiken auslagern

Die Grafiken des Themes liegen im Ordner wpcontent/themes/Themename/images. Nachdem ihr wie gestern beschrieben eine Subdomain angelegt habt, legt ihr dort einen Ordner namens “images” an und kopiert die Grafiken rein (eventuell könnt ihr die Grafiken vorher noch mit OptiPNG verkleinern). Dann ändert ihr alle Pfadangaben zu den Grafiken. Diese sind in der Datei wpcontent/themes/Themename/style.css gespeichert (vorher natürlich ein Backup machen). Aus wpcontent/themes/Themename/images/bgr_header.png macht ihr dann z. B. http://extern.example.com/images/bgr_header.png. Achtung! Im images-Ordner können auch Grafiken drin sein, die nicht über die style.css aufgerufen werden. Diese dürft ihr nach dem Auslagern natürlich nicht löschen.

Umzug des Upload-Ordners

Als zweiten Schritt könnt ihr auch noch eure Uploads auf der Subdomain auslagern. Da wir dafür Veränderungen in der Datenbank vornehmen müssen, macht bitte zuerst ein Backup der WordPress-Datenbank. Als nächstes kopiert ihr den kompletten Ordner Uploads, den ihr unter wpcontent/uploads findet, auf die Subdomain. Der Ordner sollte dann unter http://extern.example.com/uploads zu erreichen sein. Wichtig ist jetzt auch, die Rechte richtig zu setzen. Der Ordner “extern” bekommt 755 als Rechte, der Ordner Uploads mitsamt den darunterliegenden Ordnern und Verzeichnissen 777. Das ist kein Sicherheitsrisiko, sondern die standardmäßige WordPresseinstellung für den Uploads-Ordner. Mit niedrigeren Rechten ist kein Upload möglich.

Danach meldet ihr euch in WordPress als Admin an und wählt im Menü “Einstellungen” den Menüpunkt “Verschiedenes” an. Dort ändert ihr im Textfeld “Uploads in folgenden Ordnern speichern” den Uploadpfad ab. Normalerweise sieht der ungefähr so aus: /www/htdocs/Meine_Kundennummer/Mein_Ordner/wp-content/uploads. Den ändert ihr dann auf den neuen Uploadordner ab, das könnte z. B. so aussehen: /www/htdocs/Meine_Kundennummer/Mein_Ordner/extern/uploads. Wobei “extern” der Ordner ist, dem ihr die Subdomain zugewiesen habt. Es ist ein wenig schwierig, das allgemeingültig zu erklären, weil es bei jedem Hoster ein bisschen anders aussieht. Im Feld “Kompletter Pfad zu den Dateien” gebt ihr dann die Subdomain und den Ordnernamen an, in dem ihr die Uploads gespeichert habt, also z. B. http://extern.example.com/uploads. In beiden Feldern darf am Ende kein Schrägstrich stehen!

Anschließend müsst ihr noch an die Datenbank ran. Dort gebt ihr im SQL-Feld folgenden Code ein (übernommen vom Hausblog14):

UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://example.com/Mein_Ordner/wp-content/uploads/', 'http://extern.example.com/uploads/');

Mit diesem Code wird der bisherige Pfad zum Uploadordner durch den neuen Pfad ersetzt. Die erste Pfadangabe gibt an, wo der Ordner bisher gespeichert war und die zweite weist auf den neuen Ordner hin. Diesmal müssen beide Pfade mit einem Schrägstrich enden.

So, das war es dann auch schon. Ab sofort werden auch bei euch die Ressourcen besser verteilt und ihr dürft euch an einem schnelleren WordPress erfreuen

Hat alles geklappt?

Schreibt doch mal in den Kommentaren, ob bei euch alles geklappt hat. Falls etwas unklar ist, könnt ihr natürlich auch noch Fragen zu der Anleitung stellen.

Piet von Netzpanorama hat gestern in seinem Artikel Artikelübersicht oder Inhaltsverzeichnis als WordPress Unterseite beschrieben, wie er mit dem WordPress-Plugin Articles eine Sitemap erstellt. Genauer gesagt erstellt dieses Plugin eine HTML-Sitemap, die die Benutzerfreundlichkeit eines Blogs verbessern soll. Das ist der Unterschied zu einer XML-Sitemap, die man erstellt, damit Google sich besser auf der eigenen Website zurechtfindet.

Während bei Piet das Plugin einwandfrei funktioniert, gab es bei mir und zwei anderen Usern Probleme. Articles bietet nämlich zwei Möglichkeiten, eine Sitemap in den eigenen Blog einzubinden. Bei der ersten Variante musste man einen php-Code einfügen, was einen größeren Eingriff ins Template bedeutet hätte.

Einstellungen des Sitemap-Plugins Articles

Für die zweite Möglichkeit musste man lediglich eine neue Seite erstellen und dort in der HTML-Ansicht einen Token einfügen. Außerdem musste man in den Plugineinstellungen ein Auswahlfeld von “No” auf “Yes” ändern. Und genau da hakte es bei mir. Ich konnte zwar die Auswahl auf “Yes” ändern, nach Drücken des Buttons “Update Articles Settings” wurde automatisch wieder die Auswahl auf “No” gestellt.

Ich dachte zuerst, es würde vielleicht an den Dateirechten liegen und stellte das Pluginverzeichnis und die Plugindatei auf 777. Das brachte aber leider nix. Also guckte ich mir mal die WordPress-Datenbank mal näher an und siehe da, da fand ich einen passenden Eintrag, den ich nur von 0 auf 1 ändern musste.

Ich poste hier jetzt mal die genaue Anleitung, wie man die Änderung vornimmt. Wer diese nachvollziehen will, sollte aber unbedingt vorher ein Backup der WordPress-Datenbank machen. Wie das funktioniert habe ich in diesem Artikel bereits erklärt: Datenbank optimieren mit phpMyAdmin.

Datenbankwert bei aka_token von 0 auf 1 ändern

Um in den Plugineinstellungen von Article bei der Option “Enable token method for showing the articles list” den Wert “Yes” einzustellen, muss man in der Tabelle wp_options den Wert “aka_token” auswählen (wenn Articles gerade erst installiert wurde, müsste der Wert in der Tabelle ziemlich weit hinten stehen) und auf Bearbeiten klicken. Dort ändert man den angezeigten Wert von “0″ auf “1″ und klickt auf “OK”. Jetzt braucht man nur noch wie vorgesehen eine Seite zu erstellen und dort den Token einzufügen.

Artikel in die Sitemap aufnehmen

Für ein weiteres Problem habe ich leider keine brauchbare Lösung gefunden. Damit Articles weiß, welchen Beitrag man in der Sitemap haben will, muss man nämlich jeden einzelnen Beitrag bearbeiten und dort bei “Mark as an Article?” mittels eines Radiobuttons das voreingestellte “No” auf “Yes” ändern. Wenn man mehrere hundert Beiträge hat, ist das natürlich ein riesiger Aufwand. Diese Einstellung wird zwar auch in der Datenbank gespeichert, es muss aber zuvor für jeden Artikel ein Datenbankeintrag angelegt werden. Und da ist es doch einfacher, diese Einstellung direkt im Beitrag vorzunehmen. Falls jemand eine einfache Lösung für dieses Problem hat, bin ich natürlich für eine Anregung dankbar

Alles in allem muss ich doch Piet zustimmen, der meinte, dass sich diese Fleißarbeit auf jeden Fall lohnen würde. Denn die von Articles erstellte Sitemap ist nicht nur übersichtlich, sondern auch optisch gut gelungen.

Im ersten Teil der Reihe “Webseiten beschleunigen” hatte ich beschrieben, wie man mit Hilfe von OptiPNG die Dateigröße von Grafiken verkleinern und damit die Ladezeit verkürzen kann. Im zweiten Teil widme ich mich nun einem etwas komplexeren Thema, nämlich der Verwendung von Expires-Header.

Leverage browser caching

Wenn man mit dem Googletool PageSpeed die eigene Website analysieren lässt, dürfte bei den meisten wohl diese Meldung mit einem roten Ausrufezeichen angezeigt werden: Leverage browser caching. Dies bedeutet soviel wie, dass das Browsercaching nicht optimal eingestellt ist. Doch wie kann ich das Browsercaching meiner Seiten optimieren? Um dies zu erreichen, erkläre ich erst mal, wie so ein Browsercaching überhaupt funktioniert.

© katstep / Pixelio

Funktionsweise des Browsercaches

Wenn man eine Website besucht, speichert der Browser des Users diese in einem Zwischenspeicher, dem Browsercache. Wenn der User die gleiche Seite ein zweites Mal besucht, fragt der Browser beim Webserver der Webseite nach, ob sich diese geändert hat. Falls ja, fordert der Browser des Users diese Seite nochmal neu an. Falls nein, liest der Browser diese aus seinem Cache. Das geht natürlich wesentlich schneller, da die benötigten Daten ja schon auf dem Rechner des Users liegen und nicht mehr per Internet übertragen werden müssen.

Im ersten Moment hört sich das nach einer optimalen Lösung an. Allerdings verbraucht auch bereits die Abfrage, ob die Seite schon mal besucht wurde oder nicht, eine gewisse Zeit. Für eine Datei ist das nicht viel, aber eine einzige Seite ruft ja oftmals 10-20 Dateien auf, wie z. B. das Logo, das Favicon, CSS-Dateien, Javascript-Dateien usw. Und bei jeder einzelnen Datei fragt der Browser beim Server nach, ob sich diese geändert hat. Diese vielen Abfragen summieren sich dann natürlich und allein dadurch kann sich die Ladezeit einer Seite um 2-3 Sekunden verlängern.

Den richtigen Zeitraum einstellen

Verhindern kann man dies, indem der Server dem Browser eines Users mitteilt, dass er für eine gewisse Zeit auf diese Abfragen verzichten soll. Dies erreicht man durch die Verwendung von Expires-Header. Mit einem Expires-Header gibt man an, für welchen Zeitraum diese Abfragen nicht mehr erfolgen sollen. Wie lange dieser Zeitraum ist, ist von Dateityp zu Dateityp verschieden und über die richtige Einstellung sollte man sich vor der Verwendung von Expires-Header einige Gedanken machen.

Der Nachteil, wenn man Expires-Header verwendet, ist nämlich, dass Änderungen, die man an einer Datei vornimmt, vom Browser des Users nicht erkannt werden. Schließlich fragt er ja nicht mehr nach, ob eine Datei geändert wurde oder nicht. Wenn man also z. B. eine wichtige css-Datei hat, sollte man den Zeitraum nicht zu hoch einstellen, weil der User die Änderungen an dieser Datei ja erst bei der nächsten Abfrage mitbekommt. Bei Bildern ist es dagegen meistens so, dass man diese nachdem man sie in die Website eingebaut hat, nicht mehr ändert. Deshalb kann man hier den Zeitraum ziemlich hoch einstellen.

Eintragungen in der .htaccess

Nach dem langen theoretischen Vorgeplänkel, das aber leider notwendig war, folgt nun die Praxis. Wenn ihr Expires-Header verwenden wollt, müsst ihr folgende Eintragungen in eurer .htaccess machen.

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/css "access plus 1 week"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType application/x-javascript "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 year"
</IfModule>

Die If-Abfrage in der ersten Zeile prüft ob das Apache-Modul mod_expires.c verfügbar ist. Falls ja, wird es aktiviert und der Zeitraum für die einzelnen Dateitypen wird eingestellt. ‘ExpiresByType text/css “access plus 1 week”‘ bedeutet z. B. dass nachdem der Browser des Users auf eine css-Datei zugegriffen hat, er eine Woche lang diese Datei aus dem Browsercache holt und sie erst nach Ablauf dieser Frist erneut einliest.

Man kann die Expires-Header natürlich auch noch für andere Dateitypen verwenden. Bei reinen HTML-Dateien macht es allerdings weniger Sinn, da diese ja meist nur wenige kb groß sind. Expires-Header lassen sich auch mit WordPress nutzen, allerdings sollte man die .htaccess nur in die Verzeichnisse wp-admin und wp-includes einbauen und nicht in das Verzeichnis wp-content.

Oben habe ich geschrieben, dass Änderungen an den Dateien erst nach Ablauf des eingestellten Zeitraums wirksam werden. Falls man trotzdem wichtige Änderungen vornehmen will, die sofort bei allen Usern sichtbar werden sollen, kann man zu einem kleinen Kniff greifen. Man hängt an die Datei, die man ändern möchte, einfach eine Zahl an, z. B. style2.css und ändert den Aufruf im HTML-Code. Da diese Datei für den Browser ja neu ist, wird er sie neu einlesen. Dieser Trick ist aber nur bei kleinen Websites sinnvoll oder wenn nur wenige Dateien geändert werden müssen, da der Aufwand sonst zu groß wird.

Was bringen Expires-Header?

Ich habe den oben geposteten Code in die .htaccess meiner Rätselseite eingebaut und ich war überrascht über die erhebliche Leistungssteigerung, die der Einsatz der Expires-Header gebracht hat. Ich hatte das Gefühl, als hätte ich einen kleinen Turbo dazugeschaltet

Und das Schöne daran ist, man schlägt 2 Fliegen mit einer Klappe. Erstens verringert sich die Ladezeit beim Besucher der Website und zweitens wird auch der Server weniger beansprucht, da er ja weniger Anfragen bearbeiten muss.

Eigene Erfahrungen

Setzt ihr auf euren Websites auch Expires-Header ein? Welche Zeiträume habt ihr für die einzelnen Dateien eingestellt? Schreibt doch in den Kommentaren was zu euren Erfahrungen.

Artikelreihe Webseiten beschleunigen:

Teil 1: Dateigröße von Grafiken verkleinern

Teil 3: Parallele Downloads

Teil 4: Die gzip-Compression

Gestern habe ich eine statische Seite in WordPress erstellt und wollte auf dieser Seite 3 Bilder einbinden. Der Text sollte neben den Bildern entlang fließen. Also eigentlich nichts besonderes. Das Problem war nur, dass es ziemlich wenig Text war und die Grafiken wesentlich höher als der Text waren. Dadurch wurde alles bunt miteinander vermischt:

Wordpress-Artikel ohne Leerzeilen

Ich habe dann natürlich die naheliegendste Möglichkeit ausprobiert und einige Zeilenumbrüche eingefügt. In der visuellen Ansicht des WordPress-Editors sah das auch so aus, wie ich es haben wollte. Aber sobald ich auf Vorschau geklickt habe, waren die Zeilenumbrüche wieder weg.

Naja, dachte ich mir, wenn es in der visuellen Ansicht nicht funktioniert, versuche ich mal mein Glück in der HTML-Ansicht und habe dort einige “<br />” eingefügt. Nach einem Klick auf den Vorschau-Button bot sich mir allerdings das bekannte Bild. Die Zeilenumbrüche waren wieder verschwunden

Dann habe ich die Hilfe von Tante Google in Anspruch genommen und schnell festgestellt, dass ich nicht der einzige war, der Probleme damit hatte, Leerzeilen in WordPress einzufügen. Die ersten Einträge, die ich fand, haben mir leider nicht viel weitergeholfen. Da wurde zum Beispiel vorgeschlagen, folgenden Eintrag in die style.css aufzunehmen:

.entry p { margin-bottom: 1em; }

Das brachte aber leider auch keinen Erfolg

Langer Rede, kurzer Sinn: Ich habe nach einigem Suchen dann sogar 2 Möglichkeiten gefunden, wie man Leerzeilen in WordPress einfügen kann.

Zum einen gibt es die etwas unsaubere Lösung ein geschütztes Leerzeichen in ein p oder in ein blockquote einzubauen, also so:

<p>&nbsp;</p>

bzw. so:

<blockquote>&nbsp;</blockquote>.

Die zweite Lösung, die ich bei Rainer Meyer gefunden habe ist dann etwas sauberer, da sie CSS einsetzt um den benötigten Leerraum zu schaffen:

<p style="margin-top: 20px">20 Pixel Leerraum</p>

Damit erzeugt man vor dem Absatz einen 20 Pixel großen Leerraum. Man kann natürlich auch margin-bottom verwenden, um den Leerraum hinter dem Absatz zu erzeugen. Das Ganze sah danach dann so aus:

Wordpress-Artikel mit Leerzeilen

Das bleibt natürlich nicht so. Der Leerraum wird noch mit Text aufgefüllt werden. Es ging mir nur darum, mal eine Zwischenlösung zu haben, bis der restliche Text geschrieben war.

Wobei ich mich frage, was macht da ein Blogger, dem es nur ums reine Schreiben geht und der von HTML und CSS keine Ahnung hat? Da hätte ich doch gedacht, dass WordPress eine einfachere Lösung bietet, um Leerzeilen einzufügen.

Oder gibt es eine und ich habe sie nur nicht gefunden? Wenn ihr eine wisst, dann postet sie doch bitte als Kommentar.