Mesures des extensions de navigateurs

Le processus de chargement d'une page web peut être divisé en plusieurs étapes principales :

1. Le navigateur traite la demande localement, en vérifiant par exemple la présence de données locales mises en cache, avant d'effectuer une requête sur le réseau.
2. Si la ressource n'est pas disponible localement, elle est demandée sur le réseau.
3. Le serveur reçoit la demande et la traite.
4. Les données nécessaires pour construire la structure de la page sont transférées du serveur au navigateur par l'intermédiaire du réseau.
5. Les ressources supplémentaires nécessaires au rendu de la page sont récupérées et la page est finalement affichée sur le navigateur de l'utilisateur.

Par la suite, nous aborderons plus en détail chaque partie mentionnée ci-dessus. Nous commençons par définir certains composants génériques tels que les pages, les hits, les protocoles et les ressources.

URL de la page

Une page URL est définie comme toute URL qui déclenche l'analyse d'un fichier HTML qui est ensuite rendu sur le navigateur du client.

Du point de vue de l'API Time Navigation du W3C, lorsque le navigateur demande une page, un calcul de New Navigation est déclenché.

URL de l'appel API

Une URL d'appel API est définie comme toute URL qui déclenche un appel API vers un serveur cible au nom d'un navigateur. Elle diffère de l'URL d'une page en fonction du type de données/contenu reçu du serveur cible. En général, les URL des appels API renvoient des données au format XML ou JSON, tandis que les URL des pages renvoient des ressources web telles que CSS, javascript et des images.

Chargements de pages et requêtes

Lorsqu'un navigateur demande une page web et les ressources web associées (JavaScripts, images, feuilles de style, ...), il envoie des requêtes HTTP aux différents serveurs sur lesquels résident ces ressources. Un appel à une ressource web est appelé "chargement de page" ou "requête" selon le type de requête web effectuée, ressources web ou appels API respectivement.

La plateforme DEM de Netskope distingue trois types de chargement de pages :

• Le chargement de la page de "navigation" est celui qui déclenche la demande initiale de la page web.
• Le chargement d'une page "ressource" déclenche l'interrogation de tous les types de ressources, à l'exception du chargement de la page "navigation" elle-même.
• Un chargement de page "requête" est une sous-partie de la catégorie de chargement de page "ressource". Il ne comprend que les demandes initiées par les types d'initiateurs suivants : xmlhttprequest, fetch et beacon. Ce type de résultat est essentiel dans le contexte des "applications à page unique".

Type MIME

MIME signifie Multipurpose Internet Mail Extensions. Le "type MIME" identifie en fait le type de ressource qui est chargée. Ainsi, dans l'exemple ci-dessus, le type MIME est "css", car le fichier style.css est chargé.

Cette information n'est pas fournie par le navigateur. Netskope a développé une heuristique spécifique pour faire correspondre les noms de fichiers aux types MIME correspondants.

Délai de traitement

Le processus de chargement d'une page web peut être divisé en plusieurs étapes principales :

1. Le navigateur traite la demande localement, en vérifiant par exemple la présence de données locales mises en cache, avant d'effectuer une requête sur le réseau.
2. Si la ressource n'est pas disponible localement, elle est demandée sur le réseau.
3. Le serveur reçoit la demande et la traite
4. Les données demandées sont transférées du serveur au navigateur par l'intermédiaire du réseau
5. La page web est affichée sur le navigateur de l'utilisateur.

Le temps nécessaire pour que tout ce processus soit terminé correspond à l’indicateur de temps de chargement. Le timing de navigation inclut toutes les étapes qui se produisent avant que la structure de la page web soit prête, et le timing des ressources inclut la récupération de toutes les ressources qui composent la page, afin que “Loading Time = Navigation + Resources”.

Du point de vue de l’API de navigation temporelle du W3C, le temps des ressources est défini comme le temps entre le moment où le navigateur a terminé d’analyser l’intégralité du fichier HTML et construit le DOM (domContentLoadedEventStart) et le moment où la page web entière est entièrement rendue à l’écran de l’utilisateur (domComplete).

Lorsque le point domContentLoadedEventStart est atteint, le DOM est prêt. Néanmoins, cela ne signifie pas que l'étape suivante consiste simplement à rendre/peindre tous les éléments sur l'écran. Certaines ressources (images, JavaScripts asynchrones, vidéos, ...) peuvent encore être demandées et chargées. L'ensemble du processus de demande et d'obtention de ressources supplémentaires est inclus dans cette phase de ressources.

