Kāpēc ne Web lapas nekavējoties parādīt savu tekstu?

Ja jums ir tendence skatīties pārlūkprogrammas rūti ar ērgļa aci, iespējams, esat ievērojuši, ka lapas bieži ielādē savus attēlus un izkārtojumu, pirms ielādējat savu tekstu - tieši pretējo iekraušanas modeli, ko pieredzējām 90. gados. Kas notiek?

Šodienas jautājumu un atbilžu sesija mums dod pieklājību no SuperUser-Stack Exchange apakšnodaļas, kas ir kopienas orientēta Q & A tīmekļa vietņu grupa.

Jautājums

SuperUser lasītājs Laurent ir ļoti ziņkārīgs par to, kāpēc tieši lapas, šķiet, ielādē elementus pilnīgi savādāk, nekā viņi reiz darīja. Viņš raksta:

Esmu ievērojis, ka nesen daudzās tīmekļa vietnēs ir lēns, lai parādītu savu tekstu. Parasti fons, attēli un tā tālāk tiks ielādēti, bet nav teksta. Pēc kāda laika teksts sāk parādīties šeit un tur (ne vienmēr tas viss vienlaikus).

Būtībā tas darbojas pretēji, kā tas bija agrāk, kad teksts tika parādīts vispirms, pēc tam attēli un pārējie tika ielādēti pēc tam. Kādas jaunas tehnoloģijas rada šo problēmu? Kāda ideja?

Ņemiet vērā, ka es esmu lēns savienojums, kas, iespējams, akcentē problēmu.

Par piemēru skatiet [iepriekš] - viss ir ielādēts, bet paies vēl dažas sekundes, līdz teksts beidzot tiek parādīts.

Tātad, ko dod? Laurents un daudzi no mums atceras laiku, kad teksts tika ielādēts vispirms, un viss pārējais - garrīši animēti GIF, flīžu foni un visi citi 90. gadu beigu tīmekļa pārlūkošanas artefakti - vēlāk. Kas vispirms izraisa dizaina elementu pašreizējo situāciju, vēlāk tekstu?

Atbilde

SuperUser līdzstrādnieks Daniels Anderssons piedāvā brīnišķīgi detalizētu atbildi, kas iegūst tiesības uz to, kāpēc - fonti-last-mystery:

Viens no iemesliem ir tas, ka tīmekļa dizaineri mūsdienās vēlas izmantot tīmekļa fontus (parasti WOFF formātā), piem. izmantojot Google Web fontus.

Agrāk vienīgie fonti, kas bija redzami vietnē, bija tie, kurus lietotājs bija uzstādījis lokāli. Tā kā, piemēram, Mac un Windows lietotājiem ne vienmēr bija tie paši fonti, dizaineri instinktīvi vienmēr definēja noteikumus kā

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

ja, ja sistēmā netika atrasts pirmais fonts, pārlūks meklēs otro, un, visbeidzot, rezerves „sans-serif” fontu.

Tagad varat norādīt fontu URL kā CSS noteikumu, lai pārlūkprogramma lejupielādētu fontu kā tādu:

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

un pēc tam ielādējiet konkrēta elementa fontu, piemēram,

font-family: “Droid Serif”, sans-serifs; 

Tas ir ļoti populārs, lai varētu izmantot pielāgotus fontus, taču tas rada arī problēmu, ka teksts netiek rādīts, kamēr pārlūks nav ielādējis resursus, kas ietver lejupielādes laiku, fonta ielādes laiku un atveidošanas laiku. Es ceru, ka tas ir artefakts, ko jūs piedzīvojat.

