29Aug

Hvorfor viser ikke nettsider umiddelbart deres tekst?


Hvis du er tilbøyelig til å se nettleservinduet med et ørnøye, har du kanskje lagt merke til at sidene ofte laster inn bilder og layout før de laster inn teksten - det nøyaktig 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?

Vær oppmerksom på 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.eksgjennomGoogle Web-fonter.

Tidligere var de eneste skriftene som kunne vises på et nettsted, de som brukeren hadde lokalt installert. Siden f.eks. Mac- og Windows-brukere har ikke nødvendigvis samme skrifttyper, designere har instinktivt alltid definert regler som

font-familie: Arial, Helvetica, sans-serif;

hvor, hvis den første skrifttypen ikke ble funnet på systemet, ville nettleseren se etter den andre, og til slutt en tilbakebetaling "sans-serif" skrift.

Nå kan man gi en skrifttype-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, for eksempel:

font-familie: 'Droid Serif', sans-serif;

Dette er veldig populært for å kunne bruke egendefinerte skrifter, men det fører også til at det ikke vises noen tekst før ressursen er lastet 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 det er lagt inn, ser jeg vanligvis lederne først, og et halvt sekund senere er alle de tomme mellomromene overfylt med overskrifter( dette er sant på Chrome og Opera, i det minste. Ikke prøvd andre).

( Designere spruter også JavaScript helt overalt i disse dager, så kanskje noen prøver å gjøre noe smart med teksten, derfor er det forsinket. Det ville være veldig stedsspesifikt, men: Den generelle tendensen til at tekst blir forsinket iDisse tider er webfontspørsmålet beskrevet ovenfor, tror jeg.)

-tillegg:

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

Fenomenet er tydeligvis 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 som gjengir webteksttekst med en tilbakebetalingstype under webfonteringsperioden. Selv om nettfonten er cached, vil være en gjengivelse forsinkelse .Det er mange kommentarer i denne spørsmåletråden som sier noe annet, og at det er flatt ut feil at bufret skriftene oppfører seg slik, men f.eks.fra den ovennevnte lenken:

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 datasikkerhet /otf/ woff
  • Vil: Viser en bufret data-uri ttf /otf/ woff
  • Vil ikke: Viser en skrifttype som allerede er installert og oppkalt i den tradisjonelle skrifttypestakken
  • Vil ikke: Viser en skrifttype som er installert og oppkalt ved hjelp av den lokale() plassering

Siden Chrome venter til feilrisikoen er borte før rendering, gir dette en forsinkelse. Til hvilken -grad er effekten 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 effekten helt.

Irish har også noen oppdateringer om nettleseradferd i 2011-04-14 på bunnen av innlegget:

  • Firefox ( som av 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 i de tre sekundene skjønt. .. forhåpentligvis. .
  • IE9 støtter WOFF og TTF og OTF( selv om det krever en innebygd bitsett-for det meste moot hvis du bruker WOFF). MEN!IE9 har en feil. :(
  • Webkit har en patch som venter på å lande for å vise tilbakebetalingstekst etter 0,5 sekunder. Så samme oppførsel som FF, men 0.5s i stedet for 3.s.

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

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