--- lastModified: 2026-10-13 type: feature title: "Test de vitesse web avec Runner AI" description: "Utilisez le test de vitesse web de Runner AI pour lire les résultats Lighthouse disponibles. Transformez un constat vérifié en correction à examiner." category: ai-cro h1: "Test de vitesse web pour une correction vérifiable" keyword: "test de vitesse web" legacyKind: structured --- Un **test de vitesse web** mesure le chargement d'une page dans les conditions d'un test donné. L'audit de Runner AI peut inclure Lighthouse et afficher les résultats disponibles pour mobile et ordinateur avec les constats d'exploration. Commencez avec une boutique publiée et une cible SEO admissible. Utilisez les preuves enregistrées pour demander une correction ciblée, sans supposer qu'un score décrit tous les clients ou modifie automatiquement votre boutique. ## Lancez le test de vitesse web sur une boutique accessible Ouvrez votre projet de boutique, puis **Développer** et **SEO**. Si Runner affiche la liste de configuration initiale, remplissez la condition de publication et terminez la première analyse avant d'attendre un rapport. Les données d'exemple ne mesurent pas votre boutique. Vérifiez que la boutique publique s'ouvre à l'adresse que vous voulez examiner avant d'interpréter un résultat. Ouvrez la carte de santé du site et la vue d'audit. L'action de nouvel audit ouvre les paramètres sans modifier la boutique. Choisissez une limite de pages adaptée, activez l'option Lighthouse et lancez l'audit. Cette limite concerne l'exploration : elle ne signifie pas que chaque URL explorée reçoit un test Lighthouse mobile et ordinateur distinct. Vérifiez l'adresse analysée affichée avec les résultats. Attendez le rapport plutôt que de considérer un audit lancé comme une mesure terminée. Notez la cible et les modifications effectuées depuis le contrôle précédent. L'[audit de site ecommerce](/fr/ecommerce-website-audit) organise les constats techniques et les problèmes du parcours d'achat. Cette page concerne les preuves de vitesse facultatives de ce processus, pas les tests de charge avec des clients simultanés ni la surveillance continue de disponibilité. ## Lisez les résultats sans compléter les valeurs absentes Lorsque Lighthouse fournit des résultats, Runner présente des cartes distinctes pour mobile et ordinateur. Elles affichent les scores disponibles de performance, d'accessibilité, de bonnes pratiques et de SEO, puis les métriques reçues. Vérifiez l'appareil et l'adresse avant de comparer les analyses. Un bon résultat sur ordinateur ne confirme pas une qualité identique sur mobile. Un score global n'explique pas non plus chaque source de retard. Les métriques peuvent inclure First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Speed Index, Time to Interactive, Cumulative Layout Shift, Interaction to Next Paint et Time to First Byte. Les valeurs dépendent de la réponse du fournisseur. Un tiret indique une valeur absente, pas un délai nul ni un contrôle réussi. N'inventez pas d'estimation. Les durées et les valeurs de décalage de mise en page décrivent aussi des propriétés différentes. Considérez le rapport comme une preuve issue d'une analyse précise, pas comme un recensement de tous les clients. Mesures de laboratoire, données de terrain et aperçu répondent à des questions différentes. Les [outils d'optimisation web](/fr/website-optimization-tools) aident à choisir des diagnostics complémentaires ou des données d'utilisateurs réels. Ne promettez pas une hausse de conversion, un meilleur classement ou un temps de chargement garanti parce qu'un score a changé. ## Transformez un constat vérifié en correction ciblée Utilisez les vues des problèmes et des pages pour repérer l'URL concernée et lire les constats enregistrés. Le temps de réponse apporte du contexte, mais ne correspond pas au délai d'apparition du principal contenu visuel. Ouvrez la page publique et reproduisez la tâche lente. Notez le chemin, l'appareil, l'état initial, le résultat attendu et le retard observé, sans envoyer d'identifiants ni de données clients privées. L'action de correction avec Runner ouvre une conversation avec les preuves choisies et une demande de travail. L'option pour tous les problèmes lance une conversation plus large. Aucune ne modifie ou ne publie la boutique à elle seule. Limitez la demande à un travail examinable et demandez de conserver les faits produits, la navigation, les commandes d'achat et les contenus sans rapport avec le problème. Si l'image principale d'un produit apparaît tard, indiquez la page et le comportement observé. Demandez une investigation avant de supprimer toutes les images ou tous les scripts. Une dépendance externe ou une contrainte opérationnelle peut demander une décision distincte. Un contrôle d'[accessibilité web ecommerce](/fr/ecommerce-website-accessibility) aide à vérifier que la correction ne retire pas des libellés, un comportement de focus ou des informations nécessaires aux clients. ## Retestez la correction publiée Examinez la proposition dans l'aperçu et répétez la tâche initiale. Vérifiez la sélection des produits, la navigation, le panier et les contenus concernés. L'examen de l'aperçu ne met pas à jour la boutique publique. Publiez seulement le travail approuvé, ouvrez à nouveau l'adresse publique et comparez un nouvel audit aux preuves précédentes pour la même URL analysée et le même appareil. Gardez les comparaisons ciblées. Si le contenu, la cible ou les conditions changent, notez la différence au lieu d'attribuer chaque variation de score à la modification. Répétez un résultat surprenant avant de conclure et conservez la métrique ou le comportement que vous vouliez améliorer. Un meilleur score ne remplace pas la vérification que le client peut toujours accomplir sa tâche. Runner distingue Lighthouse non demandé de Lighthouse indisponible. Dans le premier cas, demandez un audit avec l'option activée. Dans le second, utilisez les constats d'exploration terminés et réessayez le contrôle facultatif plus tard. Si l'exploration échoue, vérifiez l'adresse publique et envisagez un audit plus petit. Des preuves absentes restent un contrôle non résolu, pas une confirmation de rapidité. Le [catalogue Runner AI](/fr) présente les processus voisins. ## Questions fréquentes ### Runner AI teste-t-il chaque page avec Lighthouse ? Ne le supposez pas. La limite de pages concerne l'exploration technique, tandis que le résultat Lighthouse identifie son URL analysée. Vérifiez cette adresse et les cartes disponibles avant d'appliquer le résultat à une page produit, une collection ou au paiement. Les preuves concernent la page et les conditions effectivement analysées. ### Une métrique absente signifie-t-elle que la page a réussi ? Non. Un tiret signifie qu'aucune valeur n'est disponible. Il ne représente ni zéro milliseconde ni des Core Web Vitals validés. Séparez les valeurs absentes des scores reçus et utilisez une mesure complémentaire adaptée si cette métrique importe. Des données incomplètes ne justifient pas une affirmation de performance. ### La correction avec Runner accélère-t-elle automatiquement la boutique ? Non. Elle ouvre une conversation avec des preuves et une demande. Examinez la proposition et l'aperçu, puis décidez séparément de la publication. Répétez ensuite la tâche et mesurez le résultat public. Une conversation ou une modification acceptée ne prouve ni une amélioration du chargement ni une hausse de conversion. ### Que faire si Lighthouse manque mais que l'exploration est terminée ? Utilisez les résultats disponibles et gardez le contrôle facultatif ouvert. Confirmez la cible publique et réessayez Lighthouse plus tard. Ne remplacez pas une mesure absente par des données d'exemple ou un score inventé. Une exploration terminée et un test de vitesse web réussi sont deux résultats différents.