30 oct 2026Blog

Cómo comparar el rendimiento de React SSR

PRNext

Un punto de referencia SSR útil responde a una pregunta específica: ¿cuánto trabajo correcto puede completar la aplicación dentro de un presupuesto de recursos, con qué latencia y costo? Un número de solicitudes por segundo por sí solo deja demasiadas cosas sin explicar.

Este método se aplica a versiones, perfiles o tiempos de ejecución React. Separa las mediciones HTTP de los viajes del navegador e incluye un ejemplo de k6 para adaptarse a una ruta fija. El ejemplo en sí no establece ningún resultado de rendimiento.

Definir una respuesta correcta

Elija una ruta representativa: una lista dinámica, un API o una página de transmisión. Corrija el volumen de datos, las dependencias y las condiciones de autenticación. Una ruta fija puede devolver un marcador de solicitud único para detectar respuestas obsoletas o compartidas incorrectamente.

Valide el estado, el tipo de contenido y un valor de cuerpo esperado. Para SSR dinámico, verifique que la renderización realmente se produzca. Un archivo estático almacenado en caché y una página recién renderizada son cargas de trabajo diferentes.

Haga que los entornos sean comparables

Identifique la confirmación, los artefactos, el nodo, React, el sistema operativo y las opciones del compilador. En una máquina determinada, conserve el mismo ejecutable de Nodo y las mismas dependencias de la aplicación. Utilice compilaciones de producción y registre la configuración de compresión y caché.

Establecer presupuestos para todo el grupo, incluidos los trabajadores y cualquier apoderado. Explique la topología: dos procesos detrás de un proxy necesitan contexto en comparación con un servidor directo. Prefiera una máquina generadora de carga separada y controle si se satura.

Crear una ruta de accesorios dinámica

En una aplicación de prueba de App Router, cree app/bench/page.jsx con este contenido. El marcador varía según la solicitud y la representación dinámica es explícita. Este ejemplo hace muy poco trabajo; reemplácelo con una representación representativa al evaluar un escenario comercial.

Mantenga la misma fuente para los tiempos de ejecución que se comparan. Un marcador por sí solo no prueba el aislamiento de todos los datos: agregue sesiones separadas y afirmaciones específicas de la aplicación cuando los usuarios formen parte del escenario.

aplicación/bench/page.jsx

export const dynamic = "force-dynamic";

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

Agregar validación al generador de carga.

Guarde este ejemplo como bench.js. Espera una ruta de fijación /bench que repita el parámetro de consulta id en su HTML. Cree esa ruta en su aplicación de prueba; ni Next.js ni PRNext lo suministran automáticamente. BASE_URL apunta a una instancia de prueba que usted controla.

El umbral de comprobaciones invalida la ejecución cuando una respuesta no supera la validación. Los redireccionamientos están deshabilitados para evitar medir silenciosamente una página diferente. Este es un ejemplo de concurrencia cerrada: cuando el servidor se ralentiza, cada usuario virtual espera más. No simula una tasa fija de llegada.

banco.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)
  });
}

Calentamiento separado de las ventanas medidas

Con k6 instalado, ejecute un calentamiento por separado y luego varias ventanas medidas. Alterne el orden de los candidatos y mantenga el resultado de cada ejecución. El comando utiliza la sintaxis del entorno de shell POSIX; adapte la asignación BASE_URL en PowerShell.

El generador tiene red propia y costo CPU. Mantenga los parámetros idénticos para ambos candidatos y registre la actividad del servidor competidor. Las ventanas repetidas ayudan a describir la variabilidad, pero no eliminan el sesgo de la topología ni hacen que un dispositivo no sea representativo.

Terminal

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

Leer rendimiento, latencia, CPU y memoria juntos

p95 es una duración por debajo de la cual se completan 95% de solicitudes muestreadas. En k6, http_req_duration excluye fases como la búsqueda DNS y el establecimiento de la conexión inicial. Nombra la métrica en lugar de llamarla velocidad.

Calcule el trabajo del grupo CPU por respuesta correcta por separado en la ventana medida: el delta CPU del grupo dividido por las respuestas validadas. HTTP p95 no es consumo de CPU. Registre la memoria de grupo y el PSS del árbol de procesos con el método indicado. Invalide una ventana que contenga contenido incorrecto antes de comparar el rendimiento.

Agregar un recorrido del navegador

Un cliente puede recibir HTML rápidamente y aún esperar a que se hidrate. Mida la navegación, la navegación hacia atrás y la interacción comercial por separado. Comprobar que contadores, sesiones o estado de forma se mantienen correctos durante todo el recorrido.

En nuestra comparación de VPS, las ganancias del servidor no se traducen en ganancias en todas las mediciones del navegador. Publicar esas diferencias hace que la evaluación sea más útil. Mantenga el protocolo, la salida bruta y las limitaciones junto con los gráficos.

Lea nuestra campaña SSR y navegación en dos máquinas VPS