sehr schöne Idee und Lösung.

Kleine Anmerkung, weil du es erwünschst: Die Funktion auslagern und add_action abfragen. Eventuell würde ich noch prüfen, ob die gzip-Funktion von WP vorhanden ist, falls es wieder rein kommt und man das Deaktivieren vergisst. Aber nur als i-Tüpfelchen.

Danke fürs Feedback, Frank.

Die Funktion könnte man auslagern, aber so ist es schön in einem Funktionsaufruf verpackt (create_function ist seit PHP 5 rasant).

Wenn die Komprimierung wieder reinkommt und der Nutzer diese aktiviert, so sollte die Abfrage ob_get_length dies erkennen und die Kompression durch das Plugin unterbinden.

seit PHP 5 rasant klingt gut und muss ich mir merken.
Danke für die Aufklärung und wieder lernt man dazu.

vielleicht interessant: http://comox.textdrive.com/pipermail/wp-testers/2008-March/007035.html

Merci für den Hinweis.
Ich bin auch der Meinung, dass die Kompression dem Server überlassen werden soll: Apache macht es deutlich performanter. Aber wie ich im Artikel oben schrieb, gibt es Hosting-Pakete mit eingeschränktem Zugriff auf Servereinstellungen – da ist das Plugin dran und bringt WordPress die Komprimierung wieder bei.

meine aktuelle index.php im root:
<?php
/* Short and sweet */

define(‘WP_USE_THEMES’, true);
ob_start(‘ob_gzhandler’);
require(‘./wp-blog-header.php’);
ob_end_flush();
?>

Was hälst du davon. Messe mit YSlow Empty Cache - 40K und Primed Cache - 30K gegenüber der Standard-index.php

Mit dieser Lösung bekomme ich auf einfache weise einen Geschwindigkeitsschub.
Was das Plugin nicht überflüssig macht, nur mal als Idee.

Ich bin großer Freund vom Caching – ich cache alles mögliche und überall. Schau, hier im Blog kommen sogar CSS- und JavaScript-Dateien komprimiert beim Browser an.

Deine Lösung ist gut, aber wie du schon heute sagtest, in Form eines Plugins sind solche Ansätze besser aufgehoben. Achja, in meinem Plugin kann ebenfalls die Stufe der Komprimierung eingestellt werden – da spielt man idealerweise ein wenig mit dem Wert (Zeit für Komprimierung gegen Ausgabegröße -> 6 ist in den meisten Fällen die goldene Mitte).

erzeugst du die Komprimierung schon als Ablage, oder dynamisch, wenn es geladen wird?
Ich hatte bisher CSS nicht komprimiert um schnell via WP im Editor zugreifen zu können.

Bei meinen Projekten werden 2 Arten an Komprimierung angewendet:

• Nach der Fertigstellung des Projekts werden JS- und CSS manuell durch den JavaScript-Compressor gejagt. Das Original bleibt natürlich für weitere Anpassungen unberührt. Könnte man auch dynamisch beim Laden der Dateien erledigen, kostet aber Zeit und Server-Performance.
• Zunächst kommt die automatische gzip-Kompression, die ich in der .htaccess veranlasse (für Apache 2):

  <FilesMatch "\.(js|css)$">
    SetOutputFilter DEFLATE
  </FilesMatch>
  

Ich hatte mit folgendem Syntax gespielt, aber nicht wirklich Verbesserungen gemessen.

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP:Accept-Encoding} .*gzip.*
RewriteRule ^js/(.*)\.js$ /js/$1.js.gz [L]
RewriteRule ^/(.*)\.css$ /$1.css.gz [L]
AddEncoding x-gzip text.gz


Dein obiger Code ist in der .htaccess des root?

Ja, im Root-Verzeichnis. Eine einwandfreie Funktionalität hängt von vielen Faktoren ab, z.B. das Modul (DEFLATE aus meinem Beispiel) muss auf dem Server installiert sein; auch .htaccess muss solche Befehle absetzen dürfen, im anderen Fall werden diese ignoriert.

Dazu findet man im Netz ganze Menge, abhängig von der jeweiligen Serverkonfiguration.

Danke !

Ich habe verschieden Wege mal zum Testen durchgespielt, Plugins etc. und gemessen mit YSlow. Fazit: Handarbeit ist die beste Methode, was du mir also bestätigst. Es ist wie mit vielen Themen, die Arbeit kann man doch nicht auslagern ;-) .

Sonst hätten wir Entwickler nichts zu tun :)

Tja… es funktionierte eine Zeit lang gut bis es dann auf einmal den WYSIWYG-Editor blockierte :/

Auf einmal :)
Lass mich raten, nach der Aktualisierung auf WP 2.5.1?

Nein

Den WYSIWYG-Editor im Admin-Bereich oder? Denn das kann eigentlich nicht sein, da seit der Version 0.2 werden die Seiten aus der Area übersprungen…

