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. vont être 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é:

L'une des raisons est que les concepteurs de sites Web préfèrent aujourd'hui utiliser des polices Web (généralement au format WOFF ), par exemple via des polices Google Web .

Auparavant, les seules polices pouvant être affichées sur un site étaient celles que l'utilisateur avait installées localement. Par exemple, les utilisateurs de Mac et de Windows n’ayant pas nécessairement les mêmes polices, les concepteurs ont toujours instinctivement défini des règles comme suit:

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:

font-family: '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 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, 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 à un site, cependant: Je pense que le problème des polices Web est décrit ci-dessus.)

Une addition

Cette réponse est devenue très populaire, même si je n’ai pas donné beaucoup de détails, ou peut - être à cause de cela. Il y a eu beaucoup de commentaires dans le fil de la question, je vais donc essayer de développer 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 de 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 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. Toutes les solutions WebKit (Chrome, Safari, etc.) choisissent d'éviter FOUT en ne rendant pas le texte de 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 y aura un délai 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écharger et afficher un fichier ttf / otf / woff distant
• Will: Afficher un ttf / otf / woff en cache
• Will: Télécharger et afficher un fichier data-uri ttf / otf / woff
• Will: Afficher une cache de données-uri ttf / otf / woff
• Ne veut pas: afficher une police déjà installée et nommée dans votre pile de polices traditionnelle
• Ne veut pas: afficher 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. Dans quelle mesure l'effet est visible (en particulier 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.

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 WOFF, TTF et OTF (bien que cela nécessite un ensemble de bits d’incorporation - la plupart du temps sans intérêt si vous utilisez WOFF). POURTANT!!! 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.
• Ajout : Blink a également enregistré un bogue pour cela , mais il semble qu'aucun consensus final n'ait encore été trouvé sur ce qu'il doit faire - 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, par exemple 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 en cours de rendu avec une police Web qui est toujours en cours d'acheminement dans les tuyaux de votre navigateur.

De plus, comme votre navigateur est Google Chrome, qui utilise WebKit pour restituer la page, il a été décidé (WebKit) qu'il est préférable de ne pas voir le texte du tout tant que la police Web n'est pas téléchargée. Si, toutefois, vous préférez que le texte soit lisible avec une police système de remplacement appropriée, vous pouvez utiliser un outil tel que WebFont Loader de Google pour y parvenir.

Réponse courte: AJAX ou WOFF

Les sites Web sont "lents à afficher leur texte" pour plusieurs raisons . La lenteur sur portableapps.com est causée par le téléchargement des polices WOFF . Cependant, ce que vous décrivez comme "le texte commence à apparaître ici et là" est plus souvent causé par AJAX .

Un site Web est composé de nombreuses parties. La façon dont ces pièces sont téléchargées et assemblées est un choix de conception sous le contrôle du concepteur de sites Web . La lenteur est due à la manière dont le développeur a choisi d'assembler les blocs de construction suivants:

• Page HTML initiale
• CSS
• JS
• Images
• Polices WOFF
• Demandes AJAX
• Manipulation DOM

Sites traditionnellement:

Traditionnellement, il était courant pour les développeurs de placer le contenu textuel dans la page HTML initiale et de l'afficher dès qu'il était disponible . Le HTML ferait référence à plusieurs ressources qui seraient ensuite téléchargées. Le navigateur redessinait ensuite progressivement l'écran pour inclure les styles et les images au fur et à mesure de leur disponibilité. AJAX et WOFF n'étaient pas disponibles.

Sites Web WOFF:

Les polices WOFF permettent à un site Web d'utiliser des polices qui ne sont normalement pas disponibles pour le navigateur, en téléchargeant des polices avec le site Web . Certains développeurs demandent au navigateur de ne pas afficher le contenu du texte avant le téléchargement de toutes les polices WOFF. D'après mon expérience, cette approche n'a pas encore gagné une large utilisation.

Sites Web AJAX:

Certains développeurs choisissent de ne pas inclure le contenu du texte dans la page HTML initiale. Au lieu de cela, ils choisissent de télécharger le contenu textuel en utilisant AJAX. Cela se produit après le chargement de la page de base . D'après mon expérience, cette méthode a été largement adoptée par les polices WOFF et est le plus souvent à l'origine de la lenteur que vous décrivez.

Déterminer la cause

Pour déterminer la cause d'un site spécifique, une analyse est nécessaire à l'aide d'outils tels que Firebug ou Chrome Developer Tools . Ou bien, vous pouvez ouvrir le site à l'aide d' Internet Explorer 8 , qui prend en charge AJAX mais pas WOFF. Si le site est toujours lent, le problème est AJAX et non WOFF.

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 de la feuille de style CSS, vous le voyiez brièvement tel qu'il apparaît brut, suivi d'un clignotement lorsque le navigateur le redessine. 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:

1. chercher du HTML (plusieurs allers-retours pour DNS, TCP, demande / réponse)
2. 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.
3. 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)
4. une fois que le CSS externe et JS ont fini de charger, analyser / exécuter JS, analyser / appliquer des styles
5. 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 pour peindre 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-under -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),

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 des 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.

Eh bien, il y a plusieurs raisons. Une des raisons est également que les commandes permettant de définir un arrière-plan ou au-dessus d'une page HTML sont souvent récupérées dans un fichier CSS séparé chargé en premier. avant le chargement du corps du document contenant le texte.

Une autre cause est que, bien qu'il soit possible de saisir la taille d'une image, dans la plupart des cas, les concepteurs Web ne l'utilisent pas. Le brouwser doit donc d'abord charger les images entières sur les pages pour pouvoir envelopper le texte.

Certains concepteurs souhaitent également afficher les premières images et le texte suivant. Pour ce faire, ils utilisent du javascript. Par exemple, une simple page affiche d'abord une bannière, puis tout le reste dessus.

Mais si vous vous demandez pourquoi il y a tant de messages publicitaires sur le spam sur mes pages alors que je ne veux que lire les nouvelles, il existe une solution pour vous. Vous pouvez utiliser des bloqueurs de spam si vous utilisez Firefox. Avec un tel addon, le navigateur Web connaît les sites qui fournissent du spam et les bloque simplement, ce qui permet un chargement de page beaucoup plus rapide, tout en vous permettant de voir les images importantes relatives aux articles que vous avez lus.

Je recommanderais à tous ceux qui traitent avec un chargement de page lent d'essayer de rester fidèle. fidler peut être utilisé avec IEexplorer ou avec FireFox (à l'aide de sa fonction proxy). Fidler vous indiquera en réalité combien de temps il faut et quand des parties d'une page Web sont chargées. C'est un outil de débogage HTML.