Statify & Caching?
-
Hallo
sobald FastestCache oder auch WPSuperCache installiert ist, liefert Statify nichtmal annähernd korrekte Daten.
Gibt es ein Cache-Plugin mit dem/das mit Statify gut und korrekt zusammenarbeitet?Gruß
Axel
-
Hallo Axel,
hast du JavaScript basierte Erfassung in den Statify Einstellungen aktiviert? Bei längeren Caching anzeigten ggf. mit abgeschalteter Nonce-Prüfung, falls die Gültigkeit nicht ebenfalls erhöht ist.
Ohne wird bei Antworten aus dem Cache nichts erfasst und die Zahlen liegen entsprechend deutlich zu niedrig.Ich betreibe selbst ein paar Seiten mit Statify und WP Super Cache und Caching-Zeiten 4-12h ohne Schwierigkeiten.
Gruß,
StefanHallo Stefan,
1: Ja, JS-basiert ist aktiviert
2: Ich habe mehrere Websites und sehe das Problem bei allen.
3: Der Dev von FSCache schrieb: https://wordpress.org/support/topic/does-fc-make-statify-stop-counting/
4: https://www.axellauer.de/temp/stat.jpg (auf anderen Seiten habe ich täglichen Wechsel von 0 zu über 500 der sich nicht durch Positionsschwankungen bei Google erklärt denn diese überwache ich auch)Den Punkt mit der Nonce-Prüfung verstehe ich allerdings nicht wirklich.
Was wäre die Einstellung die ich aktivieren sollte? Nonce an oder aus?
“wenn die Cache-Zeit länger als die Nonce-Gültigkeitsdauer eingestellt ist”
Was ist “Nonce-Dauer” und wie ermittle ich die Cache-Zeit?
Gruß
AxelWenn die verlinkte Seite eine der betroffenen ist, fehlt hier jede Spur von Statify, auch wenn ich Laden am Cache vorbei durch willkürliche Parameter in der URL (z.B. …?nocache – fast 10fache Ladezeit wird wohl ohne Cache sein) erzwinge. Das Problem liegt also nicht unmittelbar am Caching.
Du verwendest hier offenbar die WPFC JavaScript „Optimierung“, d.h. JS Ressourcen werden nicht direkt eingebunden, sondern zusammengefasst. Hier fehlt der Statify Teil auf jeden Fall – schlecht.
Ich habe die Einstellungen nicht vor Augen, ggf. kann man das Statify JS davon ausschließen. Das Plugin fügt die Ressource erst recht spät in der
wp_footer()Phase hinzu, wenn vorher schon rausgesprungen wird, wäre das problematisch.Die Seite wirft JavaScript Fehler durch einen eingebetteten Avia Cookie Consent Schnipsel, der ausgeführt wird, bevor JQuery geladen ist. Das sollte auf jeden Fall auch korrigiert werden, ob es mit dem Problem zusammenhängt schwer zu sagen.
UnerMenu beklagt sich auch, dass die normale Initialisierung (sehr wahrscheinlich dadurch) nicht funktioniert und ein Fallback greifen musste.Zu den Nonces.
Ganz kurz: WP generiert für AJAX Anfragen Einmalcodes (Nonces), um zu legitimieren, dass die Anfrage wirklich von der Seite kommt. Sind nicht ewig gültig, daher kann es bei langen Caching-Zeiten vorkommen, dass die Anfragen mit Status 401 abgewiesen werden. Kann man abschalten, geht ja „nur“ um Statistik, also im Regelfall nichts kritisches. Sollte man im Hinterkopf haben, ist hier aber nicht das Problem.https://codex.wordpress.org/WordPress_Nonces
Gruß,
StefanHallo Stefan,
ja, Statify hatte ich inzwischen deaktiviert denn eine Statistik die nicht zählt ….
Habe Statify aber gerade wieder aktiviert da Du ja anscheinend was prüfen wolltest.Zum Rest:
Ich versuche deinen Ausführungen zu folgen, aber bin nicht sicher ob es mir gelingt.“Du verwendest hier offenbar die WPFC JavaScript „Optimierung“, d.h. JS Ressourcen werden nicht direkt eingebunden, sondern zusammengefasst. ”
Du meinst damit die Einstellungen des Cache-Plugins, korrekt?
Welche hiervon ist das denn?
Und gibt es hier überhaupt eine Einstellung die eine Verbesserung herbeiführt oder geht das mit diesem Cache-Plugin überhaupt nicht?
https://axellauer.de/screenshots/fscache.jpg“Die Seite wirft JavaScript Fehler durch einen eingebetteten Avia Cookie Consent Schnipsel, der ausgeführt wird, bevor JQuery geladen ist.”
Du meinst diesen, korrekt?
“Uncaught ReferenceError: jQuery is not defined
<anonymous> https://www.axellauer.de/:573”“UberMenu beklagt sich auch, dass die normale Initialisierung (sehr wahrscheinlich dadurch) nicht funktioniert und ein Fallback greifen musste.”
Das kann ich nicht nachvollziehen.
Wo siehst Du das?Gruß
AxelHallo Axel,
jetzt sieht es etwas anders aus.
Ohne Cache wird korrekter Weise /wp-content/plugins/statify/js/snippet.min.js eingebunden und ruft sauber wp-ajax.php auf. Kommt mit Status 204 zurück, so sollte es sein.Mit Cache fehlt das JS Snippet, dafür gibt es dann eine /cache/wpfc-minified/…/…js, in der eigentlich alle JS Ressourcen zusammengefasst werden sollten.
Die ist recht überschaubar, es fehlt aber auf jeden Fall Statify.
Andere Ressourcen werden z.T. ganz normal eingebunden.Ich sehe entsprechend auf der gecachten und “optimierten” Seite 2 Fehler:
- Statify tut nichts
- UberMenu muss auf Fallback zurückgreifen und liefert die Meldung in der Browserkonsole:
Notice: UberMenu initialized via window.load. This indicates that an unrelated error on the site prevented it from loading via the normal document ready event.
Da aber ohnehin nur ein sehr kleiner Anteil der Skripte zusammengefasst wird, bringt dies Einstellung im gegebenen Szenario auch nicht allzu viel. Ich würde zunächst versuchen, diese Funktion abzuschalten: “JS kombinieren”.
Wenn das nicht hilft, wäre meine nächste Vermutung, dass es ein Problem beim Preload (“Vorlagen”) geben könnte, sodass Statify der Meinung ist, kein Skript einbinden zu müssen und die Seite entsprechend ohne gecacht wird.
Ich komme heute auf jeden Fall nicht mehr dazu, ein Testszenario aufzubauen und einmal zu debuggen, welche Kombination das Problem verursacht, werde es mir die Tage aber auf jeden Fall noch einmal ansehen. Ich weiß, dass WP Super Cache und JS Zusammenfassung mit Autoptimize keine Probleme machen, also kein generelles NoGo. Aber hier läuft es ganz offensichtlich nicht rund.
Gruß,
StefanHallo Stefan,
nachdem ich zuerst dachte die Änderungen an den Settings hätten geholfen sieht es nun wieder so aus wie vorher.
– Erster Tag: Zählte, aber ungefähr um den Faktor 5 weniger als “normal”
– Zweiter Tag: 70% von Tag 1
– Dritter Tag: 10% von Tag 1
– Vierter Tag (heute): Taucht nicht mal mehr als Datum auf – es hat quasi gestern Nachmittag aufgehört zu tracken.Und das ist genau das Verhalten das ich auf mehreren Websites beobachte – ein über ca 4 bis 6 Tage alternierendes Besucheraufkommen das zwischen 0 und “Irgendwas” schwankt – wobei “Irgendwas” auch nur ein Bruchteil jener Zahlen ist die vor dem Einbau von WPC oder FC getrackt wurden.
Gruß
AxelHallo Axel,
das Problem ist immerhin einfach: Caching-Zeit länger als Nonce-Gültigkeit (s.o.)
Die AJAX Anfrage von Statify liefert auf gecachten Seiten aktuell fast ausschließlich “403 Forbidden”, ohne Cache ordnungsgemäß 204.Passt soweit ganz gut zur Beobachtung, direkt nach dem Neuaufbau des Caches sind die Daten frisch, alles gut. Dann laufen die Nonces zunehmend ab nach 8-12h werden zunehmend weniger Seiten erfasst. Bis der Cache neu aufgebaut wird, durch Ablauf oder Bearbeitung einzelner Inhalte, dann geht das Spiel von vorne los.
Bei entsprechend langen Cache-Zeiten würde es sich wohl anbieten, die Nonce-Prüfung für die Statistik zu deaktivieren (in den Statify Einstellungen). Sollte dieses Problem unmittelbar lösen.
Gruß,
StefanHallo Stefan,
OK, ist geändert. Werde es beobachten und mich in einigen Tagen wieder meldenGruß Axel
Kurz noch eine andere Frage zu “Beste Inhalte”:
Werden hier nur die Einstiegsseiten gezählt?
Oder auch wenn bspws. 100 Leute auf der Index einsteigen, aber 90 davon dann nach “XY” gehen und dort abspringen und XY selbst keine Besucher über SuMas generiert: Würde dann “XY” in der Bestenliste auftauchen?Gruß
AxelHi @alauer
Würde dann “XY” in der Bestenliste auftauchen?
Ja, es werden ja nur “Views” gezählt. Dabei ist es egal woher diese Views kommen. Solange das Skript/Snippet ausgeführt wird, wird gezählt. Dazu bedarf es nicht einer externen Quelle.
Beste Grüße
Torsten
The topic ‘Statify & Caching?’ is closed to new replies.
