29Aug
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 - le modèle de chargement opposé que nous avons connu durant les années 1990.Que se passe-t-il?
Question d'aujourd'hui &La session de réponse nous est offerte par SuperUser, une subdivision de Stack Exchange, un regroupement communautaire de sites Web Q & A.
La question Lecteur
SuperUser Laurent est très curieux de savoir pourquoi exactement les pages semblent charger des éléments complètement différemment de ce qu'elles étaient autrefois. Il écrit:
J'ai remarqué que récemment de nombreux sites Web sont lents à afficher leur texte. Habituellement, le fond, les images et ainsi de suite 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).
Il fonctionne fondamentalement le contraire comme avant, quand le texte était affiché en premier, puis les images et le reste se chargeait après. 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'un moment où le texte chargé en premier et tout le reste - des GIF animés, des arrière-plans en mosaïque et tous les autres artefacts de la fin des années 90 - est venu plus tard. Quelles sont les causes de la situation actuelle des éléments de conception d'abord, texte plus tard?
La réponse
SuperUser contributeur Daniel Andersson offre une réponse merveilleusement détaillée qui va droit au but du mystère why-the-fonts-load-last:
L'une des raisons est que les web designers aiment utiliser les polices web( habituellement en format WOFF), par exemplePolices Web throughGoogle.
Auparavant, les seules polices pouvant être affichées sur un site étaient celles que l'utilisateur avait installées localement. Depuis par exempleLes utilisateurs Mac et Windows n'ont pas forcément les mêmes polices, les concepteurs ont toujours défini les règles de façon systématique comme
famille de polices: Arial, Helvetica, sans-serif;où, si la première police n'a pas été 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 en tant que règle CSS pour que le navigateur télécharge une police, comme suit:
@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;Cela est très populaire pour pouvoir utiliser des polices personnalisées, mais cela pose également le 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 des polices et le temps de rendu. Je m'attends à ce que ce soit l'artefact que vous rencontrez.
A titre d'exemple: un de mes journaux nationaux, Dagens Nyheter, utilise les polices web pour leurs titres, mais pas pour leurs prospects, donc quand ce site est chargé je vois d'habitude les leads en premier, et une demi seconde plus tardpeuplé de titres( c'est vrai sur Chrome et Opera, au moins, n'en ai pas essayé d'autres).
( De plus, les concepteurs jalonnent absolument JavaScript partout aujourd'hui, alors peut-être que quelqu'un essaye de faire quelque chose d'intelligent avec le texte, c'est pourquoi il est retardé, ce qui serait très spécifique au site.ces temps est le problème de polices web décrit ci-dessus, je crois.)
Addition:
Cette réponse est devenue très upvoted, bien que je ne sois pas entré dans beaucoup de détails, ou parce de ceci. Il y a eu beaucoup de commentaires dans le fil de la question, donc je vais essayer de développer un peu [...]
Le phénomène est apparemment connu sous le nom de "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 l'article de Paul Irish sur le FOUT en lien avec les polices web.
Ce que l'on peut noter, c'est que différents navigateurs gèrent cela différemment. J'ai écrit plus haut que j'avais testé Opera et Chrome, qui se comportaient tous les deux de manière similaire. Tous ceux basés sur WebKit( Chrome, Safari, etc.) choisissent d'éviter FOUT par pas rendant le texte de police web avec une police de secours pendant la période de chargement des polices web. Même si la police Web est mise en cache, sera un délai de rendu .Il y a beaucoup de commentaires dans ce fil de la question qui disent le contraire et qu'il est tout à fait faux que les polices mises en cache se comportent comme ceci, mais par ex.à partir du lien ci-dessus:
Dans quels cas obtiendrez-vous un FOUT
- Will: Téléchargement et affichage d'un ttf distant /otf/ woff
- Will: Affichage d'un ttf mis en cache /otf/ woff
- Will: Téléchargement et affichage d'un uri de données ttf /otf/ woff
- Afficher: Afficher 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 en utilisant local()
Étant donné que Chrome attend que le risque FOUT disparaisse avant le rendu, cela entraîne un retard. Pour quelle étendue l'effet est visible( en particulier lors du chargement du cache) semble dépendre entre autres de la quantité de texte qui doit être rendue et peut-être d'autres facteurs, mais la mise en cache ne supprime pas complètement l'effet.
irlandais a aussi quelques mises à jour concernant le comportement du navigateur à partir du 2011-04-14 en bas du post:
- 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 secours. Le webfont se chargera probablement dans ces trois secondes si. .. espérons.
- IE9 soutient WOFF et TTF et OTF( bien qu'il exige une chose de bitset d'embarquement - principalement moot si vous employez WOFF). CEPENDANT! !!IE9 a un FOUT.:(
- Webkit a un patch qui attend d'atterrir pour afficher le texte de repli après 0.5 secondes, soit le même comportement que FF mais 0.5s au lieu de 3.
S'il s'agissait d'une question destinée aux concepteurs, on pourrait éviter ces typesdes problèmes tels que webfontloader, mais ce serait une autre question, le lien irlandais de Paul va plus en détail sur ce sujet
Avez-vous quelque chose à ajouter à l'explication?les utilisateurs avertis de Stack Exchange? Consultez le fil de discussion complet ici.