Frage Warum zeigen Websites heutzutage ihren Text nicht sofort an?


Ich habe festgestellt, dass in letzter Zeit viele Webseiten ihren Text nur langsam darstellen. Normalerweise werden der Hintergrund, Bilder usw. geladen, aber kein Text. Nach einiger Zeit erscheint der Text hier und da (nicht immer alle gleichzeitig).

Im Prinzip funktioniert das Gegenteil, als der Text zuerst angezeigt wurde, dann wurden die Bilder und der Rest danach geladen. Welche neue Technologie schafft dieses Problem? Irgendeine Idee?

Beachten Sie, dass ich eine langsame Verbindung habe, die das Problem wahrscheinlich akzentuiert.

Unten sehen Sie ein Beispiel - alles ist geladen, aber es dauert noch ein paar Sekunden, bis der Text endlich angezeigt wird:

enter image description here


440
2018-02-07 06:22


Ursprung


In diesem speziellen Fall verwendet PortableApps.com die Schriftart "Ubuntu". John versuchte zuerst OpenSans, aber wir wechselten ziemlich schnell zu Ubuntu. Ich war der Hauptvertreter des Switching ... Eine Möglichkeit, das Problem zu lösen, besteht darin, die Schriftfamilie selbst zu installieren. Wenn Sie es von installieren font.ubuntu.com es wird sofort funktionieren. - Chris Morgan
Die Antwort von Daniel ist Augenöffner. Ich dachte, das ist absichtlich getan, damit wir alle Anzeigen auf der Seite sehen können. - Manoj R
Wie einige Leute hier betont haben, gibt es unendlich viele Gründe, warum Text auf unerwartete Weise rendern kann, da das Rendern einer Seite nur durch die Vorstellungskraft des Entwicklers / Entwicklers eingeschränkt wird. Dies war zumindest seit dem ANSI-Positionscode der Fall Boards zum Implementieren von Multiuser-Chats und UIs mit überlappenden Fenstern mit Schlagschatten. Meebo war einer der ersten, der einige dieser Effekte in einem Browser ohne Applet reproduziert. "Funktioniert das Gegenteil wie früher", vereinfacht das Internet erheblich und bezieht sich nicht einmal auf einen bestimmten Zeitraum. - PJ Brunet
Warum also generelle Verallgemeinerungen über das Internet auf einer zufälligen Bildschirmobergrenze von einer Website mit einem niedrigen Alexa-Rang machen? Die beste Antwort lautet auch: "Heutzutage werden die Designer mit XYZ arbeiten" sollte mit einigen reellen Zahlen versehen werden, wie "5% der Websites verwenden Google Web Fonts ab 2012" oder was auch immer es ist. - PJ Brunet
Schriftdateien werden jedoch im Cache gespeichert. Diese Site wartet lange auf das Laden von m.aspx, um diesen Teil zu überprüfen - user613326


Antworten:


Ein Grund ist, dass Webdesigner heutzutage gerne Webfonts verwenden (normalerweise in WOFF Format), z.B. durch Google Web-Schriftarten.

Zuvor waren die einzigen Schriftarten, die auf einer Site angezeigt werden konnten, diejenigen, die der Benutzer lokal installiert hatte. Da z.B. Mac- und Windows-Benutzer hatten nicht unbedingt die gleichen Schriften, Designer definierten instinktiv immer Regeln

font-family: Arial, Helvetica, sans-serif;

Wo, wenn die erste Schriftart nicht auf dem System gefunden wurde, würde der Browser nach der zweiten Schriftart suchen, und schließlich nach einer Fallback- "Sans-Serif" -Schriftart.

Nun kann man eine Font-URL als CSS-Regel angeben, damit der Browser eine Schriftart herunterladen kann:

