Ist die Zeile „AddHandler php70-cgi .php“ in der .htaccess ein Turbo?

Kürzlich informierte mein Provider allinkl.com die Kunden, dass PHP 7 unterstützt werde. Diese Information habe ich nicht groß beachtet bis ich bei Hennig Uhle auf diesen Artikel stieß: „Soll ich jetzt meinen WordPress-Blog mit PHP 7 betreiben? › Henning Uhle“ | Klick

Also habe ich meine .htaccess – Datei um diese Zeile ergänzt: AddHandler php70-cgi .php

Vielleicht bilde ich mir das ein. Aber ich finde, dass sich die Änderung spürbar auswirkt.

Das Thema Blogperformance hat mich in letzter Zeit nicht sonderlich interessiert. Die Wechsel und Gestaltungsexperimente zwischen den 3 WordPress-Themes, die ich hier favorisiert habe, machten mehr Spaß.

Als ich vor einigen Tagen eine Messung mit dem Speed-Tool von Pingdom gemacht habe, war ich mit dem Wert nicht unbedingt zufrieden. Der zeitliche Verlauf macht deutlich, was ich meine.

[symple_highlight color=“blue“]Ich weiß, dass es auch viele andere gute Tools gibt, die schlechtere Werte zeigen :-) Ich will euch nur Arbeit ersparen :-) [/symple_highlight]

Zeitlicher Verlauf der Messergebnisse bei Pingdom
Zeitlicher Verlauf der Messergebnisse bei Pingdom

Wegen meiner Experimentierfreudigkeit habe ich die Cache-Funktionen (Plugins) abgeschaltet. Die .htaccess-Inhalte habe ich unverändert gelassen (s. ganz unten).

Bei dem momentan eingesetzten ganz wunderbaren Theme von MH-Themes (MH Magazine) gefällt mir sehr, dass unter vielen tollen Features die Nutzung von Fotos bzw. deren responsive Darstellung excellent funktioniert. Es sind manchmal Kleinigkeiten bei anderen Themes, die mich in dieser Hinsicht nicht zufriedenstellen. Da werden sogar Featureimages runter- oder heraufskaliert. Ich muss aber ehrlicherweise dazu anmerken, dass meine Nörgelei auch auf Verständnisprobleme zurückgehen können. Ich kann kein Englisch.

***

Kürzlich wurde beim Webmasterfriday die Frage gestellt, wie Blogger mit den archivierten, bzw. zum Teil alten Artikeln (Blogarchiv) umgehen. Eine wirklich überzeugende Lösung habe ich nicht gefunden.

Plugins, die Archivinhalte – schön gestaltet – auflisten, gibt es einige. Sie laufen performancemäßig nicht so toll. Großen Mengen von Artikeln brauchen lange, bis der Leser die Ausgabe vollständig angezeigt erhält. Diese Plugins machen meiner Erfahrung nach nur Sinn bei einer kleineren Anzahl von Artikeln.

Ich präferiere den Einsatz von 2 Widgets, mithilfe derer die Top-Artikel (nach Views oder Kommentaren) für unterschiedliche Zeiträume ausgegeben werden. Allerdings wird auch das nicht der Weisheit letzter Schluss sein. Allzu viele Widgets, die am Ende nur viele Abfragen erzeugen, sollte man IMHO nicht einsetzen. [einruecken][highlight]Schließlich können sich die Leser über die Suche, über Sitemaps oder Kategorien und Tags ausreichend komfortabel informieren. [/highlight][/einruecken]

***

Einen einzigen Artikel, den ich einmal für den Webmasterfriday geschrieben habe, habe ich prominent verlinkt. Er verbirgt sich im 1. Menü (ganz oben) hinter dem Eintrag „über mich„. Man kann Artikel, die einem besonders am Herzen liegen, manuell in einem Widget zusammenstellen. Also einfach eine manuelle Linkliste anlegen bzw. sie ins Text-Widget packen. Aber das ist doch ziemlich viel Aufwand.


Das Thema Flüchtlinge beschäftigt mich sehr. Liest jemand im Blog einen Artikel aus der Kategorie „Flüchtlinge“ wird in der linken Sidebar eine Leseempfehlung der kommentarreichsten Artikeln dieser Kategorie ausgegeben. Das bewerkstellige ich mithilfe des Plugins „Widget Logic“ und den spezifischen Parametern.

