Warum zeigen Websites ihren Text heute nicht sofort an?

74522
this.lau_

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 unten - alles ist geladen, aber es dauert einige Sekunden, bis der Text schließlich angezeigt wird:

enter image description here

440
In diesem Fall verwendet PortableApps.com die Schriftart "Ubuntu". John versuchte es zuerst mit OpenSans, aber wir wechselten ziemlich schnell zu Ubuntu. Ich war der Hauptbefürworter des Wechsels. Eine Möglichkeit, das Problem zu beheben, besteht darin, die Schriftfamilie selbst installieren zu lassen. Wenn Sie es von http://font.ubuntu.com/ installieren, wird es sofort funktionieren. Chris Morgan vor 11 Jahren 72
Die Antwort von Daniel ist Augenöffner. Ich dachte, das ist absichtlich so gemacht, dass wir alle Anzeigen auf der Seite sehen können. Manoj R vor 11 Jahren 21
As several people have pointed out here, there are infinite reasons for text to render in unexpected ways, as rendering a page is only limited by the imagination of the developer/designer, which has been the case at least since ANSI position codes allowed 1980s bulletin boards to implement multiuser chats and UIs with overlapping windows with drop shadows. Meebo was one of the first to reproduce some of these effects in a browser without an Applet. "Works the opposite as it used to" vastly over-simplifies the Internet and doesn't even refer to a specific time period. PJ Brunet vor 11 Jahren 1
So why make sweeping generalizations about the Internet based on one random screen cap from a website with a low Alexa rank? The best answer also makes a bold claim: "nowadays designers do XYZ" should be backed up with some real numbers, like "5% of websites use Google Web Fonts as of 2012" or whatever it is. PJ Brunet vor 11 Jahren 6
Schriftdateien werden jedoch im Cache gehalten. Diese Website hat lange auf das Laden von m.aspx gewartet, da sie diesen Teil überprüfen könnten user613326 vor 11 Jahren 1
/ me erinnert sich an die Wahl eines Browsers basierend auf "load order" Grady Player vor 11 Jahren 0
@ user613326 Wenn Sie also innerhalb der Site von Seite zu Seite klicken, wird die Verzögerung beim Laden der Schriftart nicht angezeigt. Wenn Sie jedoch auf "Neu laden" klicken, muss der Browser alle zwischengespeicherten Dateien erneut überprüfen und die Verzögerung wird erneut angezeigt. tylerl vor 11 Jahren 0
@tylerl did you try to do a time trace of the page loading? try using fidler (works with FF to) (also reloading each page isnt normal browsing behaviour. But maybe he has a cash size of zero MB.. user613326 vor 11 Jahren 0
@ user613326: Nun, bei Firefox Portable beträgt die Cache-Größe * normalerweise * 0 MB. Ich kann mich nicht erinnern, ob Chrome Portable das hat oder nicht. Chris Morgan vor 11 Jahren 0
@chriss Morgan, nun, nein, das ist nicht voreingestellt, firefox reserviert automatisch eine Cache-Größe, die * variabel ist.> gehen Sie zu> Optionen> Erweitert> Netzwerk-Registerkarte [dort im Cache-Webinhalt]. Sie können die Standardeinstellung überschreiben und auf null oder setzen eine feste Größe Ich würde nicht raten, es auf Null zu setzen, wenn Sie etwas Geschwindigkeit mögen. (* Standardinstallation basierend auf frisch installiertem Linux Mint) Oder Sie sind möglicherweise durch den Offline-Webcontent-Speicher verwirrt, der Offline-Browsing zu einem anderen Thema enthält. In einigen Fällen behalten Sie die Einstellungen bei. user613326 vor 11 Jahren 0
@chriss Wiki says Firefox portable used to disable disk cache. But that this was on the old version 2.0, and it's no longer the default. sourcejedi vor 11 Jahren 0
Ich habe einen Link mit 512 Kbit / s (was im heutigen Alter unterdurchschnittlich ist), und die allgemeine Erfahrung mit der von Ihnen erwähnten Website ist gut, manchmal dauert es eine Millisekunde und manchmal auch nicht. Ich denke, die Designer sollten sich keine Sorgen um die Verwendung von Web-Fonts machen ... Syed Aqeel Ashiq vor 11 Jahren 0

8 Antworten auf die Frage

483
Daniel Andersson

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

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

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

Wenn der erste Zeichensatz nicht auf dem System gefunden wurde, suchte der Browser nach dem zweiten Zeichensatz und zuletzt nach einer "serifenlosen" Fallschrift.

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

und laden Sie dann die Schriftart für ein bestimmtes Element, z.

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. 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 oder aus diesem Grund nicht viel ins Detail ging . Es gab viele Kommentare in dem Fragenthread, also werde ich versuchen, 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 "Blitz von nicht gestylten Inhalten" und "Blitz von ungestyltem Text" im Besonderen bekannt. Wenn Sie nach "FOUC" und "FOUT" suchen, erhalten Sie 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.) vermeiden es, FOUT zu vermeiden, indem der Text der Webschriftart während des Ladens der Webschriftart nicht mit einer Fallback-Schriftart dargestellt wird. Selbst wenn die Webschriftart zwischengespeichert wird, kommt es zu einer Renderverzögerung . Es gibt viele Kommentare in diesem Fragenthread, die etwas anderes sagen und dass es völlig falsch ist, dass sich zwischengespeicherte Schriftarten so verhalten, aber zB über den obigen Link:

