A mai Kérdések és válaszok munkamenetét a SuperUser - a Stack Exchange, a Q & A weboldalak közösség által irányított csoportosulásának részlegével - köszönheti.
A kérdés
A SuperUser olvasó Laurent nagyon kíváncsi arra, hogy pontosan az oldalak tűnnek-e betölteni az elemeket teljesen másképpen, mint egyszer. Ír:
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.
Tehát mi ad? Laurent, és sokan közülünk emlékszünk egy olyan időpontra, amikor a szöveg elsőként és minden más eszközön - az animált GIF-ek, a hátterek és a 90-es évek végi webes böngészés minden más tárgya - jöttek később. Mi okozza a tervezési elemek jelenlegi helyzetét, később a szöveget?
A válasz
A SuperUser közreműködője, Daniel Andersson csodálatosan részletes választ ad, amely a legfrissebb titokzatosság mélyére jut:
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;
ahol, ha az első betűtípus nem található a rendszeren, akkor a böngésző a második, végül pedig a "sans-serif" betűtípust keresi.
Mostantól CSS-szabályként megadhatunk egy betűs URL-t, hogy a böngésző letöltse a betűtípust:
@import url(https://fonts.googleapis.com/css?family=Droid+Serif:400,700);
majd betölti a betűtípust egy adott elemhez pl.
font-family: 'Droid Serif',sans-serif;
Ez nagyon népszerű ahhoz, hogy egyedi betűtípusokat használhasson, de azt is okozza, hogy a böngésző nem tölti be a szöveget, amíg az erőforrás nem töltődik be, amely tartalmazza a letöltési időt, a betöltési időt és a megjelenítési időt. Arra számítottam, hogy ez a műtárgy, amit tapasztal.
Például: az egyik nemzeti újságom, Dagens Nyheter, webes betűtípust használ a főcímekhez, de nem az ólomokat, ezért ha betöltötte ezt a webhelyet, először látom a vezetőket, és fél másodperccel később minden üres mezőt betöltöttek főcímekkel (ez legalább a Chrome-ban és az Opera-ban van, még nem próbáltam meg másokat).
(A tervezők is szétszórják a JavaScriptet mindenütt napjainkban, szóval talán valaki megpróbál valami okoskodni a szöveggel, ezért késik.) Ez nagyon helyspecifikus lenne: a szöveg általános tendenciája késni fog ezeken a nyelveken hiszen hiszek a fent említett webes betűkészletek.)
Kiegészítés:
Ez a válasz nagyon felidéződött, bár nem mentem részletesen, vagy talánmert ebből. Sok kérdés merült fel a kérdéssorban, ezért megpróbálok kicsit kibővíteni […]
A jelenség nyilvánvalóan az "unstyle tartalom" flash néven ismert, és különösen a "flash of unstyled text". A "FOUC" és a "FOUT" keresése több információt ad.
Tudom ajánlani a webes tervező Paul Irish postján a FOUT a webes betűtípusokkal kapcsolatban.
Megjegyezzük, hogy a különböző böngészők ezt másképp kezelik. Fent említettem, hogy teszteltem az Opera-t és a Chrome-ot, akik mindketten hasonlóan viselkedtek. Minden WebKit-alapú (Chrome, Safari stb.) A FOUT-ot választjanem a webes betűtípus betöltése során webes betűtípus-szöveget jelenít meg a tartalék betűtípussal. Még akkor is, ha a webes betűtípus gyorsítótárba kerülakarat legyen renderelt késés. Nagyon sok megjegyzés található ebben a kérdésben, amikor másként szól, és hogy rossz, hogy a gyorsítótárazott betűtípusok így viselkednek, pl. a fenti linkből:
Milyen esetekben kap egy FOUT
- Akarat: Távoli ttf / otf / woff letöltése és megjelenítése
- Akarat: A tárolt ttf / otf / woff megjelenítése
- Akarat: Adatok letöltése és megjelenítése: ttf / otf / woff
- Akarat: A tárolt adatok megjelenítése - uri ttf / otf / woff
- Nem fog: Olyan betűtípus megjelenítése, amely már telepítve van, és a hagyományos betűkészletben szerepel
- Nem fog: Olyan betűtípus megjelenítése, amelyet a helyi () helyszínen telepítettek és neveztek
Mivel a Chrome elvárja, amíg a FOUT kockázat el nem tűnik a renderelés előtt, ez késleltetést okoz. Amelyhezmértékben a hatás látható (különösen a cache-ból való betöltéskor), úgy tűnik, hogy többek között a megjelenített szöveg és más tényezők függvénye, de a gyorsítótár nem teljesen távolítja el a hatást.
Az ír a böngésző viselkedését illetően néhány frissítést is tartalmaz a 2011-04-14-es pozíció alján:
- Firefox (az FFb11 és az FF4 Final-tól) már nincs FOUT! Wooohoo! Http: //bugzil.la/499292 Alapvetően a szöveg láthatatlan 3 másodpercig, majd visszaadja a visszaesett betűtípust. A webfont valószínűleg betölti a három másodperc alatt … remélhetőleg..
- Az IE9 támogatja a WOFF és a TTF és az OTF-et (bár ez egy olyan beágyazási bajtot igényel - főként a WOFF használatával). AZONBAN!!! Az IE9-nek van egy FOUT.:(
- A Webkitnek van egy javítócsomagja, amely várakozik a földre, hogy 0.5 másodperc múlva visszaadja a szöveget. Tehát ugyanaz a viselkedés, mint az FF, de a 3s helyett 0,5s.
Ha ez egy olyan kérdés volt, amelyet a tervezőknek terveztek, akkor olyan módokon is meg lehetne menni, amelyek elkerülnék az ilyen jellegű problémákat
webfontloader
de ez még egy kérdés. A Paul Irish kapcsolat részletesen foglalkozik ezzel a kérdéssel.
Van valami a magyarázathoz? Hangzik ki a megjegyzésekben. Szeretne többet válaszolni a többi technikus-tudós Stack Exchange felhasználóiról? Nézze meg a teljes vitafonalat itt.
