WordPress: Gravatare cachen

86 Kommentare
WordPress: Gravatare cachen

Im Zuge der Serie Blog-Ladezeiten optimieren, geht es heute den Gravataren an den Kragen. Oftmals sind dies die kleinen Bösewichte, die bei den Artikelansichten die Ladezeiten in die Höhe treiben lassen, da sĂ€mtliche Gravater von gravatar.com geholt werden mĂŒssen. Ein Dienst wie das bereits vorgestellte pingdom-tools brint es dann auch an den Tag.

Oftmals sind die Gravatare sehr schnell da – doch es kommt auch sehr hĂ€ufig vor, dass der ein oder andere Gravatar mal “hĂ€ngt”. Außerdem gibt es eine gewisse AbhĂ€ngigkeit von der VerfĂŒgbarkeit des Gravatar-Servers.

Warum also die Gravatare nicht cachen?

Nun, die Idee ist ja nicht neu. Dazu gibt es mehrere Anleitungen und/ oder Plugins im Netz. Doch so richtig funktioniert hat nichts von alledem. Da erinnerte ich mich an Tanja, die mit Ihrem Cache-Skript so allerlei Anwendungsmöglichkeiten aufzeigte. Das Skript kann, in jeweils abgewandelter Form, fĂŒr zahlreiche Cache-Lösungen herangezogen werden. Man muss nur erfinderisch sein. Ob Ihr nun Widgets cachen wollt, “related Posts” oder den ganzen Kommentarbereich – hier seid Ihr richtig!

Jedenfalls hatten wir einen Dialog und wenige Tage spĂ€ter wandte sich Tanja per E-Mail an mich. Sie habe eine Gravatar-Cache-Lösung und ich solle es gleich ausprobieren. Das hat allerdings nicht auf Anhieb geklappt – in einem zweistĂŒndigen Telefonat haben “wir” es dann doch zum Laufen gebracht. Über die Hintergrunde werde ich nach Vorstellung des Skripts noch eingehen. Lest Euch zuerst alles durch, bevor Ihr anfangt. ;-)

Was bedeutet denn ĂŒberhaupt “Gravatar-Cache”?

Die Gravatare Eures Blogs, die anhand der E-Mail-Adresse der Kommentierenden von gravatar.com geholt werden, werden “gefangen” und auf Eurem eigenen Host (als Kopie) abgelegt. Im Standard-Zustand des nachfolgend vorgestellten Skriptes werden die Gravatare vier Wochen lang gecached. Das heißt: Ein einmal von gravatar.com geladener Gravatar in Eurem Blog wird fortan nicht mehr von gravatar.com , sondern von der Kopie auf Eurer Domain (Eurem Wenhoster) geholt. Ihr könnt Euch selbst davon ĂŒberzeugen: Je nach Browser kann dies in aller Regel per Klick mit der rechten Maustaste auf einen Gravatar in meinem Kommentarbereich ĂŒberprĂŒft werden. Im KontextmenĂŒ gibt es einen Eintrag “Grafikadresse kopieren” (Firefox), “Eigenschaften” (Internet Explorer 8), “Bild-Adresse kopieren (Opera)” oder “Bild-URL-kopieren” (Chrome 4).

Doch genug der langen Worte – schreiten wir zur Tat.

Gravatare cachen

1. Cache-Ordner anlegen

OrdnerstrukturIhr legt direkt in das Root (also in der obersten Ebene des ftp-Verzeichnisses) einen Ordner “z-cache” an. Darin legt Ihr einen weiteren Ordner “gravatar” an. Im gravatar-Ordner legt Ihr wiederum einen Ordner “images” an. Alle drei genannten Ordner bekommen die Rechte 777.

2. comments.php bearbeiten

Ihr sucht den Gravatar-Aufruf der Kommentarausgabe:

<?php echo get_avatar( $comment, 60); ?>

Dieser Aufruf sollte normalerweise in der comments.php Eures Themes stehen. Es kann jedoch auch vorkommen, dass Euer Theme etwas anders arbeitet. In meinem Fall befindet sich der Aufruf beispielsweise in der functions.php. Auch die GrĂ¶ĂŸe “60″ kann variieren. Möglicherweise kommen bei Euch Gravatare anderer GrĂ¶ĂŸe zum Einsatz (bei mir sind es 50x50px). Dazu gleich mehr. Wir fahren mit der comments.php fort – ich erinnere an die obligatorische Sicherungskopie!!!

Jedenfalls löscht Ihr die o.g. Zeile und setzt stattdessen folgenden Code ein:

