Waarom geven webpagina's niet onmiddellijk hun tekst weer?

Als je met een adelaarsoog naar het browservenster kijkt, 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 vraag van vandaag &Antwoord sessie komt naar ons met dank aan SuperUser-een onderverdeling van Stack Exchange, een community-gestuurde groepering 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 alles tegelijkertijd).

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

Houd er rekening mee 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, herinneren zich 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 de waarom-de-lettertypen volgt:

Een reden is dat webontwerpers tegenwoordig graag weblettertypen gebruiken( meestal in WOFF-formaat)), bijvvia Google Web-lettertypen.

Eerder waren de enige lettertypen die op een site konden worden weergegeven die de gebruiker lokaal had geïnstalleerd. Omdat b.v. Mac- en Windows-gebruikers hadden niet noodzakelijk dezelfde lettertypen, ontwerpers definieerden instinctief altijd regels als

-lettertypefamilie: Arial, Helvetica, sans-serif;

waarbij, 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 vervolgens 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 wordt geladen, zie ik meestal de leads eerst en een halve seconde later zijn alle lege spaties hierbovenbevolkt 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 voor de site zijn: de algemene tendens dat tekst wordt vertraagddeze tijden is de kwestie van het weblettertype hierboven beschreven, geloof ik.)

Optelling:

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

Het fenomeen is blijkbaar bekend als "flash van unstyled content" in het algemeen, en "flash of unstyled text" in het bijzonder. 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, enz.) Kiezen ervoor om FOUT te vermijden door niet rendering van weblettertypetekst met een fallback-lettertype tijdens de laadperiode van het weblettertype. Zelfs als het weblettertype in de cache wordt opgeslagen, zal een rendervertraging 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 bijvoorbeeldvia de bovenstaande link:

In welke gevallen krijgt u een FOUT

• Will: Een externe ttf downloaden en weergeven /otf/ woff
• Will: Een cache ttf weergeven /otf/ woff
• Will: Een gegevensurve downloaden en weergeven /otf/ woff
• Will: Een cache-gegevenstype weergeven /otf/ woff
• Zal niet: Een lettertype weergeven dat al is geïnstalleerd en een naam heeft in uw traditionele lettertypestack
• Will not: 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. Aan welke -uitbreiding het effect zichtbaar is( vooral bij het laden uit 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 de post:

• 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 inbedding-bitsets vereist, meestal als je WOFF gebruikt). NOCHTANS! !!IE9 heeft een FOUT.:(
• Webkit heeft een patch die wacht om te landen om fallback-tekst weer te geven na 0,5 seconden. Dus hetzelfde gedrag als FF maar 0,5s in plaats van 3s.

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

Heeft u iets toe te voegen aan de uitleg? Geluid uit in de opmerkingen. Wilt u meer antwoorden van andere techneuten lezen?savvy Stack Exchange-gebruikers? Bekijk hier de volledige discussiethread.