Proč webové stránky okamžitě nezobrazí text?

Pokud jste náchylní sledovat podokno prohlížeče pomocí orla, možná jste si všimli, že stránky často načítají své obrázky a rozložení před načtením textu - přesně opačný vzorek načítání, který jsme zažili během devadesátých let. Co se děje?

Dnešní zasedání Otázky a odpovědi nás přichází s laskavým svolením SuperUser - podřízené rozdělení Stack Exchange, které je založeno na komunitě prostřednictvím skupin webových stránek.

Otázka

Čtenář SuperUser Laurent je velmi zvědavý, proč se zdá, že přesně stránky načítají prvky úplně jinak než jednou. Napsal:

Všiml jsem si, že v poslední době mnoho webových stránek pomalu zobrazuje jejich text. Obvykle budou pozadí, obrázky a tak dále načteny, ale žádný text. Po nějaké době se text začíná objevovat tady a tam (ne vždy to všechno najednou).

V podstatě funguje opak, jako když to bylo dříve, když byl text nejprve zobrazen, potom se obrázky a ostatní začaly načítat. Jaká nová technologie vytváří tento problém? Nějaký nápad?

Všimněte si, že jsem na pomalém připojení, což pravděpodobně zdůrazňuje problém.

Viz příklad - vše je načtené, ale trvá to ještě několik sekund, než se konečně zobrazí text.

Takže co dává? Laurent a mnozí z nás si pamatují čas, kdy se text načten nejprve a všechno ostatní - podivné oživené GIF, dlaždicové pozadí a všechny ostatní artefakty prohlížení webu konce 90. let - přišly později. Co způsobuje současnou situaci prvků návrhu, text později?

Odpověď

Sponzor SuperUser Daniel Andersson nabízí úžasně detailní odpověď, která se dostává přímo do spodní části záhadu "why-the-fonts-load-last":

Jedním z důvodů je, že weboví návrháři dnes chtějí používat webové písma (obvykle ve formátu WOFF), např. prostřednictvím webových písemGoogle.

Dříve byly na webu zobrazeny pouze fonty, které uživatel instaloval místně. Protože např. Uživatelé Mac a Windows nemuseli nutně mít tytéž fonty, návrháři instinktivně vždy definovali pravidla jako
font-family: Arial, Helvetica, sans-serif; 
kde, pokud první písmo nebylo nalezeno v systému, prohlížeč by hledal druhý a nakonec záložní písmo "sans-serif".

Nyní můžete zadat adresu URL písma jako pravidlo CSS, abyste získali prohlížeč ke stažení písma, jako takové:
@import url (http://fonts.googleapis.com/css?family=Droid+Serif:400,700); 
a pak načíst písmo pro konkrétní prvek například:
font-family: 'Droid Serif', sans-serif; 
To je velmi populární, pokud chcete používat vlastní písma, ale také vede k problému, že se žádný text nezobrazí, dokud nebude prostředek načten prohlížeč, což zahrnuje čas stahování, čas načítání písma a čas vykreslení. Očekávám, že se jedná o artefakt, který zažíváte.

Jako příklad: jeden z mých národních novin, Dagens Nyheter, používá webové fonty pro jejich titulky, ale ne jejich vodítka, takže když je toto místo načteno, obvykle vidím vodiče jako první a o půl vteřiny později jsou všechny prázdné prostory nahoře s titulky (to platí v případě Chrome a Opera alespoň. Nezkoušejte ostatní).

(Také designéři poskvrňují JavaScript absolutně všude v těchto dnech, takže možná se někdo pokouší udělat něco chytrého s textem, což je důvod, proč je zpožděno. To by bylo velmi specifické pro danou stránku, ačkoli: obecná tendence, aby text byl zpožděn v těchto Times je otázka webových písem popsaná výše.

Přidání:

Tato odpověď se stala velice oblíbenou, ačkoli jsem nešel příliš podrobně, nebo snad protože z toho. Tam bylo mnoho komentářů v dotazu vlákno, takže se pokusím rozšířit trochu [...]

Tento fenomén je zjevně známý jako "záblesk neoslepeného obsahu" obecně a "záblesk neoslepeného textu" zvláště. Vyhledávání "FOUC" a "FOUT" poskytuje více informací.

Mohu doporučit příspěvek webdesignera Paul Irish na FOUT v souvislosti s webovými fonty.

Dá se na paměti, že různé prohlížeče to zvládnou jinak. Napsal jsem výše, že jsem zkoušel operu a Chrome, kteří se podobně chovají. Všechny programy založené na WebKit (Chrome, Safari atd.) Se rozhodnou vyhnout FOUT ne vykreslování textu písma na webu pomocí záložního písma během načítání písma webových stránek. I kdyby webová písma je ukládána do mezipaměti, tam vůle být zpoždění vykreslení. Existuje spousta komentářů v této otázce vlákno říká jinak a že je plochý špatně, že mezipaměti písma se chovají takto, ale např. z výše uvedeného odkazu:

V jakých případech dostanete FOUT

Vůle: Stahování a zobrazení vzdáleného ttf / otf / woff

Vůle: Zobrazení vyrovnávací paměti ttf / otf / woff v mezipaměti

Vůle: Stahování a zobrazení data-uri ttf / otf / woff

Vůle: Zobrazí data uložená v mezipaměti ttf / otf / woff

Nebude: Zobrazuje písmo, které je již nainstalováno a pojmenované ve vašem tradičním zásobníku písem

Nebude: Zobrazuje písmo, které je nainstalováno a pojmenováno pomocí lokálního () umístění

Vzhledem k tomu, že Chrome čeká, dokud nebude riziko FOUT před vykreslováním, bude to zpožděno. Ke kterému rozsah efekt je viditelný (zejména při načítání z vyrovnávací paměti) se zdá být závislý mimo jiné na množství textu, který je třeba vykreslit a možná i na jiné faktory, ale ukládání do vyrovnávací paměti zcela nezmizí účinek.

Irish má také některé aktualizace týkající se chování prohlížeče od 2011-04-14 v dolní části příspěvku:

Firefox (od FFb11 a FF4 Final) už nemá FOUT! Wooohoo! Http: //bugzil.la/499292 V podstatě je text neviditelný po dobu 3 sekund a pak to vrátí záložní písmo. Webfont se pravděpodobně nahraje během těch tří vteřin, ačkoliv ... doufejme ...

IE9 podporuje WOOFF a TTF a OTF (ačkoli to vyžaduje vkládání bitové věty - většinou neplatí, pokud používáte WOFF). NICMÉNĚ!!! IE9 má FOUT. :(

Webkit má patch čekání na přistání, aby ukázal záložní text po 0,5 sekundách. Stejné chování jako FF, ale 0.5s namísto 3s.

Pokud by to byla otázka určená pro návrháře, mohli bychom se vyhnout způsobům, jako tomu například vyvrátit webfontloader, ale to by byla další otázka. Paul Irish odkaz odkazuje na tuto otázku.

Musíte něco přidat k vysvětlení? Vypadněte v komentářích. Chcete se dozvědět více odpovědí od ostatních uživatelů technologie Stack Exchange? Podívejte se na celý diskusní příspěvek zde.