Vitesse de page sous charge

Aperçu

Vitesse de page sous charge mesure les Core Web Vitals sur l'une de vos pages pendant qu'un test de charge cloud s'exécute contre elle. Au lieu de ne voir que des métriques serveur comme les temps de réponse et les taux d'erreur, vous voyez aussi ce qu'un vrai navigateur subit lorsque le backend est mis sous charge, et vous pouvez lire le nombre d'utilisateurs virtuels à partir duquel l'expérience de la page commence à se dégrader.

Pendant que le test augmente les utilisateurs virtuels, LoadFocus charge la page que vous choisissez dans un vrai navigateur headless à intervalles réguliers et enregistre :

• LCP (Largest Contentful Paint)
• CLS (Cumulative Layout Shift)
• FCP (First Contentful Paint)
• TTFB (temps de réponse du serveur)

Chaque capture est associée au nombre d'utilisateurs virtuels actifs à ce moment, de sorte que les résultats superposent la métrique à la courbe de charge sur une seule chronologie.

Pourquoi c'est important

Un test de charge vous dit que le serveur est resté disponible. Il ne vous dit pas si la page semblait encore rapide pour un visiteur pendant qu'elle était sous charge. À mesure que le backend sature, les pages sont plus lentes à s'afficher : le LCP grimpe, le TTFB augmente, la mise en page peut se décaler. Vitesse de page sous charge rend cela visible, et l'indicateur le plus important pour la planification de capacité est le nombre d'utilisateurs virtuels à partir duquel une métrique sort de la plage "bon".

Prérequis

• Un test de charge cloud général (URL). Cette fonctionnalité est disponible sur le test de charge cloud standard, pas sur les tests JMeter ou k6.
• Un forfait Page Speed Monitoring. Sur le forfait gratuit, l'interrupteur affiche une invitation à passer à un forfait supérieur au lieu de s'activer.
• Chaque capture consomme un test Page Speed de votre quota Page Speed Monitoring. Une exécution capture jusqu'à environ 15 échantillons.
• Elle fonctionne sur les exécutions manuelles. Les exécutions planifiées ne capturent pas encore les Core Web Vitals.
• Utilisez une exécution d'au moins quelques minutes. Le navigateur cloud met environ une minute à démarrer, donc une exécution courte peut se terminer avant d'avoir capturé quoi que ce soit.

Activation

1. Ouvrez un test de charge cloud général et allez dans sa configuration. Sous Plus d'options, cliquez sur la ligne Vitesse de page sous charge.
2. Activez Measure Core Web Vitals under load.
3. Dans Page to measure, saisissez la page à mesurer. Par défaut, il s'agit de la première URL de requête du test. Utilisez une page réellement servie par le système que vous testez, sinon les métriques ne refléteront pas la charge.
4. Facultatif : activez Faire échouer le test quand les Core Web Vitals au pic de charge dépassent ces budgets et renseignez LCP max (ms), CLS max, FCP max (ms) et TTFB max (ms). Laissez un champ vide pour ignorer cette métrique. Chaque budget est comparé à la mesure prise au pic de charge, c'est-à-dire à la plus forte concurrence mesurée par le navigateur.
5. Lancez le test comme d'habitude.

Lire les résultats

Une fois l'exécution terminée, ouvrez sa page de résultats et allez dans l'onglet Vitesse sous charge. Le panneau Vitesse de la page sous charge apparaît dès que des échantillons ont été collectés. Le bouton Sur plusieurs exécutions bascule vers la tendance sur plusieurs exécutions, voir Page Speed Under Load trends.

• Le graphique superpose deux courbes sur la chronologie de l'exécution : la montée en charge des utilisateurs virtuels et la métrique sélectionnée. Vous pouvez observer la métrique monter à mesure que la charge augmente.
• Le sélecteur de métrique (LCP, CLS, FCP, TTFB) change la métrique affichée dans le graphique et les tuiles.
• Les tuiles résument l'exécution :
  • Baseline : la métrique à la charge la plus faible
  • Peak-load : la métrique à la charge la plus élevée
  • Change under load : la différence en pourcentage entre les deux
  • Left good (par exemple "LCP left good, at ~620 VU") : le nombre d'utilisateurs virtuels auquel la métrique a dépassé pour la première fois la limite de la plage "bon" (LCP 2,5 s, CLS 0,1, FCP 1,8 s, TTFB 0,8 s)
• Le tableau des échantillons liste chaque capture avec son heure, son nombre d'utilisateurs virtuels et les quatre métriques.

Remarques

• Le nombre d'utilisateurs virtuels affiché est reconstruit à partir de la montée en charge configurée de votre test (utilisateurs, temps de montée et paliers). C'est une approximation précise de la concurrence à chaque point, et non le calendrier exact des threads exécuté.
• Les Core Web Vitals ici sont des mesures en laboratoire de la page que vous indiquez. Elles complètent, sans les remplacer, les données de terrain de Page Speed Monitoring.