***

Wer allerdings zu viele solcher Angebote platziert, stößt schnell auf das Problem, dass die Zahl der HTTP Requests oder Datenbankabfragen ansteigt. Hierdurch wird die Ladezeit eines Blogs sich nicht verbessern!

Allerdings bringt IMHO eine gute Komprimierung der im Blog verwendeten Fotos deutlich mehr als auf die HTTP Requests zu achten oder auf Datenbankabfragen.

Das bekommt man eindrucksvoll vor Augen geführt, wenn man zum Testen Pagespeed Insight von Google benutzt.

Viele quälen sich mit den Maßgaben, die laut Google zum Erfolg führen sollen, einigermaßen herum. Ich mache das nicht mehr! Die Bilder werden komprimiert, zudem verwende ich im Blog das Plugin „EWWW Image Optimizer„.

Tante Google reichen diese Maßnahmen aber nicht. Führt man eine maximale Komprimierung der von Google angemeckerten Bilder durch und startet den Text erneut, ist von den positiven Auswirkungen überrascht – ich war es jedenfalls. Die Maßnahme bringt es. Aber, wie gesagt, der Aufwand…

Denn was bedeutet das für die Zukunft? Nun — bei einem Wechsel des Themes ist zumindest mal ratsam, Plugins wie „Force Regenerate Thumbnails“ oder „Regenerate Thumbnails“ den gesamten Fotobestand „überarbeiten“ zu lassen. Meiner Erfahrung nach, habt ihr nach einem solchen Wechsel das Problem mit Google Pagespeed erneut an der Backe.

Ich tue mir das nicht mehr an. Ludger hat es erst kürzlich sehr erfolgreich gemacht.

Ich gebe mich (vorerst) damit zufrieden:

Letzte Messung Pindom
Letzte Messung Pindom

Hier noch wie versprochen der Inhalt meiner .htaccess-Datei:

[symple_toggle title=“.htaccess“ state=“closed“]AddHandler php70-cgi .php

RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} !FeedBurner [NC]
RewriteCond %{HTTP_USER_AGENT} !FeedValidator [NC]
RewriteRule ^feed/?([_0-9a-z-]+)?/?$ http://feeds.feedburner.com/NetzexilRssFeed [R=302,NC,L]

php_value memory_limit 512M
php_value post_max_size 32M
php_value upload_max_filesize 32M
php_value max_execution_time 300
php_value max_input_time 300
php_value session.gc_maxlifetime 86400

ExpiresActive On
ExpiresDefault „access plus 1 days“
ExpiresByType text/html „access plus 5 minutes“
ExpiresByType text/xml „access plus 6 hours“
ExpiresByType text/css „access plus 1 weeks“
ExpiresByType text/javascript „access plus 1 weeks“
ExpiresByType application/javascript „access plus 1 weeks“
ExpiresByType application/x-javascript „access plus 1 weeks“
ExpiresByType text/ecmascript „access plus 1 weeks“
ExpiresByType image/gif „access plus 1 years“
ExpiresByType image/png „access plus 1 years“
ExpiresByType image/jpeg „access plus 1 years“
ExpiresByType image/ico „access plus 1 years“
ExpiresByType image/icon „access plus 1 years“
ExpiresByType image/x-icon „access plus 1 years“
ExpiresByType video/x-flv „access plus 1 years“
ExpiresByType video/quicktime „access plus 1 years“
ExpiresByType application/x-shockwave-flash „access plus 1 years“
ExpiresByType application/pdf „access plus 1 years“

# gzip Compression if availiable
AddEncoding gzip .gzip

AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/x-shockwave-flash

# Add correct content-type for fonts
AddType application/vnd.ms-fontobject .eot
AddType font/ttf .ttf
AddType font/otf .otf
AddType font/x-woff .woff
AddType image/svg+xml .svg
# Compress compressible fonts
AddOutputFilterByType DEFLATE font/ttf font/otf image/svg+xml
# Add a far future Expires header for fonts
ExpiresByType application/vnd.ms-fontobject „access plus 1 year“
ExpiresByType font/ttf „access plus 1 year“
ExpiresByType font/otf „access plus 1 year“
ExpiresByType font/x-woff „access plus 1 year“
ExpiresByType image/svg+xml „access plus 1 year“
# Begin WordPress

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