<?php $teil = get_comment_author_email(); //1 Teil Cachefile
	$teil = strtolower  ($teil);
	$teil = md5($teil);
	$cachefile13 = "z-cache/gravatar/".$teil.".html";
	$cachetime13 = 40320 * 60; // 40320 = 4 Wochen
	if (file_exists($cachefile13) && (time() - $cachetime13 < filemtime($cachefile13))) {
		include($cachefile13);
		//$test = date('d.m.Y H:i', (filemtime($cachefile13) + $cachetime13));
		//echo "<!-- Cache vom ".date('j. F Y H:i', filemtime($cachefile13))." - naechster Update: $test-->";
	}
	else {
	ob_start(); ?>

		<?php $text = get_comment_author_email();
		$text = strtolower  ($text);
		$text = md5($text);
		$cachefile21 = "z-cache/gravatar/images/".$text.".png";
		$grav_img = "http://www.gravatar.com/avatar/".$text."?s=60&d=wavatar&r=G";

		ob_start();
		$fp = fopen($grav_img, "rb");
		fpassthru($fp);
		fclose($fp);
		$file = ob_get_contents();
		ob_end_clean();

		$fp = fopen($cachefile21, "wb+");
		fwrite($fp, $file);
		fclose($fp); ?>

		<img alt="" src="http://www.plerzelwupp.de/<?php echo $cachefile21;?>" height="60" width="60" />

		<?php //echo get_avatar( $comment, 60); ?>

	<?php $fp = fopen($cachefile13, 'w'); // Cache 2. Teil
	fwrite($fp, ob_get_contents());
	fclose($fp);
	ob_end_flush();
	} // Cache Endefile ?>
  • Wenn Ihr Gravatare anderer GrĂ¶ĂŸe verwendet, Ă€ndert Ihr die Zahl “60″ in den Zeilen 18, 31 (2x) und 33 entsprechend.
  • Die Webadresse in Zeile 31 mĂŒsste Ihr auf Euren Blog umstellen.
  • Die Zeilen 1-12 leiten den Cache ein, die Zeilen 35-39 schließen ihn wieder. In eventuellen Test-Szenarien löscht Ihr diese Zeilen und schaut, ob der Kern funktioniert. Beim ersten Aufruf einer Kommentarseite dauert die Ladezeit erheblich lĂ€nger – ein gutes Zeichen: das Cache-Skript macht seine Arbeit. Vergewissert Euch im FTP-Verzeichnis, ob die neu angelegten Ordner gefĂŒllt werden. PrĂŒft außerdem nach, ob die geladenen Gravatare tatsĂ€chlich “bei Euch gehostet” sind.

Das war’s auch schon. Ab sofort mĂŒssten Eure Gravatare gecached werden! Doch erinnert euch an meine Worte: Lest erst mal weiter – insbesondere, was die Funktion fopen() betrifft.

Workaround: Mögliche Fehlerquellen erkennen

Arbeitet das Skript noch nicht richtig?

Die beiden auskommentierten Zeilen 8 und 9 sind zu Testzwecken eingerichtet. Aktiviert diese Zeilen bei den ersten Aufrufen und setzt dabei zusĂ€tzlich die Zeit in Zeile 3 auf 1 (anstatt 40320). Vergewissert Euch, ob der Cache auch funktioniert, indem Ihr nun den Quelltext öffnet und nach “cache vom….” sucht. Da mĂŒsste nun die richtige Zeit stehen.

Wenn Ihr den Cache per FTP wieder löschen wollt, empfiehlt es sich, zuvor die Caching-Funktion zu deaktivieren: Durch Auskommentieren oder Löschen der o.g. Zeilen (1-12 und 35-39). Nach dem Löschen des Caches aktiviert Ihr diese Zeilen wieder.

Die Sache mit fopen(): Es kann sein, dass Euer Hoster diese Befehle nicht unterstĂŒtzt. Ob diese Funktionen bei Euch aktiviert sind erfahrt Ihr, wenn ich Euch eine kleine info.php bastelt. Dazu erstellt eine Textdatei mit folgendem Inhalt:

<?
phpinfo();
?>

Ihr speichert diese Datei dann unter info.php ab (aus die Dateiendung achten) und legt sie dann per ftp in Euer Heimverzeichnis. Mit dem Browser steuert Ihr diese Seite dann an – z.B. http://Eure-Domain/info.php

Dort sollten “allow_url_fopen” und “allow_url_include” Funktionen auf “on” stehen.

url_fopen

Bei mir war das zunĂ€chst nicht der Fall. Also wandte ich mich an den Kundensupport von 1&1. Nach erfreulich geringer Wartezeit erklĂ€rte mir ein kompetenter Mitarbeiter, dass diese Funktionen fĂŒr externe URLs standardmĂ€ĂŸig gesperrt ist. OK, soviel wusste ich auch. Ich wusste auch, dass diese Funktionen durch Bearbeitung der “php.ini” aktiviert werden können (bei mir war jedoch keine php.ini vorhanden – ‘dachte, ich kĂ€me nicht dran). Was ich aber nicht wusste: Bei meinem Hoster ist es erlaubt, solch eine php.ini zu erstellen. Der entsprechende Befehl zur Aktivierung der beiden Funktionen lautet:

allow_url_fopen=1
allow_url_include = on

Das Datei wird php.ini genannt und kommt sowohl in das Root, als auch in den Script-Ordner.

Wenn diese Funktionen bei Euch nicht unterstĂŒtzt werden lohnt es sich auszuprobieren, ob Ihr auch eine php.ini erstellen oder eine bereits vorhandene modifizieren könnt. Ansonsten lohnt sich ein Anruf beim Hoster. ErklĂ€rt den Mitarbeitern, was Ihr vorhabt und was Ihr mit den Funktionen machen wollt. Vielleicht sind sie gnĂ€dig. ;-)

Übrigens: Falls url_fopen nicht unterstĂŒtzt wird, merkt Ihr das auch, wenn statt denn Gravataren “fehlerhafte Bilder” angezeigt werden. Öffnet dazu eine der gecachten png-Dateien mit einem Texteditor (unter z-chache/gravatar/images). Dort mĂŒsste eine Fehlermeldung stehen – in der Art: Warning fopen(…Url….)…. failed to open stream: HTTP wrapper does not support writeable connections in … on line ……

Fazit

Die Ladezeiten der Artikel-Ansichten (mit Kommentaren) sind deutlich stabiler und schneller geworden. Kommt ein Besucher, dessen Gravatar bereits gecached ist, erhÀlt beim neuerlichen Kommentieren die Cache-Version seines Gravatars. Meines Erachtens ist dieses Skript eine glÀnzende ALternative zu einem entsprechenden Plugin.

Vielleicht hab ich Euch ein wenig auf den Geschmack gebracht? Habt Ihr schonmal die gravatar-Ladezeiten beobachtet? Euch mit diesem Thema schon beschÀftigt? Lust, das mal auszuprobieren? gerne gebe ich Hilfestellung.