@import url(http://fonts.googleapis.com/css?family=Droid+Serif:400,700);

und laden Sie dann die Schriftart für ein bestimmtes Element, z. B .:

font-family: 'Droid Serif',sans-serif;

Dies ist sehr beliebt, um benutzerdefinierte Schriftarten zu verwenden, aber es führt auch zu dem Problem, dass kein Text angezeigt wird, bis die Ressource vom Browser geladen wurde, einschließlich der Downloadzeit, der Ladezeit und der Renderzeit. Ich erwarte, dass dies das Artefakt ist, das Sie erleben.

Als Beispiel: eine meiner nationalen Zeitungen, Dagens Nyheter, verwenden Sie Web - Fonts für ihre Überschriften, aber nicht ihre Leads. Wenn diese Seite geladen wird, sehe ich normalerweise zuerst die Leads und eine halbe Sekunde später werden alle Leerstellen mit Überschriften gefüllt (dies gilt für Chrome und Opera unter am wenigsten. Habe andere nicht versucht).

(Auch Designer streuen JavaScript heutzutage überall hin, also versucht vielleicht jemand, etwas Cleveres mit dem Text zu machen, weshalb es sich verzögert. Das wäre allerdings sehr Site-spezifisch: Die generelle Tendenz, dass Texte in diesen verzögert werden mal ist das oben beschriebene web fonts problem, glaube ich.)


Zusatz

Diese Antwort wurde sehr aufgewertet, obwohl ich nicht viel ins Detail ging, oder vielleicht weil von diesem. Es gab viele Kommentare im Fragethread, also werde ich versuchen, etwas zu erweitern (viele Kommentare scheinen kurz nach dem Schutz des Themas verschwunden zu sein - einige Moderatoren haben sie wahrscheinlich manuell bereinigt). Lies auch die anderen Antworten in diesem Thread, da sie alle auf ihre eigene Art und Weise expandieren.

Das Phänomen ist im Allgemeinen bekannt als "Flash of unstyled content" im Allgemeinen und "Flash of unstyled Text" im Besonderen. Die Suche nach "FOUC" und "FOUT" gibt weitere Informationen.

Kann ich empfehlen Web-Designer Paul Irish Post auf FOUT in Verbindung mit Web-Fonts.

Was man bemerken kann ist, dass verschiedene Browser dies unterschiedlich handhaben. Ich schrieb oben, dass ich Opera und Chrome getestet hatte, die sich beide ähnlich verhielten. Alle WebKit basierten (Chrome, Safari, etc.) wählen FOUT zu vermeiden nicht Rendering Web-Schriftart-Text mit einem Fallback-Schriftart während der Web-Schriftart Ladezeit. Selbst wenn Die Web-Schriftart wird dort zwischengespeichert werden eine Renderverzögerung sein. Es gibt viele Kommentare in diesem Fragethread, die etwas anderes sagen, und es ist völlig falsch, dass zwischengespeicherte Schriftarten sich so verhalten, aber z. aus dem obigen Link:

In welchen Fällen erhalten Sie einen FOUT

  • Wille: Herunterladen und Anzeigen einer Remote-ttf / otf / woff
  • Wille: Anzeigen eines zwischengespeicherten ttf / otf / woff
  • Wille: Herunterladen und Anzeigen einer Daten-URI ttf / otf / woff
  • Wille: Anzeigen einer zwischengespeicherten Daten-URI ttf / otf / woff
  • Wird nicht: Anzeigen einer Schriftart, die bereits installiert und in Ihrem herkömmlichen Schriftartenstapel benannt ist
  • Wird nicht: Eine Schriftart anzeigen, die mithilfe des Local () - Speicherorts installiert und benannt wurde

Da Chrome wartet, bis das FOUT-Risiko vor dem Rendern weg ist, gibt es eine Verzögerung. Zu welchem Umfang Der Effekt ist sichtbar (besonders beim Laden aus dem Cache) scheint unter anderem von der Menge an Text, die gerendert werden muss, und vielleicht von anderen Faktoren abhängig zu sein, aber Caching entfernt den Effekt nicht vollständig.

Irish hat auch einige Updates bezüglich des Browserverhaltens vom 2011-04-14 am Ende des Posts:

  • Feuerfuchs (ab FFb11 und FF4 Finale) hat kein FOUT mehr! Wooohoo! http://bugzil.la/499292 Grundsätzlich ist der Text für 3 Sekunden unsichtbar und bringt dann die Fallback-Schriftart zurück. Der Webfont wird wahrscheinlich innerhalb dieser drei Sekunden laden, aber ... hoffentlich ..
  • IE9 unterstützt WOFF und TTF und OTF (obwohl es erfordert ein Einbettungsbit  Ding setzen- meistens, wenn Sie WOFF verwenden. JEDOCH!!! IE9 hat eine FOUT. :(
  • Webkit hat ein Patch wartet darauf, zu landen Fallbacktext nach 0,5 Sekunden anzeigen. Also gleiches Verhalten wie FF aber 0,5s statt 3s.
  • Zusatz: Blinz hat Ein Bug ist auch dafür registriert, aber es scheint, dass ein endgültiger Konsens bezüglich dessen, was damit zu tun ist, nicht erreicht wird - derzeit die gleiche Implementierung wie WebKit.

Wenn das eine Frage war, die sich an Designer richtet, könnte man Wege finden, solche Probleme zu vermeiden, wie z webfontloader, aber das wäre eine andere Frage. Die Paul Irish-Verbindung geht in dieser Angelegenheit weiter ins Detail.


484
2018-02-07 07:54



Haben einige der Browser versucht, den Text zuerst in einer verfügbaren Schriftart zu rendern und ihn erneut zu rendern, sobald die bevorzugte Schriftart heruntergeladen wurde? - Steve Bennett
Oh, Duh, kommentiere die nächste Antwort: paulirish.com/2009/fighting-the-font-face-fout - Steve Bennett
@ ratchetfreak würde es beunruhigend sein, die Seite neu zu formatieren, da die Schriften wahrscheinlich nicht die gleichen Metriken hätten - Samuel Edwin Ward
Einige würden es vorziehen, zum Leseteil des Browsens einer Webseite zu gelangen, anstatt zu warten, bis die Schriftart geladen ist - ratchet freak
@SteveBennett Ich bin mir ziemlich sicher, dass Internet Explorer 10 genau das tut. Ich habe noch nie einen Text gesehen, der später auftaucht. Für mich ist es immer Text, der in einer "Standardschrift" erscheint und ein paar Sekunden später wird er zum gestylten / heruntergeladenen Text. Ich bin mir nicht sicher, ob es die nächste CSS-Version oder nur die System-Standardeinstellung wählt. Edit: Ah, nett, also ist es nur Webikit mit dem versteckten Text? Ich würde das nervige und schlechte Verhalten in Betracht ziehen. Gibt es einen Browser, der das progressive Laden von Bildern ignoriert / versteckt? - Mario


Der Grund dafür ist der Text, den Sie noch nicht lesen können eine Webschrift das ist immer noch auf dem Weg die Rohre zu Ihrem Browser.

Da Ihr Browser Google Chrome ist, der WebKit zum Rendern der Seite verwendet, es wurde von ihnen entschieden (WebKit), dass es für Sie am besten ist, überhaupt keinen Text zu sehen, bis die Webschrift heruntergeladen ist. Wenn Sie jedoch ein Entwickler sind, der den Text lieber in einer geeigneten Fallback-Systemschrift lesen möchte, dann können Sie etwas wie Googles WebFont Loader um das zu erreichen.


117
2018-02-07 11:46



Leider ist es eine falsche Antwort, wenn Sie diese Seite einmal besuchen würden, würde die Schriftdatei in Ihrem Web-Cash liegen; Für andere Seiten auf dieser Website oder andere Websites, die diese Schriftart verwenden, würde sie aus Bargeld abgerufen werden. - user613326


Kurze Antwort: AJAX oder WOFF

Es gibt mehrere Ursachen von Websites sein "langsam, um ihren Text anzuzeigen". Die Langsamkeit auf PortableApps.com wird durch Herunterladen verursacht WOFF Schriftarten. Was Sie jedoch als beschreiben "Text beginnt hier und dort zu erscheinen" wird häufiger durch verursacht AJAX.

Eine Website besteht aus vielen Teilen. Wie diese Teile heruntergeladen und zusammengebaut werden, ist a Design-Wahl unter der Kontrolle der Webdesigner. Die Langsamkeit wird dadurch verursacht, wie der Entwickler die folgenden Bausteine ​​zusammenbaut:

  • Erste HTML-Seite
  • CSS
  • JS
  • Bilder
  • WOFF Schriftarten
  • AJAX-Anfragen
  • DOM-Manipulation

Traditionell Webseiten:

Traditionell war es üblich, dass Entwickler den Textinhalt in den erste HTML-Seite und zeige es an sobald es verfügbar war. Der HTML-Code verweist auf mehrere Ressourcen, die dann heruntergeladen werden. Der Browser würde dann progressiv neu zeichnen Der Bildschirm enthält die Stile und Bilder, sobald sie verfügbar waren. AJAX und WOFF waren nicht verfügbar.


WOFF Webseiten:

Mit WOFF-Fonts kann eine Website Schriftarten verwenden, die normalerweise nicht für den Browser verfügbar sind Herunterladen von Schriftarten mit der Website. Einige Entwickler weisen den Browser an, den Textinhalt erst anzuzeigen, nachdem alle WOFF-Schriftarten heruntergeladen wurden. Meiner Erfahrung nach hat dieser Ansatz noch keine weite Verbreitung gefunden.


AJAX Webseiten:

Einige Entwickler entscheiden sich dafür, den Textinhalt nicht in die ursprüngliche HTML-Seite aufzunehmen. Stattdessen laden sie den Textinhalt mit AJAX herunter. Das passiert nachdem die Basisseite geladen wurde. Nach meiner Erfahrung hat diese Methode viel gewonnen breitere Akzeptanz als WOFF Fonts und ist meistens der Grund für die Langsamkeit, die Sie beschreiben.


Ermitteln der Ursache

Um die Ursache für eine bestimmte Website zu ermitteln, ist eine Analyse mithilfe von Tools wie z Feuerwanze oder Chrome-Entwicklertools. Oder alternativ können Sie die Website mit öffnen Internet Explorer 8, die AJAX unterstützt, aber nicht WOFF. Wenn die Website noch langsam ist, ist das Problem AJAX und nicht WOFF.


19
2018-02-08 13:40





Ich kann es oft eine bewusste Entscheidung sein, den "Flash of unstyled content" zu vermeiden. Wenn der Text, der vor dem Laden des CSS angezeigt wurde, kurz angezeigt wird, erscheint der Text roh, und dann blinkt der Browser, wenn er neu gezeichnet wird. Durch das Einfügen einiger grundlegender Inline-Stile zum anfänglichen Verbergen des Inhalts, die im aktuellen Stylesheet überschrieben werden, oder mithilfe von JS vermeiden Entwickler diesen Flash.


14
2018-02-07 08:26



In neun von zehn Fällen ist es nicht absichtlich, es ist nur ein Nebeneffekt der Einbettung von Web-Fonts auf die einfachste Art und Weise. In der Tat, es erfordert ein wenig mehr Aufwand, eine sichtbare Alternative zu präsentieren, während die Web-Fonts aus dem Rohr kommen. Sehen developers.google.com/webfonts/docs/webfont_loader - Marcel
@Marcel - das kann durch langsame Stylesheets sowie langsame Schriftarten verursacht werden, siehe phpied.com/css-and-the-critical-path - r3m0t
Code, um den "Flash von nützlichem Inhalt" zu verhindern, neigt dazu, Bilder sowie Text zu verhindern. - Jon Hanna
Ich habe Mühe zu verstehen, warum unsterblicher Text schlimmer ist als gar kein Text. Ich würde eher in der Lage sein zu lesen, zu akzeptieren, dass es ein bisschen wackeln könnte. Ich finde es juckender, wenn es plötzlich nach Nirgendwo erscheint, und es ist sehr frustrierend, wenn eine Seite geladen ist und man auf eine Schriftart warten muss. - Richard Le Poidevin


Wie andere bemerkt haben, tragen benutzerdefinierte Schriftarten wahrscheinlich zur Verzögerung bei.

Um ein bisschen mehr Hintergrundwissen zu geben, macht der Browser ungefähr die folgenden Schritte, bevor er den Seiteninhalt auf dem Bildschirm darstellen kann:

  1. Fetch HTML (mehrere Rundreisen für DNS, TCP, Request / Response)
  2. Beginnen Sie, HTML zu analysieren, entdecken Sie externe Ressourcen wie externe CSS und JS. Beachten Sie, dass CSS das Layout blockiert und JS das Parsen blockiert. Daher verlangsamen externe Ressourcen wie CSS und JS, die früh in das Dokument geladen werden (z. B. im Kopf), die Zeit, die für das Anzeigen einer Seite auf dem Bildschirm benötigt wird.
  3. externe CSS und JS holen (mehrere Rundreisen: DNS und TCP, wenn diese Ressourcen in einer anderen Domäne wie CDN sind, sowie eine RTT für die Anfrage / Antwort)
  4. dieser Da sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch dieser
  5. Wenn das CSS auf benutzerdefinierte Zeichensätze verweist, müssen diese Zeichensätze jetzt ebenfalls heruntergeladen werden, was zu zusätzlichen Umlaufverzögerungen führt, um Teile der Seite, die von den benutzerdefinierten Zeichensätzen abhängen, zu rendern

Obwohl es nicht speziell um die Verzögerungen geht, die durch benutzerdefinierte Schriftarten verursacht werden, habe ich kürzlich einen Blogpost geschrieben, der zusätzliche Informationen zu den Ursachen für Renderverzögerungen enthält. Es gibt einige Vorschläge, um die Zeit für das erste Mal für Ihre Seiten zu minimieren. Dies ist hoffentlich nützlich für Leser, die daran interessiert sind, dass auf ihren Seiten Inhalte schneller angezeigt werden, einschließlich solcher Seiten, die benutzerdefinierte Schriftarten verwenden möchten: http://calendar.perfplanet.com/2012/make-your-mobile-pages-render-in-underon-e-second/


8
2018-02-07 18:26





Kurze Antwort: Entwickler.

Wenn Link- und Skript-Tags, die auf externe Dokumente (wie .css- oder .js-Dateien) verweisen, im Kopf des Dokuments platziert werden (höher im Fluss als der Hauptteil und seine Elemente), werden sie zuerst geladen. JavaScript wird von dem Markup ausgeführt, das darauf verweist. Wenn viel Code verarbeitet werden muss oder schwerfälliger Code ist, oder häufiger, wenn der zu erwartende Text auf einem Server gerendert und beim Laden in das Dokument eingefügt wird - und dieser serverseitige Code ebenfalls umständlich ist, Wenn Sie große oder blockierende E / As aufgrund der Verarbeitung mehrerer gleichzeitiger Anfragen verwenden, können Sie sicherlich Ausfallzeiten feststellen, bevor der HTML-Code überhaupt gerendert werden konnte. Einige Entwickler laden nach dem Markup und den Stilen (am Ende des Hauptteils) nicht-view-bezogenes JavaScript und versuchen am besten, sich darüber im Klaren zu sein, wie sich ihre Technologieentscheidung auf die allgemeine Benutzererfahrung auswirkt.

Die Internetverbindungsgeschwindigkeit spielt eine Rolle beim langsamen Herunterladen von Daten, aber schlecht geschriebener Code oder schlecht entworfene Technologie-Stacks (für den Typ der Website) spielen eine zunehmend zentrale Rolle beim langsamen Laden dynamischer Inhalte als schnellerer Netzwerkverbindungen Annäherung an die Allgegenwart.


4
2018-02-07 10:04



Nein - was Sie beschreiben, kann Elemente des DOM von der Anzeige blockieren, aber nicht nur Text. Die Antwort ist mit dem Ersetzen von Schriftarten zu tun die Schuld der Designerkeine Entwickler. - Toby
+1 @Toby, weil es wirklich die Schuld der Designer ist. Es ist auch extrem irritierend, wenn Sie auf einer langsamen Verbindung sind (wie, oh, ich weiß nicht, mein Handy oder das Festnetz zu Hause). So etwas macht Websites nur langsamer und irritiert die Nutzer, ohne dass es irgendeinen Nutzen bringt. - Magnus
Lange Antwort: Entwickler, Entwickler, Entwickler, Entwickler. - iono
@Toby Die Designer legen fest, welche Schriften zu verwenden sind, aber es ist die Aufgabe eines jeden guten Entwicklers, die richtigen Entscheidungen während der technischen Implementierung zu treffen. Der gute Entwickler würde auch verstehen, warum es passiert (erklärt in einer Antwort oben), welche Entscheidungen getroffen werden können, um das Problem zu vermeiden (Google Webfont Loader), und wie sich das auf die Erfahrung auswirkt. - arbales


Kurz gesagt, zu viele ladbare Objekte, die von separaten HTTP-GETs geladen werden müssen, bevor die Seite angezeigt werden kann, und eine übermäßige Abhängigkeit von der durchschnittlichen Latenz als Maß für den Standortzustand.

Die erste bezieht sich auf alle .css, .js und Webfonts, die die Seite lädt, ganz zu schweigen von der Tatsache, dass viele Websites JSEON-Objekte auch über XHR-Anfragen abrufen müssen und dann HTML von denen erzeugen, die eine Art von Templating verwenden.

Aber warum bemerken sie nicht, dass die Website langsam ist?

Wahrscheinlich, weil sie irgendwo Memecache haben, um die Dinge zu beschleunigen (oder sich einfach auf Dateisystem-Caches zu verlassen), und sie messen ihren Standort-Zustand mit durchschnittlicher Latenzzeit. Daher werden die zwischengespeicherten Objekte mit einer Latenzzeit von 6 Mikrosekunden zurückgegeben und maskieren die Tatsache, dass viele GET-Anforderungen 5000 Millisekunden benötigen, um abgeschlossen zu werden. Durchschnitt muss sterben. Es lebe die Zählung von RTTs über eine akzeptable maximale Schwelle! Diese Nummer sollte 0 sein, oder per Definition ist die RTT inakzeptabel.


3
2018-02-13 04:25





Nun, es gibt mehrere Gründe. Ein Grund ist auch, dass Befehle oft einen Hintergrund oder eine HTML-Seite definieren Oder in einem separaten CSS abgerufen, das zuerst geladen wird. bevor der Hauptteil des Dokuments geladen wird, der den Text enthält.

Ein weiterer Grund ist, dass es in den meisten Fällen möglich ist, die Größe eines Bildes einzugeben. Webdesigner machen davon jedoch keinen Gebrauch. Und so muss der Brouwser zuerst die ganzen Bilder auf die Seiten laden, so dass er weiß, wie man Text um ihn herum wickelt.

Einige Designer wollen auch erste Bilder und den nächsten Text zeigen, sie erreichen das mit etwas Javascript, also zum Beispiel zeigt eine einfache Seite zuerst ein Banner und dann alles andere darauf.

Aber wenn Sie sich fragen, warum es so viel Spam auf meinen Seiten gibt, während ich nur die Nachrichten lesen will, dann gibt es eine Lösung für Sie. Sie können Spam-Blocker verwenden, wenn Sie Firefox verwenden. Mit einem solchen Addon kennt der Webbrowser Websites, die Spam bereitstellen, und blockiert sie einfach, was zu einem viel schnelleren Laden der Seite führt, während Sie immer noch in der Lage sind, die wichtigen Bilder zu sehen, die sich auf die gelesenen Artikel beziehen.

Ich würde allen empfehlen, die sich mit langsamem Seitenladen beschäftigen, um Fidler zu versuchen. Fidler kann mit IEexplorer oder mit FireFox verwendet werden (unter Verwendung seiner Proxy-Funktion) Fidler zeigt Ihnen, wie lange es tatsächlich dauert und wann Teile einer Webseite geladen werden. Es ist ein HTML-Debugging-Tool.


-1
2018-02-07 11:41



Also versuchst du Leuten zu helfen und runter zu kommen, stimmt das nicht lustig? Ok, ich werde noch einmal darüber nachdenken, bevor ich euch die technischen Sachen hier in Laien erklären werde. - user613326
Du hast das Falsche erklärt, deshalb wirst du runtergerutscht. Wie Sie auf dem Screenshot sehen können, ist die Seite vollständig geladen, nur der Text wird nicht angezeigt. Das hat nichts mit Bildern zu tun. - Femaref
Der Hauptteil des Dokuments wird fast immer vor dem externen CSS geladen. Der Browser hört nicht auf, die Seite zu analysieren, nur um externen Inhalt zu laden. Der Versuch, zu helfen, ist nur nützlich, wenn Sie tatsächlich hilfreich sind. Fehlinformationen sind schlimmer als keine Informationen. - raylu
@ Raylu Ich weiß nichts über diese Fehlinformation. Eine Antwort mit vielen Downvotes zu sehen, kann manchmal sehr hilfreich sein. :-) - LarsTech
Hi @ user613326: Wir ermutigen hier zu ehrlichen Abstimmungen, da wir in erster Linie hier sind, um nützliche Antworten für die Community zu geben. Nimm es nicht persönlich! - Flimm