In welchen Fällen erhalten Sie einen FOUT

  • Will: Herunterladen und Anzeigen einer Fernbedienung ttf / otf / woff
  • Will: Anzeige eines zwischengespeicherten TTF / otf / woff
  • Will: Herunterladen und Anzeigen einer Daten-uri ttf / otf / woff
  • Will: Anzeige einer zwischengespeicherten Daten-uri ttf / otf / woff
  • Wird nicht: Zeigt eine Schriftart an, die bereits installiert und in Ihrem herkömmlichen Fontstapel benannt ist
  • Wird nicht: Anzeige einer Schriftart, die mit dem Speicherort local () installiert und benannt wird

Da Chrome vor dem Rendern wartet, bis das FOUT-Risiko verschwunden ist, führt dies zu einer Verzögerung. 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 auch einige Updates zum Browserverhalten von 2011–04–14 am Ende des Beitrags hinzugefügt:

  • Firefox (ab FFb11 und FF4 Final) 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 dazu ein Bitsatz 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.
  • Zusatz : Blink hat auch hier 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 an Designer war, könnte man Wege gehen, um solche Probleme wie zu vermeiden webfontloader, aber das wäre eine andere Frage. Der Paul-Iren-Link geht in dieser Angelegenheit weiter ins Detail.

Hat einer der Browser versucht, den Text zuerst in einer verfügbaren Schriftart darzustellen und erneut zu rendern, sobald die bevorzugte Schriftart heruntergeladen wurde? Steve Bennett vor 11 Jahren 7
Oh, duh, kommentiere die nächste Antwort: http://paulirish.com/2009/fighting-the-font-face-fout/ Steve Bennett vor 11 Jahren 4
@ratchetfreak wäre es unangenehm, die Seite neu zu formatieren, da die Schriftarten wahrscheinlich nicht die gleichen Metriken haben würden Samuel Edwin Ward vor 11 Jahren 5
Einige möchten lieber zum Lesen von Webseiten blättern, anstatt zu warten, bis die Schrift geladen ist ratchet freak vor 11 Jahren 6
@SteveBennett Ich bin mir ziemlich sicher, dass Internet Explorer 10 genau das tut. Ich habe später noch nie Text gesehen. Für mich ist es immer Text, der in irgendeiner "Standardschriftart" erscheint, und einige Sekunden später ändert sich der Text in den Stil / Download. Ich bin mir nicht sicher, ob es sich für das nächste CSS oder nur für das Standardsystem des Systems handelt. Edit: Ah, schön, also ist es nur Webikit mit dem versteckten Text? Ich würde dieses nervige und schlechte Benehmen in Betracht ziehen. Gibt es einen Browser, der das Laden progressiver Bilder ignoriert oder verbirgt? Mario vor 11 Jahren 0
@ user613326: Auch wenn die Schrift zwischengespeichert wird, kommt es zu einer Verzögerung. Es gibt viele Leute, die dies in den Kommentaren bestreiten, aber das macht es an sich nicht falsch. Die Analyse- und Renderzeit bleibt auch dann erhalten, wenn die Downloadzeit verstrichen ist (obwohl immer noch Latenzzeiten erforderlich sind, um den HTTP 200 zu empfangen), und auf komplizierten Seiten sind dies erhebliche Verzögerungen. Probier es einfach. Es kann durch Entwicklertricks, wie im verlinkten Blogbeitrag und im Webfontloader-Projekt erwähnt, geändert werden. Dies ist jedoch nicht der eigentliche Schwerpunkt der vorliegenden Frage: _Warum_ passiert das FOUT _Wenn_ passiert? Daniel Andersson vor 11 Jahren 0
Bemerkenswert ist, dass sein Verhalten zumindest in Firefox mit den Einstellungen `gfx.downloadable_fonts.enabled` und` gfx.downloadable_fonts.fallback_delay` kontrolliert werden kann. Ersteres ermöglicht das vollständige Deaktivieren des Ladevorgangs von Webfonts, während die letzten 3 Sekunden bis zur Anzeige der Schriftart über Fallback sind. Soweit ich testen konnte, bedeutet dies, dass der Text direkt angezeigt wird und später der Webfont angewendet wird. Welches ist ein viel wünschenswerteres Verhalten für mich. Bobby vor 11 Jahren 0
Verglichen mit den durchschnittlichen Bildgrößen dieser Tage ist das Herunterladen von Schriftarten relativ klein. In den meisten Fällen zeigen Ihnen Fidler oder der Entwickler-Look von IExplorer oder Entwickler-Look von Firefox (drücken Sie F12), woher Ihr langsamer Seitenaufbau stammt. Meistens wird dies durch externen Code verursacht, wie gehostete Seitenzähler, Google-Statistiken, Analysegeräte für den Datenverkehr oder der Server selbst hat möglicherweise nicht optimierten Java / PHP / ASP-Code. Inhalte für große Websites werden oft in Datenbanken gespeichert, und selbst diese können langsam sein. Während das Seiten-Make-up auf solchen Websites standardmäßig ist (zwischengespeichert) und schnell geladen wird. user613326 vor 9 Jahren 0
117
Marcel

