Tester son site sur mobile

Pour vérifier qu’un site fonctionne sur mobile, associez un rapport de performance à un test concret du parcours du visiteur. Une page rapide peut avoir un bouton d’envoi inaccessible. Une mise en page responsive peut perdre les données d’un formulaire.

Google a retiré son Mobile-Friendly Test et son API en décembre 2023. PageSpeed Insights, Lighthouse, l’émulation du navigateur et un vrai téléphone couvrent des aspects différents. Aucun de ces outils ne certifie à lui seul qu’un site est utilisable, accessible ou bien placé dans les résultats de recherche.

Choisissez les pages et les actions à tester

Prenez la page d’accueil, une page importante de produit ou de service et un article. Incluez le parcours réel de contact, de réservation ou d’achat, même s’il passe par un autre domaine. Testez les langues utiles et plusieurs états : première visite avec le bandeau de consentement, visite suivante, menu ouvert et formulaire comportant une erreur.

Notre test mobile gratuit peut servir de premier contrôle. Il examine le HTML récupéré et les informations de réponse pour repérer, par exemple, une balise viewport manquante, des largeurs fixes ou de très petits caractères définis directement dans le HTML. Il ne rend pas la page, n’exécute pas son JavaScript et ne calcule pas la mise en page à partir des feuilles de style externes. La taille du HTML n’est pas le poids total téléchargé, et le temps de récupération n’est pas le temps de chargement sur téléphone. Vérifiez les alertes dans un navigateur.

Distinguez les deux résultats de PageSpeed

Ouvrez PageSpeed Insights, entrez l’URL publique et sélectionnez Mobile.

Les données de terrain proviennent du Chrome UX Report et couvrent les 28 jours précédents. Vérifiez si le rapport indique « Cette URL » ou « Origine ». Faute de données suffisantes pour l’URL, PageSpeed peut afficher celles de l’origine, qui regroupe les pages ayant le même protocole, nom d’hôte et port. Une évaluation réussie au niveau de l’origine ne prouve pas que cette page précise a réussi. Si les données manquent aux deux niveaux, l’absence d’évaluation n’est pas un échec.

La partie laboratoire est un nouveau test Lighthouse dans des conditions simulées. Elle aide à rechercher une ressource lente ou un script bloquant. Son score de performance est distinct de l’évaluation de terrain. Une seule navigation ne mesure pas l’INP de vos visiteurs. Google explique ces différences.

Ouvrir en grand le rapport mobile enregistré du 4 août 2026 (Origine sélectionnée ; Core Web Vitals réussis)

Cet exemple enregistré montre les données de terrain de l’origine : LCP de 2,4 secondes, INP de 112 millisecondes et CLS de 0. Il ne contient aucun score de performance Lighthouse. Il illustre la portée d’un rapport ; ce n’est pas une mesure actuelle de notre page d’accueil.

Comprendre les seuils Core Web Vitals

Ces catégories utilisent le 75e centile des mesures de terrain concernées, pas leur moyenne :

Pour réussir l’évaluation complète, les trois mesures doivent être bonnes. Si les données INP sont insuffisantes, PageSpeed peut néanmoins afficher une réussite lorsque LCP et CLS sont bons. Des données LCP ou CLS insuffisantes empêchent l’évaluation. Cette règle de PageSpeed ne dispense pas de tester les interactions.

Comparez Search Console à périmètre égal

Dans Search Console, ouvrez Core Web Vitals puis le rapport mobile. Examinez le groupe concerné, sa mesure la plus mauvaise et les URL d’exemple. Google regroupe les pages dont l’expérience est similaire ; ces groupes ne correspondent pas nécessairement à vos modèles de page. Reproduisez le défaut avant d’accuser un composant partagé.

PageSpeed et Search Console peuvent diverger même lorsqu’on compare uniquement les données de terrain. Vérifiez le périmètre, URL, origine ou groupe, l’appareil, la période et le traitement des URL. Search Console distingue les paramètres d’URL, tandis que les données de terrain de PageSpeed les regroupent sans ces paramètres. Expliquer chaque différence par « laboratoire contre utilisateurs réels » est donc inexact. La documentation du rapport détaille ces distinctions.

Après publication d’une correction, refaites immédiatement les mêmes manipulations et mesures de laboratoire. Les résultats de terrain évoluent avec l’arrivée de nouvelles visites dans la fenêtre glissante. « Démarrer le suivi » lance une validation de 28 jours, sans forcer l’exploration ni la réindexation du site. Les données affichées peuvent évoluer avant la fin des 28 jours ; la validation exige toujours sa période de suivi et suffisamment de données.

Consignez les réglages de Lighthouse

Dans Chrome, ouvrez la page puis DevTools, choisissez Lighthouse et sélectionnez Mobile avant de lancer l’audit. Lighthouse en local peut examiner des pages authentifiées auxquelles une requête publique PageSpeed n’a pas accès. Consultez les méthodes d’utilisation de Lighthouse.

Enregistrez le rapport, la date, l’URL, la version de Lighthouse, le profil d’appareil, les réglages de ralentissement et la version de la page. Gardez ces conditions constantes pour comparer une modification et répétez un résultat surprenant. La machine, le navigateur, le consentement et la configuration peuvent changer les mesures. Ralentir manuellement le processeur dans DevTools ne garantit pas de reproduire la simulation de PageSpeed.

