Lange weiße Seite beim Navigieren

Schließe mich dem vollumfänglich an. Seit der Designumstellung, sind die Ladezeiten teils nervig lange. Ich hoffe, dass kann zeitnah behoben werden.

 

Schalt mal die Tracking Protection aus. Bessert sich das Verhalten?

 

Bei mir ist dieses Verhalten erst mehrere Tage nach der Design-Umstellung eingetreten.

 

Ich hätte ebenfalls gesagt, das ich es seit ca. letzten Donnerstag/Freitag, exakt mit dem selben Verhalten, zu tun habe.
Bei mir auch in Windows 10 64Bit mit Firefox 66.0.3 64Bit
Forum hingegen funktioniert ohne Probleme.

Edit: Nach kurzer analyse liegt es möglicherweise im HTML an der Klasse "async-hide", welche im Firefox erst nach 4s durch den "Anti-flicker snippet"-Abschnitt entfernt wird. Warum bei Chromium die Klasse schneller entfernt wird, wundert mich, aber ich habe auch keine tieferen Einblicke.

 

Hallo,
ich habe seit ein paar Tagen auch dieses Problem unter Firefox und im Brave Browser. Der Seitenaufbau steht für fast 3 Sekunden einfach still. Das bestätigt auch eine Laufzeitanalyse. Dabei bleibt die Seite leer. Nach der langen Wartezeit ploppt die Seite dann schon vollständig aufgebaut auf. Die Nutzung euer Seite leidet darunter enorm. Das Problem habe ich aber allerdings nur bei "strenger" Einstellungen der Optionen "Seitenelemente blockieren" (Firefox) bzw. aktivierten Blockierung von Ads und Trackern (Brave). Folgende Elemente werden da blockiert:

google-analytics.com/analytics.js
typekit.net/p.gif?s=1&k=bxw3gkn&ht=tk&h=www.gamestar.de&f=15701.15705.15708.17001.17005.17006&a=699962&js=1.19.2&app=typekit&e=js&_=1556553386353
script.ioam.de/iam.js?m=1

Ich habe aber Gamestar Plus und Tracker deaktiviert.

Eine Lösung ist: Im Firefox oben links auf das Schildsymbol klicken und "Blockierung für diese Webseite deaktivieren"

 

Es liegt an der Tracking Protection von Firefox. Die sorgt für eine sekundenlange Pause beim Laden der Seite. Hat man einen Scriptblocker, funktioniert es ohne Probleme, ebenso als Plus-Kunde.

Ich eröffne mal ein Ticket in der Bugzilla.

 

Ist bei mir seit ein paar Tagen auch so, auch als Plus-Kunde!
Das Forum läuft normal, aber News etc. haben alle mehrere Sekunden Pause, bevor etwas angezeigt wird.

 

Ich glaube hier vermischen sich verschiedene Probleme. Das eine scheint definitiv ein Bug in der Tracking Protection von Firefox zu sein. Etwa seit dem Relaunch scheint die Seite aber auch anders gehostet zu werden weshalb manche User wohl deutlich längere Ladezeiten haben.

 

Mit Mobile Safari hat man ein ähnliches Problem. Ich hab das sowohl mit meinem iPhone, als auch iPad seit ca. einer Woche. Da ist zwar auch Purify als Adblocker an, aber als eingeloggter Plus-Account, kann's daran ja nicht liegen.

Edit: okay, wenn man Purify komplett als Content-Blocker abschaltet, funktioniert's normal oder mit einem Whitelist-Eintrag, aber Sinn der Sache kann das als Plus-User dann ja auch nicht sein.

 

Doch, ich habe das mit eingeloggtem Plus-Account mit aktiver Firefox Tracking Protection auch. Dann ist es wohl doch kein Firefox spezifisches Problem.
Aber wie kriegt man es hin dass ein Browser so lange mit dem first paint wartet Wie funktioniert Purify, verwendet das auch eine Filterliste von Disconnect?

 

Purify stammt vom ursprünglichen uBlock-Entwickler und hat eine eigene Filterliste. Leider wird die nirgendwo veröffentlicht. iOS lässt ja nur eine bestimmte Anzahl von Einträgen zu, daher wird die speziell dafür gemacht.

Aber ist auch egal, ich hab's gefunden. Hier ist der Übeltäter:

Code:

(function (a, s, y, n, c, h, i, d, e) {
s.className += ' ' + y; h.start = 1 * new Date;
h.end = i = function () { s.className = s.className.replace(RegExp(' ?' + y), '') };
(a[n] = a[n] || []).hide = h; setTimeout(function () { i(); h.end = null }, c); h.timeout = c;
})(window, document.documentElement, 'async-hide', 'dataLayer', 4000, { 'GTM-PVDT9ZS': true });

Das setzt beim Laden von Google Tag Manager mit einem Timeout von vier Sekunden die Klasse "async-hide", die weiter oben DOM in einem Style-Element mit "opacity: 0 !important;" definiert wird. Das "blockt" das Rendering bzw. es sieht so aus, weil einfach die ganze Seite durchsichtig wird. Wenn ich in Chrome über den Web Inspector die Domain "www.google-analytics.com" direkt blocken lasse, verhält sich Chrome genauso. Interessanterweise blocken weder uBlock Origin noch PrivacyBadger die Domain, auch wenn sie in den Filterlisten steht bzw. in den Einstellungen von PrivacyBadger explizit geblockt wird. Nur im Web Inspector ging's dann.

Vermutlich trifft hier Firefox genauso ins Schwarze wie Purify und blockt die Domain.

Dieser Code stammt direkt von Google und wird als Anti-Flicker-Maßnahme bezeichnet, siehe https://developers.google.com/optimize/. Die normale Tag-Manager-Einbindung funktioniert ohne diese Klasse und den Timeout.

Interessanterweise reicht es in Purify nicht "www.google-analytics.com" in die Whitelist aufzunehmen, da der wohl die Whitelist nur für die Domain der eigentlich aufgerufenen Seite berücksichtigt, nicht aber von Sub-Requests an andere Domains.

Hat nun eine Weile gedauert, bis ich das rausgefunden habe und in Chrome reproduzieren konnte ...

Im Endeffekt kamen drei Schuldige in Frage, weil Purify genau drei Requests blockt: Google Analytics, Info Online (ioam.de) und das Tracking von TypeKit. TypeKit setzt ebenfalls zusätzliche Klassen auf das Document Element, aber die haben keine vorgegebenen Styles und unterliegen dem jeweiligen Seitenbetreiber. Hatte daher erst TypeKit in Verdacht, aber die gesetzten Klassen werden nirgendwo definiert. Und Info Online produziert durch die geblockte URL lediglich einen Script-Fehler, der aber nicht weiter tragisch ist -- zumindest für den Nutzer.

 

Danke, habe das so in das Ticket geschrieben. Bin mal gespannt ob da jemandem was dazu einfällt oder es WONTFIX wird.

 

Da es um Tracking geht, schwierig.

Würde es ja wie Ars Technica machen: Abonnenten werden komplett vom Tracking ausgenommen, ohne wenn und aber.

 

Das Ganze steht halt am Ende völlig im Widerspruch zu...

​

 

Ich meinte bei Mozilla. Die arbeiten ja gerade intensiv an der Tracking Protection.

 

Ich habe das tatsächlich auch, wenn ich hier Artikel aufrufen möchte. Im Forum dagegen nicht. Zunächst eine weiße Seite, dann kommt nach einigen Sekunden aber alles.

€: Beispielsweise hier:
https://www.gamestar.de/artikel/bue...e-kopfhoerer-koennen-ueberzeugen,3343415.html

Im neuen Tab geöffnet, Tab-Titel ist auch sofort da, aber kurz gibt es einen weißen Bildschirm und dann ist alles da.

Selbst wenn ich Do not Track von "Immer" auf "Nur wenn Firefox bekannte Elemente zur Aktivitätenverfolgung blockieren soll" abändere.

 

Mit Do Not Track hat das nichts zu tun. Sonder damit:

 

Auch auf Standard passiert das.

 

Das ganze ist kein Firefox Problem. Das habe ich auch mit Chrome.

 

Habs generell überall außer im Forum. Neuste FF Version.

Ladezeiten (weißer Bildschirm) von fast 5Sek+ sind atm die Regel, was ziemlich nervt :/

 

Also bei mir unter FF läuft es seit Donnerstag/Freitag wieder,
vielen Dank an @MadCat für die ausführliche Problem-Analyse und @Lurtz & @Mary Marx für das melden an die Techniker.

(@Lurtz kann man als normal sterblicher eigentlich auch Tickets erstellen?)

 

Ja, bei mir ist es auch nicht mehr aufgetreten.

@N I T R O
Wie gesagt ich habe das Ticket im Firefox-Bugtracker erstellt, da kann jeder angemeldete User Tickets erstellen. Bei Gamestar natürlich nicht.