Cloud und Internet

Warum zeigen Webseiten ihren Text nicht sofort an?



Wenn Sie dazu neigen, den Browserbereich mit einem Adlerauge zu beobachten, haben Sie vielleicht bemerkt, dass Seiten häufig ihre Bilder und ihr Layout laden, bevor sie ihren Text laden – das genau entgegengesetzte Lademuster, das wir in den 1990er Jahren erlebt haben. Was ist los?

Die heutige Frage-und-Antwort-Sitzung kommt mit freundlicher Genehmigung von SuperUser – einer Unterabteilung von Stack Exchange, einer Community-gesteuerten Gruppierung von Q&A-Websites.

Die Frage

SuperUser-Leser Laurent ist sehr neugierig, warum genau Seiten Elemente ganz anders zu laden scheinen als früher. Er schreibt:

Mir ist aufgefallen, dass in letzter Zeit viele Websites ihren Text nur langsam anzeigen. Normalerweise werden der Hintergrund, Bilder usw. geladen, aber kein Text. Nach einiger Zeit taucht der Text hier und da auf (nicht immer alles gleichzeitig).

Es funktioniert im Grunde das Gegenteil wie früher, als zuerst der Text angezeigt wurde, dann die Bilder und der Rest wurde danach geladen. Welche neue Technologie verursacht dieses Problem? Irgendeine Idee?

Beachten Sie, dass ich eine langsame Verbindung habe, was das Problem wahrscheinlich noch verstärkt.

Sehen [above] zum Beispiel – alles ist geladen, aber es dauert noch ein paar Sekunden, bis der Text endlich angezeigt wird.

Was gibt es also? Laurent und viele von uns erinnern sich an eine Zeit, als der Text zuerst geladen wurde und alles andere – grell animierte GIFs, gekachelte Hintergründe und all die anderen Artefakte des Webbrowsings der späten 90er – später kamen. Was bewirkt die aktuelle Situation von Gestaltungselementen zuerst, Text später?

Die Antwort

SuperUser-Mitwirkender Daniel Andersson bietet eine wunderbar detaillierte Antwort, die dem Geheimnis, warum die Schriftarten geladen sind, auf den Grund geht:

Ein Grund ist, dass Webdesigner heutzutage gerne Webfonts verwenden (normalerweise in WOFF Format), zB durchGoogle Webfonts.

Bisher konnten auf einer Site nur die Schriftarten angezeigt werden, die der Benutzer lokal installiert hatte. Da zB Mac- und Windows-Benutzer nicht unbedingt die gleichen Schriftarten hatten, legten Designer instinktiv immer Regeln wie

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

Wenn die erste Schriftart auf dem System nicht gefunden wurde, würde der Browser nach der zweiten suchen und schließlich nach einer „sans-serif“-Fallback-Schriftart.

Jetzt kann man als CSS-Regel eine Schriftart-URL angeben, um den Browser dazu zu bringen, eine Schriftart herunterzuladen:

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

und laden Sie dann die Schriftart für ein bestimmtes Element, indem Sie zB:

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

Dies ist sehr beliebt, um benutzerdefinierte Schriftarten verwenden zu können, führt aber auch zu dem Problem, dass kein Text angezeigt wird, bis die Ressource vom Browser geladen wurde, was die Downloadzeit, die Ladezeit der Schriftart und die Renderzeit umfasst. Ich gehe davon aus, dass dies das Artefakt ist, das Sie erleben.

Als Beispiel: eine meiner überregionalen Zeitungen, Dagens Nyheter, verwenden Sie Webfonts für ihre Schlagzeilen, aber nicht für ihre Leads. Wenn diese Site geladen wird, sehe ich normalerweise zuerst die Leads und eine halbe Sekunde später werden alle Leerzeichen oben mit Schlagzeilen gefüllt (dies gilt für Chrome und Opera, at mindestens. Habe noch keine anderen ausprobiert).

(Außerdem streuen Designer heutzutage JavaScript absolut überall ein, also versucht vielleicht jemand etwas Schlaues mit dem Text zu machen, weshalb er verzögert wird. Das wäre jedoch sehr standortspezifisch: die allgemeine Tendenz, dass Text in diesen verzögert wird mal ist das oben beschriebene Problem mit den Webfonts, glaube ich.)

Zusatz:

Diese Antwort wurde sehr positiv bewertet, obwohl ich nicht ins Detail gegangen bin, oder vielleicht weil von diesem. Es gab viele Kommentare im Fragethread, daher werde ich versuchen, etwas zu erweitern […]

Das Phänomen ist offenbar allgemein als „Flash of Unstyled Content“ und im Besonderen „Flash of Unstyled Text“ bekannt. Wenn Sie nach „FOUC“ und „FOUT“ suchen, erhalten Sie weitere Informationen.

kann ich empfehlen Beitrag des Webdesigners Paul Irish auf FOUT im Zusammenhang mit Webfonts.

Auffällig ist, dass verschiedene Browser dies unterschiedlich handhaben. Ich habe oben geschrieben, dass ich Opera und Chrome getestet habe, die sich beide ähnlich verhielten. Alle WebKit-basierten (Chrome, Safari usw.) vermeiden FOUT durch nicht Rendern von Webschrifttext mit einer Fallback-Schriftart während des Ladezeitraums der Webschrift Selbst wenn die Webschrift wird zwischengespeichert, da werden eine Renderverzögerung sein. Es gibt viele Kommentare in diesem Fragethread, die etwas anderes sagen und dass es absolut falsch ist, dass sich zwischengespeicherte Schriftarten so verhalten, aber z. B. aus dem obigen Link:

In welchen Fällen erhalten Sie eine FOUT

  • Wille: Herunterladen und Anzeigen eines entfernten 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 bereits installierten und benannten Schriftart in Ihrem herkömmlichen Schriftartenstapel
  • Wird nicht: Anzeigen einer installierten und mit dem local()-Speicherort benannten Schriftart

Da Chrome wartet, bis das FOUT-Risiko vor dem Rendern verschwunden ist, führt dies zu einer Verzögerung. Zu welchem Umfang der Effekt ist sichtbar (insbesondere beim Laden aus dem Cache) scheint unter anderem von der zu rendernden Textmenge und möglicherweise anderen Faktoren abhängig zu sein, aber Caching beseitigt den Effekt nicht vollständig.

Irish hat auch einige Updates zum Browserverhalten vom 14.04.2011 am Ende des Beitrags:

  • Feuerfuchs (ab FFb11 und FF4 Finale) hat kein 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 jedoch wahrscheinlich innerhalb dieser drei Sekunden geladen… hoffentlich…
  • IE9 unterstützt WOFF und TTF und OTF (obwohl es erforderlich ist) ein Einbettungsbitsetze ding– meist strittig, wenn Sie WOFF verwenden). JEDOCH!!! IE9 hat ein FOUT. 🙁
  • Webkit hat ein Patch, der darauf wartet, zu landen um Fallback-Text nach 0,5 Sekunden anzuzeigen. Also gleiches Verhalten wie FF, aber 0,5s statt 3s.

Wenn dies eine Frage für Designer wäre, könnte man Wege gehen, um diese Art von Problemen zu vermeiden, wie z webfontloader, aber das wäre eine andere Frage. Der Paul Irish Link geht auf diese Angelegenheit näher ein.


Möchten Sie der Erklärung noch etwas hinzufügen? Ton in den Kommentaren ab. Möchten Sie mehr Antworten von anderen technisch versierten Stack Exchange-Benutzern lesen? Den vollständigen Diskussionsthread finden Sie hier.



Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Schaltfläche "Zurück zum Anfang"