Hvis du er tilbøjelig til at se browservinduet med et ørneøje, har du måske bemærket, at sider ofte indlæser deres billeder og layout, før de indlæser deres tekst - det nøjagtige modsatte indlæsningsmønster, vi oplevede i 1990'erne. Hvad sker der?
Dagens spørgsmål og svar-session kommer til os med tilladelse fra SuperUser - en underinddeling af Stack Exchange, en community-driven gruppe af Q&A websteder.
Spørgsmålet
SuperUser-læser Laurent er meget nysgerrig efter, hvorfor netop sider synes at indlæse elementer helt anderledes end de engang gjorde. Han skriver:
Jeg har bemærket, at for nylig er mange websteder langsomme med at vise deres tekst. Normalt vil baggrunden, billederne og så videre blive indlæst, men ingen tekst. Efter et stykke tid begynder teksten at vises her og der (ikke altid alt på samme tid).
Det fungerer grundlæggende det modsatte, som det plejede, da teksten først blev vist, derefter blev billederne og resten indlæst bagefter. Hvilken ny teknologi skaber dette problem? Enhver idé?
Bemærk, at jeg har en langsom forbindelse, hvilket sandsynligvis fremhæver problemet.
Se [above] for et eksempel - alt er indlæst, men det tager et par sekunder mere, før teksten endelig vises.
Så hvad giver? Laurent, og mange af os, husker en tid, hvor teksten blev indlæst først, og alt andet - garrish animerede GIF'er, flisebelagte baggrunde og alle de andre artefakter fra slutningen af 90'erne webbrowsing - kom senere. Hvad forårsager den nuværende situation med designelementer først, tekst senere?
Svaret
SuperUser-bidragsyder Daniel Andersson tilbyder et vidunderligt detaljeret svar, der kommer helt til bunden af hvorfor-skrifttyperne-last-sidste mysterium:
En af årsagerne er, at webdesignere i dag gerne bruger webskrifttyper (normalt i WOFF format), f.eks. igennem Google Web fonts .
Tidligere var de eneste skrifttyper, der kunne vises på et websted, dem, som brugeren havde installeret lokalt. Da f.eks. Mac- og Windows-brugere havde ikke nødvendigvis de samme skrifttyper, designere definerede instinktivt altid regler som
font-family: Arial, Helvetica, sans-serif;hvor, hvis den første skrifttype ikke blev fundet på systemet, ville browseren kigge efter den anden og sidst en "sans-serif" font.
Nu kan man give en font-URL som en CSS-regel for at få browseren til at downloade en font som sådan:
@import url (http://fonts.googleapis.com/css?family=Droid+Serif:400,700);og indlæs derefter 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 indlæst af browseren, som inkluderer downloadtid, fontindlæsningstid og gengivelsestid. Jeg forventer, at dette er den artefakt, du oplever.
Som et eksempel: en af mine nationale aviser, Dagens nyheder , brug webskrifttyper til deres overskrifter, men ikke deres kundeemner, så når dette websted indlæses, ser jeg normalt kundeemnerne først, og et halvt sekund senere er alle de tomme mellemrum ovenfor befolket med overskrifter (dette gælder i Chrome og Opera, kl. mindst. Har ikke prøvet andre).
(Desuden drypper designere JavaScript absolut overalt i disse dage, så måske prøver nogen at gøre noget klogt med teksten, hvorfor det er forsinket. Det ville dog være meget stedsspecifikt: Den generelle tendens til, at tekst forsinkes i disse gange er det problem med webfonte, der er beskrevet ovenfor, tror jeg.)
Tilføjelse:
Dette svar blev meget opstemt, selvom jeg ikke gik i detaljer, eller måske fordi af dette. Der har været mange kommentarer i spørgsmålstråden, så jeg vil prøve at udvide lidt […]
Fænomenet er tilsyneladende kendt som "flash af ustyleret indhold" generelt og "flash af ustylet tekst" i særdeleshed. Søgning efter “FOUC” og “FOUT” giver mere info.
Jeg kan anbefale webdesigner Paul Irishs indlæg på FOUT i forbindelse med webskrifttyper .
Hvad man kan bemærke er, at forskellige browsere håndterer dette forskelligt. Jeg skrev ovenfor, at jeg havde testet Opera og Chrome, som begge opførte sig ens. Alle WebKit-baserede (Chrome, Safari osv.) Vælger at undgå FOUT by ikke gengivelse af webskrifttekst med en reservefont i løbet af indlæsningsperioden for webskrifttypen. Selvom webskrifttypen er cache, der vilje være en gengivelsesforsinkelse . Der er mange kommentarer i denne spørgsmålstråd, der siger noget andet, og at det er forkert forkert, at cachelagrede skrifttyper opfører sig sådan, men f.eks. fra ovenstående link:
I hvilke tilfælde får du et FOUT
- Vilje: Downloading og visning af en ekstern ttf / otf / woff
- Vilje: Viser en cachelagret ttf / otf / woff
- Vilje: Download og visning af 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 skrifttypestak
- Vil ikke: Visning af en skrifttype, der er installeret og navngivet ved hjælp af den lokale () placering
Da Chrome venter, indtil FOUR risikoen er forsvundet inden gengivelse, giver dette en forsinkelse. Til hvilken grad effekten er synlig (især ved indlæsning fra cache) synes at være afhængig af blandt andet den mængde tekst, der skal gengives, og måske andre faktorer, men caching fjerner ikke effekten fuldstændigt.
Irsk har også nogle opdateringer vedrørende browseradfærd fra og med 2011–04–14 nederst i indlægget:
- Firefox (fra og med FFb11 og FF4 Final) har ikke længere et FOUT! Wooohoo! http://bugzil.la/499292 Grundlæggende er teksten usynlig i 3 sekunder, og derefter bringer den tilbagefaldsskrifttypen tilbage. Webfonten indlæses sandsynligvis inden for de tre sekunder ... forhåbentlig ..
- IE9 understøtter WOFF og TTF og OTF (selvom det kræver det en indlejringsbit sæt ting - for det meste skidt, hvis du bruger WOFF). IMIDLERTID!!! IE9 har en FOUT. :(
- Webkit har et plaster, der venter på at lande for at vise reservetekst efter 0,5 sekunder. Så samme adfærd som FF men 0,5 sek. I stedet for 3 sek.
Hvis dette var et spørgsmål rettet mod designere, kunne man gå på måder at undgå denne slags problemer som f.eks
webfontloader, men det ville være et andet spørgsmål. Paul Irish-linket går nærmere ind på denne sag.
Har du noget at tilføje til forklaringen? Lyder i kommentarerne. Vil du læse flere svar fra andre teknisk kyndige Stack Exchange-brugere? Tjek den fulde diskussionstråd her .
