Mobile Analysis in PageSpeed Insights

Dans PageSpeed Insights, les pages sont analysées afin de vérifier si elles sont conformes à nos recommandations·et s'affichent bien en moins·d'une·seconde·sur·un réseau·mobile. Des·études ont·démontré·que tout délai·supérieur à·une·seconde interrompt le fil des·pensées·du mobinaute et engendre ainsi une·mauvaise·expérience. Notre·objectif est·de·maintenir le mobinaute·concentré sur·la·page et·de·lui offrir·une·expérience·optimale,·quel·que·soit l'appareil·ou·le type de·réseau.

Il·n'est·pas·facile·de·respecter cette limite·d'une·seconde. Heureusement pour nous, l'ensemble de la page n'a pas besoin de s'afficher pendant ce délai. C'est le contenu au-dessus de la ligne de flottaison que nous devons renvoyer et afficher en moins d'une seconde, ce qui permet au mobinaute de commencer à interagir avec la page dès que possible. Ensuite, pendant que le mobinaute interprète le contenu qui s'affiche en premier sur la page, le reste peut s'afficher progressivement en arrière-plan.

S'adapter aux réseaux mobiles à latence élevée

Le respect du critère qui consiste à afficher le contenu au-dessus de la ligne de flottaison en moins d'une seconde sur les appareils mobiles constitue un défi propre à ce type de réseau. Les mobinautes peuvent accéder à votre site par le biais d'une multitude de réseaux 2G, 3G et 4G qui sont différents. La latence du réseau est considérablement plus élevée qu'avec une connexion câblée, et une part importante de notre délai de 1 000 ms est utilisée pour afficher du contenu au-dessus de la ligne de flottaison, avec :

  • des boucles de 200 à 300 ms sur les réseaux 3G ;
  • des boucles de 50 à 100 ms pour les réseaux 4G.

Le réseau 3G est le plus répandu dans le monde. Ainsi, même si les déploiements 4G se développent au niveau international, attendez-vous à ce que la majorité des mobinautes utilisent un réseau 3G pour accéder à votre page. Par conséquent, nous partons du principe que chaque requête réseau prendra, en moyenne, 200 millisecondes.

À présent, revenons en arrière. Si nous examinons une séquence de communication typique entre un navigateur et un serveur, 600 ms sont déjà nécessaires au traitement du réseau : une résolution DNS pour transformer le nom d'hôte (par exemple, google.com) en adresse IP, une boucle sur le réseau pour le protocole de transfert TCP et enfin une boucle complète sur le réseau pour envoyer la requête HTTP. Cela nous laisse seulement 400 ms.

Offrir l'expérience d'un affichage inférieur à une seconde

Après avoir soustrait la latence du réseau, il ne nous reste plus que 400 millisecondes et il y a encore beaucoup d'étapes : le serveur doit afficher la réponse, le code de l'application côté client doit s'exécuter, et le navigateur doit mettre en page et afficher le contenu. Cela étant dit, les critères suivants devraient nous aider à ne pas dépasser la limite :

(1) Le serveur doit afficher la réponse (< 200 ms)
Le temps de réponse du serveur est le temps nécessaire pour que le serveur affiche le code HTML initial, sans tenir compte du temps de transport réseau. Étant donné que nous avons très peu de temps, cette étape doit être effectuée le plus rapidement possible ; idéalement en 200 millisecondes, voire moins.
(2) Le nombre de redirections doit être réduit au strict minimum
Les redirections HTTP supplémentaires sont susceptibles d'ajouter une ou deux boucles sur le réseau (deux si une résolution DNS de plus s'impose), ce qui entraîne des centaines de millisecondes de latence additionnelle sur les réseaux 3G. C'est pour cela que nous encourageons vivement les webmasters à réduire le nombre de redirections, voire même à les supprimer totalement, particulièrement pour les documents HTML. Il convient d'éviter les redirections "m point" lorsque cela est possible.
(3) Le nombre de boucles sur le réseau pour le premier affichage doit être réduit au strict minimum

