# Mesurer les performances SSR d’une application React

Un benchmark SSR utile doit répondre à une question précise : combien de travail correct l’application accomplit-elle dans un budget donné, avec quelle latence et quel coût ? Un nombre de requêtes par seconde isolé laisse beaucoup de choses dans l’ombre.

La méthode ci-dessous s’applique à une comparaison entre versions, profils ou moteurs React. Elle distingue les mesures HTTP des parcours navigateur et donne un exemple k6 à adapter à une route de test. Aucun chiffre de performance n’est déduit de cet exemple.

## Définir une réponse correcte

Choisissez une route représentative : liste dynamique, API ou page avec streaming. Fixez le volume de données, les dépendances et les conditions d’authentification. Une route de benchmark peut renvoyer un marqueur de requête unique pour détecter une réponse ancienne ou partagée à tort.

Validez le statut, le type de contenu et un élément attendu dans le corps. Si l’essai porte sur du SSR dynamique, assurez-vous que le travail de rendu a bien lieu. Un fichier statique mis en cache et une page produite à chaque requête sont deux charges différentes.

## Rendre les environnements comparables

Identifiez le commit, les archives, Node, React, le système et les options de compilation. Sur une machine donnée, gardez le même exécutable Node et les mêmes dépendances applicatives. Utilisez des builds de production et indiquez les réglages de cache et de compression.

Fixez les ressources du groupe complet, en incluant les workers et le proxy éventuel. Décrivez la topologie : deux processus derrière un proxy ne se comparent pas sans explication à un serveur direct. Placez si possible le générateur sur une machine séparée et surveillez sa saturation.

## Créer une route de test dynamique

Dans une application App Router de test, créez app/bench/page.jsx avec ce contenu. Le marqueur varie avec la requête et le rendu dynamique est explicite. Le volume de travail de cet exemple est minime : remplacez-le par votre rendu représentatif pour évaluer un cas métier.

Gardez le même code pour les moteurs comparés. Le marqueur seul ne prouve pas l’isolation de toutes les données : ajoutez des sessions distinctes et les assertions spécifiques à votre application si votre scénario dépend des utilisateurs.

```jsx
export const dynamic = "force-dynamic";

export default async function Benchmark({ searchParams }) {
  const { id = "missing" } = await searchParams;
  return <main>Benchmark marker: {id}</main>;
}
```

## Ajouter une validation au générateur de charge

Dans bench.js, cet exemple attend une route /bench qui renvoie le paramètre id dans son HTML. La route doit être créée dans votre fixture ; elle n’est fournie automatiquement ni par Next.js ni par PRNext. BASE_URL vise une instance de test que vous contrôlez.

Le seuil sur checks rend l’essai invalide si une réponse échoue à une vérification. Les redirections sont désactivées pour éviter de tester silencieusement une autre page. Cet exemple utilise une concurrence fermée : quand le serveur ralentit, chaque utilisateur virtuel attend davantage. Il ne simule pas un débit d’arrivée fixe.

```js
import http from "k6/http";
import { check } from "k6";

export const options = {
  vus: 16,
  duration: "60s",
  thresholds: { checks: ["rate==1"], http_req_failed: ["rate==0"] }
};

export default function () {
  const id = `request-${__VU}-${__ITER}`;
  const base = __ENV.BASE_URL || "http://127.0.0.1:3000";
  const response = http.get(`${base}/bench?id=${id}`, { redirects: 0 });
  check(response, {
    "status 200": r => r.status === 200,
    "HTML response": r => String(r.headers["Content-Type"]).includes("text/html"),
    "fresh marker": r => typeof r.body === "string" && r.body.includes(id)
  });
}
```

## Séparer chauffe et fenêtres mesurées

Avec k6 installé, lancez une chauffe séparée, puis plusieurs fenêtres mesurées. Alternez l’ordre des candidats et conservez les sorties de chaque passage. L’exemple de commande fonctionne depuis un shell POSIX ; adaptez la déclaration de BASE_URL sous PowerShell.

Le générateur conserve son propre coût réseau et CPU. Gardez les paramètres identiques pour les deux candidats et notez les événements concurrents du serveur. Des fenêtres répétées donnent une meilleure lecture de la variabilité ; elles n’effacent pas un biais de topologie ou une fixture non représentative.

```sh
BASE_URL=http://127.0.0.1:3000 k6 run --duration 10s bench.js
BASE_URL=http://127.0.0.1:3000 k6 run --summary-export result-a.json bench.js
```

## Lire débit, latence, CPU et mémoire ensemble

Le p95 indique une valeur de durée sous laquelle se terminent 95 % des requêtes de l’échantillon. Dans k6, http_req_duration ne comprend pas toutes les phases comme la résolution DNS et l’établissement initial de connexion. Nommez la mesure plutôt que de l’appeler simplement vitesse.

Calculez séparément le travail CPU du groupe par réponse correcte sur la fenêtre mesurée : delta CPU du groupe divisé par réponses validées. Un p95 HTTP n’est pas une mesure CPU. Relevez aussi la mémoire du groupe et la PSS de son arbre en indiquant la méthode. Si du contenu est faux, invalidez la fenêtre avant de comparer les performances.

## Compléter par un parcours navigateur

Le client peut recevoir un HTML rapidement puis attendre l’hydratation. Mesurez séparément une navigation, un retour arrière et une interaction métier. Vérifiez que le compteur, la session ou le formulaire conserve le bon état pendant le parcours.

Dans notre comparaison sur VPS, les gains serveur ne se traduisent pas par une victoire sur toutes les mesures navigateur. Publier ces différences rend la décision plus utile. Gardez le protocole, les résultats bruts et les limites à côté des graphiques.

[Lire notre campagne SSR et navigation sur deux VPS](/fr/blog/prnext-vs-nextjs-benchmarks-vps)

## Sources

[k6: built-in metrics](https://grafana.com/docs/k6/latest/using-k6/metrics/reference/)

[k6: checks](https://grafana.com/docs/k6/latest/using-k6/checks/)

[k6: thresholds](https://grafana.com/docs/k6/latest/using-k6/thresholds/)

[Linux: cgroup v2](https://docs.kernel.org/admin-guide/cgroup-v2.html)

[Node.js: process.memoryUsage()](https://nodejs.org/api/process.html#processmemoryusage)

Published: 2026-10-30

Modified: 2026-10-30

Author: PRNext

---

Language: fr

Canonical: https://prnext.dev/fr/blog/mesurer-performances-react-ssr

Index: https://prnext.dev/llms.txt