Pourquoi les sites Web n'affichent-ils pas immédiatement leur texte ces jours-ci?
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 en même temps).
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-dessous pour un exemple - tout est chargé, mais il faut encore quelques secondes avant que le texte ne soit finalement affiché:
Une des raisons est que les concepteurs Web préfèrent 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 Mac et Windows n’ont pas nécessairement les mêmes polices, les concepteurs ont toujours instinctivement toujours défini des règles
font-family: Arial, Helvetica, sans-serif;
où, si la première police n’est pas trouvée sur le système, le navigateur cherche 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:
font-family: 'Droid Serif',sans-serif;
Il est très courant d'utiliser des polices personnalisées, mais cela pose également le problème suivant: aucun texte n'est affiché tant que la ressource n'a pas é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 suppose que c'est l'artefact que vous rencontrez.
Par exemple, un de mes journaux nationaux, Dagens Nyheter , utilise des polices Web pour leurs titres, mais pas leurs leads. Ainsi, lorsque ce site est chargé, je vois généralement les leads en premier, puis une demi-seconde plus tard. les espaces ci-dessus sont remplis avec des titres (c'est le cas avec Chrome et Opera, du moins. Je n'en 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 à un site, cependant: Je pense que Times est le problème des polices Web décrit ci-dessus.)
Une addition
Cette réponse est devenue très populaire, bien que je n’aie pas donné beaucoup de détails, ni peut-être à cause dede cela. Il y a eu beaucoup de commentaires dans le fil de la question, je vais donc essayer de développer un peu plus semble avoir disparu peu de temps après que le sujet ait été protégé - un modérateur les a probablement nettoyées manuellement.) Lisez également les autres réponses dans ce fil car elles se développent toutes à leur manière.
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 concepteur Web de Paul Irish sur FOUT en relation avec 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 by pasrendant le texte de la police Web avec une police de secours pendant la période de chargement de la police Web.Même sila police Web est mis en cache, il y a seraun retard de rendu . Il y a beaucoup de commentaires dans cette question qui disent le contraire et qu'il est totalement 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
- Will:Téléchargement et affichage d'un fichier ttf/otf/woff distant
- Will:Affichage d'un fichier ttf/otf/woff mis en cache
- Will:Téléchargement et affichage d'un fichier data-uri/otf/woff
- Will:Affichage d'une donnée en cache dans un fichier-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 ()
Étant donné que Chrome attend que le risque FOUT ait disparu avant de générer le rendu, cela entraîne un délai. Pour lequel étenduel'effet est visible (surtout lors du chargement à partir du cache) semble dépendre, entre autres, de la quantité de texte à restituer et peut-être d'autres facteurs, mais la mise en cache ne supprime pas complètement l'effet.
En irlandais, des mises à jour concernant le comportement du navigateur ont également été mises à jour en 2011–04–14:
- 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 renvoie la police de secours. La webfont va probablement se charger dans ces trois secondes… espérons….
- IE9 prend en charge les formats WOFF, TTF et OTF (bien qu'il nécessite un bit d'intégrationune chose à définir - la plupart du temps sans intérêt si vous utilisez WOFF). CEPENDANT !!! IE9 a un FOUT. :(
- Webkit a un correctif en attente d'atterrissage pour afficher un texte de repli après 0,5 seconde. Donc, même comportement que FF mais 0,5s au lieu de 3s.
- Addition: Blink a un bogue enregistré pour cela aussi , mais il semble qu'aucun consensus final n'ait été atteint concernant sa solution - actuellement, même implémentation que WebKit.
S'il s'agissait d'une question destinée aux concepteurs, on pourrait trouver des moyens d'éviter ce genre de problèmes, tel que webfontloader , mais ce serait une autre question. Le lien Paul Irish entre dans les détails de cette affaire.
La raison en est que le texte que vous ne pouvez pas encore lire est restitué avec une police Web qui est toujours en route vers votre navigateur.
De plus, comme votre navigateur est Google Chrome, qui utilise WebKit pour restituer la page, il a été décidé par eux (WebKit) - il est préférable de ne pas voir du texte tant que la police Web n'est pas téléchargé. Si, toutefois, vous préférez que le texte soit lisible avec une police système de remplacement appropriée, vous pouvez utiliser quelque chose comme WebFont Loader de Google pour y parvenir.
Il arrive souvent que ce soit un choix délibéré d’éviter les «éclairs de contenu non stylé». Si le texte affiché avant le chargement du CSS, vous le voyiez brièvement tel qu'il apparaissait brut, puis clignotait lorsque le navigateur le redessinait. En introduisant des styles de base en ligne pour masquer initialement le contenu, qui sont remplacés dans la feuille de style réelle, ou en utilisant JS, les développeurs évitent ce flash.
Comme d'autres l'ont noté, les polices personnalisées contribuent probablement au retard.
Pour donner un peu plus d’arrière-plan, le navigateur effectue à peu près les tâches suivantes avant de pouvoir afficher le contenu de la page à l’écran:
- chercher du HTML (plusieurs allers-retours pour DNS, TCP, demande/réponse)
- commencez à analyser le code HTML, découvrez des ressources externes telles que CSS externe et JS. Notez que CSS bloque la disposition et que JS bloque l'analyse. Ainsi, les ressources externes telles que CSS et JS chargées au début du document (par exemple dans la tête) ralentissent le temps nécessaire pour qu'une page affiche le contenu à l'écran.
- extraire les CSS et JS externes (plusieurs allers-retours: DNS et TCP si ces ressources se trouvent sur un domaine différent tel que CDN, ainsi qu'un RTT pour la demande/réponse)
- une fois que le CSS externe et JS ont fini de charger, analyser/exécuter JS, analyser/appliquer des styles
- si le CSS fait référence à des polices personnalisées, ces dernières doivent également être téléchargées, ce qui entraîne des délais d'aller-retour supplémentaires pour restituer toute partie de la page qui dépend des polices personnalisées.
Bien qu'il ne s'agisse pas spécifiquement des retards causés par les polices personnalisées, j'ai récemment écrit un article de blog qui donne des informations supplémentaires sur les causes des retards de rendu. Il donne quelques suggestions pour minimiser le temps nécessaire à la peinture pour vos pages. Espérons que cela sera utile aux lecteurs souhaitant que leurs pages affichent du contenu plus rapidement, y compris les pages qui souhaitent utiliser des polices personnalisées: http://calendar.perfplanet.com/2012/make-your-mobile-pages-render-in sous une seconde/
Réponse courte: développeurs.
Lorsque les balises de lien et de script faisant référence à des documents externes (tels que des fichiers .css ou .js) sont placées dans l'en-tête du document (plus haut dans le flux que le corps et ses éléments), elles sont chargées en premier. JavaScript s'exécute à partir du balisage qui le référence. s'il y a beaucoup de code à traiter, ou si c'est du code encombrant, ou plus communément si le texte que vous vous attendez à voir est restitué sur un serveur et inséré dans le document au chargement - et que le code côté serveur est également encombrant, En raison du traitement de plusieurs requêtes simultanées, il est possible que vous constatiez des temps d'arrêt avant que le code HTML ait eu l'occasion de générer un rendu important. Certains développeurs choisissent de charger du code JavaScript non lié à la vue après les balises et les styles (à la fin du corps), et les meilleurs essayent d'être plus conscients de l'impact de leur décision technologique sur l'expérience utilisateur globale lors de la mise en œuvre.
Il est évident que la vitesse de la connexion Internet joue un rôle dans le téléchargement lent des données, mais un code mal écrit ou des piles de technologies mal conçues (pour le type de site Web) jouent un rôle de plus en plus central dans le chargement lent du contenu dynamique, comme les connexions réseau plus rapides approche de l'ubiquité.
En un mot, trop d’objets chargeables devant être chargés à partir de HTTP GET avant que la page puisse être affichée, et une dépendance excessive à la latence moyenne comme mesure de la santé du site.
La première fait référence à tous les fichiers .css, .js et web que la page se charge, sans oublier le fait que de nombreux sites doivent également extraire des objets JSON via des requêtes XHR, puis générer du code HTML à partir de ceux utilisant une sorte de modèle.
Mais pourquoi ne remarquent-ils pas que le site est lent?
Probablement parce qu'ils ont memecache dedans quelque part pour accélérer les choses (ou s'appuient simplement sur des caches de système de fichiers) et mesurent la santé de leur site en utilisant le temps de latence moyen. Ainsi, les objets mis en cache sont renvoyés avec une latence de 6 secondes et masquent le fait que de nombreuses demandes GET prennent 5 000 millisecondes. Les moyennes doivent mourir. Vive le comptage des RTT au dessus d'un seuil maximum acceptable! Ce nombre doit être 0 ou, par définition, le RTT est inacceptable.