Miksi Web-sivut eivät näytä heti tekstiä?

Jos olet taipuvainen katsomaan selainpaneelia kotkan silmällä, olet ehkä huomannut, että sivut lataavat usein kuvia ja asettelua ennen kuin lataavat tekstinsä täsmälleen päinvastaisen latausmallin, jota koimme 1990-luvulla. Mitä tapahtuu?

Nykypäivän Kysymys- ja vastaus -istunto tulee meille suotuisasti SuperUserin - Stack Exchange -alueen, yhteisöpohjaisen Q & A-sivustojen ryhmittymän - kautta..

Kysymys

SuperUser-lukija Laurent on erittäin utelias siitä, miksi sivut näyttävät lataavan elementtejä täysin eri tavalla kuin kerran. Hän kirjoittaa:

Olen huomannut, että viime aikoina monet sivustot näyttävät hitaasti tekstinsä. Yleensä tausta, kuvat ja niin edelleen ladataan, mutta ei tekstiä. Jonkin ajan kuluttua teksti alkaa näkyä täällä ja siellä (ei aina kaikki samanaikaisesti).

Se toimii pohjimmiltaan päinvastaisena, kun tekstiä näytettiin ensin, sitten kuvat ja loput ladattiin myöhemmin. Mitä uutta teknologiaa tämä ongelma luo? Mikä tahansa idea?

Huomaa, että olen hitaassa yhteydessä, mikä luultavasti korostaa ongelmaa.

Katso esimerkki [yllä] - kaikki on ladattu, mutta se vie vielä muutaman sekunnin ennen kuin teksti lopulta näytetään.

Joten mikä antaa? Laurent ja monet meistä muistavat aikaa, jolloin teksti ladattiin ensimmäisenä ja kaikki muut-garrish-animoidut GIF-levyt, kaakeloidut taustat ja kaikki muut 90-luvun lopun selaamisen artefaktit tulivat myöhemmin. Mikä aiheuttaa design-elementtien nykyisen tilanteen, tekstin myöhemmin?

Vastaus

SuperUserin avustaja Daniel Andersson tarjoaa ihan yksityiskohtaisen vastauksen, joka saa juuri sen, miksi -fonts-load-last-mysteeri:

Yksi syy on se, että web-suunnittelijat haluavat nykyään käyttää web-fontteja (yleensä WOFF-muodossa), esim. kauttaGoogle Web -fontteja.

Aiemmin vain sellaiset fontit, jotka olivat näkyvissä sivustossa, olivat ne, jotka käyttäjä oli paikan päällä asentanut. Koska esimerkiksi Mac- ja Windows-käyttäjillä ei välttämättä ollut samat fontit, suunnittelijat määrittivät instinktiivisesti aina säännöt

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

missä, jos ensimmäistä kirjasinta ei löytynyt järjestelmästä, selain etsii toista ja lopulta varmuuskopion ”sans-serif” -kirjasinta.

Nyt voit antaa fontin URL-osoitteen CSS-säännöksi, jotta selain voi ladata fontin sellaisenaan:

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

ja lataa sitten tietyn elementin fontti esimerkiksi:

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

Tämä on erittäin suosittu, jotta voit käyttää mukautettuja fontteja, mutta se johtaa myös ongelmaan, että tekstiä ei näytetä ennen kuin resurssi on ladattu selaimella, joka sisältää latausajan, fontin latausajan ja renderöinnin. Odotan, että tämä on artefakti, jota koet.

Esimerkkinä mainittakoon, että yksi kansallisista sanomalehdistäni, Dagens Nyheter, käyttää web-fontteja otsikoihinsa, mutta ei niiden johtoon, joten kun sivusto ladataan, näen tavallisesti ne ensin, ja puoli sekuntia myöhemmin kaikki tyhjät välilyönnit on täytetty otsikoilla (tämä pätee ainakin Chromeen ja Operaan. Etkö ole kokeillut muita).

