Warum zeigen Webseiten ihren Text nicht sofort an?

Wenn Sie das Browser-Fenster mit einem Adlerauge betrachten möchten, haben Sie vielleicht bemerkt, dass Seiten ihre Bilder und das Layout häufig laden, bevor sie ihren Text laden - genau das entgegengesetzte Lademuster wie in den 1990ern. Was ist los?

Heutige Frage &Die Antwortsitzung kommt dank SuperUser, einer Unterteilung von Stack Exchange, einer Community-gesteuerten Gruppierung von Q & A-Websites, zu uns.

Die Frage

SuperUser Leser Laurent ist sehr neugierig darauf, warum genau Seiten Elemente völlig anders zu laden scheinen als früher. Er schreibt:

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).

Es funktioniert grundsätzlich das Gegenteil wie früher, 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.

Siehe [oben] für ein Beispiel - alles ist geladen, aber es dauert noch ein paar Sekunden, bis der Text endlich angezeigt wird.

Also was gibt's? Laurent, und viele von uns, erinnern sich an eine Zeit, als der Text zuerst geladen wurde und alles andere - garrische animierte GIFs, gekachelte Hintergründe und all die anderen Artefakte des Internets der späten 90er - kamen später. Was verursacht die aktuelle Situation von Designelementen zuerst, Text später?

Der Antwort-

-SuperUser-Mitwirkende Daniel Andersson bietet eine wunderbar detaillierte Antwort, die das Geheimnis der "Why-the-Fonts-Load-Last" -Serie auf den Grund bringt:

Ein Grund dafür ist, dass Web-Designer heutzutage gerne Web-Fonts verwenden( normalerweise im WOFF-Format)), z. Büber 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-Anwender hatten nicht unbedingt die gleichen Schriften, Designer definierten instinktiv immer Regeln wie die

-Schriftfamilie: Arial, Helvetica, Sans-Serif;

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

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 dann laden Sie die Schriftart für ein bestimmtes Element von z. B.:

Schriftfamilie: 'Droid Serif', Sans-Serif;

Dies ist sehr populär, 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 Zeichensatzladezeit und der Renderzeit. Ich erwarte, dass dies das Artefakt ist, das Sie erleben.

Als Beispiel: Eine meiner überregionalen Zeitungen, Dagens Nyheter, verwenden 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 alle Leerstellenbevölkert mit Überschriften( das gilt zumindest für Chrome und Opera. Habe noch keine anderen ausprobiert).

( 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 ortsspezifisch: Die generelle Tendenz, dass Text verzögert wirdDiese Zeiten sind das oben beschriebene Webfonts-Problem, glaube ich.)

-Zusatz:

Diese Antwort wurde sehr hochgestuft, obwohl ich nicht sehr ins Detail ging, oder vielleicht , weil dies ist. Es gab viele Kommentare im Fragethread, also werde ich versuchen, etwas zu erweitern. [...]

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.

Ich kann Web-Designer Paul Irish's Post auf FOUT in Verbindung mit Web-Fonts empfehlen.

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 usw.) wählen, FOUT von zu vermeiden, nicht , um Web-Schriftarttext mit einer Fallback-Schriftart während des Ladens der Web-Schriftart zu rendern. Auch wenn die Webschriftart zwischengespeichert wird, wird 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.von dem obigen Link:

In welchen Fällen erhalten Sie einen FOUT

• Will: Herunterladen und Anzeigen eines Remote-ttf /otf/ woff
• Wird: Anzeigen eines zwischengespeicherten ttf /otf/ woff
• Wird: Herunterladen und Anzeigen eines Daten-URI ttf /otf/ woff
• Will: Anzeigen eines zwischengespeicherten Daten-URI ttf /otf/ woff
• Wird nicht angezeigt: Anzeigen einer Schriftart, die bereits installiert und in Ihrem traditionellen Schriftartenstapel
• benannt ist Nicht möglich: Anzeigen einer Schriftart, die mit local() installiert und benannt wirdStandort

Da Chrome wartet, bis das FOUT-Risiko vor dem Rendern weg ist, ergibt sich eine Verzögerung. Auf welchen Extent der Effekt sichtbar ist( insbesondere beim Laden aus dem Cache) scheint unter anderem von der Menge an Text, die gerendert werden soll, 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:

• Firefox ( ab FFb11 und FF4 Final) hat keine 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 eine eingebettete Bitset-Sache erfordert - meistens, wenn Sie WOFF verwenden). JEDOCH! !!IE9 hat eine FOUT.:(
• Webkit hat einen Patch, der darauf wartet, nach 0.5 Sekunden zu landen, um den Fallback-Text anzuzeigen. Also dasselbe Verhalten wie FF, aber 0.5s statt 3s.

Wenn das eine Frage an Designer wäre, könnte man solche Wege vermeidenvon Problemen wie webfontloader, aber das wäre eine andere Frage. Der Paul Irish Link geht in dieser Angelegenheit weiter ins Detail.

Haben Sie etwas, um die Erklärung hinzuzufügen? Hören Sie in den Kommentaren auf. Möchten Sie mehr Antworten von anderen Technologien lesen? Erfahrene Stack Exchange-Benutzer? Sehen Sie sich den vollständigen Diskussionsfaden hier an