Prioriser le contenu visible - Google PageSpeed Insights
Vous vous demandez si quelqu'un peut m'aider. J'ai des problèmes avec la priorité du contenu visible (PVC).
J'ai lu toute la documentation de Google et je sais que le contenu au-dessus de la ligne de flottaison correspond aux 500 pixels de haut, mais je ne comprends pas ce que Google détecte à l'extérieur ou à l'intérieur de ces 500 pixels pour le déclencher. J'ai tout essayé pour trouver une solution.
Je peux créer des pages et recevoir l'avertissement PVC lorsque la page entière est au-dessus du pli, des pages sans barre latérale, des pages sans image ou de petites images, des pages utilisant CSS pour charger les images, des pages sans fichiers externes, pas de js , etc.
Je suis également capable de faire des pages avec beaucoup d'images et des images de fond au-dessus du pli qui l'évitent.
Je n'arrive pas à trouver un modèle ou une solution cohérente qui éclaire sur la manière dont Google décide ce qui déclenche un avertissement PVC.
Par exemple, une page qui n’utilise aucun fichier externe, aucune police, au-dessus du pli, a:
En-tête d'environ 150 pixels de hauteur avec une seule petite image Barre de navigation Aucune image de héros/grande image Div ne contenant pas de barre latérale, uniquement les balises h1 et h2 avec du texte clé
Et au-dessous du pli, des images et du texte.
Comment cette page est-elle identifiée comme ne donnant pas la priorité au contenu visible?
De plus, je peux créer une page donnant la priorité au contenu de la ligne de pliage et en être satisfaite en tant que modèle, l'enregistrer sous un nouveau nom de fichier et apporter des modifications mineures au texte/aux images avec le code principal exactement de la même manière. l'un et pas l'autre.
C’est la seule chose qui se répète à maintes reprises dans les informations sur la vitesse des pages - mes pages sont donc en proie à des tonnes de problèmes de vitesse qui peuvent en être la cause.
Voici l'erreur pour ceux qui se demandent:
Prioriser le contenu visible Votre page nécessite des allers-retours sur le réseau supplémentaires pour restituer le contenu au-dessus du pli. Pour optimiser les performances, réduisez la quantité de HTML nécessaire pour rendre le contenu au-dessus du pli. L'intégralité de la réponse HTML n'était pas suffisante pour rendre le contenu au-dessus du pli. Cela indique généralement que des ressources supplémentaires, chargées après l'analyse HTML, étaient nécessaires pour le rendu du contenu au-dessus du pli. Donne la priorité au contenu visible nécessaire au rendu au-dessus du pli en l'incluant directement dans la réponse HTML. Aucun du contenu final au-dessus du pli n'a pu être rendu, même avec la réponse HTML complète.
Avant que le navigateur puisse afficher la page, il doit construire le DOM et CSSOM des arbres. En conséquence, nous devons nous assurer que le HTML et le CSS sont transmis au navigateur le plus rapidement possible.
Le résultat final de tout ce processus est le modèle d'objet de document (DOM) de notre page simple, que le navigateur utilise pour tous les traitements ultérieurs de la page.
Chaque fois que le navigateur traite le balisage HTML, il effectue toutes les étapes suivantes: conversion d'octets en caractères, identification des jetons, conversion de jetons en nœuds et construction de l'arborescence DOM. Tout ce processus peut prendre un certain temps, surtout si nous avons une grande quantité de HTML à traiter.
Les arbres CSSOM et DOM sont combinés dans un arbre de rendu, qui est ensuite utilisé pour calculer la mise en page de chaque élément visible et sert d'entrée au processus Paint qui restitue les pixels à l'écran. L'optimisation de chacune de ces étapes est essentielle pour obtenir des performances de rendu optimales.
La construction de l’arbre de rendu montre que le chemin de rendu critique nécessite à la fois le DOM et le CSSOM de construire l’arbre de rendu. Cela crée une implication importante en termes de performances: HTML et CSS bloquent le rendu des ressources. Le code HTML est évident, car sans le DOM, nous n’aurions rien à restituer, mais l’exigence CSS pourrait être moins évidente.
Par défaut, CSS est traité comme une ressource bloquant le rendu , ce qui signifie que le navigateur ne restituera aucun contenu traité avant la construction du fichier CSSOM. Envoyez-le au client dès que possible et le plus rapidement possible pour optimiser le temps de rendu initial.
JavaScript nous permet de modifier pratiquement tous les aspects de la page: le contenu, le style et sa réponse aux interactions de l'utilisateur. Cependant, JavaScript peut également bloquer la construction du DOM et retarder le rendu de la page. L'exécution de notre script en ligne bloque la construction du DOM, ce qui retarde également le rendu initial.
Une autre propriété de l'introduction de scripts dans une page Web est qu'ils peuvent lire et modifier non seulement le DOM, mais également les propriétés CSSOM. Cela peut changer l'affichage de toutes ou de certaines propriétés des styles. De cette manière, le navigateur retarde l'exécution du script et la construction du DOM jusqu'à la fin du téléchargement et de la construction du CSSOM.
Par défaut, l'exécution de JavaScript est "blocage de l'analyseur" : lorsque le navigateur rencontre un script dans le document, il doit suspendre la construction du DOM, passez le contrôle à JavaScript. et laissez le script s'exécuter avant de procéder à la construction du DOM. Parce que le navigateur ne sait pas ce que le script prévoit d’afficher sur la page, il assume le pire des scénarios et bloque l’analyseur. Les scripts en ligne bloquent toujours l'analyseur, sauf si vous écrivez du code supplémentaire pour différer leur exécution.
Pour obtenir des performances optimales, définissez votre code JavaScript asynchrone et supprimez tout code JavaScript non nécessaire du chemin de rendu critique.
Pour que le premier rendu soit le plus rapide possible, nous devons minimiser trois variables:
Le nombre de ressources critiques. La longueur du chemin critique. Le nombre d'octets critiques.
Une ressource critique est une ressource qui pourrait bloquer le rendu initial de la page. Moins ces ressources sont nombreuses, moins de travail est nécessaire pour le navigateur, le processeur et les autres ressources.
De même, la longueur du chemin critique est une fonction du graphe de dépendance entre les ressources critiques et leur taille en octets: certains téléchargements de ressources ne peuvent être lancés qu'après le traitement d'une ressource précédente.
Enfin, moins le navigateur doit télécharger d’octets critiques, plus il peut traiter le contenu et le rendre visible à l’écran. Pour réduire le nombre d'octets, nous pouvons réduire le nombre de ressources (les éliminer ou les rendre non critiques) et veiller à réduire la taille du transfert en compressant et en optimisant chaque ressource.
La séquence générale des étapes pour optimiser le chemin de rendu critique est la suivante:
Analysez et caractérisez votre chemin critique: nombre de ressources, octets, longueur. Minimisez le nombre de ressources critiques: éliminez-les, différez leur téléchargement, marquez-les comme asynchrones, etc.
Optimisez le nombre d'octets critiques pour réduire le temps de téléchargement (nombre d'allers-retours). Optimisez l'ordre dans lequel les ressources critiques restantes sont chargées: téléchargez tous les actifs critiques le plus tôt possible pour réduire la longueur du chemin critique.
Résumé - chaîne approximative de dépendance pour la création de contenu visible: Visible conten => DOM => ressources critiques (par exemple, css, javascript).
Solution possible: appliquer des styles dans une tête d'élément, mais sans les incorporer dans le code HTML et utiliser des téléchargements asynchrones asynchrone/différé pour tous les scripts. Tout cela est appliqué dans AMP - Pages mobiles accélérées.
Source: chemin de rendu critique de Google Web Fundamentals et Optimisation de la chemin de rendu critique de l'aide de Google Patners.
Cet avertissement est probablement le résultat de css ou de javascript en bas de la page ou en dessous du contenu du pli ci-dessus. Si quelque chose dans ces fichiers est nécessaire pour restituer l'apparence de votre page, la page entière est chargée, le fichier css au bas de la page est chargé, puis le contenu ci-dessus s'affiche.
C'est trop lent. Vous devez placer rend CSS et JS de blocage au-dessus de votre contenu au-dessus du pli, de manière à ce qu'il soit chargé avant le reste de votre page. Cela permettra à votre contenu au-dessus du pli d'être affiché avant que les fichiers .js et css au bas de votre page ne soient chargés. Cela rendra votre page beaucoup plus rapide.