Les ressources représentent donc différents processus qui se déroulent en parallèle : le calcul de l'arbre de rendu de la page, la mise en page correspondante, la peinture des éléments, ainsi que la demande (éventuellement par le biais de requêtes réseau New ) des ressources restantes.

Temps de chargement

La mesure du "temps de chargement" correspond au temps de chargement des pages (PLT) utilisé depuis des années. Il est parfois encore considéré comme la principale mesure de performance des services web. Il représente le temps nécessaire pour qu'une page web soit entièrement chargée.

Les principales phases du chargement d'une page web sont présentées ci-dessous :

1. L'utilisateur clique sur le lien d'une page web ou saisit une URL valide Le navigateur effectue différentes étapes comme la résolution de l'URL si elle n'est pas disponible dans le cache (requête DNS) et l'établissement d'une session TCP/TLS avec le serveur
2. Le serveur reçoit la demande et la traite
3. Le serveur envoie les données demandées au navigateur de l'utilisateur.
4. Le navigateur commence à analyser le code HTML et demande éventuellement des ressources supplémentaires (CSS, JS, ...).
5. Tous les éléments composant la page web sont entièrement chargés. Le navigateur peut commencer à afficher la page à l'écran.

Comme vous pouvez le constater, le temps de chargement est mesuré à partir de la demande de l'utilisateur jusqu'au moment où la page web est entièrement chargée et affichée à l'écran. À ce stade, le curseur du navigateur s'arrête.

Une vue plus détaillée de la séquence des événements est présentée ci-dessous :

Le calcul de nos mesures est basé sur l'API de navigation temporelle du W3C.

Le calcul de la valeur métrique du temps de chargement correspond à loadEventEnd-startTime.

Il calcule le temps écoulé entre la demande de la page web par le navigateur (startTime) et le moment où tous les composants sont entièrement chargés (loadEventEnd).

Redirect

Les redirections HTTP peuvent avoir un impact sur les performances de vos services web. Il est donc important de les surveiller.

