☰

Warum zeigen Websites ihren Text heutzutage nicht sofort an?

tag-icon • tag-icon performance browser display webkit
Warum zeigen Websites ihren Text heutzutage nicht sofort an?

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 erscheint der Text hier und da (nicht immer der gesamte Text gleichzeitig).

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

Beachten Sie, dass ich eine langsame Verbindung habe, was das Problem wahrscheinlich verschärft.

Unten sehen Sie ein Beispiel – alles wird geladen, aber es dauert noch ein paar Sekunden, bis der Text schließlich angezeigt wird:

Bildbeschreibung hier eingeben

Antwort1

Ein Grund dafür ist, dass Webdesigner heutzutage gerne Webfonts verwenden (normalerweise inWOFFFormat), z. B. durchGoogle Web Fonts.

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

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

Wenn die erste Schriftart auf dem System nicht gefunden wird, sucht der Browser nach der zweiten und zuletzt nach einer Ersatzschriftart ohne Serifen.

Nun kann man die URL einer Schriftart als CSS-Regel angeben, damit der Browser eine Schriftart herunterlädt, und zwar etwa so:

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

und laden Sie dann die Schriftart für ein bestimmtes Element, beispielsweise durch:

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.

Ein Beispiel: Eine meiner nationalen Zeitungen,Tagesnachrichten, verwenden Webfonts für ihre Überschriften, aber nicht für die Leads, sodass ich beim Laden der Site normalerweise zuerst die Leads sehe und eine halbe Sekunde später alle leeren Bereiche darüber mit Überschriften gefüllt sind (das trifft zumindest auf Chrome und Opera zu. Andere habe ich noch nicht ausprobiert).

(Außerdem verwenden Designer heutzutage überall JavaScript, also versucht vielleicht jemand etwas Cleveres mit dem Text zu machen, weshalb er verzögert wird. Das wäre allerdings sehr sitespezifisch: Die allgemeine Tendenz zur Textverzögerung heutzutage ist, glaube ich, das oben beschriebene Problem mit Webfonts.)

Zusatz

Diese Antwort wurde sehr positiv bewertet, obwohl ich nicht sehr ins Detail gegangen bin, oder vielleichtWeildavon. Es gab viele Kommentare im Fragen-Thread, also werde ich versuchen, sie ein wenig zu erweitern (viele Kommentare scheinen kurz nach dem Schutz des Themas verschwunden zu sein – ein Moderator hat sie wahrscheinlich manuell bereinigt). Lesen Sie auch die anderen Antworten in diesem Thread, da sie alle auf ihre eigene Weise erweitert werden.

Das Phänomen ist offenbar allgemein als „Flash of unstyled content“ und insbesondere als „Flash of unstyled text“ bekannt. Eine Suche nach „FOUC“ und „FOUT“ liefert weitere Informationen.

Ich kann empfehlenBeitrag des Webdesigners Paul Irish auf FOUT im Zusammenhang mit Webfonts.

Was man beachten kann, 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 Browser (Chrome, Safari usw.) vermeiden FOUT durchnichtRendern von Webfont-Text mit einer Ersatzschriftart während der Ladezeit des Webfonts.Selbst wennder Webfont wird zwischengespeichert, esWilleeine Renderverzögerung sein. In diesem Fragenthread gibt es viele Kommentare, die das Gegenteil behaupten und sagen, dass es schlichtweg falsch ist, dass sich zwischengespeicherte Schriftarten so verhalten. Hier ein Beispiel aus dem obigen Link:

In welchen Fällen erhalten Sie ein FOUT

  • Wille:Herunterladen und Anzeigen eines Remote-TTF/OTF/WOFF
  • Wille:Anzeige 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 in Ihrem herkömmlichen Schriftartenstapel installiert und benannt ist
  • Wird nicht:Anzeigen einer Schriftart, die unter Verwendung des Speicherorts local() installiert und benannt wurde

Da Chrome wartet, bis das FOUT-Risiko vor dem Rendern verschwunden ist, kommt es zu einer Verzögerung.AusmaßDer Effekt ist sichtbar (insbesondere beim Laden aus dem Cache). Er scheint unter anderem von der Menge des zu rendernden Textes und möglicherweise anderen Faktoren abhängig zu sein, aber durch das Zwischenspeichern wird der Effekt nicht vollständig entfernt.