Ich freue mich ĂŒber Eure Kommentare :-)

Nachtrag vom 16.02.2010

Jeffrey vom infoblog.li hat sich der Sache nun ebenfalls angenommen und das Skript noch erweitert bzw verfeinert. Die Gravatare können nun per Skript aktualisiert werden, was den Vorteil hat, das Alter der gecachten Gravatre nicht stĂ€ndig auslesen zu mĂŒssen.  Das Skript könnte dann (beispielsweise ĂŒber Nacht) per cronjob gestartet werden.  Jeffreys Beitrag ist hier zu lesen.

Schade nur, dass mein Hoster keine cronjobs zulÀsst :-( vielleicht gibt es in dieser Hinsicht VorschlÀge(?)

Artikel bewerten

Bewertung fĂŒr: WordPress: Gravatare cachen:
1 Stern2 Sterne3 Sterne4 Sterne5 Sterne
5,00 von 5 Sternen bei 1 abgegebenen Stimmen.
Loading...Loading...
  1. *wow* ein mega ausfĂŒhrlicher Artikel. So klappt es bestimmt bei anderen auch, danke :-)

    • plerzelwupp

      Tanja, ich hab zu danken. Die Lösung ist von dir.

      Jedoch hab ich mir MĂŒhe gegeben, das anschaulich darzustellen und die Probleme zu beschreiben, auf die wir gestoßen sind ;-)

  2. Klingt gut, werde ich mir die Tage mal durchlesen, wobei die Gravatare bei mir aktuell nur im Backend angezeigt werden, mein Theme verschluckt die leider.

    • plerzelwupp

      Herzlichen Dank.
      Zu Deinem Problem: Möglicherweise sind die Gravatare in deiner comments.php nicht integriert?
      Wie schaut’s denn da aus?

  3. Vielen Dank euch beiden fĂŒr die tolle Arbeit!

    Muss ich in den nÀchsten Tagen gleich ausprobieren.

    So wie es im Code aussieht, werden zu alte (>4 Wochen) Gravatare nicht mehr benutzt, doch werden diese abgelaufenen Bilder dann auch im Verzeichnis gelöscht ? Ich habe keine unlink Befehl gefunden :)

    • plerzelwupp

      Hey Jeffrey :-)

      Vielen Dank fĂŒr dein Lob und die anerkennenden Worte.

      Zu deiner Frage: Ehrlich gesagt bin ich da ĂŒberfragt, da ich nicht weiß, wie sich “cachetime” in diesem Zusammenhang auswirkt. Das interessiert mich nun aber auch. Werde ich jedenfalls abklĂ€ren. Auf hĂ€ndisches Löschen alle 4 Wochen wĂŒrde ich auch gerne verzichten wollen. ;-)

      • Das “alte” Bild hat ja den gleichen Namen wie ein neu geladenes, es wird quasi durch ĂŒberschreiben aufgefrischt…
        So mal schnell gedacht :-)

        Netter Code ansonsten. Muss mir nur noch ĂŒberlegen, ob ich wirklich url_fopen bei mir öffnen will :-)

      • Marc hat recht, die alten werden einfach ĂŒberschrieben ;-)
        Wer url_fopen nicht aktivieren will, kann es alternativ mit fread() oder curl versuchen. Da steh ich persönlich aber auf dem Schlauch (meine PHP Kenntnisse sind ja echt begrenzt). Es geht auch nur um den einen fopen(), der den Gravatar von gravatatr.com holt.

      • plerzelwupp

        @gregel und Tanja

        vielen Dank, dass Ihr hier in die Bresche gesprungen seid.

        Vielleicht ist es wirklich nicht ganz verkehrt, den Cache alle halbe Jahre mal vollkommen zu löschen. Dann erwischt’s auch die Besucher, die nur 1x da waren. Das dĂŒrfte genĂŒgen. Die einzelnen DateigrĂ¶ĂŸen sind ja recht gering.

    • Ich habe es nun auch bei mir im Blog eingebaut und es funktioniert wirklich zuverlĂ€ssig!

      Auch das Auslagern auf eine Subdomain ging recht gut :)

  4. Super Artikel, werde das die Tage evtl. mal umsetzen, mein WordPress hat von Ladezeiten-Optimierung noch nichts gehört. :)

    • plerzelwupp

      hallo Tarik,

      auch dir vielen Dank fĂŒr die RĂŒckmeldung.

      Ich war gerade mal auf deiner Seite, du Tiefstapler – die lĂ€uft doch sehr flott. ;-)

    • Eine andere Lösung, wenn auch nicht gut, ist die Deaktivierung Gravatar Plugins ĂŒberhaupt. Dies wird dazu beitragen, die Ladezeiten auf der Website, sowie drastisch reduzieren Website zu laden (wie jedes Mal jemand einen Kommentar macht, muss der Server eine Verbindung zu gravatar.com um das Avatar-Bild zu bekommen).

      Dies könnte fĂŒr einige langjĂ€hrige Benutzer beunruhigend, aber es ist besser, um die FunktionalitĂ€t im Austausch entfernen fĂŒr schnellere Ladezeiten.

      Dee

  5. Hallo Oliver,

    vielen Vielen Dank fĂŒr diese tolle Beschreibung und auch ich werde mich in diesen Tagen hinsetzen und das mal bei mir einbauen!

    Gruß
    Matthias

    • Bei Dir mĂŒsste es, genauso wie bei mir, ohne andere Servereinstellungen gehen ;-)

    • plerzelwupp

      Hey Matthias,

      danke fĂŒr Deine RĂŒckmeldung. Wenn ich mich recht erinnere, ist dein Blog auf Tanjas Empfehlung umgezogen(?) So interpretiere ich auch Tanjas Stellungnahme zur Servereinstellung.

      Demnach dĂŒrfte die Umstellung in weniger als 5 min erledigt sein. ;-)

    • Hallo Oliver, hallo Tanja,

      ja da hat Oliver wohl recht! ;-) Mit hat Tanja auch schon den einen oder anderen Nachmittag durchtelefoniert und ja mein Serverumzug ist ihr zu verdanken, fĂŒr den ich ihr heute noch dankbar bin!

      Gruß

  6. Ich versteh ja die Plugin-Phobie mancher nicht so ganz, aber jedem wie im beliebt ;) (wer eine aehnliche funktion lieber via plugin haben möchte: GravatarLocalCache dĂŒrfte hier weiterhelfen)

    Eine kleine Anmerkung zum Code:
    Warum noch n zweites mal “get_comment_author_email()” im else Zweig? der gewĂŒnschte Inhalt steht doch schon in $teil…

    und wer allow_url_fopen nicht mag, aber die curl extension hat kann den code z.B. mit dem funktionsschnipsel aus http://de.php.net/manual/de/function.file-get-contents.php (zu finden im kommentar von 3n1gm4) anpassen…

    • Das zweite könnte man theoretisch weglassen und das cachefile21 mit $teil zusammenbauen, da hast Du Recht. Den zweiten Teil habe ich als erstes geschrieben, um erst mal nur die Gravatare zu holen, dann den ersten Teil außen rum, um sie zu cachen.
      Plugins mögen wir nicht, da mit Ihnen der gesamte WordPress Core immer langsamer wird. Vieles davon muss man einfach auch nicht immer mitladen, sondern es hilft schon diese Funktionen nur an den richtigen Stellen auszufĂŒhren. WordPress selbst ist ohnehin schon super mies was die Performance betrifft. Aber das ist natĂŒrlich reine Geschmackssache ;-)
      Bei mir persönlich ist es so, dass ich durch meine dofollow Funktion, die weitaus mehr kann als jedes dofollow Plugin, sowieso meinen Kommentarbereich Cachen muss. Wo gehobelt wird fallen SpÀne und das geht nunmal nicht ohne Datenbankabfragen und damit auch bei mir nicht mehr ohne speziellen Cache an dieser Stelle.

    • plerzelwupp

      Hey Olli,

      ein Namensvetter – herzlich willkommen im Blog. :-)

      Wie ich sehe, steckst Du tiefer in der (php-)Materie als ich (der solche Codes zwar einigermaßen versteht, ansonsten nur “klauen” und modifizieren, aber nicht selbst erstellen kann).

      Nun könnte die Gegenfrage lauten: Und warum schreibst du dann darĂŒber?

      Nun, ich hab einfach Spaß am Experimentieren, komme nicht vom Fach. Es ist der reine Forschertrieb und ich berichte ĂŒber meine “Erfahrungen” – deshalb heißt der Blog auch so.

      Durch Dich hab ich nun weitere Erfahrungen gesammelt. Ich werde weiter forschen und weiter experimentieren. Danke fĂŒr den Link zum Kommentar. :-)

      Danke auch an Tanja fĂŒr die Stellungnahme :-)

    • Das ganze via curl ist eine nette Idee, daran werde ich mich einmal versuchen!
      Wenn es klappt, rufe ich ganz laut piep :-)

      Vielleicht sollte man noch das Gravatar-Verzeichnis via htaccess vor externem Zugriff schĂŒtzen. url_fopen muss kein Risiko sein – wenn man sich 100% sicher ist, was fĂŒr Skripte auf dem Webspace liegen… Aber sicher ist sicher :-)

      • plerzelwupp

        Das hoffe ich doch, dass du dann ganz laut “piep” rufst. Im Erfolgsfall hoffe ich dann auch, dass du mir nicht böse bist, wenn ich das hier nachpflege ;-)

      • @Tanja:
        Sicherlich, ein perfekter Codeschnipsel an der richtigen Stelle ist schneller als jedes Plugin, aber ein wenig optimierter eigener Schnipsel kann auch langsamer als ein entsprechend optimiertes Plugin sein und der Schnipsel muss an jeder entsprechenden Stelle selbst eingebaut werden (man mĂŒsste z.B. auch entsprechende Widgets anpassen). Und btw. mit n paar Optimierungen ist WordPress gar nicht so mies, was die Performance betrifft, da kenn ich noch schlimmere Kandidaten…

        @all:
        Man könnte hier natĂŒrlich ne ewig lange Pro-Contra-Liste erstellen, und beide Varianten haben ihre Vor- und Nachteile…

        Allgemein sollte man aber im Hinterkopf haben, das man Codeschnipsel auch “pflegen” muss (SicherheitslĂŒcken etc.) und da kann fremdes Know-How (Pluginentwickler) durchaus hilfreich sein (sprich es kĂŒmmert sich jemand drum, der Ahnung hat). Zumal man vll. nach dem Einbau von 40 Codeschnipseln irgendwann auch die Übersicht verliert…

      • Verbesserungsmöglichkeiten sind sicherlich ĂŒberall gegeben ;-)

        @Marc: Nur rĂŒber damit und ganz laut Schreien, wenn Du was zustande bekommst. Ich wĂŒrde mich freuen ;-)

  7. Danke fĂŒr den interessanten Artikel. Leider brauche ich diese Caching-Lösung bei mir erst ĂŒberhaupt nicht auszuprobieren, denn auf meinem Webspace ist zwar fopen aktivierbar und aktiviert, aber sind maximale Rechte 777 aus SicherheitsgrĂŒnden nicht erlaubt. :-(

    Das ist zwar schade, zumal man damit leider auch PHP Speedy nicht einsetzen kann. Aber es gibt ja noch Caching-Alternativen mit weniger extensiven Schreibrechten.

    • plerzelwupp

      Hallo Dieter,

      vielen Dank, dass Du Dir Zeit fĂŒr eine RĂŒckmeldung genommen hast :-)

      Dass die Schreibrechte nicht erlaubt sind, ist aber doof (da wĂŒrde ich dann doch lieber ohne fopen auskommen wollen). Es kommt ja öfter vor, dass man diese Schreibrechte benötigt (zumindest temporĂ€r).

      Nun – alles in allem ist es mit Spielerei verbunden. Klar geht’s auch ohne. Was man nicht hat, vermisst man auch nicht ;-)

    • Wenn php (via CGI/FCGI oder suPHP) eingebunden ist, und damit unter dem “eigentlichen” (also nicht einem allgemeinen/z.B. Webserverbenutzer) Benutzer lĂ€uft, reicht im Zweifelsfalle auch ein 700… 777 ist nur notwendig, wenn eben Zugriffe durch verschiedene Benutzer erfolgen muss… (Die Rechte verteilen sich ja wie folgt: Benutzer/Gruppe/Alle)

  8. Hmmmm, die Sache hat nur einen kleinen Haken: Es gibt ja Leute, die schon mal ihren Gravatar Ă€ndern und das wĂŒrde man dann ja gar nicht mehr mitbekommen.
    Ich Ă€nder meinen extrem selten, aber ich bin schonmal gefragt worden, warum man auf meinem Blog denn nicht den neuen Gravatar sehen wĂŒrde, sondern immer noch den alten. Okay, diese Person hatte vergessen im Bowser ihren Cache zu leeren, aber es zeigt mir, das es manchen scheinbar schon wichtig ist, dass dann auch ihr neuer Gravatar gezeigt wird…..

    • Das muss natĂŒrlich jeder fĂŒr sich entscheiden, ob ihm aktuelle Gravatare oder eine schnellere Ladedezeit lieber sind.

      Allenfalls kann man ja die “Cache-Ablauf-Zeit” (Zeile 4) verkleinern, sodass die Gravatare öfters aktualisiert werden.

    • plerzelwupp

      Ja patsy, da hast du vollkommen Recht. Wie Jeffrey schon sagt, muss das jeder fĂŒr sich entscheiden. Wenn die Gravatare 4 Wochen lang gecached werden, kann es sein, dass max 3,99 Wochen der falsche Gravatar geladen wird.

      Das muss man entweder in Kauf nehmen, oder die Cache-Zeit dann doch etwas verkĂŒrzen.

      • Ich persönlich finde 4 Wochen eine ziemlich annehmbare Zeit. Wenn es jemanden stört kann er sich ja melden (wird er wohl sowieso) und dann wird halt die entsprechende Datei in den Ordner rausgepfriemelt und manuell gelöscht.

  9. Watt ein Artikel, boah ey, alle Achtung!
    Bin mir noch unschlĂŒssig ob ich das machen soll. Ich finde meinen Blog nicht unbedingt langsam. Vielleicht wenn er noch was gewachsen ist ;)

    • plerzelwupp

      Hallo Luigi,

      danke fĂŒr Deine RĂŒckmeldung. Nun, es ist natĂŒrlich auch Spielerei; eine Sache fĂŒr Experimentierfreudige oder Freaks – niemand erwartet von irgendjemanden, dass er solch eine Spielerei mitmacht ;-)

  10. Hallo und Danke fĂŒr den Artikel.

    Hat jemand auch konkrete Zahlen? Mit welchem Faktor kann man rechnen.

    Ich frage, weil ich ein wenig skeptisch bin. Erstens behauptet Gravatar auf ihren Seiten, dass ein Cachen nicht sinnvoll ist, weil der Gravatar-Server selbst recht schnell sein soll. OK, hier steht Aussage gegen Aussage.

    Nun kommen aber noch Google Speed oder YSlow von Yahoo. Hier wird bei Analysen von Webseiten immer expliziet darauf hingewiesen, dass man Bilderauf mehrere Domains verteilen soll, weil Browser dann parallele Anfragen durchfĂŒhren können. Kommt alles von einer Domain (der eigenen) geht das nur noch begrenzt. Also spricht auch dies gegen ein lokales Caching.

    FĂŒr mich war die Sache bislang klar: Gravatare immer von Orginla-URL. Schön, hier auch mal eine andere Meinung zu hören.

    Und eben dies fĂŒhrt zur Frage nach konkreten Zahlen. Wie viel schneller ist es denn geworden. Nicht, dass wir am Ende nur von einem Plazebo-Effekt reden.

    • Man kann dazu ja einfach eine Subdomain ala static.example.de einrichten. Yahoo schreibt IIRC, dass man zwischen 2 und 4 Domains fĂŒr eine Seite nutzen sollte, um die beste Performance zu bekommen. Ansonsten ist es halt das Abwiegen von DNS-Lookups und parallelen Downloads.

  11. Hauptvorteil des Cachens auf dem eigenen Server (könnte auch ein CDN sein) liegt darin, das man Einfluss darauf nehmen kann, wie lange die Bilder beim Besucher im Cache/Proxy verweilen dĂŒrfen… daraus ergibt sich, das die Hauptvorteile auch erst bei wiederkehrenden Besuchern zum tragen kommen…

    Und naja, die Tools empfehlen zum einen das Verteilen, aber zum anderen auch das Reduzieren der DNS-Anfragen… Auch da gilt, man muss seine Besucherstruktur kennen und dann abwĂ€gen, ne allgemeingĂŒltige Aussage kann man da leider nicht treffen…

  12. plerzelwupp

    @Markus, Matthias, Olli

    Ja, diese Erfahrung hab ich auch schon gemacht. Es ist ein stetiges Auswiegen.

    Meine CSS samt Hintergrundbildchen hab ich bereits ausgelagert (auf appspot.com). Ein paar Subdomains hab ich auch schon angelegt. Da hab ich mal experimentiert und Javascript ausgelagert – hat sich aber nicht gelohnt.

    Die Gravatar dorthin auszulagern ist eigentlich eine gute Idee – das probiere ich gleich mal aus.
    Ansonsten lĂ€dtz die Seite recht flott – allerdings ist die Erreichbarkeit miserabel.

    Naja, wie auch immer: ich bin mal gespannt, wie sich das auf die DNS Lookups auswirkt. Ich halte Euch auf dem Laufenden ;-)

  13. Hi,
    hoffe ich habs jetzt grad nicht ĂŒberlesen, aber ich denke fĂŒr dich wĂ€re http://www.cronjob.de/ oder http://www.cron-job.org/ eine gute Alternative zur fehlenden CronJob-Möglichkeit deines Anbieters.

    Ansonsten danke, das Script kommt bei mir die Tage auch mal mit rein.

    Viele GrĂŒĂŸe,
    Uli

    • plerzelwupp

      Hallo Uli,

      herzlichen Dank fĂŒr die beiden Links. Genau so etwas hab ich gesucht. Ironischerweise hab ich sogar noch daran gedacht, dass es sicherlich externe Dienste gibt, die bestimmte Dateien zu bestimmten Uhrzeiten in bestimmten Intervallen aufrufen. Doch fĂŒndig bin ich zunĂ€chst nicht geworden.

      Das hier ist wirklich eine tolle Sache.

  14. @uli:

    Vielen Dank fĂŒr diesen Tipp, das scheint die Lösung fĂŒr unsere Probleme zu sein.

    Ich kannte den service schon nur ist er mir in diesen Fall nicht in den Sinn gekommen.

    Werde ich gleich heute Abend testen und allenfalls meinen Artikel ergÀnzen!

    • plerzelwupp

      Hey Jeffrey, danke fĂŒr die RĂŒckmeldung. Deinen Artikel hab ich gestern noch gesehen – doch ich bin nicht mehr dazu gekommen, mir die Sache nĂ€her anzuschauen. Ich hab mein komplettes Theme gelöscht und ein Update aufgesetzt. Nun sind es wieder die zahlreichen Kleinigkeiten, die angepasst und optimiert werden mĂŒssen.
      Uff, den Gravatar-Cache hab ich bereits um dein weiteres Skript ergÀnzt. ;-)

      Ich komme gleich mal vorbei…..

  15. Das Cachen konnte ich mit den Gravataren/Favataren/Avataren/MonsterIDs… mit meiner Software von Haus aus. Allerinsg habe ich es letztendlich doch abstellen mĂŒssen.

    GrĂŒĂŸe aus Mannem. :D

    • plerzelwupp

      Hey – noch ein “Monnemer”. Ist das nicht schön? Die ganze Zeit dĂŒmple ich alleine vor mich hin, dann treffe ich innerhalb einer Woche gleich zwei Kollegen aus der Heimat.
      Das reicht ja schon fast fĂŒr ein Bloggetreffen ;-)

      • Total verrĂŒckt, hĂ€tt ich jetzt auch net gedacht :P Wobei es ja noch net lang meine Heimat ist ;)

  16. Ich habe zwar keinen Plan warum und weshalb aber…
    Alleine schon das es so etwas gibt finde ich Genial!

    Lieben Gruss, Arven

  17. Waaah, genau das was ich gerade noch gesucht habe. Das fast einzige auf meinem Blog was noch von woanders geholt wird sind eben die bösen Gravatar-Bildchen.

    Nun habe ich endlich eine Möglichkeit es anderes zu machen. Super gut! *beifall*

    LG
    Timo

    • plerzelwupp

      Hey Timo,

      herzlich Willkommen im Blog :-)

      Wenn du wirklich daran interessiert bist, das einzubauen, dann solltest du auch den Nachtrag beherzigen und das weitere Skript fĂŒr den Cronjob installieren. Klappt wirklich vorzĂŒglich.

  18. Zu diesem Thema hatte ich mal einen Link getwittert, wo die Einbindung der Avatare im Blog analysiert und der entstehende Performance-Verlust aufgezeigt wurde: http://twitter.com/wpSEO/status/9000317007

    Ich persönlich lasse Avatare nicht vom eigenen Server cachen und verarbeiten aus folgenden Top-GrĂŒnden:
    - Serverlast bzw. Requests wĂŒrden (fast) proportional zu der Zahl der Kommentare im Blog steigen.
    - Anzahl der parallelen, aber beschrĂ€nkten Verbindungen zum eigenen Server wĂŒrde in die Höhe springen, Seitenaufbau entsprechend langsamer als die Verteilung der zu ladenden Elemente.
    - AktualitĂ€t der Bilder wĂŒrde nicht dem Nutzererwarten entsprechen.

    • Sehe ich anders, sorry, dass ich dir da zwischenreinfunken muss. Es kommt auf die Cache-Methode an, wĂŒrde ich behaupten wollen.

      NatĂŒrlich cached man von einer anderen Domain, womit die parallelen Verbindungen auf dem Haupt-Vhost nicht ansteigen und die Seite wie gewohnt lĂ€dt (Argument #2).
      Ich rufe beispielsweise die PHP-Datei zum Cache nur auf, wenn die URL nicht gefunden wird (kann man mit Apache wie auch mit nginx entsprechend konfigurieren), ansonsten gestaltet sich der Aufruf fast wie gewohnt, also kaum Steigerung der Last, wenn man mal von den Festplattenzugriffen absieht. Diese werden durch das deutlich schnellere Ladeverhalten beim Nutzer wieder gerechtfertigt.

      Die AktualitĂ€t der Bilder wird bei mir gewahrt, dass es ca. eine Woche dauert, bis diese bei mir aktualisiert werden. Da die meisten Browser ebenfalls entsprechend cachen, wĂŒrde ich da das Nutzerverhalten mal in den Wind schiessen.

      Ich stimme dir jedoch zu, dass es durchaus aufwendig ist, wenn man keinen Zugriff auf Apache oder Nginx hat und nicht so “low-level” tweaken kann, sondern viele PHP-Aufrufe gestalten muss. In diesem Fall könnten hohe Kommentarzahlen durchaus einen Einschlag in die Performance haben.

      Viele GrĂŒĂŸe,
      Uli

    • plerzelwupp

      Nun hab ich ja wirklich zwei Fachleute hier. Vielen Dank fĂŒr Eure Stellungnahmen.

      Nach Uli’s Methode hab ich auch Ă€smtliche Bilder der Startseite gecached (welche ursprĂŒnglich von der tinthumb.php generiert wurden). An dieser Stelle möchte ich mich nochmlas recht herzlich bei Uli fĂŒr die UnterstĂŒtzung bedanken.

      Über Server-Performance etc kann ich nicht mitreden – da fehlt mir die Sachkenntnis. Tatsache aber ist, dass die Bilder auf einer cookiefreien Subdomain (bierreth.eu) liegen. Nun schlug ich gleich zwei Fliegen mit einer Klappe: Mit den gĂ€ngigen Tools stellte ich fest, dass die Bilder beim Seitenaufbau erheblich schneller zur VerfĂŒgung stehen. Außerdem können diese nun im Browser gecached werden (die Originalbilder der tinthumb haben “keine Dateiendung”, welche per htaccess geregelt werden können).

      Bei den Gravatern nutze ich noch die fopen-Lösung. Das werde ich aber demnĂ€chst auch umstellen. Jedenfalls waren bei den Gravataren von gravatar.com immer wieder Ausreißer dabei, was mit Wartezeiten verbunden ist.

      Im Großen und Ganzen bin ich sehr glĂŒcklich mit den gecachten Gravataren und Artikelbildern. Die Seite lĂ€dt definitiv schneller und zuverlĂ€ssiger. Extern bin ich nur noch von Woopra und Blogoscoop abhĂ€ngig…..

      Wohl gemerkt – ich bin kein Experte auf dem Gebiet. Ich bin aber auch kein Automechaniker und kann dennoch autofahren ;-)

  19. Auweh, verdammt viele Kommentare :)

    Ich hab mir grad mal Jeffrey’s Script angeguckt und fĂŒr suboptimal befunden. Nun ist in mir der Ehrgeiz geweckt, das ganze als WordPress-Plugin zu bauen. Ich hoffe, ich darf deinen Quellcode als Vorlage “klauen”?

    • plerzelwupp

      Hallo Pattrick,

      an deiner Stelle wĂŒrde ich mich an Uli wenden (siehe weiter oben), der das Skript bereinigt und verbessert hat. Nun basiert es auf curl und nicht mehr auf fopen.
      Die Grundlage zu dem hier dargestellten Skript stammt von Tanja

  20. Das Plugin ist schon fertig. Die Gravatare können sowohl per cron als auch automatisch aktuell gehalten werden. Dabei habe ich alles komplett neu entwickelt.

    Das Ganze wird gleich auf meiner Homepage vorgestellt.

  21. Das Script habe ich nun fertiggestellt, kannst es dir ja mal angucken :)

  22. Hallo @all
    Hier scheinen ja wirklich ne Menge Spezialisten zu sein. Da löchere ich doch euch mal, statt immer nur Tanja ;)
    Ob ich sowas hinkriege, weiß ich noch nicht, aber ich hab mal ne Frage, die Sonnenhexer schon angekratzt hat. User, die keine Gravatare haben, werden bei mir nur im Adminbereich mit dem blauen G-Logo angezeigt, nicht aber in den Kommentaren auf der Seite. Hab auch schon die “Identicon”, “Wavatar” usw. versucht, aber nix. Hat jemand ne Idee warum da nix angezeigt wird?
    Danke fĂŒr die MĂŒhe und schöne GrĂŒĂŸe

    • Wenn Du “fremd gehst” kriegst Du trotzdem eine Antwort von mir *lacht*. Ich wĂŒrde das ja gerne Oliver ĂŒberlassen, aber der ist zur Zeit noch mehr “Land unter” als ich ;-)
      Hab mir das gerade mal angesehen. Das mĂŒsste an der Einstellung in Deinem Theme liegen. Kuck mal hier direkt nach der GrĂ¶ĂŸe (s=120). Da wird eingestellt was als default angezeigt wird. Im Normalfall werden hier die Einstellungen aus dem Adminbereich ĂŒbernommen, können aber direkt in der comments.php oder von einem Plugin ĂŒberschrieben werden. Und bei Dir wird in diesem Fall &default=http%3A%2F%2Fwww.chaosweib.com%2Fwp-includes%2Fimages%2Fblank.gif&size=40 genommen. Musst mal in der comments.php kucken, was da in der entsprechenden Passage bei get_avatar() ĂŒbergeben wird. Falls dort nicht der “Fehler” steckt, ist es wahrscheinlich in einem Plugin zu suchen. Irgendwas ĂŒberschreibt Dir auf jeden Fall die Admin Einstellungen.

      • Du bist ja wie 4711, immer dabei *lol*
        Bei mir steht da:

      • Sorry, wird nicht angezeigt.
        …wp-includes/images/blank.gif”; ?>

      • Ja… hatte den Beitrag hier im Abo ;-)
        Lass mal den ganzen &default=... Kram dort weg.
        In den Code-Klammern im Kommentarbereich wird was nicht angezeigt, wenn ” enthalten ist. Das muss entsprechend mit ‘& l t ;’ oder ‘& g t ;’ ersetzt werden. Habe es jetzt mal absichtlich mit Leerzeichen geschrieben, denn ohne könnte es sich wieder in das Zeichen umbauen.

      • Jetzt hat es mir die Zeichen gefressen *grummel* Ich meinte die beiden auf der Tastatur links neben dem Y…

      • Du hast ne Mail. Bin aber jetzt erstmal weg. Bis spĂ€ter.

  23. Danke fĂŒr dieses PHP-Beispiel. Jetzt brauche ich mir das nicht ĂŒberall selber zusammen zu frickeln.

  24. Hallo,
    danke fĂŒr diese guten Tips.Haben mir sehr weiter geholfen.
    DrĂŒĂŸe aus MĂŒnchen

  25. Ich danke auf fĂŒr diesen Codeschnipsel. Werde den mal auf meinen Websites einbauen und ausprobieren. Ich gehe einfach mal davon aus dass kein Copyright besteht :-)

  26. Coole Sache, wusste garnicht wie sowas gemacht wird. Danke!!!

  27. Rechtsanwalt

    Sehr ausfĂŒhrlich beschrieben, aber fĂŒr mich doch etwas zu kompliziert.

    • Mit der aktuellen Version des WordPress Frameworks von Xtreme One kannst du Gravatare ohne großen Aufwand ĂŒber das Backend cachen lassen. Weiter können hier auch CSS, Javascript und HTML komprimiert ausgegeben werden. FĂŒr “faule” WordPress-Nutzer wie mich ist das ideal und die 69,95 € waren gut angelegt. Keine Angst – ich bekomme kein Geld fĂŒr Marketing vom xtreme-Team. Ich bin nur ein zufriedener Nutzer… :-)

  28. Danke fĂŒr dieses PHP-Beispiel. Jetzt brauche ich mir das nicht ĂŒberall selber zusammen zu frickeln.

  29. Jetzt hat es mir die Zeichen gefressen *grummel* Ich meinte die beiden auf der Tastatur links neben dem Y


  30. WordPress: Gravatare cachen – WordPress, Gravatar, Cache, cachen, Plugin, Ladezeiten – Plerzelwupps Erfahrungen November 08, 2011 admin …