#End WordPress
#EWWW IMAGE Optimizer

RewriteEngine On
RewriteCond %{HTTP_ACCEPT} image/webp
RewriteCond %{REQUEST_FILENAME} (.*)\.(jpe?g|png)$
RewriteCond %{REQUEST_FILENAME}\.webp -f
RewriteRule (.+)\.(jpe?g|png)$ %{REQUEST_FILENAME}.webp [T=image/webp,E=accept:1]

Header append Vary Accept env=REDIRECT_accept

AddType image/webp .webp
#EWWW IMAGE Optimizer
# BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

[/symple_toggle]

WordPress und das Speicherlimit

Die letzten 2 Tage hatte ich gut mit meiner WordPress-Installation zu tun. Es begann mit einer Fehlermeldung, die eigentlich nicht sonderlich aufregend ist.

Blogger, die ihren Blog selbst hosten, wissen, dass das Fehlen spezifischer Einträge in der wp-config.php oder .htaccess wie define('WP_MEMORY_LIMIT', '96M'); bzw. php_value memory_limit 96M zu unschönen Fehlermeldungen führen kann. In diesem Fall erschien sie nur im Backend.

*Fatal error*: Allowed memory size of 268435456
bytes exhausted (tried to allocate 16948561 bytes) in
*/www/htdocs/w00f1b59/qb/wp-includes/wp-db.php* on line *1092*

Eigentlich nichts, was man nicht schnell durch ein bisschen Googeln lösen könnte.

Viele geben WordPress etwas mehr „Spielraum“ und setzen den Wert nicht auf 96M oder 128M sondern auf 256M. Mit diesem Speicherlimit sollte WordPress eigentlich klar kommen.

Änderungen ohne Erfolg

Die Änderungen des Speichers brachte jedoch keine Besserung.

So habe ich das Theme getauscht, alle Plugins ausgeschaltet und einzeln wieder aktiviert, um zu sehen, ob vielleicht eines der eingesetzten Plugins der Übeltäter wäre. Auch diese Maßnahmen führten nicht zum Erfolg.

Was löst den Fehler aus?

Hier läuft die aktuelle Version von WordPress. Alle Plugins und Themes sind auf dem neusten Stand!

Die Fehlermeldung war auch nicht ohne Weiteres reproduzierbar. Sie trat zuverlässig nur dann auf, wenn ich ein neues Plugin installieren wollte. Nicht, wenn ein bereits vorher installiertes nur aktiviert wurde. Zusätzlich konnte ich den Menüpunkt „Design anpassen“ im Backend nicht mehr aufrufen, ohne, dass die Fehlermeldung erschien.

Letzten Endes musste ich also den Support meines Hosters einschalten. Alleine kam ich nicht weiter.

24 Stunden hat es gedauert

Erst gestern Abend erhielt ich die Antwort, die das Problem (vorläufig) gelöst hat.

WordPress enthält im Ordner wp-include eine Datei namens wp-includes/default-constants.php. Darin befindet sich der Eintrag:

if ( ! defined( 'WP_MAX_MEMORY_LIMIT' ) ) {
define( 'WP_MAX_MEMORY_LIMIT', '256M' );
}

Somit wurden meine Einträge in der .htaccess ignoriert,  Änderungen in .htaccess oder wp-config.php also nicht wirksam!

Nachdem dieser Eintrag von 256M auf 512M geändert war, gab WordPress Ruhe.

Ich habe alle Plugins getestet. Es ist nicht festzustellen, dass eines übermäßig viel Speicher frisst oder diesen nicht ordnungsgemäß wieder freigibt. Vielleicht liegt es in meinem Fall an einer Backup-Routine, die täglich läuft. Die Datenmenge ist inzwischen ziemlich groß.

Vielleicht erspart mein kleiner Artikel anderen Blogger ja die lange Suche nach einem möglichen Fehlergrund.

Brauchen wir Blogparaden zur Inspiration?

Was ist das Beste am Bloggen? In einem Fotoblog habe ich mal gelesen, der Autor habe das Fotografieren als Chance begriffen, seine Kreativität auszuleben.