Der Grund dafür ist, dass der Text, den Sie noch nicht lesen können, mit einer Web-Schriftart gerendert wird, die sich noch in den Pipes zu Ihrem Browser befindet.

Da es sich bei Ihrem Browser um Google Chrome handelt, bei dem WebKit zum Rendern der Seite verwendet wird, wurde von ihnen (WebKit) entschieden, dass Sie am besten überhaupt keinen Text sehen, bis die Webschriftart heruntergeladen ist. Wenn Sie jedoch ein Entwickler sind, der stattdessen lieber den Text in einer geeigneten Fall-System-Schriftart lesen soll, können Sie dazu den WebFont Loader von Google verwenden .

Leider ist dies eine falsche Antwort. Wenn Sie diese Seite einmal besuchen würden, würde sich die Schriftartdatei in Ihrem Web-Cash befinden. Für andere Seiten auf dieser Website oder für andere Websites, die diese Schriftart verwenden, wird diese von Bargeld abgerufen. user613326 vor 11 Jahren 0
19
KevSheedy

Kurze Antwort: AJAX oder WOFF

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

Eine Website besteht aus vielen Teilen. Wie diese Teile heruntergeladen und zusammengebaut werden, ist eine Konstruktionsentscheidung unter der Kontrolle des Webdesigners . Die Langsamkeit wird dadurch verursacht, wie der Entwickler die folgenden Bausteine ​​zusammenstellt:

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

