Varför visar inte webbsidor omedelbart deras text?

Om du är benägen att titta på webbläsarfönstret med ett örnöne kan du ha märkt att sidor ofta laddar upp sina bilder och layout innan de laddar texten. Det exakta motsatta laddningsmönstret vi upplevde under 1990-talet. Vad pågår?

Dagens Question & Answer-session kommer till oss med tillstånd av SuperUser-en indelning av Stack Exchange, en community-driven gruppering av Q & A-webbplatser.

Frågan

SuperUser-läsare Laurent är väldigt nyfiken på varför exakta sidor verkar ladda element helt annorlunda än de gjorde en gång i taget. Han skriver:

Jag har märkt att nyligen många webbplatser är långsamma för att visa sin text. Vanligtvis kommer bakgrunden, bilderna och så vidare att laddas, men ingen text. Efter en tid börjar texten visas här och där (inte alltid allt på samma gång).

Det fungerar i grunden motsatsen som det brukade, när texten först visades, då var bilderna och resten lastade efteråt. Vilken ny teknik skapar detta problem? Någon idé?

Observera att jag har en långsam anslutning, vilket förmodligen accentuerar problemet.

Se [ovan] för ett exempel - allt är laddat men det tar några sekunder innan texten äntligen visas.

Så vad ger? Laurent, och många av oss, kom ihåg en tid när texten laddades först och allt annat - grymt animerade GIF-bilder, kaklade bakgrunder, och alla andra artefakter i slutet av 90-talets webbläsning - kom senare. Vad orsakar den nuvarande situationen för designelement först, text senare?

Svaret

SuperUser-bidragsgivaren Daniel Andersson erbjuder ett fantastiskt detaljerat svar som får rätt till botten av varför-fonterna-last-sista mysteriet:

En orsak är att webbdesigners gillar att använda webbfonter (vanligtvis i WOFF-format), t.ex. genom Googles webbsidor.

Tidigare var de enda teckensnitt som kunde visas på en webbplats de som användaren hade installerat lokalt. Eftersom t.ex. Mac- och Windows-användare hade inte nödvändigtvis samma teckensnitt, designers definierade instinktivt alltid regler som
font-family: Arial, Helvetica, sans-serif; 
var, om det första tecknet inte hittades på systemet, skulle webbläsaren leta efter den andra och till sist en "back" -sans-serif-typsnitt.

Nu kan man ge en fontadress som en CSS-regel för att få webbläsaren att ladda ner ett teckensnitt, som sådant:
@import url (http://fonts.googleapis.com/css?family=Droid+Serif:400,700); 
och ladda sedan teckensnittet för ett visst element med t.ex.
font-family: "Droid Serif", sans-serif; 
Detta är väldigt populärt för att kunna använda anpassade teckensnitt, men det leder också till problemet att ingen text visas tills resursen har laddats av webbläsaren, vilket inkluderar nedladdningstiden, typsnittets laddningstid och återgivningstid. Jag förväntar mig att detta är artefakt som du upplever.

Som ett exempel: En av mina nationella tidningar, Dagens Nyheter, använder webbfonter för sina rubriker, men inte deras ledningar, så när den sidan laddas ser jag vanligtvis ledningarna först och en halv sekund senare fylls alla tomma utrymmen ovan. med rubriker (det här är sant på Chrome och Opera, åtminstone. Har inte försökt andra).

(Designare sprider också JavaScript överallt idag, så kanske någon försöker göra något smart med texten, vilket är anledningen till att det är försenat. Det skulle vara mycket specifikt på webbplatsen, men den allmänna tendensen att texten försenas i dessa gånger är problemet med webb-teckensnitt som beskrivs ovan, tror jag.)

Tillägg:

Det här svaret blev väldigt uppvotat, men jag gick inte in i mycket detalj eller kanske därför att av detta. Det har varit många kommentarer i frågestråden, så jag ska försöka expandera lite [...]

Fenomenet är uppenbarligen känt som "flash of unstyled content" i allmänhet och "flash of unstyled text" i synnerhet. Söka efter "FOUC" och "FOUT" ger mer info.

Jag kan rekommendera webbdesigner Paul Irlands post på FOUT i samband med webbfonter.

Vad man kan notera är att olika webbläsare hanterar detta på ett annat sätt. Jag skrev ovan att jag hade testat Opera och Chrome, som båda uppförde sig på samma sätt. Alla WebKit-baserade (Chrome, Safari, etc.) väljer att undvika FOUT genom inte återgivning av webbtyptext med ett bakfontstryck under webtypens laddningsperiod. Även om webbfonten är cachad där kommer vara en återställningsfördröjning. Det finns många kommentarer i den här frågestråden som säger något annat och att det är platt ut fel att cachade teckensnitt beter sig så här, men t.ex. från ovanstående länk:

I vilka fall får du en FOUT

Kommer: Hämtar och visar en fjärrkontroll ttf / otf / woff

Kommer: Visar en cachad ttf / otf / woff

Kommer: Nedladdning och visning av data-uri ttf / otf / woff

Kommer: Visar en cachad data-uri ttf / otf / woff

Ska inte: Visar en typsnitt som redan är installerad och namngiven i din traditionella typsnittstapel

Ska inte: Visar en typsnitt som är installerad och namngiven med lokal ()

Eftersom Chrome väntar tills FOUT-risken är borta innan rendering ger detta en fördröjning. Till vilken utsträckning effekten är synlig (speciellt när du laddar från cachen) verkar vara beroende av bland annat den mängd text som behöver göras och kanske andra faktorer, men caching eliminerar inte fullständigt effekten.

Irländare har också några uppdateringar om webbläsarbeteendet från 2011-04-14 längst ner i posten:

Firefox (från FFb11 och FF4 Final) har inte längre ett fel! Wooohoo! Http: //bugzil.la/499292 I grund och botten är texten osynlig i 3 sekunder, och sedan tar den tillbaka fallback-tecknet. Webfont kommer troligtvis att laddas inom de tre sekunder men ... förhoppningsvis ...

IE9 stöder WOFF och TTF och OTF (även om det kräver en inbäddad bituppsats-för det mesta om du använder WOFF). DOCK!!! IE9 har en FOUT. :(

Webkit har en korrigeringsfil som väntar på att landa för att visa efterföljande text efter 0,5 sekunder. Så samma beteende som FF men 0.5s istället för 3s.

Om det här var en fråga som syftar till designers kan man gå in på sätt att undvika sådana problem som webfontloader, men det skulle vara en annan fråga. Paul Irish-länken går vidare i detalj om denna fråga.

Har du något att lägga till förklaringen? Ljud av i kommentarerna. Vill du läsa mer svar från andra tech-savvy Stack Exchange-användare? Kolla in hela diskussionsgängan här.