Si vous avez tendance à 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 – le modèle de chargement exactement opposé que nous avons connu dans les années 1990. Que se passe-t-il?
La question
Le lecteur SuperUser Laurent est très curieux de savoir pourquoi les pages semblent charger des éléments complètement différemment de ce qu’elles faisaient 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. vont être chargés, mais pas de texte. Après un certain temps, le texte commence à apparaître ici et là (pas toujours tout en même temps).
Cela fonctionne essentiellement à l’inverse comme avant, lorsque le texte était affiché en premier, puis les images et le reste se chargeaient ensuite. 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 [above] pour un exemple – tout est chargé mais cela prend quelques secondes de plus 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 s’est chargé en premier et tout le reste – GIF animés garrish, arrière-plans en mosaïque et tous les autres artefacts de la navigation Web de la fin des années 90 – est venu plus tard. Qu’est-ce qui cause la situation actuelle des éléments de conception en premier, du texte plus tard?
La réponse
Le contributeur SuperUser Daniel Andersson offre une réponse merveilleusement détaillée qui va droit au fond du mystère pourquoi-les-polices-chargent-le-dernier:
L’une des raisons est que les concepteurs Web aiment de nos jours utiliser des polices Web (généralement WOFF format), par exemple viaPolices Web Google.
Auparavant, les seules polices qui pouvaient être affichées sur un site étaient celles que l’utilisateur avait installées localement. Comme les utilisateurs de Mac et Windows, par exemple, n’avaient pas nécessairement les mêmes polices, les concepteurs définissaient instinctivement toujours les 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 secours «sans-serif».
Maintenant, on peut donner une URL de police comme 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:
font-family: 'Droid Serif',sans-serif;
Ceci est très populaire pour pouvoir utiliser des polices personnalisées, mais cela conduit également au problème qu’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 vivez.
A titre d’exemple: un de mes journaux nationaux, Dagens Nyheter, utilisez des polices Web pour leurs titres, mais pas leurs pistes, donc lorsque ce site est chargé, je vois généralement les pistes en premier, et une demi-seconde plus tard, tous les espaces vides ci-dessus sont remplis de titres (c’est vrai sur Chrome et Opera, à Je n’ai pas essayé d’autres).
(De plus, les concepteurs saupoudrent du JavaScript absolument partout ces jours-ci, alors peut-être que quelqu’un essaie de faire quelque chose d’intelligent avec le texte, c’est pourquoi il est retardé. Ce serait très spécifique au site, cependant: la tendance générale du texte à être retardé dans ces est le problème des polices Web décrit ci-dessus, je crois.)
Une addition:
Cette réponse est devenue très positive, même si je n’ai pas donné beaucoup de détails, ou peut-être à ce sujet. Il y a eu de nombreux commentaires dans le fil de questions, je vais donc essayer de développer un peu […]
Le phénomène est apparemment connu sous le nom de «flash de contenu non stylisé» en général, et de «flash de texte non stylisé» en particulier. La recherche de «FOUC» et «FOUT» donne plus d’informations.
Je peux recommander Message du web designer Paul Irish sur FOUT à propos des 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 deux de la même manière. Tous ceux basés sur WebKit (Chrome, Safari, etc.) choisissent d’éviter FOUT en rendant le texte de la police Web avec une police de remplacement pendant la période de chargement de la police Web. la police Web est mise en cache, il y a un délai de rendu. Il y a beaucoup de commentaires dans ce fil de questions disant le contraire et qu’il est complètement faux que les polices mises en cache se comportent comme ceci, mais par exemple à partir du lien ci-dessus:
Dans quels cas obtiendrez-vous un FOUT
- Téléchargement et affichage d’un ttf / otf / woff distant
- Affichage d’un ttf / otf / woff mis en cache
- Téléchargement et affichage d’un data-uri ttf / otf / woff
- Affichage d’un data-uri ttf / otf / woff mis en cache
- Affichage d’une police déjà installée et nommée dans votre pile de polices traditionnelle
- Affichage d’une police installée et nommée à l’aide de l’emplacement local ()
Étant donné que Chrome attend que le risque FOUT disparaisse avant le rendu, cela donne un délai. La visibilité de l’effet (en particulier lors du chargement à partir du cache) semble dépendre entre autres de la quantité de texte à rendre 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 à partir de 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 Fondamentalement, le texte est invisible pendant 3 secondes, puis il ramène la police de remplacement. La police Web se chargera probablement dans ces trois secondes… espérons-le ..
- IE9 prend en charge WOFF et TTF et OTF (bien qu’il nécessite un peu d’intégrationrégler la chose– surtout sans intérêt si vous utilisez WOFF). POURTANT!!! IE9 a un FOUT. 🙁
- Webkit a un patch en attente d’atterrir pour afficher le texte de secours après 0,5 seconde. Donc même comportement que FF mais 0,5s au lieu de 3s.
S’il s’agissait d’une question destinée 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 plus en détail sur cette question.
Avez-vous quelque chose à ajouter à l’explication? Sonnez dans les commentaires. Vous voulez lire plus de réponses d’autres utilisateurs de Stack Exchange férus de technologie? Consultez le fil de discussion complet ici.
