Question 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 sont lents à afficher leur texte. Habituellement, le fond, 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 à la fois).

En gros, cela fonctionne comme avant, lorsque le texte était affiché en premier, puis les images et le reste se chargeaient 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é:

enter image description here


440
2018-02-07 06:22


origine


Dans ce cas particulier, PortableApps.com utilise la police "Ubuntu". John a d'abord essayé OpenSans, mais nous sommes passés à Ubuntu assez rapidement. J'étais le principal partisan de la commutation ... une façon de supprimer le problème est de faire installer la famille de polices. Si vous l'installez de font.ubuntu.com cela fonctionnera immédiatement. - Chris Morgan
La réponse de Daniel est révélatrice. J'ai pensé que cela était fait exprès pour que nous puissions voir toutes les publicités sur la page. - Manoj R
Comme plusieurs personnes l’ont souligné, il ya des raisons infinies pour que le texte soit rendu de manière inattendue, car le rendu d’une page n’est limité que par l’imagination du développeur / concepteur, du moins depuis que les codes de position ANSI autorisent le bulletin des années 1980 cartes pour implémenter des chats multi-utilisateurs et des interfaces utilisateur avec des fenêtres superposées avec des ombres portées. Meebo a été l'un des premiers à reproduire certains de ces effets dans un navigateur sans Applet. "Travaille au contraire car il simplifiait énormément Internet et ne faisait même pas référence à une période spécifique." - PJ Brunet
Alors, pourquoi faire des généralisations radicales sur Internet en se basant sur une limite d’écran aléatoire à partir d’un site Web dont le rang Alexa est faible? La meilleure réponse est également une affirmation audacieuse: "les concepteurs actuels de XYZ" devraient être sauvegardés avec des chiffres réels, comme "5% des sites Web utilisent Google Web Fonts à partir de 2012". - PJ Brunet
Mais les fichiers de polices sont conservés dans le cache, ce site a longtemps attendu le chargement de m.aspx, ils pourraient vérifier cette partie - user613326


Réponses:


Une des raisons est que les concepteurs Web aiment utiliser les polices Web (généralement dans WOFF format), par ex. par 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’avaient pas nécessairement les mêmes polices, les concepteurs définissaient instinctivement toujours les 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 deuxième, 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;

Ceci est très populaire pour pouvoir utiliser des polices personnalisées, mais cela entraîne également le problème qu'aucun texte ne s'affiche jusqu'à ce que la ressource ait é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 m'attends à ce que ce soit l'artefact que vous rencontrez.

A titre d’exemple, l’un de mes journaux nationaux, Dagens Nyheter, utilisez les polices Web pour leurs titres, mais pas leurs pistes, alors lorsque ce site est chargé, je vois les pistes en premier, et une demi-seconde plus tard, tous les espaces vides sont remplis (ceci est vrai sur Chrome et Opera, à le moins, n’ont pas essayé d’autres).