Prenons l'exemple d'une session HTTP (http://www.netskope.com) redirection vers la session HTTPS sécurisée correspondante (https://www.netskope.com). D'un point de vue temporel, vous voyez sur l'image ci-dessous que la première connexion HTTP est entièrement intégrée dans le temps de redirection de la connexion HTTPS. Cela signifie que les mesures initiales de la session HTTP(DNS, TCP, Serveur et Transfert) ne sont pas disponibles en tant que telles. Leur impact potentiel sur les performances est inclus dans le temps de redirection de la connexion sécurisée correspondante. La connexion HTTP initiale n'est pas signalée.

Le temps nécessaire au navigateur pour effectuer une redirection correspond à l'indicateur de redirection de Netskope. Comme le montre la vue W3C Time Navigation API ci-dessous, Redirect time = fetchStart - startTime.

Wait

Le processus de chargement d'une page web peut être divisé en plusieurs étapes principales :

1. Le navigateur traite la demande localement, en vérifiant par exemple la présence de données locales mises en cache, avant d'effectuer une requête sur le réseau.
2. Si la ressource n'est pas disponible localement, elle est demandée sur le réseau.
3. Le serveur reçoit la demande et la traite
4. Les données demandées sont transférées du serveur au navigateur par l'intermédiaire du réseau
5. La page web est affichée sur le navigateur de l'utilisateur.

La mesure Netskope Wait fait partie de la première étape. Lorsqu'un navigateur doit récupérer une ressource, il effectue deux contrôles de base avant de lancer une requête sur le réseau :

1. Le navigateur vérifie si la ressource est disponible localement dans son cache
2. Si la ressource n'est pas disponible localement, le navigateur vérifie s'il est autorisé à récupérer la ressource.

La durée de la deuxième étape dépend principalement des éléments suivants :

• Protocole HTTP utilisé :
  Par exemple, dans HTTP/1.1, la plupart des navigateurs ne peuvent pas établir plus de 6 sessions TCP simultanées vers le même nom d'hôte/domaine. Lorsque le navigateur atteint cette limite, il doit attendre les emplacements disponibles sur New.
• Demandes plus prioritaires :
  Le navigateur peut devoir attendre que les éléments JS ou CSS bloquant le rendu soient récupérés et exécutés en premier avant de pouvoir procéder à d'autres opérations.
• Allocation d'espace dans le cache du disque :
  Pendant la brève procédure d'allocation de l'espace dans le cache du disque, le navigateur ne peut effectuer aucune autre tâche.

Le temps nécessaire au navigateur pour effectuer ces vérifications de base correspond à l'indicateur Netskope Wait. Comme le montre la vue W3C Time Navigation API ci-dessous, le temps d 'attente = domainLookupStart - fetchStart.

Réseau & Configuration du proxy

Le processus de chargement d'une page web peut être divisé en plusieurs étapes principales :

1. Le navigateur traite la demande localement, en vérifiant par exemple la présence de données locales mises en cache, avant d'effectuer une requête sur le réseau.
2. Si la ressource n'est pas disponible localement, elle est demandée sur le réseau.
3. Le serveur reçoit la demande et la traite
4. Les données demandées sont transférées du serveur au navigateur par l'intermédiaire du réseau
5. La page web est affichée sur le navigateur de l'utilisateur.

Comme le montre la vue W3C Time Navigation API ci-dessous, la partie Réseau comprend le processus de résolution FQDN (Fully Qualified Domain Name) ainsi que l'établissement d'une session TCP/TLS, de sorte que "Network Setup = DNS time + Connection Time + TLS time".

Le temps de mise en place du réseau est un paramètre présent à la fois pour le trafic dirigé et pour le trafic contourné. Dans les deux scénarios, l'instance du navigateur doit établir une session TCP et négocier TLS. La différence, lorsque le trafic est dirigé vers Netskope, est que le navigateur établit d'abord une connexion avec le service proxy de Netskope et que le service proxy établit ensuite une connexion avec l'application cible pour le navigateur après avoir appliqué toutes les politiques pertinentes, d'où l'apparition d'une mesure ultérieure du temps d'établissement du proxy (qui représente le temps de connexion TCP et le temps de négociation SSL entre le service proxy de Netskope et l'application web cible). Pour le trafic contourné, le temps d'installation du réseau représente le temps d'installation du DNS, de la connexion TCP et de la négociation SSL directement vers la cible de l'application, donc AUCUN temps d'installation du proxy ne sera présent.

Temps de réponse du serveur

Le processus de chargement d'une page web peut être divisé en plusieurs étapes principales :

1. Le navigateur traite la demande localement, en vérifiant par exemple la présence de données locales mises en cache, avant d'effectuer une requête sur le réseau.
2. Si la ressource n'est pas disponible localement, elle est demandée sur le réseau.
3. Le serveur reçoit la demande et la traite
4. Les données demandées sont transférées du serveur au navigateur par l'intermédiaire du réseau
5. La page web est affichée sur le navigateur de l'utilisateur.

Comme le montre la vue W3C Time Navigation API ci-dessous, le temps du serveur = responseStart - requestStart. Il est équivalent à ce qui est communément appelé TTFB (Time To First Byte). Une fois que le client a envoyé une requête web au serveur, la métrique Serveur correspond au temps nécessaire au serveur pour renvoyer le premier paquet (qui comprend le code d'état de la réponse) au client.

Il s'agit d'une mesure de performance très importante, car elle est directement liée aux performances du serveur !

Transfert de données

Le processus de chargement d'une page web peut être divisé en plusieurs étapes principales :

1. Le navigateur traite la demande localement, en vérifiant par exemple la présence de données locales mises en cache, avant d'effectuer une requête sur le réseau.
2. Si la ressource n'est pas disponible localement, elle est demandée sur le réseau.
3. Le serveur reçoit la demande et la traite
4. Les données demandées sont transférées du serveur au navigateur par l'intermédiaire du réseau
5. La page web est affichée sur le navigateur de l'utilisateur.

L'indicateur de transfert Netskope correspond à la quatrième étape. Lorsqu'un navigateur extrait une ressource d'un serveur, le transfert correspond au temps nécessaire au serveur pour renvoyer la ressource au navigateur après avoir calculé la demande (le serveur a renvoyé le code d'état 200 au navigateur). Cette mesure dépend directement de la taille de la ressource à charger ainsi que des conditions du réseau (latence et perte de paquets).