Piemēram: viens no maniem nacionālajiem laikrakstiem, Dagens Nyheter, izmanto virsrakstiem tīmekļa fontus, bet ne to vadību, tāpēc, kad šī vietne tiek ielādēta, parasti es pirmo reizi redzu vadus, bet pusstundu vēlāk visas tukšās vietas tiek aizpildītas ar virsrakstiem (tas attiecas vismaz uz pārlūku Chrome un Opera..

(Arī šajās dienās dizaineri apkaisa JavaScript absolūti visur, tāpēc varbūt kāds mēģina kaut ko gudri izdarīt ar tekstu, tāpēc tas aizkavējas. Tas būtu ļoti specifisks vietnei: vispārēja tendence tekstā aizkavēties laiki ir iepriekš aprakstītais tīmekļa fontu jautājums.

Papildinājums:

Šī atbilde kļuva ļoti aktuāla, lai gan es neiedziļinājos sīkāk vai varbūt tāpēc, ka no šī. Jautājumā ir bijuši daudzi komentāri, tāpēc es centīšos mazliet paplašināt […]

Acīmredzot šī parādība ir pazīstama kā „neiedodama satura zibspuldze” kopumā, un jo īpaši “neaktīva teksta zibspuldze”. “FOUC” un “FOUT” meklēšana dod vairāk informācijas.

Es varu ieteikt web dizainera Paul Īrijas ziņu par FOUT saistībā ar tīmekļa fontiem.

Jāatzīmē, ka dažādas pārlūkprogrammas to apstrādā atšķirīgi. Es rakstīju iepriekš, ka esmu pārbaudījis Opera un Chrome, kuri abi rīkojās līdzīgi. Visi WebKit balstītie (Chrome, Safari uc) izvēlas izvairīties no FOUT ne padarīt tīmekļa fontu tekstu ar rezerves fontu tīmekļa fontu iekraušanas perioda laikā. Pat ja tur ir tīmekļa kešatmiņa gribu būt aizkavēšanās. Šajā jautājumā ir daudz komentāru, kas norāda, ka citādi ir nepareizi un ka kešatmiņā saglabātie fonti ir tādi, piemēram, no iepriekš minētās saites:

Kādos gadījumos jūs saņemsiet FOUT

• Vai: Tālvadības ttf / otf / woff lejupielāde un rādīšana
• Vai: Parādot kešatmiņā ievadītu ttf / otf / woff
• Vai: Datu uri ttf / otf / woff lejupielāde un rādīšana
• Vai: Kešatmiņā ievadītu datu uri ttf / otf / woff parādīšana
• Nebūs: Tiek parādīts fonts, kas jau ir instalēts un nosaukts jūsu tradicionālajā fonta stekā
• Nebūs: Uzstādītā un vietējā () atrašanās vietā nosaukta fonta parādīšana

Tā kā Chrome gaida, līdz FOUT risks ir pagājis pirms atveidošanas, tas rada kavēšanos. Uz kuru apjomā efekts ir redzams (jo īpaši, ja ielādē no kešatmiņas), šķiet, ir atkarīgs, cita starpā, ar tekstu, kas ir jāpadara, un, iespējams, citiem faktoriem, bet kešatmiņa pilnībā neatceļ efektu.

Īru valodā arī ir daži atjauninājumi, kas attiecas uz pārlūkprogrammas darbību, sākot ar 2011-04-14 ziņojuma apakšā:

• Firefox (kā FFb11 un FF4 fināls) vairs nav FOUT! Wooohoo! Http: //bugzil.la/499292 Pamatā teksts ir neredzams 3 sekundes, un tad tas atkal atjauno rezerves fontu. Tīmekļa vietne, iespējams, tiks ielādēta šo trīs sekunžu laikā, lai gan ... cerams…
• IE9 atbalsta WOFF un TTF un OTF (lai gan tas prasa, lai tiktu izmantota bitset lieta, galvenokārt strīdīga, ja lietojat WOFF). Tomēr! IE9 ir FOUT. :(
• Webkit ir plāksteris, kas gaida, lai parādītu rezerves tekstu pēc 0,5 sekundēm. Tāda pati uzvedība kā FF, bet 0.5s vietā 3s.

Ja tas bija jautājums, kas bija paredzēts dizaineriem, varētu rasties iespējas izvairīties no šādām problēmām, piemēram, webfontloader, bet tas būtu vēl viens jautājums. Saites Paul Īrijas saite šajā jautājumā ir sīkāk aprakstīta.

Vai kaut kas jāpievieno paskaidrojumam? Skaņas izslēgšana komentāros. Vai vēlaties lasīt vairāk atbildes no citiem tehnoloģiju gudriem Stack Exchange lietotājiem? Apskatiet pilnu diskusiju pavedienu šeit.