Ако сте склонни да гледате прозореца на браузъра с очи за орел, може би сте забелязали, че страниците често зареждат своите изображения и оформление, преди да заредят текста си - точно обратното натоварване, което преживяхме през 90-те години. Какво става?
Днешната сесия за въпроси и отговори ни идва с любезното съдействие на SuperUser - подразделение на Stack Exchange - обединяване на уеб сайтове с въпроси и отговори.
Reader на SuperUser Laurent е много любопитен защо точно страниците изглежда натоварват елементи напълно различно, отколкото веднъж. Той пише:
Забелязах, че напоследък много уебсайтове бавно показват текста си. Обикновено фонът, изображенията и т.н. ще бъдат заредени, но няма текст. След известно време текстът започва да се появява тук и там (не винаги всичко е едновременно).
В основата си работи обратното, както преди, когато текстът беше показан на първо място, тогава изображенията и останалите се зареждаха след това. Каква нова технология създава този проблем? Някаква идея?
Имайте предвид, че съм на бавна връзка, което вероятно подчертава проблема.
Вижте [по-горе] за пример - всичко е заредено, но е необходимо още няколко секунди, преди текстът да се покаже накрая.
И така, какво дава? Лоран и много от нас си спомнят време, когато текстът се зарежда на първо място и всичко останало - гарнирани анимирани GIF, плочки с фон, както и всички останали артефакти от сърфирането в края на 90-те години. Какво причинява първо текущото състояние на дизайнерските елементи, текст по-късно?
Сътрудникът на SuperUser Даниел Андерсън предлага чудесно подробен отговор, който стига до дъното на последната загадка "Защо шрифтовете":
Една от причините е, че в днешно време уеб дизайнерите предпочитат да използват уеб шрифтове (обикновено във формат WOFF), напр. презGoogle Уеб шрифтове.
По-рано, единствените шрифтове, които могат да се показват на даден сайт, са тези, които потребителят е инсталирал локално. Тъй като, Потребителите на Mac и Windows не са имали непременно същите шрифтове, инстинктивно дизайнерите винаги са дефинирали правилата като
шрифт-семейство: Arial, Helvetica, sans-serif;
където, ако първият шрифт не е намерен в системата, браузърът ще търси втория и накрая резервен шрифт "sans-serif".
Сега може да даде URL адрес на шрифта като правило за CSS, за да накара браузъра да изтегли шрифт като такъв:
@import url (http://fonts.googleapis.com/css?family=Droid+Serif:400,700);
и след това заредете шрифта за конкретен елемент, например:
шрифт-семейство: "Droid Serif", sans-serif;
Това е много популярно, за да можете да използвате персонализирани шрифтове, но това води и до проблема, при който не се показва текст, докато ресурсът не бъде зареден от браузъра, което включва времето за изтегляне, времето за зареждане на шрифта и времето за рендиране. Очаквам, че това е артефактът, който изпитвате.
Като пример: един от моите национални вестници, Dagens Nyheter, използва уеб шрифтове за заглавията си, но не и техните линии, така че когато се зарежда този сайт, обикновено виждам изводите и след половин секунда всички празни пространства по-горе се попълват с заглавия (това важи и за Chrome и Opera, поне не са опитали другите).
(Също така, дизайнерите поръсват JavaScript абсолютно навсякъде тези дни, така че може би някой се опитва да направи нещо умно с текста, поради което се забавя. Това обаче би било много специфично за сайта: общата тенденция за забавяне на текста пъти е въпросът за уеб шрифтове, описан по-горе.
Освен това:
Този отговор стана много популярен, макар че не бях в много подробности или може бизащото от това. Има много коментари във въпросната нишка, затова ще се опитам да разширя малко [...]
Феноменът е очевидно известен като "проблясък на нестилизирано съдържание" като цяло, и по-специално "отблясък от нестимулиран текст". Търсенето на "FOUC" и "FOUT" дава повече информация.
Мога да препоръчам публикацията на уеб дизайнера Paul Irish във FOUT във връзка с уеб шрифтове.
Това, което може да се отбележи е, че различните браузъри се справят с това по различен начин. Написах по-горе, че съм тествал Opera и Chrome, които и двете се държеха по същия начин. Всички базирани на WebKit (Chrome, Safari и др.) Избират да избегнат FOUTне превръщането на текста на уеб шрифта с резервен шрифт по време на периода за зареждане на шрифтове в мрежата.Дори ако уеб шрифтът е кеширан, тамще бъде забавяне на отлагането, Има много коментари в тази тема нишка, казвайки по друг начин и че е неправилно, че кешираните шрифтове се държат по този начин, но напр. от горната връзка:
В какви случаи ще получите FOUT
- Ще: Изтегляне и показване на отдалечено устройство ttf / otf / woff
- Ще: Показване на кеширана ttf / otf / woff
- Ще: Изтегляне и показване на данни ttf / otf / woff
- Ще: Показване на кеширана информация ttf / otf / woff
- Няма да: Показване на шрифт, който вече е инсталиран и наименуван в традиционния стек на шрифта
- Няма да: Показване на шрифт, който е инсталиран и наименуван чрез локалното () местоположение
Тъй като Chrome чака, докато рискът FOUT изчезне преди рендиране, това ще доведе до забавяне. Към койтостепен ефектът е видим (особено когато се зарежда от кеш), изглежда зависи от това колко текст трябва да бъде изобразен, а може би и други фактори, но кеширането не премахва напълно ефекта.
Irish също има някои актуализации относно поведението на браузърите от 2011-04-14 в дъното на публикацията:
- Firefox (от FFb11 и FF4 Final)вече няма FOUT! Wooohoo! Http: //bugzil.la/499292 Основно текстът е невидим за 3 секунди и след това връща резервния шрифт.Webfont вероятно ще се зареди в рамките на тези три секунди, макар че ... надявам се ...
- IE9 поддържа WOFF и TTF и OTF (въпреки че изисква вграждане на нещо битове - най-вече, ако използвате WOFF).ВЪПРЕКИ ТОВА!!! IE9 има FOUT. :(
- Webkit има пластир, който чака да се приземи, за да покаже резервен текст след 0.5 секунди. Същото поведение като FF, но 0.5s вместо 3s.
Ако това беше въпрос, насочен към дизайнерите, може да се намерят начини за избягване на такива проблеми като
webfontloader
, но това ще бъде друг въпрос. Връзката между Пол и Ирландия става по-подробна по този въпрос.
Имате ли нещо, което да добавите към обяснението? Звучи в коментарите. Искате ли да прочетете повече отговори от други потребители на Stack Exchange? Вижте цялата тема на дискусията тук.