Da es recht ungewöhnlich ist, dass du allen Optimierungsmaßnahmen zum Trotz nicht über einen Pagespeed-Wert von 66 Punkten kommst, habe ich mich schon gefragt, wo die .htaccess bei dir liegt. Du hast die schon im gleichen Verzeichnis wie die index.php und wp-config.php deines Blogs?
Natürlich kannst du diverse Plugins durchprobieren, wobei die eigentlich nichts anderes machen sollten.
Bei mir ist es so, dass ich ein Webhosting-Paket gebucht habe und dort mehrere WordPress-Blogs laufen lasse, dass heißt jede Website hat einen eigenen Ordner und dort habe ich jeweils WordPress installiert. Stellt das ein Problem dar?
Aber die .htaccess Datei von meiner Hochdruckreiniger-Seite liegt im gleichen Ordner wie die wp-config. Also sollte es eigentlich laufen.
So, ich habe mir das Plugin Autoptimize installiert und es zeigen sich erste Erfolge: Zumindest hat sich der PageSpeed schon mal etwas verbessert.
Mein Ziel lag bei einem PageSpeed von 80, ist der vielleicht durch weitere Maßnahmen noch zu erreichen?
Diese htaccess-Anweisungen sind ja in If-Abfragen gekapselt. Sie werden also nur ausgeführt, wenn das Modul auch vorhanden ist.
Im Zweifel mal den Hoster fragen, was möglich ist.
GZIP ist auf jeden Fall aktiv:
http://www.whatsmyip.org/http-compression-test/
Aber diese Tests checken nur, ob die Seite selbst GZIP ausgeliefert wird. Und nicht, ob das auch für alle Komponenten (Skripte, CSS, etc.) passiert.
In Firebug (Firefox-Addon) oder anderen Entwickler-Tools, lässt sich über den Netzwerk-Reiter anschauen, was die einzelnen Elemente für einen Statuscode haben. Bei aktiviertem Browser-Cache sollte nicht 200 OK, sondern 304 Not modified stehen.
Gruß, Torsten
Letztendlich ist Pagespeed auch keine Sportart, bei der man Medaillen sammeln kann. Die Verwendung eines CDN für eine kleine Website/Blog halte ich für überzogen. Yahoos Yslow unterscheidet deshalb auch zwischen industriell genutzten Websites und kleinen Blogs. Insgesamt zählt auch mehr, ob die Webseiten in einer gescheiten Zeit ausgeliefert werden (oder der Anwender abspringt, wenn nach 5 Sekunden immer noch nichts angezeigt wird).
Wenn du „das Notwendige“ getan hast, würde ich mehr Aufwand bei den Inhalten betreiben. 🙂
Ich habe soeben beim Webhoster nachgefragt. Dieser teilte mir mit, dass sie mir dies für meinen Tarif nicht zur Verfügung stellen können. (Ich müsste meinen Tarif upgraden.)
In der Tat habe ich einen sehr günstigen Tarif und überlege ein Upgrade vorzunehmen.
Gibt es denn andere Möglichkeiten (außer GZIP) CSS und Javascript-Dateien zu komprimieren? Ansonsten werde ich wohl meinen Tarif aufstocken. Ist jetzt auch nicht so wahnsinnig teuer 😉
<loriot>Ah ja.</loriot> 🙂
Das Stylesheet kann man komprimieren (z.B. online bei http://cssminifier.com/). Die komprimierte Datei (ich habe sie nachfolgend style.min.css genannt) enthält keine Kommentare und muss im Theme-Verzeichnis abgelegt werden. Anschließend bindest du das Stylesheet mit folgenden Zeilen in der functions.php ein:
add_action( 'wp_enqueue_scripts', 'theme_enqueue_styles' );
function theme_enqueue_styles() {
wp_enqueue_style( 'theme-style', get_stylesheet_directory_uri() . '/style.min.css' );
}
Damit wird das Stylesheet komprimiert übertragen.
Dabei sind noch zwei Dinge anzumerken:
1.) die style.css enthält den Theme-Header – einen Kommentar mit Angaben über das Theme. Ohne diese Angaben funktioniert dein Theme nicht mehr. Du musst also ein unkomprimiertes style.css mit dem Header behalten. Die Style-Regeln nach dem Kommentar kannst du dann aber löschen; sie erscheinen ja in dem komprimierten Stylesheet.
2.) Besser wäre es, hierfür ein Child-Theme anzulegen, da ansonsten deine Änderungen an Stylesheet und functions.php beim nächsten Update verloren gehen.
Bei besonders großen Stylesheets, die mehrere hundert Zeilen Code enthalten, kann das schon sinnvoll sein. Noch wichtiger: Nicht am falschen Ende sparen. Wenn zuviele Kunden auf einem Shared Host bedient werden müssen, verlangsamt das die Seite mehr, als du mit noch so viel Performanceoptimierung rausholen kannst.
@bego: Wäre das nicht eher „minifizieren“ und komprimieren dann so etwas wie GZip/Deflate? Überlege gerade ob das im Englischen überhaupt so trennscharf ist, wenn von „compress“ gesprochen wird …
@torsten: Völlig korrekt, hier geht es nur darum, etwas „Luft“ rauszulassen, in dem man unnötige Leerschritte und Zeilenumbrüche sowie Kommentare löscht. GZip erzielt sicher eine stärkere Reduktion des Datentransfers. Aber was nicht geht, geht nun mal nicht.
Übrigens hatte ich vergessen zu erwähnen, dass man auch die JavaScript-Dateien minimieren kann – eine Option, die auch von W3 Total Cache mit angeboten wird … und meine Webseiten regelmäßig unbrauchbar gemacht hat.
Aber vorher gibt es so viele andere Möglichkeiten, wo man mit der Performance-Optimierung anfangen kann: Wie groß müssen Bild-Dateien sein? Welche Kompressionsraten sind qualitativ vertretbar? Können EXIF-Daten entfernt werden? Kann ich Sprites verwenden? Kann ich Hintergrund-Gradienten mit CSS darstellen? Brauche ich so viele zusätzliche Webfonts? Enthält mein Stylesheet ungenutzte Regeln? Lässt sich das Stylesheet effizienter schreiben? …
PS: Sorry für die sprachlich unkorrekte Ausdrucksweise. Ich hätte „minimieren“ statt „komprimieren“ schreiben sollen.
War nicht böse gemeint! Ging eher ums sprachliche Fachsimpeln…
Bei einem der letzten Meetups hatten wir einen Fotografen, der uns den Hinweis gab, dass es womöglich rechtlich untersagt sein kann, die Metadaten eines Bildes zu entfernen, denn auch darin können Copyright-Informationen stehen, die man dann löscht. Ein Problem, dass ich vorher nie gesehen habe.
Gruß, Torsten
Sooo, nachdem ich mein Webhosting-Paket erweitert habe, sieht es so aus als ob die Anpassungen in der .htaccess (GZIP) endlich richtig funktionieren:
http://www.myimg.de/?img=screenshoteb0dc.png
Danke für eure Hilfe! 😉 Mit dem Ergebnis bin ich sehr zufrieden.