Traditionell Websites:

Traditionell war es üblich, dass Entwickler den Textinhalt in die ursprüngliche HTML-Seite einfügen und ihn anzeigen, sobald er verfügbar war . Der HTML-Code würde auf mehrere Ressourcen verweisen, die dann heruntergeladen würden. Der Browser zeichnet dann den Bildschirm schrittweise neu, um die Stile und Bilder aufzunehmen, sobald sie verfügbar sind. AJAX und WOFF waren nicht verfügbar.

WOFF-Websites:

WOFF-Schriftarten ermöglichen es einer Website, Schriftarten zu verwenden, die dem Browser normalerweise nicht zur Verfügung stehen, indem Schriftarten mit der Website heruntergeladen werden . Einige Entwickler weisen den Browser an, den Textinhalt erst anzuzeigen, wenn alle WOFF-Schriftarten heruntergeladen wurden. Nach meiner Erfahrung hat dieser Ansatz noch keine breite Anwendung gefunden.

AJAX-Websites:

Einige Entwickler entscheiden sich dafür, den Textinhalt nicht in die ursprüngliche HTML-Seite aufzunehmen. Stattdessen wählen sie den Textinhalt mit AJAX aus. Dies geschieht, nachdem die Grundseite geladen wurde . Nach meiner Erfahrung hat sich diese Methode viel weiter durchgesetzt als WOFF-Schriftarten und ist meistens die Ursache für die Langsamkeit, die Sie beschreiben.

Ursache ermitteln

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 auch mit Internet Explorer 8 öffnen, das AJAX, aber nicht WOFF unterstützt. Wenn die Site immer noch langsam ist, liegt das Problem bei AJAX und nicht bei WOFF.

14
Greg H

Oft ist es eine bewusste Entscheidung, den "Blitz von nicht gestylten Inhalten" zu vermeiden. Wenn der vor dem Laden des CSS angezeigte Text angezeigt wird, wird er kurz angezeigt, als er roh dargestellt wurde, und dann ein Flash, wenn er vom Browser neu gezeichnet wird. Durch das Einfügen einiger grundlegender Inline-Stile zum anfänglichen Ausblenden des Inhalts, der im aktuellen Stylesheet überschrieben wird, oder mithilfe von JS vermeiden Entwickler dieses Flash.

In neun von zehn Fällen ist dies nicht vorsätzlich, es ist lediglich ein Nebeneffekt, wenn Web-Fonts auf einfachste Weise eingebettet werden. In der Tat ist es ein bisschen mehr Aufwand, eine sichtbare Alternative zu präsentieren, während die Web-Schriften die Pipe herunterkommen. Siehe https://developers.google.com/webfonts/docs/webfont_loader Marcel vor 11 Jahren 6
@ Marcel - Dies kann durch langsame Stylesheets sowie langsame Schriftarten verursacht werden, siehe http://www.phpied.com/css-and-the-critical-path/ r3m0t vor 11 Jahren 0
Code, der das "Aufflammen nützlicher Inhalte" verhindert, verhindert, dass Bilder sowie Text erscheinen. Jon Hanna vor 11 Jahren 0
Ich habe Schwierigkeiten zu verstehen, warum ungestylter Text schlechter ist als überhaupt kein Text. Ich könnte lieber anfangen zu lesen und akzeptieren, dass es ein bisschen wackeln könnte. Ich finde es nerviger, wenn es plötzlich nirgends erscheint und es ist sehr frustrierend, wenn eine Seite geladen wurde und man gezwungen ist, auf eine Schrift zu warten. Richard Le Poidevin vor 11 Jahren 0
8
Bryan McQuade

As others have noted, custom fonts are likely contributing to the delay.

