Pourquoi les sites web n'affichent-ils pas immédiatement leur texte de nos jours ?

Réponse courte : Les développeurs.

Lorsque des liens et des balises script faisant référence à des documents externes (comme des fichiers .css ou .js) sont placés dans l'en-tête du document (plus haut dans le flux que le corps et ses éléments), ils sont chargés en premier. JavaScript s'exécute à partir des balises qui le référencent ; s'il y a beaucoup de code à traiter, ou s'il s'agit d'un code lourd, ou plus communément si le texte que vous vous attendez à voir est rendu sur un serveur et inséré dans le document lors du chargement - et que le code côté serveur est également lourd, volumineux, ou qu'il bloque les E/S en raison du traitement de plusieurs requêtes simultanées, vous pouvez certainement constater un temps d'arrêt avant même que le HTML ait eu la chance d'être rendu. Certains développeurs choisissent de charger le JavaScript non lié à la vue après le balisage et les styles (à la fin du corps du texte), et les meilleurs essaient d'être plus conscients de la façon dont leur décision technologique affectera l'expérience globale de l'utilisateur une fois mise en œuvre.

La vitesse de la connexion Internet joue un rôle dans la lenteur du téléchargement des données, c'est évident, mais un code mal écrit ou des piles technologiques mal conçues (pour le type de site Web) jouent un rôle de plus en plus important dans la lenteur du chargement du contenu dynamique, à mesure que les connexions réseau plus rapides deviennent omniprésentes.

En bref, un trop grand nombre d'objets chargeables qui doivent être chargés à partir de GET HTTP distincts avant que la page puisse être affichée, et une confiance excessive dans la latence moyenne comme mesure de la santé du site.

Le premier fait référence à tous les .css, .js et polices de caractères que la page charge, sans oublier le fait que de nombreux sites doivent également récupérer des objets JSON par le biais de requêtes XHR, puis générer du HTML à partir de ces objets à l'aide d'un modèle quelconque.

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

Probablement parce qu'ils ont un memecache quelque part pour accélérer les choses (ou qu'ils comptent simplement sur les caches du système de fichiers) et qu'ils mesurent la santé de leur site en utilisant la 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 mettent 5000 millisecondes à aboutir. Les moyennes doivent mourir. Vive le comptage des RTT au-delà d'un seuil maximal acceptable ! Ce nombre devrait être 0 ou, par définition, le RTT est inacceptable.

Eh bien, il y a plusieurs raisons. Une raison est aussi que les commandes pour définir un arrière-plan ou en haut d'une page html souvent soit récupérées dans un CSS séparé qui est chargé en premier. avant le chargement du corps du document qui contient le texte.

Une autre raison est que, bien qu'il soit possible de taper la taille d'une image, dans la plupart des cas, les concepteurs de sites Web ne l'utilisent pas. Ainsi, le brouilleur doit d'abord charger les images entières sur les pages afin de savoir comment envelopper le texte.

Certains concepteurs veulent également afficher d'abord les images et ensuite le texte, ils y parviennent par le biais de javascript. Par exemple, une page simple 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 ne veux lire que des 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 tout simplement, ce qui permet un chargement beaucoup plus rapide de la page, tout en vous permettant de voir les images importantes qui se rapportent aux articles que vous lisez.

Je recommande à tous ceux qui sont confrontés à la lenteur du chargement des pages d'essayer fidler. fidler peut être utilisé avec IEexplorer ou avec FireFox (en utilisant sa fonction proxy). Fidler vous montrera réellement combien de temps il faut et quand les parties d'une page web sont chargées. Il s'agit d'un outil de débogage HTML.