Mir hat die Beschreibung gefallen. Ich fände es schön, wenn das Bloggen genauso verstanden werden könnte. Schließlich hat nicht jeder das Talent zum Malen, Komponieren oder die Begabung literarische Spitzenleistungen abzuliefern. Deutet nicht die Vielfältigkeit unserer Blogsphäre daraufhin, dass diese Vorstellung wirklich passen könnte?

Es gibt irre viele Blogs, die sich erkennbar kein bisschen an dem orientieren, was uns die unzähligen Ratgeber zum Bloggen zu vermitteln versuchen. Zum Beispiel so etwas: Mach bloß nicht diesen oder jenen Fehler. Denk immer daran, dass deine LeserInnen einen Mehrwert erwarten, wenn sie deinen Blog besuchen. Mir gefällt es, den eigenen Kopf zu haben und sich diesen gebetsmühlenartig wiederholten Blogtipps zu widersetzen. Für mich kann Bloggen ruhig ein bisschen anarchisch angehaucht sein.

Das heißt ja nicht, dass Blogger sich nicht über Erfolge freuen. Erfolg wird allerdings oft auch ganz unterschiedlich empfunden – ob es nun viele Kommentare sind oder eine hohe Zahl von Shares in den sozialen Netzwerken. Manche Blogger freuen sich über ihre „Schlagzahl“ und achten nach eigenem Bekunden wenig darauf, welche Reaktionen sie auslösen. Das kann ich persönlich zwar nicht so richtig glauben. Aber gehört habe ich auch das schon.

Das Resultat der eigenen Arbeit sollte sich jedenfalls organisch entwickeln. Nicht, weil man partout darauf gepolt ist, „erfolgreich zu bloggen“.

Webmasterfriday „Blogparaden“

Martin setzt zum dieswöchigen Webmasterfriday das Thema: „Blogparaden“. Sicher, wie Martin auch in seinem Artikel zu diesem Thema geschrieben hat, ist der Webmasterfriday auch eine Art Blogparade.

Ich sehe im Webmasterfriday längst eine Institution in der deutschen Bloggerlandschaft, die ich ungern missen würde. Von den wöchentlichen Beiträgen, deren Themen vorgegeben werden, können die TeilnehmerInnen jedenfalls nur profitieren. So sehe ich das auch heute immer noch.

Aus meiner Sicht ist das ein Pfund, mit dem Blogparaden einfach nicht oft wuchern können. Das soll nicht heißen, dass die dort gesetzten Themen nicht ebenfalls interessant wären.

Inzwischen gibt es einige Blogs, die es sich zur Aufgabe gemacht haben, neue Blogparaden zu promoten, damit die Bemühungen der jeweiligen Blogger nicht verpuffen. Die Reichweite des veranstalteten Blogs spielt auch in solchen Fällen eine große Rolle.

Es wird so sein, dass Blogs durch gut geplante und unter Umständen sogar mit Incentives versehene Blogparaden erfolgreich durchführen werden. Mir behagt das Konzept der Blogparade nicht so ganz. Dabei nehme ich den Webmasterfriday aus den genannten Gründen ausdrücklich aus. Keine Regel ohne Ausnahmen. :-)

Ich habe in den vielen Jahren, in denen ich als Blogger unterwegs bin, nur an ganz wenigen Blogparaden teilgenommen. Nicht, dass mich die Themen überhaupt nicht interessiert hätten. Im Gegenteil, ich habe viele verfolgt und die Beiträge der anderen Blogger manchmal sehr gern gelesen und (selten) kommentiert.

Auf die Gefahr hin, dass ich mich mit meiner Meinung in die Nesseln setze. Ich ziehe persönlich vor, mir meine Themen für meinen! Blog selbst zu suchen und mag es nicht, wenn ich mich in ein Korsett zwängen muss. Ob es nun eine Terminsetzung ist oder die manchmal total durchdeklinierten, ziemlich genauen Vorgaben.

Meine Überzeugung ist die, dass wir Blogger unsere Themen allein finden und umsetzen sollten.