To give a little more background, the browser is doing roughly the following before it can render the page contents to the screen:

  1. fetch HTML (several round trips for DNS, TCP, request/response)
  2. begin to parse HTML, discover external resources such as external CSS and JS. Note that CSS blocks layout, and JS blocks parsing. So external resources like CSS and JS loaded early in the document (e.g. in the head) slow down the time it takes for a page to display content on the screen.
  3. fetch external CSS and JS (several round trips: DNS and TCP if these resources are on a different domain such as CDN, as well as an RTT for the request/response)
  4. once the external CSS and JS have finished loading, parse/execute JS, parse/apply styles
  5. if the CSS makes reference to custom fonts, those fonts now have to be downloaded as well, resulting in additional round trip delays to render any parts of the page that depend on the custom fonts

Though it isn't about the delays caused by custom fonts specifically, I wrote a blog post recently that gives additional information about the causes of render delays. It gives some suggestions to minimize the time to first paint for your pages. Hopefully this is useful for readers interested in making their pages display content faster, including those pages that want to use custom fonts: http://calendar.perfplanet.com/2012/make-your-mobile-pages-render-in-under-one-second/

4
Benny

Short answer: Developers.

When link and script tags referencing external documents (like .css or .js files) are placed in the head of the document (higher in the flow than the body, and its elements), they are loaded first. JavaScript executes from the markup that references it; if there is a lot of code to process, or it's cumbersome code, or more commonly if the text you expect to see is being rendered on a server and populated into the document on load -- and that server-sided code is also cumbersome, large, or blocking I/O due to processing of several concurrent requests, you may certainly notice downtime before the HTML has had a chance to even render. Some developers choose to load non-view-related JavaScript after markup and styles (at the end of the body), and the best try to be more conscious of how their technology decision will affect the overal user experience when implemented.

Internet connection speed plays a role in the slow downloading of data, quite obviously, but poorly written code, or poorly designed technology stacks (for the type of website) play an increasingly central role in the slow loading of dynamic content, as faster network connections approach ubiquity.

Nein - was Sie beschreiben, kann verhindern, dass Elemente des DOMs angezeigt werden, jedoch nicht nur Text. Die Antwort bezieht sich auf das Ersetzen von Schriftarten und ist ** die Schuld der Designer **, nicht der Entwickler. Toby vor 11 Jahren 21
+1 @Toby, weil es wirklich die Schuld der Designer ist. Es ist auch extrem ärgerlich, wenn Sie sich auf einer langsamen Verbindung befinden (wie, oh, ich weiß nicht, mein Handy oder das Festnetz zu Hause). Solche Sachen machen Webseiten nur langsamer und irritieren die Nutzer ohne jeglichen Nutzen. Magnus vor 11 Jahren 0
Lange Antwort: Entwickler, Entwickler, Entwickler, Entwickler. iono vor 11 Jahren 1
@Toby Die Designer geben an, welche Schriftarten verwendet werden sollen, ja, aber es ist die Aufgabe jedes guten Entwicklers, die richtigen Entscheidungen während der technischen Implementierung zu treffen. Der gute Entwickler würde auch verstehen, warum dies geschieht (in einer Antwort oben erläutert), welche Entscheidungen getroffen werden können, um das Problem zu vermeiden (Google Webfont Loader), und wie dies die Erfahrung beeinflusst. arbales vor 11 Jahren 0
3
Michael Dillon

Kurz gesagt, zu viele ladbare Objekte, die vor dem Abrufen der Seite aus separaten HTTP-GETs geladen werden müssen, und eine übermäßige Abhängigkeit von der durchschnittlichen Latenzzeit als Maß für den Zustand der Website.

Die erste bezieht sich auf alle diese .css, .js und Webfonts, die von der Seite geladen werden, ganz zu schweigen von der Tatsache, dass viele Websites auch JSON-Objekte über XHR-Anforderungen abrufen und anschließend HTML-Code mit einer Vorlage erstellen müssen.

