Hvorfor viser ikke websider straks deres tekst?

Hvis du er tilbøjelig til at se browservinduet med et ørnøje, har du måske bemærket, at siderne ofte læser deres billeder og layout før de lægger deres tekst - det nøjagtige modsatte læssemønster, vi oplevede i 1990'erne. Hvad sker der?

Dagens Spørgsmål & Svar session kommer til os med venlig hilsen af SuperUser-en underafdeling af Stack Exchange, en community-driven gruppe af Q & A-websteder.

Spørgsmålet

SuperUser læser Laurent er meget nysgerrig på, hvorfor nøjagtige sider synes at indlæse elementer helt anderledes end de gjorde en gang om gangen. Han skriver:

Jeg har bemærket, at for nylig er mange websteder langsomme til at vise deres tekst. Normalt vil baggrunden, billederne og så videre blive indlæst, men ingen tekst. Efter lidt tid begynder teksten at blive vist her og der (ikke altid alt sammen på samme tid).

Det fungerer grundlæggende det modsatte som det plejede at, da teksten blev vist først, så blev billederne og resten lastet bagefter. Hvilken ny teknologi skaber dette problem? Enhver ide?

Bemærk, at jeg har en langsom forbindelse, hvilket sandsynligvis accentuerer problemet.

Se [ovenfor] for et eksempel - alt er indlæst, men det tager et par sekunder, før teksten endelig vises.

Så hvad giver? Laurent, og mange af os, husker en tid, hvor teksten indlæses først og alt andet - garrish animerede GIF'er, flisebaggrunde, og alle de andre genstande i slutningen af 90'erne web browsing - kom senere. Hvad forårsager den nuværende situation med designelementer først, tekst senere?

Svaret

SuperUser-bidragsyderen Daniel Andersson tilbyder et vidunderligt detaljeret svar, der får ret til bunden af hvorfor-fonterne-last-sidste mysterium:

En af grundene er, at webdesignere i dag gerne bruger web skrifttyper (normalt i WOFF format), f.eks. gennemGoogle Web skrifttyper.

Tidligere var de eneste skrifttyper, der kunne vises på et websted, de, som brugeren havde installeret lokalt. Eftersom f.eks. Mac- og Windows-brugere havde ikke nødvendigvis de samme skrifttyper, designere definerede instinktivt altid regler som
skrifttype-familie: Arial, Helvetica, sans-serif; 
hvor, hvis den første skrifttype ikke blev fundet på systemet, ville browseren se efter den anden og endelig en back-up "sans-serif" skrifttype.

Nu kan man give en skrifttype-URL som en CSS-regel for at få browseren til at downloade en skrifttype som sådan:
@import url (http://fonts.googleapis.com/css?family=Droid+Serif:400,700); 
og derefter indlæse skrifttypen for et bestemt element ved f.eks .:
font-familie: 'Droid Serif', sans-serif; 
Dette er meget populært for at kunne bruge brugerdefinerede skrifttyper, men det fører også til problemet, at der ikke vises nogen tekst, før ressourcen er blevet indlæst af browseren, hvilket inkluderer downloadtidspunktet, skrifttilsætningstiden og renderetiden. Jeg forventer, at dette er den artefakt, du oplever.

Som et eksempel: En af mine nationale aviser, Dagens Nyheter, bruger web skrifttyper til deres overskrifter, men ikke deres kundeemner, så når den side er indlæst, ser jeg sædvanligvis lederne først, og et halvt sekund senere er alle de tomme mellemrum befolket med overskrifter (det gælder i hvert fald Chrome og Opera. Har ikke prøvet andre).

(Designere spreder også JavaScript helt overalt i disse dage, så måske prøver nogen at gøre noget klogt med teksten, hvorfor det er forsinket. Det ville være meget webstedsspecifikt, selvom: den generelle tendens til, at teksten forsinkes i disse gange er problemet med web skrifttyper beskrevet ovenfor, tror jeg.)

Tilføjelse:

Dette svar blev meget opvoted, selvom jeg ikke gik i meget detaljer, eller måske fordi af dette. Der har været mange kommentarer i spørgsmålstråden, så jeg vil forsøge at udvide lidt [...]

Fænomenet er tilsyneladende kendt som "flash of unstyled content" generelt og "flash of unstyled text" i særdeleshed. Søger efter "FOUC" og "FOUT" giver mere info.

Jeg kan anbefale webdesigner Paul Irlands post på fejl i forbindelse med web skrifttyper.

Det man kan bemærke er, at forskellige browsere håndterer dette anderledes. Jeg skrev ovenfor, at jeg havde testet Opera og Chrome, som begge optrådte på samme måde. Alle WebKit-baserede (Chrome, Safari osv.) Vælger at undgå fejl ved ikke gengivelse af web skrifttypetekst med en returback skrifttype under web skrifttype indlæsning periode. Selvom web skrifttypen er cached der vilje vær en gengivelse forsinkelse. Der er mange kommentarer i dette spørgsmålstråde, der siger ellers, og at det er fladt ud forkert, at cachede skrifttyper opfører sig som dette, men f.eks. fra ovenstående link:

I hvilke tilfælde får du en fejl

Vilje: Downloading og visning af en fjernbetjening ttf / otf / woff

Vilje: Viser en cachelagret ttf / otf / woff

Vilje: Download og vise en data-uri ttf / otf / woff

Vilje: Viser en cachelagret data-uri ttf / otf / woff

Vil ikke: Viser en skrifttype, der allerede er installeret og navngivet i din traditionelle skrifttypestabel

Vil ikke: Viser en skrifttype, der er installeret og navngivet ved hjælp af den lokale () placering

Da Chrome venter, indtil fejlen FOUT er væk før gengivelse, giver dette en forsinkelse. Til hvilken grad effekten er synlig (især når du læser fra cache) synes at være afhængig af blandt andet mængden af tekst, der skal udføres og måske andre faktorer, men caching fjerner ikke fuldstændigt effekten.

Irsk har også nogle opdateringer vedrørende browseradfærd pr. 2011-04-14 i bunden af posten:

Firefox (som af FFb11 og FF4 Final) har ikke længere en fejl! Wooohoo! Http: //bugzil.la/499292 I grunden er teksten usynlig i 3 sekunder, og så bringer den tilbagebakke skrifttypen tilbage. Webfont vil sandsynligvis indlæse inden for de tre sekunder dog ... forhåbentlig ...

IE9 understøtter WOFF og TTF og OTF (selv om det kræver en indlejring bitset ting-for det meste moot hvis du bruger WOFF). IMIDLERTID!!! IE9 har en fejl. :(

Webkit har en patch, der venter på at lande for at vise efterfølgende tekst efter 0,5 sekunder. Så samme opførsel som FF men 0,5s i stedet for 3s.

Hvis dette var et spørgsmål rettet mod designere, kunne man gå ind på måder at undgå sådanne problemer som f.eks webfontloader, men det ville være et andet spørgsmål. Den Paul irske link går nærmere i denne sag.

Har du noget at tilføje til forklaringen? Lyde af i kommentarerne. Vil du læse flere svar fra andre tech-savvy Stack Exchange brugere? Tjek den fulde diskussionstråd her.