Allgemeine Frage zu Statistik

Hallo DjPD,

wenn jemand das aller erste Mal (insgesamt) auf eine Seite mit den Buttons kommt fragt dein Server die Share-Zahlen bei den jeweiligen Diensten für die aktuelle url an und speichert sie im Cache-Ordner. Von da aus werden die Zahlen auf der Seite für alle eingebunden. Eine solche Abfrage passiert maximal alle 60 Sekunden. D.h. wenn die Angaben im Cache ?lter als eine Minute sind, holt er sich neue Zahlen und aktualisiert den Cache. Pro Seite auf der die Buttons eingebunden sind ergeben sich somit maximal 60 Anfragen pro Stunde und Dienst.

Siehe z.B. auch: https://www.heise.de/ct/artikel/Shariff-Social-Media-Buttons-mit-Datenschutz-2467514.html

Auf deine Ladezeiten hat dies nur geringen Einfluss, da die Seite bereits angezeigt wird, auch wenn die Zahlen noch nicht da sind. Sieht man gut, wenn man auf eine Seite kommt, auf der l?nger niemand war. Die Buttons sind sofort da, aber die Counter noch nicht. Nach kurzer Zeit erscheinen dann auch die Zahlen. Da die Buttons h?ufig am Ende von z.B. Artikeln eingebunden werden, f?llt dies entsprechend selten auf. Schl?gt die Abfrage bei Facebook und Co. einmal fehl, st?rt dies auch nicht weiter, es fehlen nur schlicht die Counter, was die wenigstens Besucher bemerken werden.

Gru?,
JP

Vielen Dank für die super Antwort.
K?nnte man bzw. w?re es eigentlich sinnvoll, die Sekunden zu erh?hen?
Ich mein, theoretisch würde so eine Abfrage auch alle halbe oder sogar jede Stunde reichen, oder?
Ist nur mal so eine Frage. Wobei, wenn Sie schreiben, dass das nicht auff?llt, dann br?uchte man auch nichts ?ndern.

Vielen Dank nochmal.

Hallo,

grunds?tzlich werden wir an der Standard-Einstellung von 60 Sekunden, die Heise vorgesehen hat, nichts ?ndern. Unter Umst?nden w?re es jedoch denkbar, dass wir eine entsprechende Option einbauen, die es erm?glicht, diesen Wert im Einzelfall zu ver?ndern.

Zum Hintergrund:

Das Einbinden der Z?hler hat für viele Betreiber den Hauptzweck Besucher zu motivieren den jeweiligen Beitrag ebenfalls zu teilen. Beitr?ge die bereits viele Shares erhalten haben, werden tendenziell von der Masse h?ufiger geteilt, als solche, die bisher nur wenig geteilt wurden. Shares motivieren also wieder weitere Shares (irgendwie logisch – Restaurants in denen bereis ein paar Leute sitzen füllen sich z.B. auch schneller, als welche die komplett leer sind). Dazu kommt, dass 2/3 aller Shares i.d.R. innerhalb weniger Stunden eintrudeln, nachdem die ersten Leute diesen geteilt haben. Würde der Z?hler innerhalb dieser Stunden nur je einmal aktualisiert werden, würde der ganze sch?ne Effekt verloren gehen. Viele Menschen k?men auf die Seite, s?hen einen kaum geteilten Beitrag und würden wieder verschwinden. In den K?pfen steckt heutzutage halt: Was kaum Beachtung findet, verschwendet nur meine Zeit.

Der typische Verlauf eines Beitrags in den sozialen Medien sieht daher h?ufig so aus:

t = Zeitpunkt

t1 = Beitrag wird ver?ffentlicht
t2-t4 = Nichts passiert. K?nnen Minuten, Stunden oder auch Tage sein, je nach eigenem Netzwerk und wer den Beitrag so entdeckt.
t5 = Die ersten wichtigen Personen mit ordentlichem Netzwerk teilen den Beitrag.
t6 = Jetzt gehts ab. Innerhalb weniger Stunden kommen zwei Drittel aller Shares zusammen.
t7-t9 = Die Welle flaut ab. Ab jetzt kommen nur noch sporadisch Shares hinzu, gelegentlich kommt es noch einmal zu einer kleinen Welle an Shares, wenn gute Multiplikatoren den Beitrag teilen oder wenn im Heise-Forum gerade Freitag ist und das Thema passt. ??

Daher ist es natürlich für Seiten wie Heise oder auch jede andere gut besuchte Seite wichtig, dass w?hrend der Artikel neu und “hei?” ist, die Counter auch so aktuell sind, wie technisch sinnvoll m?glich ist. Für den Segelverein oder den lokalen Kirchenchor ist dies unter Umst?nden natürlich weniger wichtig, da dort h?ufig eine spezielle Zielgruppe vorbeischaut, die sich weniger durch so allgemeine Faktoren beeinflussen l?sst. Hier w?re eine Erh?hung auf z.B. alle fünf Minuten sicher sinnvoll m?glich, um die Bandbreite etwas zu schonen und weniger nutzlose Anfragen durch die Welt zu jagen.

Bei meiner Testinstallation, auf der ein fast nacktes WordPress l?uft, dauert es nach dem Laden der Seite laut Analytics 1 Sekunde die Shares für alle 10 Dienste neu abzurufen und anzuzeigen. Ohne Aktualisierung dauert es 0,5 Sekunden. Nicht unbedingt die Welt, da der Besucher ja bereits w?hrenddessen den Beitrag lesen kann. Da gibt es sehr viele Faktoren, die die Geschwindigkeit der eigenen Webseite mehr beeinflussen. Wer seine Seite mal dahingehend untersuchen will, kann mit Tools, wie z.B. https://www.gtmetrix.com gute Anhaltspunkte bekommen, wo es hapert. Was sich stark bemerkbar macht sind Caching-Plugins, die die eigene Seite komplett vorspeichern, wie z.B WP Rocket oder Cachify.