Automatiser une mesure avec l’API PageSpeed

Cette commande Bash demande un diagnostic mobile de performance, d’accessibilité et de SEO. Remplacez l’URL d’exemple par une page publique :

curl --get \
  'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
  --data-urlencode 'url=https://example.com/' \
  --data-urlencode 'strategy=mobile' \
  --data-urlencode 'category=performance' \
  --data-urlencode 'category=accessibility' \
  --data-urlencode 'category=seo'

Sous Windows, utilisez un terminal Bash pour cette syntaxe sur plusieurs lignes. Le guide de démarrage décrit l’accès à l’API et recommande une clé pour les requêtes automatisées fréquentes. Vérifiez le quota du projet avant de programmer des séries. Une erreur HTTP, y compris de quota, n’est pas un échec de la page testée.

Dans lighthouseResult, lisez categories et audits ; un score de catégorie de 0.92 correspond à 92 sur 100. Conservez fetchTime, lighthouseVersion, requestedUrl, finalUrl et configSettings, et traitez runtimeError avant d’accepter le résultat. Voir la référence des réponses. Pour un suivi continu du terrain, Google recommande les API CrUX ou CrUX History, car il prévoit de retirer les données CrUX de l’API PageSpeed.

Testez le parcours dans le navigateur et sur téléphone

Activez la barre d’appareils de DevTools et commencez à 360 × 800 et 390 × 844 pixels CSS. Faites varier la largeur, puis passez en paysage. Le mode appareil est une approximation : terminez sur les appareils et navigateurs utilisés par vos visiteurs, notamment Safari sur iPhone si nécessaire.

• Ouvrez et fermez navigation, commandes de consentement et fenêtres de dialogue. Les en-têtes fixes et bandeaux ne doivent pas cacher le contenu ou les boutons.
• Lisez les titres longs, tableaux et traductions. Testez le zoom et une mise en page étroite. Les règles d’accessibilité du contenu web (WCAG), dans leur critère de redistribution, utilisent 320 pixels CSS pour un contenu défilant verticalement, soit une fenêtre de 1280 pixels à 400 % de zoom. Les véritables tableaux à deux dimensions bénéficient d’une exception : préservez la lecture et un défilement utilisable au lieu de masquer ce qui dépasse.
• Touchez les commandes voisines et utilisez le clavier lorsque c’est possible. Le critère de taille des cibles WCAG 2.2 AA utilise 24 × 24 pixels CSS, avec des exceptions liées à l’espacement et à d’autres situations. Des commandes de 48 × 48 peuvent être plus confortables. Ces dimensions seules ne prouvent pas la conformité d’accessibilité.
• Remplissez le formulaire avec le clavier virtuel ouvert. Vérifiez libellés, focus, erreurs, conservation des données, envoi et confirmation. Pour un achat ou une réservation, utilisez un environnement de test autorisé et contrôlez le reçu ou l’enregistrement correspondant.
• Recommencez sur une connexion mobile représentative. Un chargement retardé ou une requête échouée doit laisser un moyen clair de reprendre l’action.

Un signalement utile est précis. Exemple hypothétique : « Sur la réservation en 390 × 844, le clavier et le bandeau de consentement masquent Envoyer. La page défile, mais le bouton reste inaccessible. » Joignez URL, navigateur, appareil, état, étapes, capture, résultat attendu et responsable. Une réservation bloquée mérite une correction même avec un score de performance vert.

Corrigez la cause mesurée

Pour un LCP lent, identifiez l’élément principal et ce qui retarde son affichage. S’il s’agit d’une image, rendez-la détectable tôt et évitez son chargement différé. Ne préchargez une ressource que si sa découverte doit être avancée, pas toutes les images et polices. Le guide LCP explique cette distinction.

Pour une interaction lente, enregistrez l’action et cherchez le travail bloquant. Réduisez les traitements inutiles ou fractionnez les longues tâches tout en préservant fonctions nécessaires et consentement. Pour les déplacements de contenu, réservez la place des images, intégrations et éléments ajoutés. Les guides INP et CLS traitent ces problèmes distincts.

Sur WordPress ou Shopify, testez une modification de thème ou d’application en préproduction, avec les mêmes contenus et parcours. Mesurez son effet avant d’accuser tous les plugins ou de proposer une refonte. Certaines corrections relèvent des réglages, d’autres d’un composant. Notre service d’optimisation de sites peut aider à identifier et réaliser ces travaux, avec du développement web lorsque du code doit changer.

Séparez indexation et utilisation

Google recommande le responsive pour l’indexation mobile-first, tout en acceptant d’autres configurations mobiles. Rendez le contenu, les images et les métadonnées accessibles à Googlebot. Une page utilisable peut encore avoir un problème d’indexation nécessitant une analyse SEO.

Les Core Web Vitals interviennent dans les systèmes de classement, mais de bons scores ne garantissent pas une bonne position, et un mauvais score ne prouve pas une pénalité. Les conseils de Google sur l’expérience de page les replacent dans l’utilité globale du contenu.

Gardez une trace simple : problème trouvé, correction publiée, action retestée avec succès et validation de terrain encore en attente. Revérifiez les parcours après un changement de thème, d’application, de formulaire ou de balise. Une évaluation réussie et une action menée à bien par le visiteur sont deux vérifications distinctes.