Comme le montre la vue W3C Time Navigation API ci-dessous, Transfer time = responseEnd - responseStart (temps de transfert = fin de la réponse - début de la réponse).

Errors

Lorsqu'un navigateur demande une page web et les ressources web associées (JavaScripts, images, feuilles de style, ...), il envoie des requêtes HTTP aux différents serveurs sur lesquels résident ces ressources. Une demande d'accès à une ressource web est appelée "chargement de page" ou "demande". Il peut y avoir plusieurs "Chargement de page" ou "Requête" par page vue car une page HTML peut contenir plusieurs fichiers.

Pour chaque "chargement de page" ou "demande", le navigateur envoie une requête HTTP au serveur, qui lui répond par une réponse HTTP. L'en-tête de réponse HTTP contient un code d'état qui indique si la demande HTTP a été traitée avec succès. Les réponses sont regroupées en cinq classes :

1. Réponses informatives (100 à 199)
2. Réponses positives (200 à 299)
3. Redirections (300 à 399)
4. Erreurs du client (400 à 499)
5. Erreurs de serveur (500 à 599)

Comme vous pouvez le constater, tous les codes d'état inférieurs à 400 correspondent à des demandes réussies. Les principales erreurs client que vous pouvez rencontrer sont les suivantes :

Code de statut	Description
400 - Mauvaise demande	Le serveur n'a pas pu comprendre la demande en raison d'une syntaxe non valide.
401 - Non autorisé	Bien que la norme HTTP spécifie "non autorisé", cette réponse signifie sémantiquement "non authentifié". En d'autres termes, le client doit s'authentifier pour obtenir la réponse demandée.
403 - Interdit	Le client n'a pas les droits d'accès au contenu, c'est-à-dire qu'il n'est pas autorisé, et le serveur refuse donc de fournir la ressource demandée. Contrairement à 401, l'identité du client est connue du serveur.
404 - Non trouvé	Le serveur ne trouve pas la ressource demandée

Les erreurs de serveur les plus courantes que vous pouvez rencontrer sont les suivantes :

Code de statut	Description
500 - Erreur interne du serveur	Le serveur a rencontré une situation qu'il ne sait pas comment gérer
502 - Mauvaise passerelle	Cette réponse d'erreur signifie que le serveur, tout en travaillant comme une passerelle pour obtenir une réponse nécessaire au traitement de la demande, a reçu une réponse non valide.
503 - Service indisponible	Le serveur n'est pas prêt à traiter la demande. Les causes les plus fréquentes sont un serveur en panne pour cause de maintenance ou surchargé.
504 - Délai d'attente de la passerelle	Cette réponse d'erreur est donnée lorsque le serveur agit comme une passerelle et ne peut obtenir une réponse à temps.
505 - Version HTTP non prise en charge	La version HTTP utilisée dans la demande n'est pas prise en charge par le serveur.

Le nombre de "Chargement de page" ou de "Requête" avec erreurs rapporté par Netskope correspond à toutes les requêtes HTTP pour lesquelles les codes de statut de réponse HTTP sont supérieurs à 399 ainsi qu'à tous les processus d'extraction de ressources qui échouent sans que le serveur ne réponde du tout au client.

CORS

CORS est un mécanisme qui permet à un serveur d'indiquer toute autre origine que la sienne à partir de laquelle un navigateur doit autoriser le chargement de ressources.

Comme expliqué en détail dans l'article "Quel est l'impact de CORS sur le contrôle des performances", CORS influence de manière significative la manière dont les mesures de l'API Time Navigation du W3C sont rapportées.

Lors d'une demande de ressources inter-origines, parmi toutes les mesures présentées dans la figure ci-dessus, seuls les attributs suivants sont correctement signalés :

• startTime
• fetchStart
• responseEnd
• duration

En outre, les ressources d'origine croisée qui sont redirigées auront une heure de début qui ne reflète que la ressource finale - l'heure de début sera égale à fetchStart au lieu de redirectStart. Cela signifie que l'heure de la (des) redirection(s) sera cachée de la synchronisation de la ressource.

Comme indiqué ci-dessus, malgré les limitations introduites par CORS, nous sommes toujours en mesure de calculer la durée totale d'une recherche de ressources.

Concrètement, cela signifie que vous pouvez facilement identifier les ressources qui ont un impact significatif sur les performances globales de l'application.