Hvorfor viser ikke nettsider øyeblikkelig deres tekst?

Hvis du er tilbøyelig til å se på nettleservinduet med et ørnøye, har du kanskje lagt merke til at sidene ofte laster inn bildene og layoutene sine før de laster inn teksten - det nøyaktige motsatte lastemønsteret vi opplevde i løpet av 1990-tallet. Hva skjer?

Dagens Spørsmål & Svar-sesjon kommer til oss med høflighet av SuperUser-en underavdeling av Stack Exchange, en fellesskapsdrevet gruppering av Q & A-nettsteder.

Spørsmålet

SuperUser leser Laurent er veldig nysgjerrig på hvorfor nøyaktig sider synes å laste elementer helt annerledes enn de gjorde en gang om gangen. Han skriver:

Jeg har lagt merke til at nylig mange nettsteder er sakte å vise sin tekst. Vanligvis vil bakgrunnen, bildene og så videre bli lastet, men ingen tekst. Etter en stund begynner teksten å vises her og der (ikke alltid alt på samme tid).

Det fungerer i utgangspunktet det motsatte som det pleide å være, da teksten ble vist først, da ble bildene og resten lastet etterpå. Hvilken ny teknologi skaper dette problemet? Noen ide?

Legg merke til at jeg har en langsom tilkobling, noe som sannsynligvis accentuerer problemet.

Se [over] for et eksempel - alt er lastet, men det tar noen sekunder før teksten endelig vises.

Så hva gir? Laurent, og mange av oss, husker en tid da teksten lastet først og alt annet-grynlig animerte GIF-tegninger, flislagt bakgrunner, og alle de andre gjenstandene som ble brukt på slutten av 90-tallet nettleser - kom senere. Hva forårsaker den nåværende situasjonen for designelementer først, tekst senere?

Svaret

SuperUser-bidragsyter Daniel Andersson tilbyr et fantastisk detaljert svar som kommer rett til bunnen av hvorfor-fonter-last-siste mysterium:

En grunn er at webdesignere i dag liker å bruke webfonter (vanligvis i WOFF-format), f.eks. gjennomGoogle Web-skrifttyper.

Tidligere var de eneste skriftene som kunne vises på et nettsted, de som brukeren hadde installert lokalt. Siden f.eks. Mac- og Windows-brukere hadde ikke nødvendigvis samme skrifttyper, designere angav instinktivt alltid regler som
font-familie: Arial, Helvetica, sans-serif; 
hvor, hvis den første skriften ikke ble funnet på systemet, ville nettleseren se etter den andre, og til slutt en tilbakebetaling "sans-serif" skrift.

Nå kan man gi en font-URL som en CSS-regel for å få nettleseren til å laste ned en skrift, som sådan:
@import url (http://fonts.googleapis.com/css?family=Droid+Serif:400,700); 
og last deretter inn skrifttypen for et bestemt element ved for eksempel:
font-familie: 'Droid Serif', sans-serif; 
Dette er veldig populært for å kunne bruke egendefinerte skrifttyper, men det fører også til at det ikke vises noen tekst før ressursen er lastet inn av nettleseren, som inkluderer nedlastingstiden, skriftens lastetid og gjengittid. Jeg forventer at dette er artefaktet du opplever.

Som et eksempel: En av mine nasjonale aviser, Dagens Nyheter, bruker webfonter til overskriftene, men ikke deres ledere, så når den siden er lastet, ser jeg vanligvis lederne først, og et halvt sekund senere blir alle tomme mellomrom fylt ut med overskrifter (dette er sant på Chrome og Opera, i det minste. Har ikke prøvd andre).

(Også designere sprinkle JavaScript helt overalt i disse dager, så kanskje noen prøver å gjøre noe smart med teksten, og derfor er det forsinket. Det ville være veldig spesifikt på nettstedet, men: Den generelle tendensen til at tekst blir forsinket i disse ganger er problemet med webfonter beskrevet ovenfor, tror jeg.)

Addisjon:

Dette svaret ble veldig oppvokst, selv om jeg ikke gikk inn i mye detalj, eller kanskje fordi av denne. Det har vært mange kommentarer i spørsmåletråden, så jeg skal prøve å utvide litt [...]

Fenomenet er tilsynelatende kjent som "flash of unstyled content" generelt, og "flash of unstyled text" spesielt. Søker etter "FOUC" og "FOUT" gir mer info.

Jeg kan anbefale webdesigner Paul Irlands post på feil i forbindelse med webfonter.

Det man kan merke seg er at forskjellige nettlesere håndterer dette annerledes. Jeg skrev over at jeg hadde testet Opera og Chrome, som begge oppførte seg på samme måte. Alle WebKit-baserte (Chrome, Safari, etc.) velger å unngå feil ved ikke gjengivelse av webteksttekst med en tilbakebetalingstype under webfonteringsperioden. Selv om Nettfonten er cached, der vil vær en gjengivelse forsinkelse. Det er mange kommentarer i denne spørsmåletråden som sier ellers, og at det er flatt ut feil at bufret skriftene oppfører seg slik, men f.eks. fra lenken ovenfor:

I hvilke tilfeller får du en feil

Vil: Laster ned og viser en ekstern ttf / otf / woff

Vil: Viser en bufret ttf / otf / woff

Vil: Laster ned og viser en data-uri ttf / otf / woff

Vil: Viser en bufret data-uri ttf / otf / woff

Vil ikke: Viser en skrift som allerede er installert og oppkalt i den tradisjonelle skrifttypestakken

Vil ikke: Viser en skrift som er installert og navngitt ved hjelp av lokal () -stedet

Siden Chrome venter til FOUT-risikoen er borte før rendering, gir dette en forsinkelse. Til hvilken utstrekning effekten er synlig (spesielt når du laster fra cache) synes å være avhengig av blant annet mengden tekst som må gjengis og kanskje andre faktorer, men caching fjerner ikke fullstendig effekten.

Irsk har også noen oppdateringer angående nettleserens oppførsel fra 2011-04-14 på bunnen av innlegget:

Firefox (fra FFb11 og FF4 Final) har ikke lenger en feil! Wooohoo! Http: //bugzil.la/499292 I utgangspunktet er teksten usynlig i 3 sekunder, og så bringer den tilbake tilbakebetalingstegnet. Webfont vil trolig laste inn de tre sekundene skjønt ... forhåpentligvis ...

IE9 støtter WOFF og TTF og OTF (selv om det krever en innebygd bitsett ting-for det meste moot hvis du bruker WOFF). DERIMOT!!! IE9 har en feil. :(

Webkit har en oppdatering som venter på å lande for å vise tilbakebetalingstekst etter 0,5 sekunder. Så samme oppførsel som FF, men 0,5s i stedet for 3s.

Hvis dette var et spørsmål rettet mot designere, kunne man gå inn på måter å unngå slike problemer som webfontloader, men det ville være et annet spørsmål. Paul Irish-lenken går nærmere i denne saken.

Har du noe å legge til forklaringen? Lyde av i kommentarene. Vil du lese flere svar fra andre tech-savvy Stack Exchange-brukere? Sjekk ut hele diskusjonstråden her.