Warum zeigen Webseiten ihren Text nicht sofort an?

Wenn Sie dazu neigen, das Browserfenster mit einem Adlerauge zu betrachten, haben Sie möglicherweise bemerkt, dass Seiten häufig Bilder und Layout laden, bevor sie ihren Text laden - genau das entgegengesetzte Lademuster, das wir in den 1990er Jahren erlebt haben. Was ist los?

Die heutige Question & Answer-Sitzung wird dank SuperUser zur Verfügung gestellt - einer Unterteilung von Stack Exchange, einer Community-basierten Gruppierung von Q & A-Websites.

Die Frage

Superuser-Leser Laurent ist sehr neugierig, warum genau Elemente scheinbar ganz anders geladen werden als früher. Er schreibt:

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

Im Grunde funktioniert es genau umgekehrt, wenn der Text zuerst angezeigt wurde, dann die Bilder und der Rest danach geladen wurde. Welche neue Technologie schafft dieses Problem? Irgendeine Idee?

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

Ein Beispiel finden Sie in [oben] - alles ist geladen, aber es dauert einige Sekunden, bis der Text angezeigt wird.

Was gibt es? Laurent und viele von uns erinnern sich an eine Zeit, als der Text zuerst geladen wurde und alles andere - garrish animierte GIFs, gekachelte Hintergründe und alle anderen Artefakte des Webbrowsers der späten 90er Jahre - später kamen. Was verursacht die aktuelle Situation von Gestaltungselementen zuerst, später Text?

Die Antwort

Der SuperUser-Mitwirkende Daniel Andersson bietet eine wunderbar detaillierte Antwort, die dem Rätsel um Warum-die-Schriftarten-Last-Letzten auf den Grund geht:

Ein Grund ist, dass Webdesigner heutzutage gerne Webfonts (normalerweise im WOFF-Format) verwenden, z. throughGoogle-Webfonts.

Bisher konnten auf einer Website nur Schriftarten angezeigt werden, die der Benutzer lokal installiert hatte. Da z.B. Mac- und Windows-Benutzer hatten nicht notwendigerweise die gleichen Schriftarten, Designer definierten instinktiv immer Regeln als
Schriftfamilie: Arial, Helvetica, Serifenlose; 
Wenn der erste Zeichensatz nicht auf dem System gefunden wurde, suchte der Browser nach dem zweiten Zeichensatz und schließlich nach einem Fall-Sans-Serif-Zeichensatz.

