Защо уеб страниците не показват незабавно техния текст?

Ако сте склонни да гледате прозореца на браузъра с орел, може да сте забелязали, че страниците често зареждат изображенията и оформлението им, преди да заредят текста - точно обратния модел на зареждане, който преживяхме през 90-те години. Какво става?

Днешната сесия за въпроси и отговори идва при нас с любезното съдействие на SuperUser - подразделение на Stack Exchange, групирано от общността уеб сайтове за въпроси и отговори.

Въпроса

Читателят на SuperUser Laurent е много любопитен защо точно страниците изглеждат зареждащи елементи по различен начин, отколкото някога. Той пише:

Забелязах, че наскоро много уебсайтове бавно показват текста си. Обикновено фонът, изображенията и т.н. ще бъдат заредени, но няма текст. След известно време текстът започва да се появява тук-там (не винаги всичко това едновременно).

Това всъщност работи точно обратното, както преди, когато текстът се показва първо, след това изображенията и останалите се зареждат след това. Каква нова технология създава този проблем? Някаква идея?

Имайте предвид, че съм на бавна връзка, което вероятно подчертава проблема.

Виж [по-горе] за пример - всичко е заредено, но това отнема още няколко секунди, преди текстът да се покаже накрая.

И така, какво дава? Лоран и много от нас си спомнят за времето, когато текстът се зареди първо и всичко останало - анимирани GIF файлове на гарниса, облицовани с плочки фонове и всички други артефакти от сърфирането в интернет от края на 90-те години. Какво причинява текущата ситуация на елементите на дизайна, текст по-късно?

Отговорът

Сътрудникът на SuperUser Даниел Андерсън предлага чудесно подробен отговор, който стига до дъното на мистерията за последната версия:

Една от причините е, че в днешно време уеб дизайнерите обичат да използват уеб шрифтове (обикновено във формат WOFF), напр. чрез шрифтове на Google Web.

Преди това единствените шрифтове, които можеха да се показват на сайта, бяха тези, които потребителят е инсталирал локално. Тъй като напр. Потребителите на Mac и Windows не винаги са имали едни и същи шрифтове, а дизайнерите инстинктивно винаги са дефинирали правила като
фамилия: Arial, Helvetica, sans-serif; 
където, ако първият шрифт не е намерен в системата, браузърът ще търси втория и накрая резервен шрифт sans-serif.

Сега човек може да даде шрифт URL като CSS правило, за да накара браузъра да изтегли шрифт, като такъв:
@import url (http://fonts.googleapis.com/css?family=Droid+Serif:400,700); 
и след това заредете шрифта за определен елемент чрез напр .:
семейство шрифт: 'Droid Serif', без сериф; 
Това е много популярно, за да може да се използват персонализирани шрифтове, но също така води до проблема, че не се показва никакъв текст, докато ресурсът не бъде зареден от браузъра, което включва времето за изтегляне, времето за зареждане на шрифта и времето за визуализиране. Очаквам, че това е артефактът, който преживяваш.

Като пример: един от моите национални вестници, Dagens Nyheter, използва уеб шрифтове за техните заглавия, но не и техните води, така че когато този сайт е зареден, обикновено виждам водещите пръстени, а половин секунда по-късно всичките празни пространства се попълват. със заглавия (това важи най-малко за Chrome и Opera. Не съм опитвал други).

(Също така, дизайнерите пръскат JavaScript абсолютно навсякъде тези дни, така че може би някой се опитва да направи нещо умно с текста, поради което се забавя. Това би било много специфично за сайта, въпреки това: общата тенденция текстът да се забави в тези време е проблемът с уеб шрифтовете, описан по-горе.)

Освен това:

Този отговор стана много утвърден, макар че не се впуснах в подробности или може би защото от това. Имаше много коментари във въпросната нишка, така че ще се опитам да се разширя малко […]

Явлението е очевидно известно като „светкавица на непрофилирано съдържание“ като цяло, и по-специално „проблясък на непрофилиран текст“. Търсенето на “FOUC” и “FOUT” дава повече информация.

Мога да препоръчам публикацията на уеб дизайнера Paul Irish във FOUT във връзка с уеб шрифтове.

Какво може да се отбележи е, че различните браузъри се справят по различен начин. Написах по-горе, че съм тествал Opera и Chrome, които се държали по подобен начин. Всички базирани на WebKit (Chrome, Safari и др.) Избират да избягват FOUT от не визуализиране на текст на уеб шрифта с резервен шрифт по време на периода за зареждане на уеб шрифтове. Дори ако там се кешира уеб шрифтът ще бъде забавяне на рендеринга. В този въпросник има много коментари, които говорят по друг начин и че е погрешно, че кешираните шрифтове се държат по този начин, но напр. от горната връзка:

В какви случаи ще получите FOUT

Ще: Изтегляне и показване на отдалечено ttf / otf / woff

Ще: Показване на кеширано ttf / otf / woff

Ще: Изтегляне и показване на данни uri ttf / otf / woff

Ще: Показване на кеширани данни uri ttf / otf / woff

Няма да: Показване на шрифт, който вече е инсталиран и посочен в традиционния стек на шрифта

Няма да: Показване на шрифт, който е инсталиран и наименуван чрез локалното () местоположение

Тъй като Chrome изчаква, докато FOUT рискът изчезне преди рендеринга, това води до забавяне. Към който степен ефектът е видим (особено когато се зарежда от кеша), изглежда, зависи от другото количеството текст, който трябва да бъде визуализиран и може би други фактори, но кеширането не премахва напълно ефекта.

Ирландски също има някои актуализации относно поведението на браузъра от 2011-04-14 в долната част на публикацията:

Firefox (от FFb11 и FF4 Final) вече няма FOUT! Http: //bugzil.la/499292 По същество текстът е невидим за 3 секунди и след това връща аварийния шрифт. Webfont вероятно ще се зареди в рамките на тези три секунди, въпреки че… надявам се…

IE9 поддържа WOFF и TTF и OTF (въпреки че изисква вграждане на битове нещо - най-вече спорно, ако използвате WOFF). ВЪПРЕКИ ТОВА!!! IE9 има FOUT. :(

Webkit има пластир, който чака да приземява, за да покаже резервен текст след 0.5 секунди. Така същото поведение като FF, но 0.5s вместо 3s.

Ако това беше въпрос, насочен към дизайнерите, можеше да се намерят начини да се избегнат такива проблеми като webfontloader, но това ще бъде друг въпрос. Връзката с Пол Ирландски се вписва в подробности по този въпрос.

Имате ли какво да добавите към обяснението? Звукът е изключен в коментарите. Искате ли да прочетете повече отговори от други технологични потребители на Stack Exchange? Вижте пълната тема за дискусия тук.