Das hat nichts damit zu tun, dass wir uns nicht gegenseitig helfen sollten. Auch mit Artikeln zu spezifischen Themen rund ums Bloggen oder damit im Zusammenhang stehenden technischen Aufgaben.

Ich hoffe, ihr verzeiht mir die etwas kritische Meinung zu Blogparaden.

Performance ein wenig verbessert

Manche meiner Versuche, die Performance des Blogs etwas zu verbessern, musste ich wieder zurückdrehen, weil sie unerwünschte Nebenwirkungen erzeugt haben (Minify bzw. .htaccess-Experimente).

Andere verfehlten dafür ihre Wirkung nicht. Insgesamt kann ich sagen, bin ich mit den Ergebnissen der „Messungen“ nun ganz zufrieden.

Am Design (Template x-Theme von themeforest.net) des Blogs habe ich auch einige Dinge geändert. Das führte ebenfalls zu einem kleinen Performanceschub. Die Zahl der Sidebar- und Footerwidgets habe ich auf die erforderlichen Dinge reduziert. Ansonsten laufen hier insgesamt immerhin 21 Plugins, darunter Cachify, Antispam Bee und WPSeo von Sergej Müller.

2015-03-13_19h38_07
http://gtmetrix.com/
http://tools.pingdom.com/fpt/

 

Webmastertools (Google)

 

Webmastertools (Google)

Workaround: Fotos vor der Übernahme in den Blog ordentlich komprimieren

Pixabay ist ein wunderbares Angebot. Viele setzen auf diesen Dienst und verwenden deshalb natürlich auch das WordPress – Plugin „Pixabay Images„.

Ich benutze meistens keine kleine Auflösung und habe wenig darauf geachtet, dass die von mir bevorzugten Bildergrößen schon ein paar Kb schwer sind. Die Ladezeit wurde dadurch nicht besser und einschlägige Website Speed-Tests belegen dieses Defizit.

Ich finde es deshalb schade, dass in ein Plugin wie „Pixabay Images“ nicht von vornherein auch Kommpressionsoptionen vorgesehen (eingebaut) sind. Das wäre vielleicht eine Marktlücke? Aber ich weiß nicht, wie aufwendig solche Programmierungen sind und ob sich das technisch so ohne weiteres lösen lässt.

Seit kurzem habe ich mir angewöhnt, jedes eingesetzte Foto einmal zu komprimieren. Dazu nutze ich die Website „TinyPNG„. Die Kompressionsraten sind gut, ich spare so etliche Prozente gegenüber der ursprünglichen Datei.

Komprimierung mit Tinypng

Ich finde es merkwürdig, dass auf diese Art und Weise eine bessere Kompression ermöglicht wird als beim Einsatz der einschlägig bekannten und autonom laufenden WordPress-Plugins (wie Optimus, WP Smushit oder EWWW Image Optimizer).

Vielleicht habe ich diese Plugins nicht optimal konfiguriert, aber Kompressionsraten wie die, die über die Online-Lösung (s. Link) erzielen werden, konnte ich so nie erreichen. Es gibt viele weitere Tools, die für diesen Zweck genutzt werden können, wie beispielsweise das kostenlose Tool Compressor.io.

Solange ich nichts besseres finde, werde ich die Bilder weiterhin von Pixabay downloaden und diese via Drag and Drop in das Verarbeitungsfenster von TinyPGN ziehen:

Dieser Umweg lohnt sich letztlich, vergleicht mal die Bildgrößen.

Größe 1
Größe 1

 

Das ist jetzt keine große Geschichte, aber vielleicht könnt ihr mit meinem kleinen Workaround etwas anfangen? Eine gute Bildkomprimierung ist ja nicht zu verachten. Auch diese Methode bringt bei den Geschwindigkeitstests für den Blog bessere Resultate, als wenn man die Bilder unkomprimiert übernimmt.

Mein Beitragsfoto, das ich von Pixabay heruntergeladen habe, ist jetzt 66% leichter:

Update:
Fast hätte ich eine wichtige Sache vergessen. Ich nutze als Browser Google Chrome und verwende das Plugin Downloadr (Download Manager). Damit bekommt man alle heruntergeladen Fotos in dieser Form angezeigt und kann sie (wie gesagt) per Drag and Drop komprimieren oder auch gleich ins WordPress-Fenster ziehen.