Irish bietet am Ende des Beitrags auch einige Aktualisierungen zum Browserverhalten vom 14.04.2011:

  • Feuerfuchs(Stand FFb11 und FF4 Final)hat kein FOUT mehr!Juhuu!http://bugzil.la/499292Der Text ist im Grunde 3 Sekunden lang unsichtbar und wird dann wieder mit der Ersatzschriftart angezeigt. Die Webschriftart wird aber wahrscheinlich innerhalb dieser drei Sekunden geladen … hoffentlich …
  • IE9 unterstützt WOFF und TTF und OTF (erfordert jedochein Einbettungsbit Sache festlegen– größtenteils hinfällig, wenn Sie WOFF verwenden).ABER!!! IE9 hat ein FOUT.:(
  • Webkit hatein Fleck, der darauf wartet, zu landenum Fallback-Text nach 0,5 Sekunden anzuzeigen. Also dasselbe Verhalten wie FF, aber 0,5 s statt 3 s.
  • Zusatz: Blink hatauch hierfür wurde ein Fehler registriert, aber es scheint, dass noch kein endgültiger Konsens darüber erzielt wurde, was damit geschehen soll – derzeit dieselbe Implementierung wie WebKit.

Wenn diese Frage an Designer gerichtet wäre, könnte man auf Möglichkeiten eingehen, diese Art von Problemen zu vermeiden, wie zum Beispielwebfontloader, aber das wäre eine andere Frage. Der Paul Irish-Link geht näher auf dieses Thema ein.

Antwort2

Der Grund hierfür ist, dass der Text, den Sie noch nicht lesen können, miteine Web-Schriftartdas sich noch auf dem Weg zu Ihrem Browser befindet.

Da Ihr Browser Google Chrome ist und WebKit zum Rendern der Seite verwendet,es wurde von ihnen entschieden(WebKit, also), dass es für Sie am besten ist, überhaupt keinen Text zu sehen, bis die Webschriftart heruntergeladen ist. Wenn Sie jedoch ein Entwickler sind, der es vorzieht, dass der Text stattdessen in einer geeigneten Ersatzsystemschriftart lesbar ist, können Sie etwas wieGoogles WebFont Loaderum das zu erreichen.

Antwort3

Kurze Antwort:AJAXoderWOFF

Es gibtmehrere Ursachenvon Websites, die"zeigt ihren Text langsam an"Die Langsamkeit aufwww.portableapps.comwird durch das Herunterladen verursachtWOFFSchriftarten. Was Sie jedoch als"hier und da taucht Text auf"wird häufiger verursacht durchAJAX.

Eine Website besteht aus vielen Teilen. Wie diese Teile heruntergeladen und zusammengesetzt werden, ist eineDesignauswahlunter der Kontrolle derWebdesignerDie Langsamkeit wird durch die Art und Weise verursacht, wie der Entwickler die folgenden Bausteine ​​zusammensetzt:

  • Anfängliche HTML-Seite
  • CSS
  • JS
  • Bilder
  • WOFF-Schriftarten
  • AJAX-Anfragen
  • DOM-Manipulation

Traditionelle Websites:

Traditionell war es üblich, dass Entwickler den Textinhalt in denanfängliche HTML-Seiteund zeigen Sie es ansobald es verfügbar war. Das HTML würde auf mehrere Ressourcen verweisen, die dann heruntergeladen würden. Der Browser würde dannschrittweise neu zeichnender Bildschirm, um die Stile und Bilder einzuschließen, sobald sie verfügbar waren. AJAX und WOFF waren nicht verfügbar.

WOFF-Websites:

WOFF-Schriftarten ermöglichen es einer Website, Schriftarten zu verwenden, die normalerweise nicht im Browser verfügbar sind, indemHerunterladen von Schriftarten über die Website. Einige Entwickler weisen den Browser an, den Textinhalt erst anzuzeigen, wenn alle WOFF-Schriftarten heruntergeladen wurden. Meiner Erfahrung nach hat sich dieser Ansatz noch nicht sehr weit verbreitet.

AJAX-Websites:

Einige Entwickler entscheiden sich dafür, den Textinhalt nicht in die ursprüngliche HTML-Seite einzubinden. Stattdessen laden sie den Textinhalt mit AJAX herunter. Dies geschiehtnachdem die Basisseite geladen wurde. Meiner Erfahrung nach hat diese Methode viel gewonnenbreitere Akzeptanzals WOFF-Schriftarten und ist meistens die Ursache für die von Ihnen beschriebene Langsamkeit.

Ermittlung der Ursache

Um die Ursache für eine bestimmte Site zu ermitteln, ist eine Analyse mit Tools wieFeuerwanzeoderChrome-EntwicklertoolsAlternativ können Sie die Site auch öffnen mitInternet Explorer 8, das AJAX, aber nicht WOFF unterstützt. Wenn die Site immer noch langsam ist, liegt das Problem an AJAX und nicht an WOFF.

Antwort4

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

Um ein wenig mehr Hintergrund zu geben: Der Browser macht ungefähr Folgendes, bevor er den Seiteninhalt auf dem Bildschirm darstellen kann:

  1. HTML abrufen (mehrere Roundtrips für DNS, TCP, Anfrage/Antwort)
  2. Beginnen Sie mit der Analyse von HTML und entdecken Sie externe Ressourcen wie externes CSS und JS. Beachten Sie, dass CSS das Layout und JS die Analyse blockiert. Externe Ressourcen wie CSS und JS, die früh im Dokument geladen werden (z. B. im Kopf), verlangsamen also die Zeit, die eine Seite benötigt, um Inhalte auf dem Bildschirm anzuzeigen.
  3. externes CSS und JS abrufen (mehrere Roundtrips: DNS und TCP, wenn sich diese Ressourcen in einer anderen Domäne wie CDN befinden, sowie ein RTT für die Anfrage/Antwort)
  4. Sobald das externe CSS und JS fertig geladen sind, JS analysieren/ausführen, Stile analysieren/anwenden
  5. Wenn das CSS auf benutzerdefinierte Schriftarten verweist, müssen diese Schriftarten nun ebenfalls heruntergeladen werden, was zu zusätzlichen Verzögerungen beim Rendern aller Teile der Seite führt, die von den benutzerdefinierten Schriftarten abhängen.

Obwohl es hier nicht speziell um die Verzögerungen geht, die durch benutzerdefinierte Schriftarten verursacht werden, habe ich kürzlich einen Blog-Beitrag geschrieben, der zusätzliche Informationen zu den Ursachen von Renderverzögerungen enthält. Er enthält einige Vorschläge, um die Zeit bis zum ersten Malen Ihrer Seiten zu minimieren. Hoffentlich ist dies für Leser nützlich, die daran interessiert sind, dass ihre Seiten Inhalte schneller anzeigen, einschließlich der Seiten, die benutzerdefinierte Schriftarten verwenden möchten:http://calendar.perfplanet.com/2012/make-your-mobile-pages-render-in-under-one-second/

verwandte Informationen