Waarom geven webpagina's niet onmiddellijk hun tekst weer?

Als je het browservenster met een adelaarsoog bekijkt, is het je misschien al opgevallen dat pagina's hun afbeeldingen en opmaak vaak laden voordat ze hun tekst laden, precies het tegenovergestelde laadpatroon dat we in de jaren negentig hebben ervaren. Wat gebeurd er?

De Question & Answer-sessie van vandaag komt tot ons dankzij SuperUser - een onderdeel van Stack Exchange, een gemeenschapsgedreven groep van Q & A-websites.

De vraag

SuperUser-lezer Laurent is erg benieuwd waarom pagina's elementen heel anders lijken te laden dan ooit. Hij schrijft:

Ik heb gemerkt dat recentelijk veel websites hun tekst traag weergeven. Meestal worden de achtergrond, afbeeldingen enzovoort geladen, maar geen tekst. Na verloop van tijd verschijnt de tekst hier en daar (niet altijd allemaal tegelijk).

Het werkt in feite precies het tegenovergestelde zoals vroeger, toen de tekst eerst werd weergegeven, waarna de beelden en de rest achteraf werden geladen. Met welke nieuwe technologie wordt dit probleem veroorzaakt? Enig idee?

Merk op dat ik een trage verbinding heb, wat waarschijnlijk het probleem accentueert.

Zie [hierboven] voor een voorbeeld - alles is geladen, maar het duurt nog een paar seconden voordat de tekst uiteindelijk wordt weergegeven.

Dus wat geeft het? Laurent, en velen van ons, onthouden een tijd waarin de eerst geladen tekst en al het andere - bedwelmende geanimeerde GIF's, betegelde achtergronden en alle andere artefacten van eind jaren negentig op internet bladerde - later kwamen. Wat veroorzaakt de huidige situatie van ontwerpelementen eerst, later tekst?

Het antwoord

Superuser-bijdrager Daniel Andersson biedt een prachtig gedetailleerd antwoord dat het dieptepunt van het last-laatste mysterie van waarom-de-lettertypen tot een goed einde brengt:

Eén reden is dat webontwerpers tegenwoordig graag weblettertypen gebruiken (meestal in WOFF-indeling), b.v. via Google Web-lettertypen.

Voorheen waren de enige lettertypen die op een site konden worden weergegeven, de lettertypen die de gebruiker lokaal had geïnstalleerd. Omdat b.v. Mac- en Windows-gebruikers hadden niet noodzakelijk dezelfde lettertypen, ontwerpers definieerden instinctief altijd regels zoals
font-family: Arial, Helvetica, sans-serif; 
waar, als het eerste lettertype niet op het systeem werd gevonden, de browser naar het tweede, en tenslotte een fallback "sans-serif" -lettertype zou zoeken.

Nu kan iemand een font-URL als een CSS-regel opgeven om de browser een lettertype te laten downloaden, als zodanig:
@import url (http://fonts.googleapis.com/css?family=Droid+Serif:400.700); 
en laad dan het lettertype voor een specifiek element door bijv .:
font-family: 'Droid Serif', sans-serif; 
Dit is erg populair om aangepaste lettertypen te kunnen gebruiken, maar het leidt ook tot het probleem dat er geen tekst wordt weergegeven totdat de bron door de browser is geladen, zoals de downloadtijd, de laadtijd van het lettertype en de weergavetijd. Ik verwacht dat dit het artefact is dat je ervaart.

Als voorbeeld: een van mijn nationale kranten, Dagens Nyheter, gebruikt weblettertypen voor hun headlines, maar niet hun leads, dus wanneer die site is geladen, zie ik meestal de leads eerst en een halve seconde later zijn alle lege spaties hierboven gevuld met koppen (dit geldt in ieder geval voor Chrome en Opera. Ik heb anderen niet geprobeerd).

(Ook de ontwerpers sprenkelen JavaScript absoluut overal tegenwoordig, dus misschien probeert iemand iets slims met de tekst te doen, en daarom is het vertraagd.) Dat zou echter heel specifiek zijn voor de site: de algemene tendens dat tekst in deze wordt vertraagd keer is de kwestie van het weblettertype hierboven beschreven, geloof ik.)

