Warum zeigen Websites heutzutage ihren Text nicht sofort an?

Mir ist aufgefallen, dass in letzter Zeit auf vielen Websites der Text nur langsam angezeigt wird. Normalerweise werden der Hintergrund, Bilder usw. geladen, aber kein Text. Nach einiger Zeit erscheint der Text hier und da (nicht immer alles zur gleichen Zeit).

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

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

Ein Beispiel finden Sie unten - alles ist geladen, aber es dauert noch ein paar Sekunden, bis der Text schließlich angezeigt wird:

Ein Grund dafür ist, dass Webdesigner heutzutage gerne Webfonts (normalerweise im WOFF- Format) verwenden, z. B. über Google Webfonts .

Bisher konnten nur die vom Benutzer lokal installierten Schriftarten auf einer Site angezeigt werden. Da z. B. Mac- und Windows-Benutzer nicht unbedingt die gleichen Schriftarten hatten, definierten Designer instinktiv immer Regeln wie

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

Wäre die erste Schriftart nicht auf dem System vorhanden, würde der Browser nach der zweiten und schließlich nach einer "serifenlosen" Ersatzschrift suchen.

Jetzt kann man eine Schriftart-URL als CSS-Regel angeben, damit der Browser eine Schriftart als solche herunterlädt:

@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 verwenden zu können, es führt jedoch auch zu dem Problem, dass kein Text angezeigt wird, bis die Ressource vom Browser geladen wurde, einschließlich der Downloadzeit, der Ladezeit der Schriftarten und der Renderzeit. Ich gehe davon aus, dass dies das Artefakt ist, das Sie erleben.

Als Beispiel: Eine meiner nationalen Zeitungen, Dagens Nyheter , verwendet Web-Schriftarten als Überschriften, nicht jedoch als Ableitungen. Wenn diese Site geladen wird, werden in der Regel die Ableitungen zuerst und eine halbe Sekunde später alle darüber liegenden Leerzeichen ausgefüllt mit Schlagzeilen (dies gilt zumindest für Chrome und Opera. Habe noch keine anderen ausprobiert).

(Außerdem streuen Designer JavaScript heutzutage absolut überall hin, also versucht vielleicht jemand, etwas Kluges mit dem Text zu machen, weshalb er verzögert wird. Das wäre jedoch sehr site-spezifisch: Die allgemeine Tendenz, dass sich der Text in diesen verzögert Mal ist das oben beschriebene Webfont-Problem, glaube ich.)

Zusatz

