Pourquoi les sites web n'affichent-ils pas immédiatement leur texte de nos jours ?

L'une des raisons est que les concepteurs de sites web aiment aujourd'hui utiliser des polices de caractères web (généralement en format WOFF ), par exemple par le biais de Polices Web de Google .

Auparavant, les seules polices qui pouvaient être affichées sur un site étaient celles que l'utilisateur avait installées localement. Étant donné que les utilisateurs de Mac et de Windows, par exemple, ne disposaient pas nécessairement des mêmes polices, les concepteurs définissaient toujours instinctivement les règles suivantes

font-family: Arial, Helvetica, sans-serif;

où, si la première police n'était pas trouvée sur le système, le navigateur chercherait la deuxième, et enfin une police de repli "sans-serif".

Maintenant, on peut donner l'URL d'une police comme règle CSS pour que le navigateur télécharge une police, comme telle :

@import url(http://fonts.googleapis.com/css?family=Droid+Serif:400,700);

et ensuite charger la police pour un élément spécifique par ex :

font-family: 'Droid Serif',sans-serif;

C'est très populaire pour pouvoir utiliser des polices personnalisées, mais cela entraîne également le problème suivant : aucun texte n'est affiché tant que la ressource n'a pas été chargée par le navigateur, ce qui inclut le temps de téléchargement, le temps de chargement de la police et le temps de rendu. Je suppose que c'est l'artefact que vous rencontrez.

Un exemple : un de mes journaux nationaux, Dagens Nyheter Lorsque le site est chargé, je vois généralement d'abord les titres, et une demi-seconde plus tard, tous les espaces vides au-dessus sont occupés par les titres (c'est vrai avec Chrome et Opera, au moins.)

(De plus, les concepteurs saupoudrent du JavaScript absolument partout de nos jours, alors peut-être quelqu'un essaie-t-il de faire quelque chose d'intelligent avec le texte, ce qui explique le retard. Mais cela serait très spécifique au site : la tendance générale du texte à être retardé en ces temps est le problème des polices web décrit plus haut, je crois).

Addition

Cette réponse a fait l'objet de nombreux votes, bien que je n'aie pas donné beaucoup de détails, ou peut-être parce que de ceci. Il y a eu de nombreux commentaires dans le fil de la question, je vais donc essayer de m'étendre un peu (beaucoup de commentaires semblent avoir disparu peu de temps après la protection du sujet - un modérateur les a probablement nettoyés manuellement). Lisez également les autres réponses dans ce fil de discussion, car elles sont toutes développées à leur manière.

Le phénomène est apparemment connu sous le nom de "flash of unstyled content" en général, et de "flash of unstyled text" en particulier. La recherche de "FOUC" et "FOUT" donne plus d'informations.

Je peux recommander le billet de Paul Irish, concepteur de sites web, sur FOUT en rapport avec les polices de caractères web .

Ce que l'on peut noter, c'est que les différents navigateurs gèrent cela différemment. J'ai écrit plus haut que j'avais testé Opera et Chrome, qui se sont tous deux comportés de manière similaire. Tous ceux basés sur WebKit (Chrome, Safari, etc.) choisissent d'éviter le FOUT en no rendre le texte de la police Web avec une police de secours pendant la période de chargement de la police Web. Même si la police web est mise en cache, il sera être un retard de rendu . Il y a beaucoup de commentaires dans ce fil de questions qui disent le contraire et qu'il est tout à fait faux que les polices en cache se comportent de cette façon, mais par exemple dans le lien ci-dessus :

Dans quels cas obtiendrez-vous un FOUT

• Will : Téléchargement et affichage d'un ttf/otf/woff distant
• Will : Affichage d'un ttf/otf/woff en mémoire cache
• Will : Téléchargement et affichage d'un data-uri ttf/otf/woff
• Will : Affichage d'un data-uri en cache ttf/otf/woff
• Non : Affichage d'une police qui est déjà installée et nommée dans votre pile de polices traditionnelle
• Non : Affichage d'une police installée et nommée à l'aide de l'emplacement local()

Comme Chrome attend que le risque FOUT disparaisse avant d'effectuer le rendu, cela donne un retard. Auquel étendue l'effet est visible (surtout lors du chargement à partir du cache) semble dépendre, entre autres, de la quantité de texte qui doit être rendu et peut-être d'autres facteurs, mais la mise en cache ne supprime pas complètement l'effet.

Irish propose également quelques mises à jour concernant le comportement du navigateur à partir du 2011-04-14 au bas de l'article :

• Firefox (à partir de FFb11 et FF4 Final) n'a plus de FOUT ! Wooohoo ! http://bugzil.la/499292 En fait, le texte est invisible pendant 3 secondes, puis la police de secours réapparaît. La webfont se chargera probablement dans ces trois secondes, mais espérons-le
• IE9 supporte WOFF, TTF et OTF (bien qu'il nécessite un bit d'encastrement chose établie - principalement discutable si vous utilisez WOFF). MAIS ! !! IE9 a un FOUT. :(
• Webkit a une parcelle en attente d'atterrissage pour afficher le texte de repli après 0,5 seconde. Donc le même comportement que FF mais 0.5s au lieu de 3s.
• Addition : Blink a un bug enregistré pour cela aussi mais il semble qu'un consensus final n'ait pas été atteint sur ce qu'il convient d'en faire - actuellement, la mise en œuvre est identique à celle de WebKit.

S'il s'agissait d'une question destinée aux concepteurs, on pourrait examiner les moyens d'éviter ce genre de problèmes, par exemple webfontloader mais c'est une autre question. Le lien de Paul Irish donne plus de détails sur cette question.