Š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.
Jautājums
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:
I’ve noticed that recently many websites are slow to display their text. Usually, the background, images and so on are going to be loaded, but no text. After some time the text starts appearing here and there (not always all of it at the same time).
It basically works the opposite as it used to, when the text was displayed first, then the images and the rest was loading afterwards. What new technology is creating this issue? Any idea?
Note that I’m on a slow connection, which probably accentuates the problem.
See [above] for an example – everything’s loaded but it takes a few more seconds before the text is finally displayed.
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 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.
One reason is that web designers nowadays like to use web fonts (usually in WOFF format), e.g. throughGoogle Web fonts.
Previously, the only fonts that were able to be displayed on a site was those that the user had locally installed. Since e.g. Mac and Windows users not necessarily had the same fonts, designers instinctively always defined rules as
font-family: 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:
@import url(https://fonts.googleapis.com/css?family=Droid+Serif:400,700);
un pēc tam ielādējiet konkrētā elementa fontu, piem.:
font-family: '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 tu piedzīvo.
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.