(Myös suunnittelijat ripustavat JavaScriptin täysin kaikkialla näinä päivinä, joten ehkä joku yrittää tehdä jotain älykkäästi tekstillä, minkä vuoksi se viivästyy. Se olisi kuitenkin hyvin sivustokohtainen: yleinen suuntaus tekstiin viivästyä kertaa on edellä kuvattu web-fonttien ongelma.)

Lisäys:

Tämä vastaus tuli hyvin ylösalaisin, vaikka en käynyt paljon yksityiskohtia tai ehkä koska tästä. Kysymyskierassa on ollut monia kommentteja, joten yritän laajentaa hieman […]

Ilmiö tunnetaan ilmeisesti yleisesti "muotoilemattoman sisällön salamana" ja erityisesti "tyylitön teksti". "FOUC" ja "FOUT" etsiminen antaa lisätietoja.

Voin suositella web-suunnittelijan Paul Irishin postia FOUTissa web-fonttien yhteydessä.

On huomattava, että eri selaimet käsittelevät tätä eri tavalla. Kirjoitin edellä, että olin testannut Opera ja Chrome, jotka molemmat käyttäytyivät samalla tavalla. Kaikki WebKit-pohjaiset (Chrome, Safari jne.) Haluavat välttää FOUTin ei web-kirjasintekstin renderöinti varmuuskopiona web-fontin latausjakson aikana. Vaikka Web-fontti on välimuistissa tahtoa olla viivästys. Tässä kysymyksessä on paljon kommentteja, jotka sanovat toisin, ja että se on väärä, että välimuistissa olevat kirjasimet käyttäytyvät näin, mutta esim. yllä olevasta linkistä:

Missä tapauksissa saat FOUT

• Tahtoa: Kauko-ohjaimen ttf / otf / woff lataaminen ja näyttäminen
• Tahtoa: Välimuistiin tallennetun ttf / otf / woffin näyttäminen
• Tahtoa: Tietojen lataaminen ja näyttäminen
• Tahtoa: Välimuistiin tallennettujen tietojen näyttäminen ttf / otf / woff
• Ei: Näytetään fontti, joka on jo asennettu ja nimetty perinteisessä kirjasintapinossa
• Ei: Asennetun fontin näyttäminen paikallisen () sijainnin avulla

Koska Chrome odottaa, kunnes FOUT-riski on mennyt ennen renderointia, tämä antaa viiveen. Johon laajuus vaikutus on näkyvissä (varsinkin silloin, kun se ladataan välimuistista) näyttää olevan riippuvainen muun muassa annettavan tekstin määrästä ja mahdollisesti muista tekijöistä, mutta välimuisti ei poista kokonaan vaikutusta.

Irlantilaisilla on myös joitakin päivityksiä selaimen käyttäytymisestä vuodesta 2011-04-14 postin alareunassa:

• Firefox (FFb11: n ja FF4: n finaalista) ei ole enää FOUT! Wooohoo! Http: //bugzil.la/499292 Periaatteessa teksti on näkymätön 3 sekunnin ajan, ja sitten se palauttaa varmuuskopion. Webfont latautuu todennäköisesti näissä kolmessa sekunnissa, vaikka… toivottavasti…
• IE9 tukee WOFF: a ja TTF: ää ja OTF: ää (vaikkakin se vaatii upottavan bitset-asian - enimmäkseen kiistanalaisen, jos käytät WOFF). KUITENKIN!!! IE9: llä on FOUT. :(
• Webkitillä on korjaustiedosto, joka odottaa laskeutumista näyttääkseen palautustekstin 0,5 sekunnin kuluttua. Niin sama käyttäytyminen kuin FF: llä, mutta 0,5 sekunnin sijasta 3s.

Jos tämä oli suunnittelijoille suunnattu kysymys, voisi mennä keinoihin välttää tällaisia ​​ongelmia, kuten webfontloader, mutta se olisi toinen kysymys. Paul Irlannin linkki menee tarkemmin tähän asiaan.

Onko jotain lisättävää selitykseen? Ääni pois kommenteista. Haluatko lukea lisää vastauksia muilta tech-savvy Stack Exchange -käyttäjiltä? Tutustu koko keskusteluketjuun täällä.