Kommentare zu: Caching in WordPress: Jenseits des Optimierungs-Wahns – Wie man WordPress wirklich schneller macht

Von: [Linktipps] Jede Menge Tipps für eine bessere Blog-Performance

[Linktipps] Jede Menge Tipps für eine bessere Blog-Performance — Sun, 10 Jan 2010 17:02:58 +0000

[...] gunnart oder auch auf t3n wurden die in WordPress eingebaute Caching Funktion oder aber auch andere Cache-Plugins [...]

Von: Google-Feature Page Speed | Internet und Webpromotion

Google-Feature Page Speed | Internet und Webpromotion — Fri, 18 Dec 2009 17:38:22 +0000

[...] t3n mit einem Post über unsichtbare Speed-Bremsen in CMS [...]

Von: domingos

domingos — Fri, 18 Dec 2009 12:43:50 +0000

Überflüssige Pugins abschalten, Datenbank regelmäßig optimieren, überflüssige Entwürfe löschen, WP-eigenen Cache einschalten, Fotos webgerecht komprimieren, Datenbank-eigenen Cache aktvieren, man kann alles mögliche tun, ob das für ein prvates Blog mit 30 Bescuhern pro Tag sinnvoll ist, ist aber eine andere Frage.

Von: Hannes

Hannes — Fri, 18 Dec 2009 09:21:50 +0000

@aba
wie gesagt, lässt sich ja alles mit Hilfe von ‘remove_action(‘wp_head’, ‘wp_print_head_scripts’,9,0);’ entfernen, und falls die scripts a andere hooks gehangen werden muss man leider n dump des action stacks machen und dann mit trial and error vorgehen… ärgerlich ist es nur wenn Plugins Sachen nicht über die hooks einbinden sondern über dne Output Buffer, son Plugin würde aber auch sofoer deaktiviert gehören ;)

Von: aba

aba — Thu, 17 Dec 2009 19:32:22 +0000

@sergej.
voellig richtig. dennoch finde ich einerseits die option natuerlich gut.
aber du hast recht: die ursache ist damit nicht “bekaempft”. mir graut es immer, wenn ich mir mit z.b. page analyze anschaue, wieviele zig javascript und kram und zeug geladen werden, die teilweise ja nichtmal auf allen seiten benoetigt werden…

Von: dongorgon

dongorgon — Thu, 17 Dec 2009 16:14:33 +0000

^^ So sieht’s einfach mal aus. Alles lame ausser Mutti + W3 Totalcache ;-)

Kann Hans da nur voll zustimmen

Von: Hannes

Hannes — Thu, 17 Dec 2009 10:46:15 +0000

Kann nur zustimmen, meiner Erfahrung nach ist zur Zeit W3TC das Caching Tool der Wahl, und zwar nicht nur in der Not – einfach zu handhaben und sehr gut skalierbar auf Grund der vielfältigen (aber nicht überladenen) Konfigurations-Möglichkeiten und verschiedenen Caching Backends (APC, Memcached, DB, File …) Und der Entwickler reagiert auch recht fix auf Anfragen, sehr schön! War schon n bisschen schockiert das es in der Auflistung hier gefehlt hat.

Des weiteren ist es meiner Erfahrung nach auch nicht verkehrt sich ab und zu mal an zu sehen was WordPress und diverse Plugins der Meinung sind in den header / footer werfen zu müssen, so lassen sich zum Beispiel eingebundene Scripts mit ‘remove_action(‘wp_head’, ‘wp_print_head_scripts’,9,0);’ in der functions.php des Templates entfernen (wenn man zum Beispiel wie ich lieber alle scripts minified im Footer und die JS Libary über google einbindet).

Von: sergej.mueller

sergej.mueller — Thu, 17 Dec 2009 08:21:09 +0000

@aba
Auch ein CDN bringt nichts, wenn jedes Plugin auf eigenes JS-Framework aufbaut und es in jede Blogseite “hard” einbindet.

Von: aba

aba — Wed, 16 Dec 2009 23:35:15 +0000

ich kann peter (#9) nur zustimmen: w3 total cache ist eine feine sache, zumal es auch cdn unterstuetzt.

Von: delicious Links: 16. December 2009

delicious Links: 16. December 2009 — Wed, 16 Dec 2009 23:01:53 +0000

[...] Caching in WordPress: Jenseits des Optimierungs-Wahns – Wie man WordPress wirklich schneller macht… Viele mögen jetzt sagen, dass sie ja zum Beispiel nicht auf jeder Seite ein Youtube-Video eingebunden haben, ergo das Plugin ja auch nicht auf jeder Seite ausgeführt wird. Diese Annahme ist falsch. Installiere ich in WordPress 20 Plugins, die allesamt den Content beeinflussen, dann werden bei jedem Seitenaufruf auch alle 20 Plugins ausgeführt. In unserem Beispiel wird das Youtube-Plugin also auch dann ausgeführt, wenn die Seite kein Youtube-Video enthält. Je mehr Plugins ich demnach installiere, desto mehr Aufrufe pro Seite verarbeitet WordPress. Das ganze Dilemma wird dann klar wenn man davon ausgeht, dass ein Plugin nicht nur einen Filter auf den Content anwendet, sondern parallel dazu auch Settings aus der Datenbank auslesen muss. Man könnte jetzt anmerken, dass logischerweise die Plugins erst dann die Datenbank verwenden müssen, wenn sie auch wirklich verwendet werden. Dies ist soweit richtig, setzt aber auch voraus, dass der jeweilige Programmierer überhaupt so weit mitgedacht hat Tags: wordpress speed cache caching plugins plugin [...]