Miks ei avalda veebilehti kohe teksti?

Kui teil on kalduvus vaadata brauseripaneeli koos kotkasilmaga, siis võib-olla olete märganud, et lehed laadivad oma pildid ja paigutuse sageli enne teksti laadimist - täpselt vastupidist laadimiskorda, mida me 1990. aastatel kogesime. Mis toimub?

Tänane küsimuste ja vastuste seanss saabub meiega kohtades, kus on SuperUser-Stack Exchange'i alajaotis, kogukondlikult juhitav Q&A veebisaitide rühmitus.

Küsimus

SuperUser-lugeja Laurent on väga uudishimulik, miks täpselt leheküljed näivad elemente täiesti erineval viisil, kui nad kord korda tegid. Ta kirjutab:

Olen märganud, et hiljuti on paljud veebilehed oma teksti kuvamiseks aeglased. Tavaliselt laaditakse taust, pildid ja nii edasi, kuid teksti ei ole. Mõne aja pärast hakkab tekst siin ja seal ilmuma (mitte alati korraga).

Põhimõtteliselt toimib see vastupidiselt, kui tekst esmakordselt kuvati, seejärel pildid ja ülejäänud laaditi hiljem. Milline uus tehnoloogia seda probleemi tekitab? Iga mõte?

Pange tähele, et ma olen aeglasel ühendusel, mis tõenäoliselt seda probleemi süvendab.

Näite [ülaltoodud] näite kohta - kõik on laaditud, kuid see võtab aega veel paar sekundit enne teksti lõplikku kuvamist.

Mis siis annab? Laurent ja paljud meist mäletavad aega, mil tekst laaditi esmalt ja kõik muu-garnish animeeritud GIF-id, plaaditud taustad ja kõik muud 90-ndate aastate veebibrauserite esemed tulid hiljem. Mis põhjustab esmalt disainielementide praeguse olukorra, teksti hiljem?

Vastus

SuperUser'i kaasautor Daniel Andersson pakub imeliselt üksikasjalikku vastust, mis saab õigesti just sellepärast, miks-the-fonts-last-last mystery:

Üks põhjus on see, et veebidisainerid soovivad tänapäeval kasutada veebifonte (tavaliselt WOFF-vormingus), nt. Google'i veebifontide kaudu.

Varem olid ainsad saidil kuvatavad fontid need, mida kasutaja oli kohalikult installinud. Kuna nt Maci ja Windowsi kasutajatel ei olnud tingimata samu fonte, kuid disainerid määratlevad instinktiivselt alati reegleid

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

kus, kui esimest fondi ei leitud süsteemis, otsib brauser teist ja lõpuks varukoopiafaili „sans-serif”.

Nüüd saab CSS-reeglina anda fontide URL-i, et saada brauser fontide allalaadimiseks:

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

ja seejärel laadige konkreetse elemendi font vastavalt:

font-family: „Droid Serif”, sans-serif; 

See on väga populaarne kohandatud fontide kasutamiseks, kuid see toob kaasa ka probleemi, et ühtegi teksti ei kuvata enne, kui brauser on laadinud ressursi, mis hõlmab allalaadimisaega, fontide laadimise aega ja esitamise aega. Ma loodan, et see on artefakt, mida te kogete.

Näiteks: üks mu riiklikest ajalehtedest, Dagens Nyheter, kasutab oma pealkirjade jaoks veebifonte, kuid mitte nende juhte, nii et kui see sait on laaditud, näen ma tavaliselt juhtmeid esimesena ja pool sekundit hiljem kõik ülalolevad tühjad ruumid on asustatud pealkirjadega (see kehtib vähemalt Chrome'i ja Opera kohta)..

(Ka disainerid puistavad JavaScripti absoluutselt kõikjal nendel päevadel, nii et võib-olla üritab keegi teksti abil targalt teha, mistõttu see on edasi lükatud. on eelpool kirjeldatud veebifontide probleem, ma usun.)

Lisamine:

See vastus sai väga ülestõusmisest, kuigi ma ei läinud väga üksikasjalikult või mitte sest sellest. Küsimuse teemas on palju kommentaare, nii et ma püüan veidi laiendada […]

Ilmselgelt tuntakse seda kui „stiliseerimata sisu välku” ja eriti „kustutamata teksti vilkumist”. FOUC ja FOUT otsimine annab rohkem infot.

Ma saan soovitada veebidisaineri Paul Iiri postitust FOUTis seoses veebifontidega.

Pange tähele, et erinevad brauserid hakkavad seda erinevalt käsitsema. Ma kirjutasin eespool, et olen katsetanud Opera ja Chrome'i, kes mõlemad käitusid sarnaselt. Kõik WebKitil põhinevad (Chrome, Safari jne) valivad FOUT-i vältimise mitte veebifondi teksti varundamine veebifondi laadimisperioodi ajal. Isegi kui veebifont on seal vahemällu salvestatud tahe olema viivitus. Selles küsimuses on palju kommentaare, mis ütlevad teisiti ja et on vale, et vahemällu salvestatud fondid käituvad sellisena, kuid nt. ülaltoodud lingist:

Millistel juhtudel saad FOUT

• Kas: Kaugjuhtimispuldi ttf / otf / woff allalaadimine ja kuvamine
• Kas: Vahemällu salvestatud ttf / otf / woffi kuvamine
• Kas: Andmefunktsioonide ttf / otf / woff allalaadimine ja kuvamine
• Kas: Vahemällu salvestatud andmefilmide ttf / otf / woff kuvamine
• Ei tee: Näidatakse juba installitud ja tavapärases fondipakis nime saanud font
• Ei tee: Paigaldatud ja kohaliku () asukoha järgi nime saanud fontide kuvamine

Kuna Chrome ootab, kuni FOUT-risk on enne renderdamist kadunud, annab see viivituse. Mille ulatuses mõju on nähtav (eriti vahemälust laadimisel) tundub olevat sõltuv muu hulgas pakutava teksti kogusest ja võib-olla ka muudest teguritest, kuid vahemälu ei kõrvalda efekti täielikult.

Iiri keeles on ka mõningaid brauseri käitumist puudutavaid värskendusi alates 2011-04-14 postituse allosas:

• Firefox (nagu FFb11 ja FF4 finaal) enam ei ole FOUT! Wooohoo! Http: //bugzil.la/499292 Põhimõtteliselt on tekst 3 sekundit nähtamatu ja siis toob see tagasi varukoopia. Webfont laadib tõenäoliselt need kolm sekundit, kuigi ... loodetavasti ...
• IE9 toetab WOFF-i ja TTF-i ja OTF-i (kuigi see eeldab, et kasutate WOFF-i kasutamisel blast-asju). KUID!!! IE9-l on FOUT. :(
• Webkitil on plaaster, mis ootab maandumist, et näidata varundusteksti 0,5 sekundi pärast. Nii sama käitumine kui FF-l, kuid 3-ndate asemel 0,5-ndatel.

Kui see on disainerite jaoks mõeldud küsimus, võiksid minna sellistesse probleemidesse nagu veebihaldur, kuid see oleks veel üks küsimus. Paul Iiri link läheb selles küsimuses üksikasjalikumalt.

Kas teil on midagi lisada selgitusele? Hääletage kommentaarides. Kas soovite lugeda rohkem vastuseid teistelt tech-savvy Stack Exchange'i kasutajatelt? Vaadake siin täielikku arutelu lõiku.