So, schon wieder viel zu viel geschrieben. Ich werde mal drüber nachdenken, für kleinere Seiten eine Option zum Anpassen der Cache-Lebensdauer einzubauen – wenn auch mit engen Grenzen. Ich sehe sonst schon wieder die Anfragen hier im Forum: “Z?hler funzt nicht – Ich habe meinen eigenen Beitrag geteilt und der Counter steht immer noch auf 0!”

Viele Grü?e,
JP

Und fuer Leute, die Wissen, was sie tun, gibt es die Konstanten

define("SHARIFF_BACKEND_TMPDIR","/www/example.com/htdocs/tmp");
define("SHARIFF_BACKEND_TTL","88");

fuer die wp-config.php

Mit der ersten laesst sich das TMP-Dir setzen, welches vom Backend genutzt wird. Mit der zweiten laesst sich die TTL zum Beispiel auf 88 Sekunden setzen. Beide werden auch den Spung auf die naechste groessere Version des Plugins ueberstehen. Nur SHARIFF_ALL_POSTS fliegt raus, weil die inzwischen besser im Admin-Menu abgebildet wird. Gute Gelegenheit, die Anpassung gleich mal zu erledigen ??

Das wir die TTL-Option auch im Admin-Menue einbauen, sehe ich ebenfalls nicht. Es ist einfach zu schnell ohne Verstand dort angeklickt. Wer dann Debuggen will, muss eh aufs Filesystem schauen… Also ist es als Konstante imho besser aufgehoben.

BTW: Wie es geht, steht uebrigens seit Version 1.3.0 in der FAQ ??

Auf deine Ladezeiten hat dies nur geringen Einfluss, da die Seite bereits angezeigt wird, auch wenn die Zahlen noch nicht da sind. Sieht man gut, wenn man auf eine Seite kommt, auf der l?nger niemand war. Die Buttons sind sofort da, aber die Counter noch nicht. Nach kurzer Zeit erscheinen dann auch die Zahlen.

Kurze Frage: Hei?t das, dass das Plugin also auch mit gecachten Seiten funktioniert (Auslieferung via varnish), weil technisch gesehen das “Nachladen” der Zahlen per ajax passiert?

Das wurde auch schon mal bei dem anderen Plugin gefragt, aber leider gab es keine Antwort dazu: https://www.ads-software.com/support/topic/does-this-work-with-html-page-caching (Ich habe genau das selbe “Problem” bzw. Situation mit vorgeschaltetem varnish bzw. page cache).

über varnish kann ich nichts sagen, aber das Prinzip dürfte ja im Grunde überall gleich sein. Ich nutze z.B. WP Rocket als Caching-Plugin und das funktioniert wunderbar mit Shariff zusammen. Teile ich z.B. selber einen Beitrag per Facebook (ohne eingeloggt zu sein in WordPress) geht der Z?hler innerhalb einer Minute hoch (die Cache-Lebensdauer von Shariff selber). Das h?ngt aber auch sehr von den jeweiligen Diensten ab. Twitter z.B. ist generell langsamer, als Facebook.

Wie du schon vermutet hast werden die Z?hler nicht bei der Erstellung der Seite eingefügt, sondern nachtr?glich per javascript. Dadurch st?rt es sich auch nicht an der fertig ausgelieferten gecachten Version.

Grundsaetzlich ist erstmal richtig, dass es keine spuerbare Auswirkungen auf die Ladezeit hat, weil es per Ajax nachgeladen wird.

Das Backend initialisiert aber einen ganz geringen Teil der Funktionalitaet von WP. Das ist einfach notwendig, damit nicht jeder haendisch die Konfiguration an seine Seite anpassen muss. Wer es trotzdem will, kann natuerlich einfach die index-Datei entsprechend anpassen. Daher haben WP-eigene Caches fast keine Chance einzugreifen. Macht ja auch wenig Sinn bei einem Tool, das selber “cachet”.

Serverseitige Systeme wie mod_pagespeed oder vorgeschaltete reverse Proxys halten sich normalerweise an die entsprechenden HTTP-Header, um ihren Cache zu fuellen. Da hat der Wrapper jetzt eine ganze Ladung Header dazu bekommen, die in den verbreiteten Cache-Systemen wie auch Browsern das Zwischenspeichern verhindern sollten. Ob die sich dran halten, laesst sich natuerlich nicht beeinflussen. Die geaengigste Massnahme, sie dazu zu zwingen, ist eine Auslieferung der Seite per https-Verbindung. Das liegt aber dann in der Verantwortung des Hostmasters und laesst sich durch WP oder ein Plugin nicht beeinflussen.

Und sogar wenn es ueber eine verschluesselte Verbindung laeuft, ist nicht gesagt, dass nicht doch ein Proxy dazwischen haengt, der entschluesselt -> cacht -> verschluesselt -> ausliefert. Das ist nicht mal zwangslaeufig was Kriminelles, sondern in einigen Firmen-Netzen mit besonders hohen Sicherheitsanforderungen sogar normal. Aber dann trotzdem weit ausserhalb der Verantwortung eines WP-Plugins ??