(En outre, les concepteurs saupoudrent le JavaScript absolument partout de nos jours, alors peut-être que quelqu'un essaie de faire quelque chose d'intelligent avec le texte, et c'est pourquoi il est retardé. Cela serait très spécifique au site: la tendance générale au retard fois est le problème de polices Web décrit ci-dessus, je crois.)


Une addition

Cette réponse est devenue très votée, même si je ne suis pas entrée dans les détails, ou peut-être car de cela. Il y a eu beaucoup de commentaires dans le fil de questions, alors je vais essayer de développer un peu (beaucoup de commentaires semblent avoir disparu peu de temps après la protection du sujet - certains modérateurs les ont probablement nettoyés 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 connu sous le nom de "flash de contenu non stylé" en général, et de "flash de texte non stylé" en particulier. La recherche de "FOUC" et "FOUT" donne plus d'informations.

Je peux recommander Le web designer Paul Irish a posté sur 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 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 par ne pas le rendu du 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, il y a volonté être un délai de rendu. Il y a beaucoup de commentaires dans ce fil de discussion disant autrement et que c'est complètement faux que les polices mises en cache se comportent comme ça, mais par ex. à partir du lien ci-dessus:

Dans quels cas obtiendrez-vous un FOUT

  • Volonté: Télécharger et afficher un ttf / otf / woff distant
  • Volonté: Affichage d'un ttf / otf / woff en cache
  • Volonté: Télécharger et afficher un data-uri ttf / otf / woff
  • Volonté: Affichage d'un data-uri en cache ttf / otf / woff
  • Ne pas: Affichage d'une police déjà installée et nommée dans votre pile de polices traditionnelle
  • Ne pas: Affichage d'une police installée et nommée à l'aide de l'emplacement local ()

Puisque Chrome attend que le risque de FOUT disparaisse avant le rendu, cela entraîne un délai. À qui ampleur L'effet est visible (en particulier lors du chargement depuis le 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 au 14/04/2011 au 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 sera probablement chargé dans ces trois secondes si ...
  • IE9 prend en charge WOFF et TTF et OTF (bien qu’il nécessite un peu d'intégration  mettre la chose- surtout si vous utilisez WOFF). TOUTEFOIS!!! IE9 a un FOUT. :(:
  • Webkit a un patch en attente d'atterrissage pour afficher le texte de repli après 0,5 seconde. Donc même comportement que FF mais 0.5s au lieu de 3s.
  • Une addition: Blink a un bug enregistré pour cela aussi, mais il semble qu'un consensus final n'ait pas été atteint sur ce qu'il faut faire avec - actuellement, la même implémentation que WebKit.

S'il s'agissait d'une question destinée aux concepteurs, il serait possible d'éviter les problèmes tels que: webfontloader, mais ce serait une autre question. Le lien Paul Irish va plus loin dans ce domaine.


484
2018-02-07 07:54



L'un des navigateurs a-t-il essayé de rendre le texte d'abord dans une police disponible et de le restituer une fois la police préférée téléchargée? - Steve Bennett
Oh, hum, commente la prochaine réponse: paulirish.com/2009/fighting-the-font-face-fout - Steve Bennett
@ratchetfreak, il serait déconcertant d’avoir le reformatage de la page car les polices n’auraient probablement pas les mêmes métriques - Samuel Edwin Ward
certains préfèreraient accéder à la partie lecture de la page Web au lieu d'attendre des heures pour que la police soit chargée - ratchet freak
@SteveBennett Je suis sûr que c'est exactement ce que fait Internet Explorer 10. Je n'ai jamais vu de texte surgir plus tard. Pour moi, il s'agit toujours de texte apparaissant dans une "police standard" et quelques secondes plus tard, il devient le style / téléchargé. Je ne suis pas sûr qu'il sélectionne le prochain CSS ou simplement le système par défaut. Edit: Ah, sympa, alors c'est juste Webikit avec le texte caché? Je considère ce comportement ennuyeux et mauvais. Y a-t-il un navigateur qui ignore / cache le chargement d'image progressif? - Mario


La raison en est que le texte que vous ne pouvez pas encore lire est rendu avec une police web qui est toujours en route pour les navigateurs vers votre navigateur.

En outre, votre navigateur étant Google Chrome, qui utilise WebKit pour rendre la page, il a été décidé par eux (WebKit c'est-à-dire) qu'il est préférable de ne voir aucun texte jusqu'à ce que la police Web soit téléchargée. Si, toutefois, vous êtes un développeur qui préfèrerait que le texte soit lisible dans une police de système de secours appropriée, vous pouvez utiliser quelque chose comme: Chargeur WebFont de Google pour y parvenir.


117
2018-02-07 11:46



Malheureusement, c'est une mauvaise réponse, si vous visitez cette page une fois, le fichier de police résidera dans votre argent en ligne; pour d'autres pages de ce site ou d'autres sites Web utilisant cette police, celle-ci serait récupérée en espèces. - user613326


Réponse courte: AJAX ou WOFF

Il y a plusieurs causes des sites Web étant "lent à afficher leur texte". La lenteur sur portableapps.com est causé par le téléchargement WOFF polices. 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 plusieurs parties. Comment ces pièces sont téléchargées et assemblées est un choix du design sous le contrôle de la concepteur web. La lenteur est causée par la manière dont le développeur choisit d'assembler les blocs de construction suivants:

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

Traditionnellement, les sites Web:

Traditionnellement, il était courant que les développeurs mettent le contenu du texte dans le page HTML initiale et 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 serait alors redessiner 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écharger des polices avec le site web. Certains développeurs demandent au navigateur de ne pas afficher le contenu du texte tant que toutes les polices WOFF n’ont pas été téléchargées. D'après mon expérience, cette approche n'a pas encore été très largement utilisée.


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 de texte en utilisant AJAX. Ça arrive après le chargement de la page de base. Dans mon expérience, cette méthode a beaucoup gagné adoption plus large que les polices WOFF et sont le plus souvent la cause de la lenteur que vous décrivez.


Déterminer la cause

Pour déterminer la cause d’un site spécifique, il faut analyser à l’aide d’outils tels que Pyromane ou Outils de développement Chrome. Ou alternativement, vous pouvez ouvrir le site en utilisant Internet Explorer 8, qui prend en charge AJAX mais pas WOFF. Si le site est encore lent, le problème est AJAX et non WOFF.


19
2018-02-08 13:40





Je pense souvent qu’il s’agit d’un choix délibéré d’éviter le "flash de contenu sans style". Si le texte affiché avant le chargement du CSS, vous le voyez brièvement car il apparaît brut, puis un flash au fur et à mesure que le navigateur le redessine. En mettant en place des styles en ligne de base pour masquer initialement le contenu, qui sont remplacés dans la feuille de style ou en utilisant JS, les développeurs évitent ce flash.


14
2018-02-07 08:26



Neuf fois sur dix, cela ne sera pas délibéré, cela se traduit simplement par l’incorporation la plus simple possible de polices Web. En fait, il faut un peu plus d'effort pour présenter une alternative visible pendant que les polices Web arrivent. Voir developers.google.com/webfonts/docs/webfont_loader - Marcel
@Marcel - cela peut être dû à des feuilles de style lentes ou à des polices lentes, voir phpied.com/css-and-the-critical-path - r3m0t
Code pour éviter le "flash de contenu utile", a tendance à empêcher les images d'apparaître ainsi que du texte. - Jon Hanna
J'ai du mal à comprendre pourquoi le texte non stylé est pire que l'absence de texte. Je préférerais pouvoir commencer à lire une acceptation selon laquelle il pourrait s'agiter un peu. Je trouve cela plus choquant quand il apparaît soudainement pour nulle part et c'est très frustrant quand une page s'est chargée et que vous êtes obligé d'attendre une police. - Richard Le Poidevin


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 essentiellement les opérations suivantes avant de pouvoir afficher le contenu de la page à l’écran:

  1. récupérer du HTML (plusieurs allers-retours pour DNS, TCP, demande / réponse)
  2. commencer à analyser HTML, découvrir des ressources externes telles que CSS externe et JS. Notez que la disposition des blocs CSS et JS bloque l'analyse. Ainsi, les ressources externes telles que CSS et JS chargées au début du document (par exemple, en tête) ralentissent le temps nécessaire à une page pour afficher le contenu à l'écran.
  3. récupérer des CSS et JS externes (plusieurs allers-retours: DNS et TCP si ces ressources sont sur un domaine différent tel que CDN, ainsi qu'un RTT pour la requête / réponse)
  4. une fois que les CSS et JS externes 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 polices doivent également être téléchargées, ce qui entraîne des délais supplémentaires pour le rendu des parties de la page qui dépendent des polices personnalisées.

Bien qu'il ne s'agisse pas des retards causés par les polices personnalisées en particulier, j'ai récemment écrit un article de blog qui fournit des informations supplémentaires sur les causes des retards de rendu. Il donne des suggestions pour minimiser le temps de peinture pour vos pages. J'espère que cela est utile pour les lecteurs intéressés à rendre leurs pages plus rapides à afficher du contenu, y compris les pages qui veulent utiliser des polices personnalisées: http://calendar.perfplanet.com/2012/make-your-mobile-pages-render-in-under-one-second/


8
2018-02-07 18:26





Réponse courte: Développeurs.

Lorsque des balises de lien et de script faisant référence à des documents externes (tels que des fichiers .css ou .js) sont placées 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 un code encombrant, ou plus communément si le texte que vous prévoyez de voir est rendu sur un serveur et rempli dans le document en charge - et que ce code côté serveur est également encombrant, grande ou bloquant E / S en raison du traitement de plusieurs demandes simultanées, vous pouvez certainement remarquer des temps d'arrêt avant que le HTML ait eu une chance de rendre même. Certains développeurs choisissent de charger du code JavaScript non lié à la vue après le balisage et les styles (à la fin du corps), et le meilleur essaie d’être plus conscient de la manière dont leur décision technologique affectera l’expérience utilisateur lorsqu’elle est implémentée.

La vitesse de la connexion Internet joue un rôle dans le téléchargement lent des données, de toute évidence, mais un code mal écrit ou des piles de technologie mal conçues (pour le type de site Web) jouent un rôle de plus en plus important dans le chargement lent du contenu dynamique. approche de l'ubiquité.


4
2018-02-07 10:04



Nope - ce que vous décrivez peut bloquer l'affichage d'éléments du DOM, mais pas seulement du texte. La réponse est à faire avec le remplacement de police et est la faute des concepteurs, pas les développeurs. - Toby
+1 @Toby parce que c'est vraiment la faute des concepteurs. C'est extrêmement irritant aussi si vous êtes sur un lien lent (comme, oh je sais pas, mon téléphone portable ou la ligne fixe à la maison). Des trucs comme ceux-là rendent les sites Web plus lents et irritent les utilisateurs sans aucun bénéfice. - Magnus
Réponse longue: Développeurs, développeurs, développeurs, développeurs. - iono
@Toby Les concepteurs spécifient les polices à utiliser, oui, mais c'est le travail de chaque bon développeur de faire les bons choix lors de la mise en œuvre technique. Le bon développeur comprendra également pourquoi cela se produit (expliqué dans une réponse ci-dessus), quels choix peuvent être faits pour éviter le problème (Google Webfont Loader), et comment cela affecte l'expérience. - arbales


En résumé, trop d'objets chargeables qui doivent être chargés à partir de HTTP GET distincts avant que la page puisse être affichée, et une dépendance excessive à la latence moyenne en tant que mesure de l'intégrité du site.

Le premier se réfère à tous ces fichiers .css, .js et webfont que la page charge, sans parler du fait que de nombreux sites doivent également récupérer des objets JSON via des requêtes XHR, puis générer du code HTML à partir de ceux utilisant une sorte de modélisation.

Mais pourquoi ne remarquent-ils pas que le site est lent?

Probablement parce qu'ils ont quelque chose dans Memecache pour accélérer les choses (ou simplement sur les caches de systèmes de fichiers) et qu'ils mesurent la santé de leur site en utilisant une latence moyenne. Ainsi, les objets mis en cache sont renvoyés avec une latence de 6 mircrosecondes et masquent le fait que de nombreuses requêtes GET durent 5000 millisecondes. Les moyennes doivent mourir. Vive le comptage des RTT sur un seuil maximum acceptable! Ce nombre doit être 0 ou, par définition, le RTT est inacceptable.


3
2018-02-13 04:25





Eh bien, il y a plusieurs raisons. Une des raisons est aussi que les commandes pour définir un arrière-plan ou sur une page HTML souvent Ou récupéré dans un CSS distinct chargé en premier. avant le chargement du corps du document qui contient le texte.

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

Certains concepteurs veulent aussi montrer les premières images et le texte suivant, ils y parviennent avec du javascript. Par exemple, une simple page affichera d'abord une bannière, puis tout le reste.

Mais si vous vous demandez pourquoi il y a tant de spam commercial sur mes pages alors que je veux seulement lire les nouvelles, alors il existe une solution pour vous. Vous pouvez utiliser des bloqueurs de spam si vous utilisez Firefox. Avec un tel addon, webrowser connaît les sites qui fournissent du spam et les bloque simplement, ce qui entraîne un chargement de page beaucoup plus rapide, tout en étant capable de voir les images importantes liées aux articles que vous lisez.

Je recommande à tous ceux qui gèrent le chargement lent des pages d’essayer fidler. fidler peut être utilisé avec IEexplorer ou avec FireFox (en utilisant sa fonction proxy) Fidler va effectivement vous montrer combien de temps cela prend réellement et quand des parties d'une page Web sont chargées. C'est un outil de débogage HTML.


-1
2018-02-07 11:41



alors vous essayez d'aider les gens et de vous faire voter n'est pas si amusant? Ok, je vais y réfléchir à deux fois avant d’expliquer aux gens des choses techniques en termes simples. - user613326
Vous avez expliqué la mauvaise chose, c'est pourquoi vous êtes mis en veilleuse. Comme vous pouvez le voir sur la capture d'écran, la page est entièrement chargée, seul le texte n'est pas affiché. Cela n'a rien à voir avec les images. - Femaref
Le corps du document est presque toujours chargé avant CSS externe. Le navigateur n'arrête pas d'analyser la page uniquement pour charger du contenu externe. Essayer d'aider n'est utile que si vous êtes réellement utile. La désinformation est pire que l'absence d'information. - raylu
@raylu je ne sais pas à propos de cette désinformation. Voir une réponse avec beaucoup de points de réduction peut parfois être très utile. :-) - LarsTech
Salut @ user613326: nous encourageons le vote honnête ici, car nous sommes principalement là pour apporter des réponses utiles à la communauté. Ne le prenez pas personnellement! - Flimm