Un test de vitesse vous indique la rapidité de chargement d’une page une fois. Dotcom-Monitor la charge selon un planning, aussi souvent que chaque minute, dans plus de 40 navigateurs de bureau et mobiles réels, depuis 33 emplacements de votre choix. Il enregistre chaque élément qui a chargé lentement, échoué ou manqué, et envoie une alerte lorsque le temps de chargement dépasse le seuil que vous avez défini.
Chaque session conserve un graphique en cascade synchronisé avec la vidéo, les chronologies par hôte et par élément, ainsi qu’un historique de 100 sessions par appareil. Vous pouvez voir quel élément a ralenti la page et quand le ralentissement a commencé.
Intervalle de vérification le plus court
Navigateurs réels de bureau et mobiles
Emplacements de surveillance, 6 continents
Sessions en cascade conservées par appareil
La surveillance des performances d’un site web est le chargement continu et programmé d’une page web dans un vrai navigateur depuis des emplacements fixes, enregistrant combien de temps la page et chaque élément ont mis à se charger, quels éléments ont échoué, et alertant lorsque le temps de chargement ou les erreurs dépassent un seuil défini. Contrairement à un test de vitesse ponctuel, elle produit une série temporelle : la même page, le même navigateur, le même emplacement, mesuré toutes les quelques minutes. Un ralentissement apparaît comme un changement par rapport à une référence connue.
BrowserView, surveillance des pages uniques dans un vrai navigateur
De 1 minute à 3 heures, par appareil
Plus de 40 navigateurs de bureau et mobiles : Chrome, Edge, Firefox, profils iOS et Android
33 emplacements de surveillance sur 6 continents, plus des agents privés dans votre réseau
Graphique en cascade, vidéo, capture d’écran, temps par hôte et par élément ; 100 dernières sessions conservées par appareil
Chargement complet de la page, temps réseau uniquement, un événement de Navigation Timing, ou Premier rendu significatif
Éléments échoués (4xx/5xx, délais d’attente), mots-clés manquants, erreurs de certificat et expiration
Vérification multi-emplacements, puis email, SMS, téléphone, Slack, Teams, PagerDuty, ServiceNow, webhooks
La surveillance des performances web de Dotcom-Monitor fonctionne sur la plateforme BrowserView. Vous lui donnez une URL, choisissez les navigateurs et les emplacements, et réglez un seuil de temps de chargement. Ensuite, elle charge la page dans un vrai navigateur selon votre planning, de chaque minute jusqu’à toutes les trois heures, et conserve la cascade complète, la vidéo et la ventilation des temps de chaque session. Elle vous alerte lorsque la page dépasse votre seuil, qu’un élément renvoie une erreur, ou que le contenu attendu est manquant. L’alerte inclut le diagnostic de la session.
Ce que ce n’est pas. Ce n’est pas un robot d’exploration de site et il ne suit pas les liens sur votre site. Il surveille les pages spécifiques que vous configurez : page d’accueil, pages d’atterrissage, pages produit, page de tarification. Ce n’est pas un outil pour auditer des milliers d’URL. Si vous avez besoin de surveiller un parcours multi-étapes comme une connexion ou un paiement, c’est du monitoring d’applications web ; si vous devez seulement confirmer que le site est accessible, c’est de la surveillance de disponibilité. La section adaptation du produit ci-dessous contient la comparaison complète.
Google PageSpeed Insights, GTmetrix, WebPageTest et notre propre test de vitesse de site gratuit rapportent comment une page a performé lors de la session que vous avez lancée, depuis l’emplacement que vous avez choisi. Ils ne vous disent pas que la page a été 1,4 seconde plus lente à 9h mardi qu’elle ne l’était lundi, qu’elle est lente uniquement depuis Singapour, ou que l’image principale a commencé à retourner une erreur 404 après le déploiement de jeudi. Un moniteur de performance répond à ces questions.
Question | Test de vitesse unique | Surveillance des performances du site Dotcom-Monitor |
|---|---|---|
Quelle est la vitesse actuelle de cette page ? | Oui | Oui, chaque minute si vous le souhaitez |
Est-ce que c’est devenu plus lent après la dernière mise à jour ? | Pas de référence | Oui, historique des sessions et rapports de tendance |
Est-ce lent depuis l’emplacement de mes clients ? | Seulement depuis l’emplacement choisi pour ce test | Oui, 33 emplacements au choix |
Quel élément l’a ralenti ? | Waterfall pour ce test unique | Waterfall pour chaque test, synchronisé avec la vidéo |
Une image, un script ou une police a-t-il commencé à échouer ? | Seulement si vous regardiez à ce moment | Oui, signalé comme une erreur et alerté |
Quelqu’un sera-t-il prévenu quand cela dépasse 3 secondes ? | Non | Oui, par email, SMS, téléphone, Slack, PagerDuty, webhook |
Comment ça se comporte sur un iPhone par rapport à Chrome sur desktop ? | Généralement un seul navigateur émulé | Plus de 40 navigateurs réels desktop et mobile |
Comment se charge la page pour un visiteur récurrent avec un cache chaud ? | Non | Oui, simulation de visiteur de retour |
Chaque session est un chargement complet de page dans un navigateur réel, donc le moniteur enregistre tout ce que le navigateur demande et affiche. Les clients l’utilisent le plus souvent pour trouver ce qui suit.
Définissez le nombre de secondes que vous considérez acceptable. Chaque session qui le dépasse est enregistrée comme une erreur et la cascade montre quel élément et quelle phase (DNS, connexion, SSL, premier octet ou téléchargement) a pris ce temps.
Les gestionnaires de balises, les widgets de chat, les scripts publicitaires, les polices et les balises analytiques se chargent à partir d’hôtes que vous ne contrôlez pas. La répartition de la vitesse par hôte montre quand un tiers, et non votre serveur, a ralenti la page.
Une ressource qui renvoie un code 4xx ou 5xx, qui expire, ou qui n’arrive jamais est signalée comme une erreur sur la session, nommée dans la cascade, et peut déclencher une alerte. Vous découvrez que l’image principale renvoie un 404 avant un client.
La validation par mot-clé vérifie que le texte attendu est présent sur la page, avec des expressions ET / OU / NON. Une page qui renvoie un 200 mais affiche un modèle vide, un message d’erreur ou une publicité concurrente échoue toujours au contrôle.
Les certificats SSL invalides, non correspondants ou expirant sur la page ou toute ressource qu’elle charge sont signalés. Vous pouvez définir à combien de jours avant l’expiration vous souhaitez être averti, et filtrer quels hôtes comptent.
Chaque emplacement sélectionné effectue la vérification indépendamment et rapporte ses propres temps. Un CDN edge avec un cache froid, une mauvaise réponse GeoDNS ou une route de transit congestionnée apparaît comme une erreur dans un emplacement tandis que les autres passent.
Configurer une page prend quelques minutes. Utilisez l’importation en masse pour le reste.
Dans votre compte, ajoutez un nouvel appareil, choisissez Site Web, puis Page Web Unique. Le parcours multi-étapes est une surveillance d'application web, HTTP/S est une surveillance de disponibilité, et Lighthouse Report est la tâche Lighthouse distincte.
Choisissez le navigateur, Chrome, Edge, Firefox ou un profil d’appareil mobile, ainsi que la version du navigateur. Ajoutez des identifiants HTTP basic, digest ou NTLM si la page les requiert, et un hôte DNS personnalisé si vous souhaitez surveiller un serveur de préproduction ou une origine spécifique derrière un répartiteur de charge.
Sélectionnez parmi les 33 emplacements de surveillance à travers l’Amérique du Nord, l’Europe, l’Asie-Pacifique, l’Amérique du Sud, le Moyen-Orient et l’Afrique, et un intervalle de contrôle de une minute à trois heures. Les emplacements tournent en round-robin : un intervalle d’une minute sur cinq emplacements donne une lecture d’un emplacement différent chaque minute.
Le seuil de validation du temps est le temps de chargement, en secondes, au-delà duquel une session est comptée comme une erreur. Ajoutez une validation par mot-clé pour le contenu devant être présent, une alerte de fenêtre d’expiration de certificat, et des filtres de téléchargement pour exclure les éléments que vous ne souhaitez pas évaluer, tels qu’un beacon tiers connu pour être lent.
Lorsqu’un emplacement enregistre une erreur, la plateforme relance la vérification depuis d’autres emplacements avant d’ouvrir un incident. Un clignotement de route sur un chemin ne déclenche pas d’alerte. Une page lente depuis trois continents le fait.
La notification contient les diagnostics : l’erreur, l’élément en échec, le diagramme en cascade, une capture d’écran, et un lien vers la vidéo de la session. Elle peut être dirigée par gravité via groupes d’alerte et escalade par email, SMS, appel téléphonique, Slack, Microsoft Teams, PagerDuty ou tout webhook.
Le type d’appareil à choisir pour la surveillance des performances du site web : Site Web, puis Page Web Unique.
Les paramètres derrière les étapes 2 à 4 : navigateur, seuil, limitation, visiteur de retour, calcul du temps de réponse et vérifications de certificat sont tous sur un seul écran.
BrowserView vous permet de choisir quel événement du navigateur définit le temps de réponse évalué par rapport à votre seuil. Les autres temps sont enregistrés pour le diagnostic.
Temps jusqu’à l’événement Load Complete du navigateur : HTML, CSS, scripts, images, polices et tous les actifs tiers terminés. C’est la valeur par défaut.
Seulement le temps de transfert réseau, excluant le rendu côté client et l’exécution des scripts. Utilisez ceci pour mesurer la performance du serveur et du CDN sans le temps de rendu front-end.
Score contre un jalon spécifique de Navigation Timing du W3C, comme DOM Content Loaded ou DOM Interactive, lorsque vous voulez mesurer quand la page devient utilisable plutôt que complètement chargée.
Le rendu qui suit le plus grand changement de mise en page, lorsque le visiteur voit pour la première fois le contenu principal de la page. Utilisez-le lorsque le chargement perçu compte plus que l’événement de chargement.
Chaque élément dans le diagramme en cascade est décomposé en ses phases temporelles, avec l’heure de début et de fin, de sorte qu’un temps de premier octet lent sur le document est distinct d’un téléchargement lent d’une image de 4 Mo.
Temps total et nombre d’éléments regroupés par le domaine qui les a servis. Votre origine, votre CDN et chaque tiers ont leur propre ligne.
Historique. Les 100 dernières sessions de surveillance par appareil sont conservées avec les cascades complètes, et les temps de réponse résumés alimentent les rapports de tendance, de disponibilité et de performance ainsi que les tableaux de bord, que vous pouvez partager publiquement ou en privé et exporter par email selon un calendrier.
Une alerte indiquant “le chargement de la page a dépassé 3 secondes” lance une enquête. Ces outils identifient la cause.
Chaque session produit une cascade : chaque élément dans l’ordre de chargement, ses phases temporelles sous forme de segments colorés, son code d’état, et son hôte. Survolez une barre pour le résumé, ouvrez-la pour les en-têtes et détails. La session est également enregistrée en vidéo, synchronisée avec la cascade. Avancez jusqu’au point où la page s’est bloquée et voyez quelle requête était encore en cours.
La vidéo est enregistrée par défaut lors de la première erreur de la journée de chaque emplacement ; activez “Enregistrer la vidéo à chaque exécution” pour la conserver pour chaque session, ou désactivez la vidéo et les captures d’écran pour les pages affichant des données personnelles.
Pour toute session, l’analyse IA lit les temps de la cascade, les codes d’état et les messages d’erreur et fournit un verdict en langage clair : cible indisponible, partiellement dégradée ou normale ; ce que l’utilisateur aurait expérimenté ; l’URL en échec et sa cause profonde probable avec la preuve de la cascade citée ; et les actions correctives. Elle note également lorsque votre configuration de surveillance fait partie du problème, par exemple un seuil de timeout trop strict pour la page.
Aucune invite à écrire. Un administrateur active une fois l’Analyse des Données IA au niveau du compte. Les résultats sont étiquetés comme informatifs.
Le rapport d’aperçu de l’appareil liste chaque session avec son emplacement, temps de réponse et résultat ; cliquez pour voir le diagramme en cascade, la capture d’écran prise à la fin, la vidéo et l’alerte envoyée. Filtrez uniquement les erreurs, comparez les emplacements côte à côte ou exportez le journal. Lorsqu’un client signale que la page était lente hier après-midi, vous pouvez ouvrir les sessions d’hier après-midi.
Essai gratuit de 30 jours, sans carte de crédit, tous les navigateurs et emplacements inclus.
Une récupération sans interface (headless) depuis un centre de données sur une connexion gigabit ne reflète pas l’expérience d’un visiteur sur un téléphone avec un signal faible. Configurez le moniteur pour correspondre à ce visiteur.
Chrome, Edge et Firefox sur bureau, chacun avec différentes versions sélectionnables, ainsi que des profils de navigateurs mobiles pour appareils iOS et Android. L’exécution des scripts et le temps de mise en page sont inclus dans la mesure, pas seulement le temps de transfert.
Chargez la page comme un iPhone ou un appareil Android, avec la fenêtre d’affichage, le ratio de pixels et l’agent utilisateur qui déclenchent votre mise en page responsive et les ressources spécifiques au mobile, et évaluez-la selon un seuil mobile séparé.
Simulez des réseaux mobiles lents, moyens et rapides avec une bande passante et une latence prédéfinies, ou définissez des valeurs personnalisées de téléchargement, téléversement et latence, pour mesurer le temps de chargement sur une connexion lente.
Chaque session commence avec un cache vide, l’expérience de première visite. Activez la simulation des visiteurs récurrents pour recharger immédiatement et enregistrer uniquement la deuxième visite, afin de vérifier les en-têtes de cache et les taux de réussite du CDN.
Surveillance depuis votre propre réseau. Les pages sur un intranet, derrière un VPN, ou sur un environnement de préproduction accessible uniquement via internet privé peuvent être surveillées de la même façon avec un agent privé installé dans votre réseau. Il apparaît comme un emplacement supplémentaire et alimente les mêmes rapports et alertes.
Une page peut être lente pendant une seconde depuis un emplacement pour des raisons indépendantes de votre site. Deux mécanismes empêchent que ces événements deviennent des alertes.
Vérification avant notification. Une erreur à un emplacement est recontrôlée depuis d’autres avant qu’un incident ne soit ouvert. Seul un échec confirmé envoie un message, qui indique quels emplacements ont échoué et lesquels ont réussi.
Limitation et escalade. La limitation des alertes empêche les notifications répétées tant que la page reste dans le même état d’erreur. Les règles d’escalade dirigent la première alerte vers un groupe et, si elle n’est pas résolue, la suivante vers un autre, avec des modèles intégrant le temps de réponse, l’élément en échec et l’emplacement comme variables.
Core Web Vitals, Largest Contentful Paint, Interaction to Next Paint et Cumulative Layout Shift, sont les métriques d’expérience de page que Google utilise comme signal de classement, et Google les mesure à partir de vrais utilisateurs Chrome via le Chrome User Experience Report. Google utilise ces données terrain pour ses signaux d’expérience de page, et il s’agit d’une agrégation glissante sur 28 jours. Lorsque une régression apparaît dans la Search Console, elle a déjà affecté la page pendant des semaines.
Rapport Lighthouse issu d’une tâche de monitoring programmée : scores de catégories plus LCP, CLS et Temps de Blocage Total pour la page auditée.
Le monitoring synthétique détecte la régression en premier. Une augmentation du temps de chargement complet, First Meaningful Paint ou du temps jusqu’au premier octet du document après un déploiement apparaît sur ce moniteur en quelques minutes, avant les changements CrUX. Les scores Lighthouse et les métriques de laboratoire associées, incluant LCP, CLS et Temps de Blocage Total, proviennent d’une tâche de monitoring Lighthouse programmée séparément avec ses propres seuils et alertes. Exécutez les deux sur la même URL : BrowserView pour le temps de chargement dans de vrais navigateurs depuis les emplacements de vos utilisateurs, Lighthouse pour les scores d’audit que votre équipe SEO rapporte.
Audits Lighthouse programmés avec seuils et alertes par métrique, y compris pour les pages protégées par connexion.
Ce que Google mesure, son poids, et ce que les données synthétiques et terrain vous disent respectivement.
Une explication des phases de chronométrage, des ressources bloquantes et des motifs qui indiquent des corrections spécifiques.
Trois produits de la plateforme chargent les pages web et répondent à différentes questions. La plupart des clients en utilisent deux sur le même site.
Vérifications légères HTTP(S), ping et port qui confirment que le site répond, jusqu’à chaque minute, avec des contrôles de mots-clés et des alertes de panne. Coût par vérification le plus bas, sans navigateur impliqué.
Chargements complets en vrai navigateur de pages spécifiques, évalués selon un seuil de temps de chargement, avec des waterfalls par élément, vidéo, ventilation par hôte et détection d’éléments échoués. Utilisez-le pour garder les pages clés rapides et identifier ce qui les ralentit.
Parcours utilisateur multi-étapes scriptés enregistrés avec EveryStep : connexion, recherche, ajout au panier, paiement, soumission d’un formulaire. Vérifie que chaque étape réussit et en mesure le temps, dans des navigateurs réels, avec vidéo et waterfalls par étape.
Une configuration courante pour un site e-commerce : vérifications de disponibilité sur chaque URL, surveillance des performances du site web sur la page d’accueil, les pages des principales catégories et les pages des principaux produits, et surveillance des applications web lors du passage à la caisse. Chacune utilise les mêmes emplacements, groupes d’alerte et tableaux de bord.
Les pages d’atterrissage et les pages produits sont là où le trafic payant arrive. Surveillez les pages vers lesquelles vos annonces envoient du trafic, depuis les pays où les annonces sont diffusées, sur les appareils utilisés par ce trafic.
Détectez une régression de vitesse le jour de sa mise en production plutôt que des semaines plus tard via CrUX. Associez les temps de chargement BrowserView avec la tâche Lighthouse pour les scores, et gardez un tableau de bord partageable pour montrer ce qui a changé et quand.
Définissez un SLO de temps de chargement par page et recevez une alerte lorsqu’une version le casse. La cascade et la vidéo jointes à l’alerte identifient généralement l’élément responsable. Provisionnez des moniteurs depuis le CI via l’API.
Surveillez les pages clés de chaque client sous un seul compte avec des groupes, seuils et routage d’alerte séparés, et envoyez à chaque client un rapport en marque blanche montrant le temps de chargement sur la période, ou quel script tiers doit être supprimé.
Avis issus de avis vérifiés Capterra. Notes à partir d’août 2026.
4.5
83 avis
4.6
4.6
Tous les avis proviennent de avis vérifiés Capterra. Notes au août 2026.
Un test de vitesse charge une page une seule fois, depuis un seul emplacement, et fournit le résultat. La surveillance des performances d’un site web charge la même page selon un calendrier fixe, depuis les emplacements que vous choisissez, dans les navigateurs que vous choisissez, et conserve chaque résultat, pour que vous obteniez une base de référence, une tendance et une alerte lorsque la page devient plus lente ou qu’un élément échoue. Utilisez un test de vitesse pour enquêter sur un problème connu. Utilisez la surveillance pour découvrir qu’un problème existe.
De une fois par minute à une fois toutes les trois heures, par dispositif de surveillance. Les vérifications tournent à travers les emplacements que vous avez sélectionnés, un emplacement par intervalle, et tous les emplacements fonctionnent simultanément chaque fois qu’un dispositif est créé, modifié, redémarré, ou après qu’une erreur a été détectée. Des vérifications simultanées depuis tous les emplacements à chaque intervalle sont disponibles en option.
Il détecte les éléments cassés sur la page surveillée : images, scripts, feuilles de style, polices, iframes et toute autre ressource qui renvoie un statut 4xx ou 5xx, expire, ou échoue à se charger. Ceux-ci sont signalés comme erreurs lors de la session, affichés dans le waterfall et peuvent déclencher des alertes. Il ne parcourt pas le site en suivant les hyperliens, donc un lien sur la page qui pointe vers une destination morte n’est pas testé à moins que vous ne surveilliez également cette page de destination. Pour cela, ajoutez la destination comme un dispositif distinct ou utilisez une vérification de disponibilité.
Plus de 40 navigateurs réels sur ordinateur et mobile : Chrome, Microsoft Edge et Firefox sur ordinateur, avec versions sélectionnables, et profils de navigateurs mobiles pour iPhone, iPad et appareils Android. Chaque dispositif correspond à une page dans un navigateur, donc surveiller une page sur Chrome ordinateur et sur un profil iPhone signifie deux dispositifs avec deux seuils.
BrowserView mesure le chargement complet de la page, le temps réseau uniquement, les événements de navigation W3C et la première peinture significative dans un vrai navigateur, ainsi que les phases de temporisation par élément et par hôte. Les Core Web Vitals (LCP, INP, CLS) et les scores de performance Lighthouse sont mesurés par la tâche de surveillance Lighthouse distincte sur la même plateforme, qui exécute Google Lighthouse selon un calendrier et alerte sur les seuils par métrique. Le signal de classement de Google utilise des données terrain des utilisateurs de Chrome ; la surveillance synthétique détecte une régression des semaines avant que ces données terrain ne changent.
Oui. Chaque session commence avec un cache vide, ce qui mesure l’expérience de première visite. Activez “Simuler un visiteur revenant” et le navigateur recharge la page immédiatement après le premier chargement et enregistre uniquement la deuxième visite, ce qui montre l’effet de vos en-têtes de cache et CDN.
Les pages protégées par une authentification HTTP basique, digest ou NTLM peuvent être surveillées directement en ajoutant les identifiants au dispositif. Les pages nécessitant une connexion via formulaire sont gérées par la surveillance des applications web, qui scripte l’étape de connexion. Les pages sur un intranet, derrière un VPN, ou en environnement de staging inaccessible depuis internet public sont surveillées avec un agent privé installé à l’intérieur de votre réseau. Un paramètre DNS personnalisé vous permet d’adresser le moniteur vers un serveur d’origine spécifique ou un site pré-lancement avant les changements DNS.
La surveillance des performances d’un site web charge une page et mesure la rapidité de son chargement ainsi que les échecs éventuels. La surveillance des applications web exécute un script multi-étapes, une connexion, une recherche, un paiement, et vérifie que chaque étape fonctionne en mesurant le temps de chacune. Si la question est “ma page d’atterrissage est-elle rapide”, utilisez ce produit. Si la question est “les clients peuvent-ils toujours finaliser un achat”, utilisez la surveillance des applications web. Ils partagent les emplacements, les alertes et les rapports, et la plupart des clients e-commerce utilisent les deux.
Tout : tous les emplacements de surveillance, tous les navigateurs et appareils, la capture vidéo, l’analyse AI en cascade, tous les canaux d’alerte et intégrations, pendant 30 jours, sans carte de crédit requise. Configurez un moniteur de page dans les cinq premières minutes et les données de tendance commencent à s’accumuler immédiatement.
Commencez un essai gratuit de 30 jours, pointez un moniteur sur votre page la plus importante, et sélectionnez les navigateurs et emplacements utilisés par vos clients. La première cascade est disponible en quelques minutes.
Pas de carte de crédit requise. Toutes les fonctionnalités, emplacements et navigateurs inclus dans l’essai.