Ja jums ir tendence pārlūkprogrammas rūti skatīties ar ērgļa aci, iespējams, ka esat pamanījis, 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ājumu un atbilžu sesija mums priecājas par SuperUser - Stack Exchange dalību, kas ir kopienas vadīta Q & A tīmekļa vietņu grupa.
SuperUser lasītājs Laurents ļoti interesējas par to, kāpēc tieši lapas, šķiet, lādē elementus pilnīgi citādi nekā vienreiz. Viņš raksta:
Esmu pamanījis, 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 par lēnu savienojumu, kas, iespējams, akcentē šo problēmu.
Piemēram, skat. [Augstāk] par to, ka viss ir ielādēts, bet tas aizņem vēl dažas sekundes, pirms teksts beidzot tiek rā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ā?
SuperUser autors Daniels Andersons piedāvā lieliski detalizētu atbildi, kas iegūst tiesības 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ā), piemēram, izmantojotGoogle 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ādu fontu, dizaineri instinktīvi vienmēr noteica noteikumus kā
fonta ģimene: Arial, Helvetica, sans-serif;
kur, ja sistēmā nebūtu atrasts pirmais fonts, 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 kā tādu:
@ importa URL (http://fonts.googleapis.com/css?family=Droid+Serif:400,700);
un pēc tam ielādējiet konkrētā elementa fontu, piem .:
fonta 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ēts pārlūkprogrammā, kas ietver lejupielādes laiku, fonta ielādes laiku un renderēšanas laiku. Es ceru, ka tas ir artefakts, ar kuru jūs sastopat.
Kā piemēru: viens no maniem valsts laikrakstiem Dagens Nyheter izmanto viņu fontu virsrakstus, bet ne to rādītājus, tādēļ, kad šī vietne tiek ielādēta, es parasti redzu pirmo vietu un pusi sekundes vēlāk visas iepriekš minētās tukšās vietas ir apdzīvotas ar virsrakstiem (vismaz tas attiecas uz pārlūku Chrome un Opera). Neesat izmēģinājis citus).
(Arī dizaineri skandina JavaScript šajās dienās pilnīgi visur, tāpēc varbūt kāds mēģina darīt kaut ko gudru ar tekstu, tāpēc tas ir aizkavējies. Tomēr tas būtu ļoti vietnes īpatnības: vispārējā tendence tekstā aizkavēties reizes ir iepriekš aprakstītā 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 varbūtjo no šī. Jautājuma pavedienā ir bijuši daudzi komentāri, tāpēc es mēģināšu mazliet paplašināt [...]
Problēma acīmredzot ir pazīstama kā "nepiepildīta satura zibspuldze", un jo īpaši "nepiepildīta teksta zibspuldze". Meklējot "FOUC" un "FOUT", tiek sniegta plašāka informācija.
Es varu ieteikt web dizaineru Polijas Īrijas pastu FOUT saistībā ar tīmekļa fontiem.
Kā var atzīmēt, dažādas pārlūkprogrammas to apstrādā 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 arnē tīmekļa fonta ielādes perioda laikā padarot tīmekļa fonta tekstu par rezerves fontu.Pat ja tīmeklis fonts ir kešatmiņā, turbūs būt renderēšanas kavēšanās. Š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ņemsiet FOUT
- Būs: Tālvadības ttf / otf / woff pārraidīšana un demonstrēšana
- Būs: Atspējota kešatmiņā ttf / otf / wohoff
- Būs: Datu ielāde un rādīšana ttf / otf / woff
- Būs: Kešatmiņas datu parādīšana ttf / otf / woff
- Nebūs: Fonta parādīšana, kas jau ir instalēta un nosaukta jūsu tradicionālajā fontu kaudzē
- Nebūs: Tiek parādīts fonts, kas ir instalēts un nosaukts, izmantojot vietējo () atrašanās vietu
Tā kā Chrome tiek nogaidīts līdz brīdim, kad FUT risks ir pārtraukts pirms atveidošanas, tas aizkavē. Uz kuruapjoms efekts ir redzams (it īpaši, ja tiek ielādēta no kešatmiņas), šķiet, atkarībā no citām lietām ir atkarīgs 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.Webfont, iespējams, ielādēsies šajās trīs sekundēs, lai gan ... cerams ...
- IE9 atbalsta WOFF un TTF un OTF (lai gan tas prasa iegultu bitset lieta-galvenokārt, viltus, ja jūs izmantojat WOFF).Tomēr !!! IE9 ir FOUT. :(
- Webkitam ir plāksteris, kas gaida zemi, lai parādītu rezerves tekstu pēc 0,5 sekundēm. Tāda pati darbība kā FF, bet 0,5 sekundes, nevis 3 sekundes.
Ja tas būtu jautājums, kas domāts dizaineriem, tad būtu iespējams izvairīties no tādām problēmām kā
webfontloader
, bet tas būtu vēl viens jautājums. Šajā ziņā sīkāka informācija par Paul Irish saiti.
Vai kaut ko pievienot paskaidrojumam? Skatieties komentāros. Vēlaties lasīt citas atbildes no citiem tehnoloģiju savvy Stack Exchange lietotājiem? Šeit skatiet pilnu diskusiju pavedienu.