Geht trotzdem nicht..
habs nochmal runtergeladen und aktiviert -> nur HTML-Editor möglich :(

Habe das Plugin erweitert, lade noch mal runter und berichte bitte.

Funktioniert, danke :D

Version 0.3 des Plugins ist nun offiziell online. Danke an Manuel für den Fehlerhinweis.

kein problem
übrigens, wie kann ich nachprüfen das es funktioniert (siehe dein screen wo da gzip steht)

Mit Firebug, Safari oder Online: http://www.gidnetwork.com/tools/gzip-test.php

Noch ein sehr hilfreiches WordPress-Plugin. Danke dafür!

Plugin installiert und aktiviert. Gzip Test Tool zeigt jedoch keine Kompremierung an. Wo kann ich Fehlersuche betreiben?

Das kann natürlich sein, dass dein Hoster keine Setzung von Werten mittels “ini_set” erlaubt.

Bei aktiviertem Plugin schmeisst Windows Live Writer zumindest bei mir reproduzierbar den Fehler: “Invalid response document returned from XmlRpc Server”. Compress deaktiviert und es geht wieder. Any ideas?

Windows Live Writer ist mir leider kein Begriff. Seit WordPress 2.5 läuft das Plugin auf jeder nur erdenklichen WordPress-Installation problemlos. Aber ist das komische Tool nicht dafür da, um als Administrator Beiträge zu verfassen? Denn eine Ausnahmeregel ist implementiert, die das Plugin nur im Nicht-Admin-Zustand ausführen lässt.

Ah, das wird es sein, danke für die Erklärung, das macht natürlich Sinn. Live Writer ist übrigens eines der beliebtesten Desktop-Blogging Tools unter Windows und das sag ich jetzt mal völlig wertfrei ;)

Hallo Sergej,
habe das Plug-In installiert (und auch aktiviert)
Finde aber nicht den Dialog für die manuelle Anpassung der Komprimierungsstufe. Ist der Dialog in v0.3 noch vorhanden – oder gucke ich nicht richtig?

@funkygog
Das geht zurzeit nur direkt im Quelltext des Plugins in der Zeile mit ini_set(“zlib.output_compression_level”, 6);. In der kommenden Version will ich diese Einstellung in die GUI rausholen.

Hallo Sergej,
ich habe den code oben in meine HTACCESS Datei eingetragen. Aber keine Änderung erfahren. Wie kann ich herausbekommen ob der Eintrag in der htaccess datei überhault ausgeführt und akzeptiert wird.

Übrigens: Trage ich den code ohne eine entsprechende if abfrage ( ) ein, gibt es eine Fehlermeldugn und die Webseit ist nicht erreichbar.

Danke Sergej,
der Screenshot oben hat mich in die Irre geführt.
Eigentlich wollte ich nur den Wert auf 6 setzen – aber der ist ja schon so
voreingestellt.

@funkygog
Ja, eine Sechs ist genau der richtige Wert und eine goldene Mitte zwischen der Komprimierung und der Serverauslastung.

@Stefan B.
Das sieht man im Browser wie Safari, im Firebug oder auf dieser Webseite.

Hey, ich nutze das Plugin schon eine Weile und habe jetzt mal meine Seiten durchgetestet.
Mit wurde auf http://j.mp/VRhnr immer angezeigt, dass gzip nicht aktiv bzw. nicht "compressed" ist, dann habe ich testweise mal dieses Plugin installiert http://j.mp/6J6aoF und es wurde angezeigt, dass gzip aktiviert ist.

Klappt da etwas mit einem Plugin nicht oder habe ich irgendwo einen Fehler gemacht?

Naja, im Raten bin ich echt schlecht, denn weder kenne ich deine Plugins, noch ist mir irgendeine Inkompatibilität bekannt. Am besten schaust du mit Firebug oder ähnlichen Tools. Sonst kann ich das auch für dich machen. Sag Bescheid, wenn du mein Plugin aktiviert hast, dann gebe ich dir gerne Feedback.

Hab dein Plugin aktiviert, wenn du mal schauen könntest wäre super. http://j.mp/14rtrc

In der Tat, da wird nichts komprimiert. Ich muss aber auch sagen, dass mein Plugin deutlich strikter mit den Server-Einstellungen umgeht. Das kann schon sein, dass eine vom Server festgelegte Direktive vom Plugin nicht verwendet werden kann – ich denke dabei an die Komprimierungsstufe, die man im Plugin feiner und ausgewogener anpassen kann.

Aber wenn die andere Lösung das gewünschte Resultat ergibt (auch wenn ohne Komprimierungsgrad), dann bleib doch dabei. Der Weg nach Rom ist in diesem Fall nicht relevant.

Danke erstmal. [...] jetzt weiß ich natürlich nicht, ob das überhaupt etwas bringt, zumindest im Ladezeit-Check sehe ich keinen Unterschied.

Ich sagte ja, der Weg ist gleich – ob über das eine oder das andere Plugin. Auch meine Empfehlung “Firebug” ist nicht umsonst – da siehst du auch die komprimierte Größe, die tatsächlich über die Leitung geht.

Danke für deine Tipps, Firebug deprimiert mich so, habe einfach zu viel Javascripts, etc. :D

René, dann ist mein Artikel JavaScript-Dateien mit Google bündeln genau richtig für dich ;)

Wäre es nicht gut mit dem Plugin auch noch CSS und Scripte komprimieren bzw. die CSS zusammenfassen zu können?
Gibt ja solche Allrounder schon, aber auch ohne Coding-Kenntnisse, denke ich das es vllt. auch ressourcenschonender geht ^^

@Bichareh
Um Stylesheets und Skripte zu komprimieren und zusammenzufassen muss das Plugin enorm aufgestockt werden (Parsing, Caching etc.) – da ist die Fehlerquote sehr hoch. Da sich solche Dateien kaum ändern, macht eine manuelle Zusammenfassung und die Komprimierung in der .htaccess mehr Sinn. Setze ich selbst erfolgreich ein, habe dazu auch diverse Beiträge verfasst, z.B. JavaScript-Dateien mit Google bündeln.

Habe dein Plugin gerade entdeckt. Es funktioniert super. Klar kann man mit serverseitiger Komprimierung mehr anfangen, aber ich habe es auf meinem ROOT Server bis heute nicht geschafft DEFALTE oder GZIP als apache Modul einzubinden. Bis dahin nutze ich also sein Plugin sehr gerne. Habe so auf meiner Startseite den HTML-Anteil von 186kb auf 26kb reduzieren können.

Thank you so much for this amazing plugin!