Aber warum bemerken sie nicht, dass die Website langsam ist?

Wahrscheinlich, weil sie irgendwo Memecache haben, um Dinge zu beschleunigen (oder sich nur auf Dateisystem-Caches zu verlassen) und den Zustand ihrer Website anhand der durchschnittlichen Latenzzeit messen. Daher werden die zwischengespeicherten Objekte mit einer Wartezeit von 6 Mikrosekunden zurückgegeben und verdecken die Tatsache, dass viele GET-Anforderungen 5000 Millisekunden benötigen, um abzuschließen. Durchschnittswerte müssen sterben. Es lebe das Zählen von RTTs über einem akzeptablen maximalen Schwellenwert! Diese Zahl sollte 0 sein, oder die RTT ist definitionsgemäß nicht akzeptabel.

-1
user613326

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

Ein weiterer Grund ist, dass Webdesigner in den meisten Fällen die Größe eines Bildes nicht eingeben können. Der Brouwser muss also zuerst die gesamten Bilder auf die Seiten laden, damit er weiß, wie er Text einwickelt.

Einige Designer wollen auch erste Bilder und nächsten Text zeigen, sie erreichen dies durch Javascript, so dass zum Beispiel eine einfache Seite zuerst ein Banner und dann alles andere darauf zeigt.

Aber wenn Sie sich fragen, warum es auf meinen Seiten so viel Spam-Werbematerial 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 Webrowser Websites, die Spam bereitstellen, und blockiert sie einfach, was zu einem viel schnelleren Laden der Seite führt, während Sie weiterhin die wichtigen Bilder sehen können, die sich auf die von Ihnen gelesenen Artikel beziehen.

Ich kann es allen empfehlen, die sich mit dem langsamen Laden von Seiten befassen, um Fidler auszuprobieren. fidler kann mit IEexplorer oder mit FireFox (über seine Proxy-Funktion) verwendet werden. Fidler zeigt Ihnen tatsächlich an, wie lange es tatsächlich dauert und wann Teile einer Webseite geladen werden. Es ist ein HTML-Debugging-Tool.

so you try to help people and get down voted isnt that fun ? Ok i will think twice again before explaining people technical stuff in laymens terms here. user613326 vor 11 Jahren 0
Sie haben das Falsche erklärt, deshalb werden Sie abgelehnt. Wie Sie im Screenshot sehen können, ist die Seite vollständig geladen, nur der Text wird nicht angezeigt. Das hat nichts mit Bildern zu tun. Femaref vor 11 Jahren 21
Der Hauptteil des Dokuments wird fast immer vor externem CSS geladen. Der Browser hört nicht auf, die Seite zu analysieren, nur um externe Inhalte zu laden. Der Versuch, zu helfen, ist nur nützlich, wenn Sie tatsächlich hilfreich sind. Fehlinformationen sind schlimmer als keine Informationen. raylu vor 11 Jahren 8
@raylu Ich weiß nichts über diese Desinformation. Eine Antwort mit vielen Downvotes zu sehen, kann manchmal sehr hilfreich sein. :-) LarsTech vor 11 Jahren 1
Hallo @ user613326: Wir ermutigen hier zu einem ehrlichen Downvoting, da wir in erster Linie hier nützliche Antworten für die Community liefern. Nimm es nicht persönlich! Flimm vor 11 Jahren 7
@ Raylu, was hat dich dazu gebracht? Versuchen Sie es mit Fidler user613326 vor 11 Jahren 0
@Femaref Ich wundere mich nur über die gute Antwort. Hat jemand von Ihnen das Herunterladen der Schriftdatei über das Kabel tatsächlich gesehen oder klingt es einfach nach einer guten Antwort ... weil das Netzwerk-Tracing keine ständig geladenen 2 MB-Dateien anzeigt .. Bilder werden wegen des Renderns der Seite zuerst geladen. user613326 vor 11 Jahren 0

Verwandte Probleme