Trackbacks/Pingbacks

  1. Gravatar Cache fĂŒr Wordpress ohne Plugin | Crazy Girls Tipps - [...] Und wenn man selbst gerade keine Zeit hat ĂŒber ein bestimmtes Thema zu schreiben, dann lĂ€sst man halt fĂŒr …
  2. t3n.de/socialnews - Wordpress: Gravatare cachen - ohne Plugin... Im Zuge der Serie Blog-Ladezeiten optimieren, geht es heute den Gravataren an den Kragen - …
  3. t3n-Linktipps: T-Mobile und Google, iPad Alternative ADAM, Idee fĂŒr AIR/Flash-App gesucht, Ubunchu und Gravatar-Cache » t3n News - [...] den Seitenaufbau eines Blogs ausbremsen. In seinem aktuellen Beitrag erklĂ€rt Oliver, wie man das bei WordPress ĂŒber einen Gravatar-Cache …
  4. Weekly 5-6/10 | [Gregel Dot Com] - [...] Gravatar Cache [...]
  5. Wordpress Gravatar Cache mit automatischer Aktualisierung - [...] von euch werden bereits gelesen haben, dass Tanja in Zusammenarbeit mit Oliver ein Script geschrieben hat, welches die Gravatare …
  6. Script mit Hilfe von cronjob.de automatisch ausführen lassen - [...] bin ich heute durch einen Kommentar von Uli im Beitrag von Oliver auf einen netten Service gestoßen, mit welchem …
  7. Auslieferung von Gravatar-Icons aus einem lokalen Cache – Download per curl « Leben des wolf-u.li - [...] einigen Tagen bin ich auf einem Blog auf die Idee der Auslieferung der Gravatar-Bilder aus einem lokalen Cache gestoßen. …
  8. Lesenswertes zum Wochenende | Linktipps, Lesetipps, zum Wochenende, Tipps, Empfehlungen, Artikel | blogundso.de - [...] ● Wordpress: Gravatare cachen | Plerzelwupp.de [...]
  9. Spontis Wochenschau #08 – Spontis Weblog - [...] Wordpress: Gravatare cachen Das sind diese kleinen Bildchen die beim kommentieren neben dem Kommentierenden angezeigt werden, sofern sich selbiger …
  10. WordPress GravatarCache | www.patrick-gotthard.de - [...] Seit kurzem schwirren bei meinen Blog-Nachbarn zwei Scripts zum Cachen von Gravataren umher. Angefangen hat alles bei Tanja, die …
  11. Gravatar in WordPress verwenden » Webmaster-Zentrale - [...] Gravatare gecacht, also zwischengespeichert werden können. Eine schöne Einbauanleitung dafĂŒr hat Oliver beigesteuert und Jeffrey hat Tanjas ursprĂŒngliches Skript …
  12. WordPress: Gravatare cachen - [...] WordPress: Gravatare cachen [...]... ...
  13. WordPress: Gravatare cachen – WordPress, Gravatar, Cache, cachen, Plugin, Ladezeiten – Plerzelwupps Erfahrungen | Blogmaxx.com Suchmaschine fuer Wordpress Seiten - [...] WordPress: Gravatare cachen – WordPress, Gravatar, Cache, cachen, Plugin, Ladezeiten – Plerzelwupps Erfahrungen November 08, 2011   admin …

Einen Kommentar schreiben zu Crazy Girl