Nun kann man eine Schriftart-URL als CSS-Regel angeben, damit der Browser eine Schriftart herunterladen kann:
@import url (http://fonts.googleapis.com/css?family=Droid+Serif:400,700); 
Laden Sie dann die Schriftart für ein bestimmtes Element, indem Sie z.
Schriftfamilie: 'Droid Serif', serifenlos; 
Dies ist sehr beliebt, um benutzerdefinierte Schriftarten verwenden zu können, es führt jedoch auch zu dem Problem, dass kein Text angezeigt wird, bis die Ressource vom Browser geladen wurde. Dazu gehören die Downloadzeit, die Ladezeit der Schriftart und die Renderzeit. Ich gehe davon aus, dass dies das Artefakt ist, das Sie erleben.

Ein Beispiel: Eine meiner nationalen Zeitungen, Dagens Nyheter, verwendet Webschriftarten für ihre Schlagzeilen, nicht jedoch für ihre Leads. Wenn diese Website geladen ist, sehe ich normalerweise zuerst die Leads, und eine halbe Sekunde später sind alle darüber liegenden Leerzeichen belegt mit Schlagzeilen (dies gilt zumindest für Chrome und Opera. Ich habe andere nicht ausprobiert).

(Außerdem streuen Designer heutzutage absolut überall JavaScript, daher versucht jemand vielleicht, etwas Kluges mit dem Text zu tun, weshalb er verzögert wird. Dies wäre jedoch sehr ortsspezifisch: die allgemeine Tendenz, dass Text in diesen verzögert wird Ich glaube, mal ist das oben beschriebene Problem mit Web-Fonts.)

Zusatz:

Diese Antwort wurde sehr positiv, obwohl ich nicht viel ins Detail ging oder vielleicht da von diesem. Es gab viele Kommentare im Frage-Thread, also versuche ich ein wenig zu erweitern […]

Das Phänomen ist anscheinend allgemein als "Blitz von nicht gestylten Inhalten" und "Blitz von ungestyltem Text" im Besonderen bekannt. Die Suche nach “FOUC” und “FOUT” liefert weitere Informationen.

Ich kann den Beitrag des Webdesigners Paul Irish zu FOUT in Verbindung mit Webfonts empfehlen.

Was man feststellen kann ist, dass verschiedene Browser dies unterschiedlich behandeln. Ich schrieb oben, dass ich Opera und Chrome getestet hatte, die sich beide ähnlich verhielten. Alle WebKit-basierten (Chrome, Safari usw.) verwenden, um FOUT durch zu vermeiden nicht Rendern von Web-Font-Text mit einer Fallback-Schriftart während des Ladens der Web-Schriftart. Selbst wenn Dort wird die Webschrift zwischengespeichert werden eine Renderverzögerung sein. In diesem Fragenthread gibt es viele Kommentare, die etwas anderes sagen und dass es völlig falsch ist, dass zwischengespeicherte Schriftarten sich so verhalten, aber z. vom obigen Link:

In welchen Fällen erhalten Sie einen FOUT

Wille: Herunterladen und Anzeigen einer Fernbedienung ttf / otf / woff

Wille: Anzeigen eines zwischengespeicherten TTF / OTF / WOFF

Wille: Herunterladen und Anzeigen eines data-uri ttf / otf / woff

Wille: Anzeigen einer zwischengespeicherten Daten-uri ttf / otf / woff

Wird nicht: Anzeigen einer Schrift, die bereits installiert und in Ihrem herkömmlichen Schriftstapel benannt ist

Wird nicht: Anzeigen einer Schrift, die installiert und über den Speicherort local () benannt wird

Da Chrome vor dem Rendern wartet, bis das FOUT-Risiko verschwunden ist, führt dies zu einer Verzögerung. Zu welchem Umfang Der Effekt ist sichtbar (insbesondere beim Laden aus dem Cache). Er scheint abhängig zu sein von der Menge des Textes, die gerendert werden muss, und möglicherweise anderen Faktoren. Durch das Zwischenspeichern wird der Effekt jedoch nicht vollständig beseitigt.

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

Feuerfuchs (ab FFb11 und FF4 Finale) hat keinen FOUT mehr! Wooohoo! Http: //bugzil.la/499292 Grundsätzlich ist der Text 3 Sekunden lang unsichtbar und bringt dann die Fallback-Schriftart zurück. Der Webfont wird wahrscheinlich innerhalb dieser drei Sekunden geladen ... hoffentlich ...

IE9 unterstützt WOFF und TTF und OTF (obwohl ein Bitsatz zum Einbetten erforderlich ist - meistens wenn Sie WOFF verwenden). JEDOCH!!! IE9 hat einen FOUT. :(

Webkit wartet mit einem Patch auf, um nach 0,5 Sekunden einen Fallback-Text anzuzeigen. Also dasselbe Verhalten wie bei FF aber 0,5s statt 3s.

Wenn dies eine Frage an Designer war, könnte man Wege gehen, um solche Probleme wie etwa zu vermeiden Webfontloader, aber das wäre eine andere Frage. Der Paul-Iren-Link geht in dieser Angelegenheit weiter ins Detail.

Haben Sie der Erklärung etwas hinzuzufügen? Ton aus in den Kommentaren. Möchten Sie mehr Antworten von anderen technisch versierten Stack Exchange-Benutzern lesen? Hier geht es zum vollständigen Diskussionsthread.