29Aug
Ja jums ir tendence skatīties pārlūka rūti ar ērgļa aci, iespējams, ka esat pamanījuši, ka lapas pirms to teksta ievietošanas bieži ielādē savus attēlus un izkārtojumu - precīzu pretēju ielādes modeli, ko mēs pieredzējām deviņdesmitajos gados. Kas notiek?
šodienas jautājums &Atbildes sesija mums priecājas par SuperUser - Stack Exchange, kas ir kopienas un Q & A tīmekļa vietņu grupa.
Jautājums
SuperUser lasītājs Laurent ir ļoti interesējies par to, kāpēc tieši lapas, šķiet, lādē elementus pilnīgi citādi nekā vienreiz. Viņš raksta:
Esmu ievērojis, ka nesen daudzas vietnes ir lēnas, lai parādītu to tekstu. Parasti tiek ielādēts fons, attēli utt., Bet nav teksta. Pēc kāda laika tekstu sāk parādīties šeit un tur( ne vienmēr tas viss vienā un tajā pašā laikā).
Tas pamatā darbojas pretēji, kā tas bija, kad teksts vispirms tika parādīts, pēc tam attēli un pārējais tika ielādēti pēc tam. Kāda jauna tehnoloģija rada šo problēmu? Kāda ideja?
Ņemiet vērā, ka es esmu uz lēna savienojuma, kas, iespējams, akcentē šo problēmu.
Skatīt [augstāk] par piemēru - viss ir ielādēts, bet tas aizņem dažas sekundes pirms teksta beigām tiek parādīts.
Tātad, kas dod? Laurents, un daudzi no mums, atceras laiku, kad vispirms tika ielādēts teksts un viss pārējais - animētie GIF, flīžu fondi un visi pārējie 90. gadu pārlūkošanas artefakti. Kas izraisa pašreizējo dizainparauga elementu situāciju, vēlāk tekstā?
Atbilde
SuperUser atbalstītājs Daniels Andersons piedāvā lieliski detalizētu atbildi, kas iegūta tieši uz to, kāpēc-the-fonts-load-pēdējais noslēpums:
Viens no iemesliem ir tāds, ka mūsdienu dizaineri vēlas izmantot tīmekļa fontus( parasti WOFF formātā), piemizmantojotGoogle tīmekļa fontus.
Iepriekš vienīgie fonti, kurus varēja parādīt vietnē, bija tie, kurus lietotājs bija lokāli instalējis. Tā kā piem. Mac un Windows lietotājiem nebija vienāda fonta, dizaineri instinktīvi vienmēr noteica noteikumus kā
font-family: Arial, Helvetica, sans-serif;kur, ja pirmais fonts sistēmā netiktu atrasts, pārlūks meklēs otro un, visbeidzot, rezerves "sans-serif" fontu.
Tagad var piešķirt fonta URL kā CSS noteikumu, lai pārlūkprogramma varētu lejupielādēt fontu:
@import url( http: //fonts.googleapis.com/ css? Family = Droid + Serif: 400,700);un pēc tam ielādējiet konkrētā elementa fontu, piem.:
fontu saime: "Droid Serif", sans-serif;Tas ir ļoti populārs, lai varētu izmantot pielāgotus fontus, taču tas arī noved pie problēmas, ka neviens teksts netiek parādīts, kamēr resurss nav ielādējis pārlūks, kas ietver lejupielādes laiku, fonta ielādes laiku un renderēšanas laiku. Es ceru, ka tas ir artefakts, ar kuru tu piedzīvo.
Piemēram, viens no maniem valsts laikrakstiem Dagens Nyheter izmanto viņu fona virsrakstus, bet ne to virza, tādēļ, kad šī vietne tiek ielādēta, es parasti redzu pirmos celiņus, un pusi sekundes vēlāk visas tukšās vietas tiek parādītas iepriekšaprakstīts ar virsrakstiem( vismaz tas attiecas uz pārlūku Chrome un Opera). Neesat mēģinājis citus.
( Arī dizaineri šobrīd skandina JavaScript pilnīgi visur, tāpēc varbūt kāds mēģina padarīt kaut ko gudru ar tekstu, tāpēc tas ir aizkavējies. Tomēr tas būtu ļoti konkrēts vietnei: vispārēja tendence, ka teksts tiks aizkavētsšie laiki ir iepriekš aprakstīto tīmekļa fontu problēma, es uzskatu.)
Papildinājums:
Šī atbilde kļuva ļoti pozitīva, lai gan es neievēroju sīkāk vai, iespējams, , jo par šo. Jautājuma pavedienā ir bijuši daudzi komentāri, tāpēc es centīšos mazliet paplašināt [...]
. Parasti šo fenomenu sauc par "neuzstādītā satura zibspuldzi" un jo īpaši par "neuzstādītu tekstu".Meklējot "FOUC" un "FOUT", tiek sniegta plašāka informācija.
Es varu ieteikt web dizaineru Paul Īrijas pastu FOUT saistībā ar tīmekļa fontiem.
Ko var atzīmēt, ka dažādas pārlūkprogrammas rīkojas ar to atšķirīgi. Es uzrakstīju iepriekš, ka esmu pārbaudījis Opera un Chrome, kas abi rīkojās līdzīgi. Visi WebKit balstīti( Chrome, Safari uc) izvēlas izvairīties no FOUT ar nevis , padarot web fonta tekstu ar rezerves fontu web fona ielādes periodā. Pat ja tīmekļa fons ir kešatmiņā, būs kā renderēšanas aizkaves .Šajā jautājuma ziņojumā ir daudz komentāru, ka citādi ir teikts, ka ir nepareizi, ka kešatmiņā saglabātie fonti rīkojas šādi, bet, piemēram,no iepriekšējās saites:
Kādos gadījumos jūs saņemat FOUT
- Will: Tālvadības ttf /otf/ lejupielāde un attēlošana
- Will: Displeja kešatmiņā /otf/ displejs
- Will: /otf/ datu ielāde un parādīšana ttf /otf/ woff
- Will: Parādīsit kešatmiņā saglabāto datu /otf/
- netiks: Parādot fontu, kas jau ir instalēts un nosaukts jūsu tradicionālajā fontu kaudzē
- Netiks: Tiek parādīts fonts, kas ir instalēts un nosaukts, izmantojot vietējo() atrašanās vieta
Tā kā Chrome gaida, kamēr FAT risks nav pagājis pirms atlase, tas aizkavē.Uz kādu pakāpi efekts ir redzams( it īpaši, ja ielādējas no kešatmiņas), šķiet, atkarībā no citiem faktoriem ir atkarīgs arī no teksta apjoma, kas jārisina, un, iespējams, citi faktori, bet kešdarbs pilnībā neietekmē šo efektu.
Īru valodā ir arī daži atjauninājumi par pārlūka uzvedību no 2011. gada 14. aprīļa ziņas apakšā:
- Firefox ( no FFb11 un FF4 fināla) vairs nav FOUT! Wooohoo! Http: //bugzil.la/ 499292 Būtībā teksts ir neredzams 3 sekundes, un pēc tam tas atgriež atpakaļējo fontu. Iespējams, ka webfont ielādēsies šajās trīs sekunžu laikā. .. cerams. .
- IE9 atbalsta WOFF un TTF un OTF( lai gan tai ir nepieciešams iegult bitset lieta - visbiežāk, ja jūs izmantojat WOFF). JEB KĀDI! !!IE9 ir FOUT.:(
- Webkit ir plāksteris, kas gaida zemi, lai parādītu rezerves tekstu pēc 0,5 sekunžu. Tātad tāpat kā FF, bet 0,5s, nevis 3s.
Ja tas būtu jautājums, kas domāts dizaineriem, tad varētu izvairīties no veidiem, kā izvairīties no šāda veidapar problēmām, piemēram, webfontloader, bet tas būtu vēl viens jautājums. Polijas Īrijas saite sīkāk sīkāk par šo jautājumu.
Vai kaut kas jāpievieno paskaidrojumam? Skaņa off komentāri. Vēlaties lasīt citas atbildes no citiem tech-Savvy Stack Exchange lietotāji? Apskatiet visu diskusiju pavedienu šeit.