En raison de la façon dont la capacité d'une connexion est évaluée par le protocole TCP (à savoir, TCP Slow Start), une nouvelle connexion TCP ne peut pas immédiatement utiliser toute la bande passante disponible entre le client et le serveur. Ainsi, le serveur peut envoyer jusqu'à 10 paquets TCP pour une nouvelle connexion (~14 Ko) durant la première boucle, puis il doit attendre que le client reconnaisse ces données avant de pouvoir augmenter sa fenêtre de congestion et diffuser plus de données.

Ce comportement du protocole TCP implique qu'il est important d'optimiser votre contenu pour limiter le nombre de boucles requis pour diffuser les données nécessaires au premier affichage de la page. Idéalement, le contenu situé au-dessus de la ligne de flottaison doit faire moins de 14 Ko. Cela permet au navigateur d'afficher la page dès la première boucle. Il est également important de savoir que la limite de 10 paquets (IW10) est une mise à jour récente de la norme TCP : assurez-vous de mettre à jour votre serveur pour profiter de ce changement. Dans le cas contraire, il est probable que la limite soit de trois ou quatre paquets.

(4) Évitez d'inclure des fichiers JavaScript et CSS externes qui bloquent l'affichage dans le contenu au-dessus de la ligne de flottaison

Avant qu'une page puisse s'afficher, elle doit être analysée par le navigateur. Si un script non asynchrone ou un script externe bloquant est reconnu lors de cette analyse, cela provoque l'arrêt du navigateur et le téléchargement de cette ressource. Chaque fois que cette opération est effectuée, cela ajoute une boucle complète sur le réseau et allonge le temps nécessaire au premier affichage de la page.

Ainsi, les fichiers JavaScript et CSS requis pour afficher la zone au-dessus de la ligne de flottaison doivent être intégrés, et les fichiers du même type qui permettent d'ajouter des fonctionnalités à la page doivent être chargés une fois que le contenu au-dessus de la ligne de flottaison a été diffusé.

(5) Prévoyez du temps pour la mise en page et l'affichage dans le navigateur (200 ms)
Le processus d'analyse des fichiers HTML et CSS, et d'exécution du code JavaScript prend du temps et consomme les ressources du client. Ce processus peut prendre des centaines de millisecondes selon la vitesse de l'appareil mobile et la complexité de la page. Nous vous recommandons d'accorder 200 millisecondes au traitement par le navigateur.
(6) Optimisez le temps d'exécution et d'affichage du code JavaScript
L'exécution de scripts compliqués et de codes inefficaces peut prendre des dizaines, voire des centaines de millisecondes. Utilisez les outils pour développeurs intégrés dans le navigateur pour créer et optimiser votre code. Notre cours interactif sur les outils pour les développeurs Google Chrome constitue une excellente entrée en matière.

FAQ