toevoeging:

Dit antwoord werd zeer geaccentueerd, hoewel ik niet veel in detail ging, of misschien omdat van dit. Er zijn veel opmerkingen in de vraagthread geweest, dus ik zal proberen een beetje uit te breiden [...]

Het verschijnsel is blijkbaar bekend als "flash van niet-gestileerde inhoud" in het algemeen, en in het bijzonder "flash of unstyled text". Zoeken naar "FOUC" en "FOUT" geeft meer informatie.

Ik kan het bericht van webontwerper Paul Irish op FOUT aanraden in verband met weblettertypen.

Wat opvalt is dat verschillende browsers dit anders aanpakken. Ik schreef hierboven dat ik Opera en Chrome had getest, die zich allebei op dezelfde manier gedroegen. Alle op WebKit gebaseerde degenen (Chrome, Safari, etc.) kiezen ervoor om FOUT te vermijden door niet het renderen van een weblettertype met een fallback-lettertype tijdens het laden van het weblettertype. Zelfs indien het weblettertype wordt daar in de cache opgeslagen zullen een vertraagde weergave zijn. Er zijn veel opmerkingen in deze vraagdraad die iets anders zeggen en dat het volkomen verkeerd is dat in cache opgeslagen lettertypen zich zo gedragen, maar b. van de bovenstaande link:

In welke gevallen krijg je een FOUT

Zullen: Downloaden en weergeven van een externe ttf / otf / woff

Zullen: Een gecachte ttf / otf / woff weergeven

Zullen: Downloaden en weergeven van een gegevens-uri ttf / otf / woff

Zullen: Weergave van een gecachte data-uri ttf / otf / woff

Zal niet: Een lettertype weergeven dat al is geïnstalleerd en wordt genoemd in uw traditionele lettertypestack

Zal niet: Een lettertype weergeven dat is geïnstalleerd en benoemd met de lokale () locatie

Aangezien Chrome wacht totdat het FOUT-risico is verdwenen vóór het renderen, geeft dit een vertraging. Waar naartoe omvang het effect is zichtbaar (vooral bij het laden vanuit de cache) lijkt afhankelijk te zijn van onder andere de hoeveelheid tekst die moet worden weergegeven en misschien andere factoren, maar caching verwijdert het effect niet volledig.

Irish heeft ook enkele updates met betrekking tot het gedrag van browsers vanaf 2011-04-14 onderaan het bericht:

Firefox (vanaf FFb11 en FF4 Final) heeft niet langer een FOUT! Wooohoo! Http: //bugzil.la/499292 In principe is de tekst 3 seconden onzichtbaar en dan komt het fallback-lettertype terug. Het webadres zal waarschijnlijk binnen die drie seconden worden geladen ... hopelijk ...

IE9 ondersteunt WOFF en TTF en OTF (hoewel het een embedding-bitsets vereist, meestal als je WOFF gebruikt). ECHTER!!! IE9 heeft een FOUT. :(

Webkit heeft een patch die wacht om te landen om terugvaltekst na 0,5 seconden weer te geven. Dus hetzelfde gedrag als FF maar 0,5s in plaats van 3s.

Als dit een vraag was gericht op ontwerpers, zou men manieren kunnen vinden om dit soort problemen zoals te vermijden webfontloader, maar dat zou een andere vraag zijn. De Paul Irish link gaat hier dieper op in.

Heb je iets toe te voegen aan de uitleg? Geluid uit in de reacties. Wilt u meer antwoorden van andere technisch onderlegde Stack Exchange-gebruikers lezen? Bekijk hier de volledige discussiethread.