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 fråga &Svarssession 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 exakt 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 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 det motsatta som det brukade, när texten först visades, så lastades bilderna och resten 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 gång 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, texten 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 anledning är att webdesigners idag använder webblanketter( vanligtvis i WOFF-format), t.exgenom Googles webbfonter.

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 instinktivt definierade alltid regler som

teckensnittsfamilj: Arial, Helvetica, sans-serif;

där, om det första tecknet inte hittades på systemet, skulle webbläsaren leta efter den andra, och slutligen 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 typsnitt:

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

och ladda sedan teckensnittet för ett visst element med t.ex.:

teckensnittsfamilj: 'Droid Serif', sans-serif;

Det här är mycket 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 är alla tomma blanketter ovanbefolkade 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, dock: den allmänna tendensen att texten försenas iDessa tider är problemet med webbfonter som beskrivits ovan, tror jag.)

Tillägg:

Detta svar blev mycket uppvoted, men jag gick inte in i mycket detalj, eller kanske för av detta. Det har varit många kommentarer i frågan tråd, 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 annorlunda. 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 av , inte , vilket ger webbfonttext med ett bakfelsfonter under uppladdningstiden för webbtyp. Även om webbfonten är cachad, kommer att bli 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 ett fel

• Vill: Ladda ner och visa en fjärrkontroll /otf/ woff
• Kommer: Visa en cachad ttf /otf/ woff
• Kommer: Hämta och visa en data-uri ttf /otf/ woff
• Kommer: Visa en cachad data-uri ttf /otf/ woff
• Kommer inte: Visar ett teckensnitt som redan är installerat och namnges i din traditionella teckensnittsstack
• Kommer inte: Visar ett teckensnitt som är installerat och namngivna med den lokala() plats

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

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

• Firefox ( som av FFb11 och FF4 Final) har inte längre ett fel! Wooohoo! Http: //bugzil.la/ 499292 I grunden är texten osynlig i 3 sekunder, och sedan tar den tillbaka fallback-teckensnittet. 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). MEN! !!IE9 har en FOUT.:(
• Webkit har en patch 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 3.

Om det här var en fråga som riktar sig till designers kan man gå in på sätt att undvika dessa typerav problem som webfontloader, men det skulle vara en annan fråga. Den Paul Irish-länken går vidare i detalj om den här frågan.

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