Comment les réseaux 4G influencent-ils les critères répertoriés ci-dessus ?
La diminution des latences dues aux boucles sur le réseau est l'une des améliorations clés des réseaux 4G. Cela est très utile et permet de réduire le temps de traitement total du réseau qui prend actuellement plus de 50 % de la limite d'une seconde sur les réseaux 3G. Cependant, la 3G est le type de réseau dominant dans le monde entier et le restera pendant des années. Vous devez donc optimiser vos pages en pensant aux mobinautes qui ont recours à la 3G.
J'utilise une bibliothèque JavaScript telle que jQuery, avez-vous des conseils à me donner ?
De nombreuses bibliothèques JavaScript, telles que jQuery, servent à apporter des améliorations à la page en y ajoutant de l'interactivité, des animations ou d'autres effets. Cependant, de nombreux comportements de ce type peuvent être ajoutés en toute sécurité après l'affichage du contenu au-dessus de la ligne de flottaison. Essayez de reporter l'exécution et le chargement de ce fichier JavaScript jusqu'à ce que la page soit chargée.
J'utilise une infrastructure JavaScript pour construire la page, avez-vous des conseils à me donner ?
Si le contenu de la page est construit avec un fichier JavaScript côté client, envisagez d'intégrer les modules JavaScript concernés pour éviter d'autres boucles sur le réseau. De la même manière, tirez profit de l'affichage côté serveur pour accélérer le premier chargement de page de manière significative. Affichez les modèles JS sur le serveur, intégrez les résultats au document HTML, puis utilisez une modélisation côté client une fois l'application chargée.
Comment SPDY et HTTP 2.0 peuvent-ils m'aider ?
SPDY et HTTP 2.0 ont tous les deux pour but de réduire la latence du chargement des pages en utilisant plus efficacement la connexion TCP sous-jacente (multiplexage, compression de l'en-tête, établissement de priorités). De plus, la transmission par le serveur permet d'améliorer encore plus les performances en réduisant la latence du réseau. Nous vous encourageons à considérer l'ajout d'un support SPDY à vos serveurs et le passage à la norme HTTP 2.0 une fois qu'elle sera prête.
Comment identifier un code CSS essentiel sur ma page ?
Dans les outils pour développeurs Google Chrome, ouvrez le panneau "Audits", puis exécutez un rapport sur les performances des pages Web. Dans le rapport qui est généré, recherchez "Supprimer les règles CSS non utilisées". Vous pouvez également utiliser n'importe quel outil tiers ou script pour identifier quels sélecteurs CSS sont appliqués sur chaque page.
Ces bonnes pratiques peuvent-elles être automatisées ?
Absolument. Il existe de nombreux produits payants et Open Source relatifs à l'optimisation des performances Web qui peuvent vous aider à respecter une partie ou l'ensemble des critères répertoriés ci-dessus. Si vous recherchez des solutions Open Source, consultez les outils d'optimisation PageSpeed.
Comment puis-je configurer mon serveur pour respecter ces critères ?
Tout d'abord, assurez-vous que votre serveur fonctionne avec une version à jour du système d'exploitation. Afin de profiter de l'augmentation de la capacité de la fenêtre de congestion initiale TCP (IW10), vous avez besoin du noyau Linux 2.6.39 ou version ultérieure. Pour les autres systèmes d'exploitation, consultez la documentation.
Pour optimiser le temps de réponse du serveur, instrumentez votre code ou utilisez un outil de contrôle d'application permettant d'identifier les points de congestion, tels que l'exécution des scripts, les appels de base de données, les requêtes RPC, l'affichage, etc. L'objectif est de renvoyer la réponse HTML en 200 millisecondes.
Qu'en est-il du programme Content Security Policy (CSP) ?
Si vous utilisez CSP, vous avez peut-être besoin de mettre à jour vos règles par défaut.
Tout d'abord, les attributs CSS intégrés dans les éléments HTML (par exemple "&lt p style=...&gt") doivent être évités autant que possible, car ils provoquent souvent des duplications de code inutiles et ils sont bloqués par défaut par CSP (désactivé via "intégration non sécurisée" dans "style-src"). Si CSP est activé, il bloque par défaut toutes les balises de script intégré. Si vous avez des fichiers JavaScript intégrés, vous devez mettre à jour les règles de CSP pour utiliser soit des hachages et pointeurs de script, soit l'option "intégration non sécurisée" pour autoriser l'exécution de tous les scripts intégrés. Si vous avez des styles intégrés, vous devez mettre à jour les règles de CSP pour pouvoir utiliser soit les hachages et pointeurs de style, soit l'option "intégration non sécurisée" afin d'autoriser le traitement de tous les blocs de style.

Vous avez d'autres questions ? N'hésitez pas à les poser et à donner votre avis dans notre groupe de discussion sur la page pagespeed-insights-discuss.