Diese Antwort wurde sehr positiv aufgenommen, obwohl ich nicht sehr ins Detail gegangen bin, oder vielleicht deswegen . Da der Fragenthread viele Kommentare enthält, werde ich versuchen, ihn ein wenig zu erweitern (viele Kommentare scheinen kurz nach dem Schutz des Themas verschwunden zu sein - einige Moderatoren haben 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 anscheinend allgemein als "Flash eines nicht gestalteten Inhalts" und insbesondere als "Flash eines nicht gestalteten Texts" bekannt. Suche nach "FOUC" und "FOUT" gibt weitere Informationen.

Ich kann den Beitrag von Webdesigner Paul Irish auf FOUT im Zusammenhang mit Webfonts empfehlen .

Was man beachten kann ist, dass verschiedene Browser dies unterschiedlich behandeln. Ich habe oben geschrieben, dass ich Opera und Chrome getestet habe, die sich beide ähnlich verhalten haben. Alle WebKit-basierten (Chrome, Safari usw.) vermeiden FOUT, indem sie während des Ladezeitraums für Web-Schriftarten keinen Web-Schrifttext mit einer Ersatzschrift rendern. Selbst wenn die Webschrift zwischengespeichert wird, kommt es zu einer Renderverzögerung . Es gibt viele Kommentare in diesem Fragenthread, in denen etwas anderes gesagt wird, und dass es absolut falsch ist, dass sich zwischengespeicherte Schriften wie folgt verhalten, aber z. B. über den obigen Link:

In welchen Fällen erhalten Sie eine FOUT

• Will: Herunterladen und Anzeigen eines Remote-TTF / OTF / Woff
• Will: Zeigt ein zwischengespeichertes ttf / otf / woff an
• Will: Herunterladen und Anzeigen eines Daten-Uri-TTF / OTF / Woff
• Will: Anzeige eines zwischengespeicherten Daten-Uri-TTF / OTF / Woff
• Wird nicht: Anzeigen einer Schriftart, die bereits installiert und in Ihrem traditionellen Schriftstapel benannt ist
• Wird nicht: Anzeigen einer Schriftart, die unter Verwendung des lokalen () Speicherorts installiert und benannt ist

Da Chrome vor dem Rendern wartet, bis das FOUT-Risiko beseitigt ist, tritt eine Verzögerung ein. Zu welchem Ausmaß die Wirkung sichtbar ist (vor allem , wenn aus dem Cache geladen) scheint unter anderem die Menge an Text abhängig zu sein, und vielleicht auch andere Faktoren gemacht werden muss, aber das Caching nicht vollständig entfernt den Effekt.

Irish hat am Ende des Beitrags auch einige Aktualisierungen zum Browserverhalten (Stand 2011/04/14) veröffentlicht:

• Firefox (ab FFb11 und FF4 Final) hat keine FOUT mehr! Wooohoo! http://bugzil.la/499292 Grundsätzlich ist der Text 3 Sekunden lang unsichtbar und bringt dann die Ersatzschrift zurück. Das Webfont wird wahrscheinlich innerhalb dieser drei Sekunden geladen ... hoffentlich ...
• IE9 unterstützt WOFF und TTF und OTF (obwohl es eine eingebettete Bit- Set-Sache erfordert - meistens streitig, wenn Sie WOFF verwenden). JEDOCH!!! IE9 hat einen FOUT. :(
• Webkit hat einen Patch, der darauf wartet, nach 0,5 Sekunden als Ersatztext angezeigt zu werden. Also dasselbe Verhalten wie FF, aber 0,5s statt 3s.
• Ergänzung : Blink hat auch dafür einen Fehler registriert , aber es scheint, dass noch kein endgültiger Konsens darüber erzielt wurde, was damit zu tun ist - derzeit dieselbe Implementierung wie WebKit.

Wenn dies eine Frage für Designer wäre, könnte man nach Wegen suchen, um solche Probleme zu vermeiden webfontloader, aber das wäre eine andere Frage. Der Paul Irish Link geht auf diese Angelegenheit näher ein.

Der Grund dafür ist der Text , den Sie noch nicht lesen kann , wird mit gerendert wird eine Web - Schriftart , die nach unten die Rohre an Ihren Browser immer noch auf dem Weg ist.

Da es sich bei Ihrem Browser um Google Chrome handelt, das WebKit zum Rendern der Seite verwendet, wurde von diesen entschieden (das heißt, WebKit), dass Sie am besten überhaupt keinen Text sehen, bis die Webschrift heruntergeladen ist. Wenn Sie jedoch ein Entwickler sind, der den Text lieber in einer geeigneten Fallback-Systemschrift lesen möchte , können Sie dies mit dem WebFont Loader von Google erreichen.

Kurze Antwort: Ajax oder Wuff

Es gibt verschiedene Gründe dafür, dass Websites "nur langsam ihren Text anzeigen" . Die Langsamkeit auf portableapps.com wird durch das Herunterladen von WOFF- Schriftarten verursacht. Was Sie jedoch als "Text beginnt hier und da zu erscheinen" beschreiben, wird häufiger von AJAX verursacht .

Eine Website besteht aus vielen Teilen. Wie diese Teile heruntergeladen und zusammengestellt werden, hängt von der Designauswahl des Webdesigners ab . Die Langsamkeit wird dadurch verursacht, wie der Entwickler die folgenden Bausteine ​​zusammensetzt:

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

Traditionell Websites:

Traditionell war es für Entwickler üblich, den Textinhalt in die ursprüngliche HTML-Seite einzufügen und anzuzeigen, sobald er verfügbar war . Der HTML-Code verweist auf mehrere Ressourcen, die dann heruntergeladen werden. Der Browser zeichnete den Bildschirm dann nach und nach neu , um die Stile und Bilder einzuschließen, sobald sie verfügbar wurden. AJAX und WOFF waren nicht verfügbar.

WOFF Websites:

Mit WOFF-Schriftarten kann eine Website Schriftarten verwenden, die dem Browser normalerweise nicht zur Verfügung stehen, indem sie Schriftarten mit der Website herunterlädt . Einige Entwickler weisen den Browser an, den Textinhalt erst dann anzuzeigen, wenn alle WOFF-Schriftarten heruntergeladen wurden. Meiner Erfahrung nach ist dieser Ansatz noch nicht sehr verbreitet.

AJAX-Websites:

Einige Entwickler entscheiden sich dafür, den Textinhalt nicht in die ursprüngliche HTML-Seite aufzunehmen. Stattdessen laden sie den Textinhalt mit AJAX herunter. Dies geschieht nach dem Laden der Basisseite . Nach meiner Erfahrung hat diese Methode eine viel breitere Verbreitung als WOFF-Schriften und ist häufig die Ursache für die von Ihnen beschriebene Langsamkeit.

Feststellung der Ursache

Um die Ursache für eine bestimmte Site zu ermitteln, ist eine Analyse mit Tools wie Firebug oder Chrome Developer Tools erforderlich . Alternativ können Sie die Site mit Internet Explorer 8 öffnen , der AJAX, jedoch nicht WOFF unterstützt. Wenn die Site immer noch langsam ist, liegt das Problem bei AJAX und nicht bei WOFF.

Oft ist es eine bewusste Entscheidung, das "Aufblitzen von nicht gestylten Inhalten" zu vermeiden. Wenn der vor dem Laden des CSS angezeigte Text kurz als unformatiert angezeigt wird, wird beim Neuzeichnen durch den Browser ein Flash angezeigt. Durch das Einfügen einiger grundlegender Inline-Stile zum anfänglichen Ausblenden des Inhalts, der im tatsächlichen Stylesheet überschrieben wird, oder durch die Verwendung von JS wird dieser Flash vermieden.

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

Um etwas mehr Hintergrund zu geben, geht der Browser ungefähr so ​​vor, bevor er den Seiteninhalt auf dem Bildschirm rendern kann:

1. HTML holen (mehrere Roundtrips für DNS, TCP, Request / Response)
2. Beginnen Sie mit dem Parsen von HTML, und entdecken Sie externe Ressourcen wie externes CSS und JS. Beachten Sie, dass CSS das Layout und JS das Parsen blockiert. Externe Ressourcen wie CSS und JS, die zu Beginn des Dokuments geladen wurden (z. B. im Kopf), verlangsamen die Zeit, die eine Seite benötigt, um Inhalte auf dem Bildschirm anzuzeigen.
3. Abrufen von externem CSS und JS (mehrere Roundtrips: DNS und TCP, wenn sich diese Ressourcen in einer anderen Domäne befinden, z. B. CDN, sowie eine RTT für die Anforderung / Antwort)
4. Sobald das externe CSS und JS fertig geladen sind, analysieren / führen Sie JS aus und analysieren / wenden Sie Stile an
5. Wenn das CSS auf benutzerdefinierte Schriftarten verweist, müssen diese Schriftarten jetzt ebenfalls heruntergeladen werden, was zu zusätzlichen Roundtrip-Verzögerungen beim Rendern von Teilen der Seite führt, die von den benutzerdefinierten Schriftarten abhängen

Obwohl es nicht um Verzögerungen geht, die speziell durch benutzerdefinierte Schriftarten verursacht werden, habe ich kürzlich einen Blog-Beitrag verfasst, der zusätzliche Informationen zu den Ursachen von Render-Verzögerungen enthält. Es gibt einige Vorschläge, um die Zeit für das erste Malen Ihrer Seiten zu minimieren. Dies ist hoffentlich hilfreich für Leser, die Inhalte auf ihren Seiten schneller anzeigen möchten, einschließlich der Seiten, die benutzerdefinierte Schriftarten verwenden möchten: http://calendar.perfplanet.com/2012/make-your-mobile-pages-render-in-under -eine Sekunde/

Kurze Antwort: Entwickler.

Wenn Verknüpfungs- und Skript-Tags, die auf externe Dokumente verweisen (z. B. CSS- oder JS-Dateien), im Kopf des Dokuments platziert werden (höher im Fluss als der Textkörper und seine Elemente), werden sie zuerst geladen. JavaScript wird aus dem Markup ausgeführt, das darauf verweist. wenn viel Code zu verarbeiten ist oder es sich um umständlichen Code handelt oder wenn der erwartete Text auf einem Server gerendert und beim Laden in das Dokument eingefügt wird - und dieser serverseitige Code auch umständlich ist, Bei großen oder blockierenden E / A-Vorgängen, die auf die Verarbeitung mehrerer gleichzeitiger Anforderungen zurückzuführen sind, kann es zu Ausfallzeiten kommen, bevor der HTML-Code überhaupt gerendert werden konnte. Einige Entwickler wählen das Laden von nicht mit der Ansicht in Zusammenhang stehendem JavaScript nach dem Markup und den Stilen (am Ende des Texts).

Die Geschwindigkeit der Internetverbindung spielt offensichtlich eine Rolle beim langsamen Herunterladen von Daten, aber schlecht geschriebener Code oder schlecht gestaltete Technologiepakete (für die Art der Website) spielen eine zunehmend zentrale Rolle beim langsamen Laden dynamischer Inhalte, da die Netzwerkverbindungen schneller sind Annäherung an die Allgegenwart.

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

Der erste bezieht sich auf alle CSS-, JS- und Webfonts, die auf der Seite geladen werden, ganz zu schweigen von der Tatsache, dass viele Sites auch JSON-Objekte über XHR-Anforderungen abrufen und dann HTML-Code aus diesen mithilfe von Vorlagen generieren müssen.

Aber warum merken sie nicht, dass die Seite langsam ist?

Wahrscheinlich, weil sie irgendwo einen Memecache haben, um die Dinge zu beschleunigen (oder sich nur auf Dateisystem-Caches verlassen) und den Zustand ihrer Site anhand der durchschnittlichen Latenz messen. Somit werden die zwischengespeicherten Objekte mit einer Latenz von 6 Mircrosekunden zurückgegeben und maskieren die Tatsache, dass viele GET-Anforderungen 5000 Millisekunden benötigen, um abgeschlossen zu werden. Durchschnittswerte müssen sterben. Es lebe das Zählen von RTTs über einem akzeptablen Höchstwert! Diese Zahl sollte 0 sein, oder per Definition ist die RTT nicht akzeptabel.

Nun, es gibt mehrere Gründe. Ein Grund ist auch, dass Befehle zum Definieren eines Hintergrunds oder über einer HTML-Seite häufig oder in einem separaten CSS abgerufen werden, das zuerst geladen wird. bevor der Hauptteil des Dokuments geladen wird, der den Text enthält.

Eine andere Ursache ist, dass Webdesigner in den meisten Fällen davon keinen Gebrauch machen, obwohl es möglich ist, die Größe eines Bildes einzugeben. Und so muss der Brouwser zuerst die ganzen Bilder auf die Seiten laden, damit er weiß, wie man Text darum herum schreibt.

Einige Designer, die auch erste Bilder und den nächsten Text anzeigen möchten, erreichen dies durch JavaScript, so dass beispielsweise auf einer einfachen Seite zuerst ein Banner und dann alles andere darauf angezeigt wird.

Aber wenn Sie sich fragen, warum es auf meinen Seiten so viele Spam-Werbematerialien gibt, während ich nur die Nachrichten lesen möchte, 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. Dies führt zu einem viel schnelleren Laden der Seiten, während Sie weiterhin die wichtigen Bilder zu den von Ihnen gelesenen Artikeln sehen können.

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