Pourquoi les pages Web n'affichent-elles pas immédiatement leur texte?

Si vous êtes enclin à regarder le volet du navigateur avec un œil d'aigle, vous avez peut-être remarqué que les pages chargent fréquemment leurs images et leur mise en page avant de charger leur texte, exactement le schéma de chargement opposé que nous avons connu au cours des années 1990. Que se passe-t-il?

La séance de questions et réponses d'aujourd'hui nous est offerte par SuperUser, une sous-division de Stack Exchange, un groupe de sites Web de questions-réponses dirigé par la communauté..

La question

Lecteur superutilisateur Laurent est très curieux de savoir pourquoi exactement les pages semblent charger les éléments complètement différemment de ce qu’elles étaient autrefois. Il écrit:

J'ai remarqué que récemment, de nombreux sites Web tardent à afficher leur texte. Habituellement, l’arrière-plan, les images, etc. seront chargés, mais pas de texte. Après un certain temps, le texte commence à apparaître ici et là (pas toujours tout à la fois).

Cela fonctionne fondamentalement à l’inverse, quand le texte était affiché en premier, puis que les images et le reste étaient chargés par la suite. Quelle nouvelle technologie crée ce problème? Une idée?

Notez que je suis sur une connexion lente, ce qui accentue probablement le problème.

Voir [ci-dessus] pour un exemple - tout est chargé mais il faut encore quelques secondes avant que le texte ne soit finalement affiché.

Alors qu'est-ce qui donne? Laurent et beaucoup d'entre nous se souviennent d'une époque où le texte chargé en premier et tout le reste, des GIF animés garrish, des arrière-plans en mosaïque et tous les autres artefacts de la navigation Web de la fin des années 90, sont arrivés plus tard. Quelles sont les causes premières de la situation actuelle des éléments de conception, puis du texte??

La réponse

Daniel Andersson, contributeur de SuperUser, offre une réponse merveilleusement détaillée qui va droit au fond du mystère du pourquoi-les-polices-charger-dernier:

Une des raisons est que les concepteurs Web aiment de nos jours utiliser des polices Web (généralement au format WOFF), par exemple. via les polices Google Web.

Auparavant, les seules polices pouvant être affichées sur un site étaient celles que l'utilisateur avait installées localement. Depuis par exemple Les utilisateurs de Mac et de Windows n’avaient pas nécessairement les mêmes polices, les concepteurs toujours instinctivement définis des règles comme
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 seconde, et enfin une police de remplacement «sans-serif».

Maintenant, on peut donner une URL de police en tant que règle CSS pour que le navigateur télécharge une police, en tant que telle:
@import url (http://fonts.googleapis.com/css?family=Droid+Serif:400,700); 
puis chargez la police pour un élément spécifique, par exemple:
famille de polices: 'Droid Serif', sans-serif; 
Il est très courant d'utiliser des polices personnalisées, mais le problème est qu'aucun texte ne s'affiche jusqu'à ce que la ressource ait été chargée, ce qui inclut le temps de téléchargement, le temps de chargement de la police et le temps de rendu. Je pense que c'est l'artefact que vous rencontrez.

Par exemple, l'un de mes journaux nationaux, Dagens Nyheter, utilise des polices Web pour ses titres, mais pas ses leads. Ainsi, lorsque ce site est chargé, je vois généralement les leads en premier, puis une demi-seconde plus tard, tous les espaces vides ci-dessus sont remplis. avec des titres (c'est vrai sur Chrome et Opera, au moins. Je n'ai pas essayé d'autres).

(En outre, les concepteurs saupoudrent JavaScript absolument partout ces jours-ci, alors peut-être que quelqu'un essaie de faire quelque chose d'intelligent avec le texte, ce qui explique pourquoi il est retardé. Ce serait très spécifique au site, cependant: la tendance générale du texte à être retardé Je pense que le problème des polices Web est décrit ci-dessus.)

Une addition:

Cette réponse est devenue très populaire, bien que je ne sois pas entré dans les détails, ou peut-être parce que de cela. Il y a eu beaucoup de commentaires dans le fil de la question, alors je vais essayer de développer un peu […]

Le phénomène est apparemment appelé «flash de contenu non-stylé» en général et «flash de texte non-stylé» en particulier. La recherche de "FOUC" et "FOUT" donne plus d'informations.

Je peux recommander le post du concepteur Web Paul Irish sur FOUT concernant les polices Web..

Ce que l’on peut noter, c’est que différents navigateurs gèrent cela différemment. J'ai écrit ci-dessus que j'avais testé Opera et Chrome, qui se comportaient tous les deux de la même manière. Tous ceux basés sur WebKit (Chrome, Safari, etc.) choisissent d’éviter FOUT en ne pas rendu du texte de police Web avec une police de remplacement pendant la période de chargement des polices Web. Même si la police web est mise en cache, il volonté être un retard de rendu. Il y a beaucoup de commentaires dans cette question qui disent le contraire et qu'il est absolument faux que les polices en cache se comportent comme ceci, mais par exemple. à partir du lien ci-dessus:

Dans quels cas obtiendrez-vous un FOUT

Volonté: Téléchargement et affichage d'un fichier ttf / otf / woff distant

Volonté: Afficher un ttf / otf / woff en cache

Volonté: Téléchargement et affichage d'un fichier data-uri ttf / otf / woff

Volonté: Affichage d'un cache de données-uri ttf / otf / woff

Ne sera pas: Affichage d'une police déjà installée et nommée dans votre pile de polices traditionnelle

Ne sera pas: Affichage d'une police installée et nommée à l'aide de l'emplacement local ()

Dans la mesure où Chrome attend que le risque FOUT ait disparu avant de générer le rendu, cela entraîne un délai. À qui ampleur l'effet est visible (surtout lors du chargement à partir du cache) semble dépendre, entre autres choses, de la quantité de texte à restituer et peut-être d'autres facteurs, mais la mise en cache ne supprime pas complètement l'effet.

Irish a également quelques mises à jour concernant le comportement du navigateur, mises à jour en date 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 principe, le texte est invisible pendant 3 secondes, puis il renvoie la police de remplacement. La webfont se chargera probablement dans ces trois secondes… espérons…

IE9 prend en charge les formats WOFF, TTF et OTF (bien qu'il nécessite un ensemble de bits d'intégration, la plupart du temps sans intérêt si vous utilisez WOFF). TOUTEFOIS!!! IE9 a un FOUT. :(

Webkit a un correctif en attente d'atterrissage pour afficher le texte de secours après 0,5 seconde. Donc, même comportement que FF mais 0,5s au lieu de 3s.

Si cette question s'adressait aux concepteurs, on pourrait trouver des moyens d'éviter ce genre de problèmes, tels que webfontloader, mais ce serait une autre question. Le lien Paul Irish entre dans les détails.

Avez-vous quelque chose à ajouter à l'explication? Sound off dans les commentaires. Voulez-vous lire plus de réponses d'autres utilisateurs de Stack Exchange doués en technologie? Découvrez le fil de discussion complet ici.