Lista de Verificación de Auditoría de Rendimiento — Revisión sistemática de 30 puntos con cumplimiento de CI

Receta

# Ejecuta una auditoría de rendimiento completa en 3 pasos:
 
# 1. Comprobaciones automatizadas (CI/CD)
#    - Análisis de paquete: ANALYZE=true npm run build
#    - Lighthouse CI: lhci autorun
#    - TypeScript + ESLint: npm run lint && npm run type-check
 
# 2. Comprobaciones manuales (Desarrollador)
#    - React DevTools Profiler: Registra interacciones, revisa el gráfico de llamas
#    - Chrome Memory tab: Snapshots de heap antes/después de navegación
#    - Core Web Vitals: Auditoría de Lighthouse en URL de producción
 
# 3. Monitoreo (Producción)
#    - web-vitals library: Métricas de usuario real a análisis
#    - Error tracking: Sentry, Datadog, o New Relic
#    - Bundle size tracking: Compara contra presupuesto en cada PR

Cuándo usarlo: Antes de cada lanzamiento importante, trimestralmente para aplicaciones establecidas, y cuando los usuarios reportan problemas de rendimiento. Usa el flujo de trabajo de CI para detectar regresiones automáticamente en cada solicitud de incorporación.

Ejemplo de Funcionamiento

# .github/workflows/performance.yml — GitHub Actions con puertas de rendimiento
 
name: Performance Audit
 
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]
 
jobs:
  bundle-analysis:
    name: Bundle Size Check
    runs-on

// lighthouserc.json — Configuración de Lighthouse CI con presupuestos de rendimiento
{
  "ci": {
    "collect": {
      "startServerCommand": "npm start",
      "startServerReadyPattern": "ready on",
      "url": [
        "http://localhost:3000/",
        "http://localhost:3000/products",
        "http://localhost:3000/dashboard"
      ],
      "numberOfRuns": 

// scripts/perf-audit.ts — Script de auditoría manual
import { execSync } from "child_process";
 
interface AuditItem {
  id: string;
  category: string;
  severity: "CRITICAL" | "HIGH" | "MEDIUM";
  description: string;

Lo que esto demuestra:

• 30 elementos de auditoría en 6 categorías con clasificaciones de severidad
• Comprobaciones automatizadas de CI: tamaño de paquete, puntuaciones de Lighthouse, TypeScript, ESLint
• Comprobaciones manuales: Profiler, snapshots de memoria, revisión de skeleton
• Flujo de trabajo de GitHub Actions que bloquea PRs que fallan presupuestos de rendimiento
• Lighthouse CI con umbrales numéricos específicos para cada métrica

Exploración Profunda

Cómo Funciona

• Presupuestos de paquete establecen tamaños máximos para paquetes de JavaScript. El flujo de trabajo de CI mide el paquete del cliente después de la construcción y falla si excede el umbral. Las páginas de landing deben orientarse a menos de 150KB comprimido; páginas de app menos de 300KB comprimido.
• Lighthouse CI ejecuta Lighthouse en un entorno de CI, recopilando puntuaciones de rendimiento en múltiples URLs con múltiples ejecuciones para confiabilidad estadística. Las aserciones imponen puntuaciones mínimas y valores máximos de métricas.
• Niveles de severidad priorizan elementos de auditoría. Los elementos CRITICAL causan problemas de rendimiento inmediatamente visibles para el usuario. Los elementos HIGH causan degradación medible. Los elementos MEDIUM son mejores prácticas que previenen problemas futuros.
• Comprobaciones automatizadas vs manuales — Algunos elementos (tamaño de paquete, escaneo de dependencias, reglas de lint) pueden ser completamente automatizados. Otros (análisis de Profiler, detección de fugas de memoria, coincidencia de layout skeleton) requieren criterio humano.

Variaciones

Lista de verificación rápida de 10 puntos para cada revisión de PR:

## Lista de Verificación de Rendimiento de PR
 
- [ ] Sin nuevo "use client" sin justificación
- [ ] Imágenes usan next/image con dimensiones
- [ ] Sin nuevas cascadas de fetches (paralelo con Promise.all)
- [ ] Importaciones dinámicas para componentes mayores a 30KB
- [ ] Hooks useEffect tienen funciones de limpieza
- [ ] Sin objetos inline o funciones pasadas a componentes memoizados
- [ ] Nuevos fetches de datos tienen estrategia de caché (revalidate, tags)
- [ ] Sin dependencias prohibidas (moment, lodash, axios)
- [ ] Suspense boundaries alrededor de secciones asincrónicas
-

Presupuesto de paquete en next.config.ts:

// next.config.ts — Límites de paquete a nivel de Webpack
const nextConfig = {
  experimental: {
    webpackBuildWorker: true,
  },
  webpack: (config, { isServer }) => {
    if (!isServer) {
      config.performance = {
        maxAssetSize: 300 *

Integración de Vercel Speed Insights:

// app/layout.tsx
import { SpeedInsights } from "@vercel/speed-insights/next";
import { Analytics } from "@vercel/analytics/react";
 
export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <

Notas de TypeScript

• Los tipos de script de auditoría se definen con la interfaz AuditItem para consistencia.
• La configuración de Lighthouse CI es JSON, no TypeScript, pero puede validarse con tipos de @lhci/cli.
• La librería web-vitals proporciona tipos de TypeScript para todos los objetos de métrica.

Trampas

• Las puntuaciones de Lighthouse CI varían entre ejecuciones — Las condiciones de red, la carga de CPU y el rendimiento del contenedor afectan los resultados. Solución: Ejecuta al menos 3 iteraciones (numberOfRuns: 3) y usa puntuaciones medianas para aserciones.

• La comprobación de tamaño de paquete cuenta todos los chunks, no solo entrada — El total de JavaScript cliente incluye chunks compartidos, runtime de marco de trabajo y código específico de página. Una única página puede cargar solo un subconjunto. Solución: Mide el tamaño de paquete por ruta usando @next/bundle-analyzer treemap, no solo el tamaño total de .next/static/chunks.

• El rendimiento de CI difiere de producción — Los runners de CI son infraestructura compartida con rendimiento variable. Las puntuaciones de Lighthouse en CI pueden ser 10-20 puntos más bajas que en producción. Solución: Establece umbrales de CI ligeramente más bajos que objetivos de producción, y valida con mediciones reales de producción.

• Las comprobaciones automatizadas pierden problemas en tiempo de ejecución — El tamaño de paquete y Lighthouse detectan problemas de tiempo de carga pero pierden problemas de rendimiento en tiempo de ejecución como fugas de memoria, interacciones lentas y CLS acumulado. Solución: Complementa comprobaciones automatizadas con sesiones periódicas de análisis manual.

• Sobre-optimizar para la puntuación de Lighthouse — Técnicas como diferir la carga de todo para jugar con la puntuación pueden perjudicar la experiencia real del usuario. Solución: Prioriza métricas reales del usuario (CrUX, web-vitals) sobre puntuaciones de laboratorio.

Alternativas

FAQs

const nextConfig = {
  webpack: (config, { isServer }) => {
    if (!isServer) {
      config.performance = {
        maxAssetSize: 300 * 1024,
        maxEntrypointSize: 300 * 1024

interface AuditItem {
  id: string;
  category: string;
  severity: "CRITICAL" | "HIGH" | "MEDIUM";
  description: string;
  check: () => boolean |

// app/layout.tsx
import { SpeedInsights } from "@vercel/speed-insights/next";
 
export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en"

Relacionado

• Core Web Vitals — Optimización detallada para cada métrica de CWV
• Optimización de Paquete — Estrategias para cumplir presupuestos de tamaño de paquete
• Análisis de Rendimiento — Técnicas de análisis manual para el proceso de auditoría
• Fugas de Memoria — Técnicas de auditoría de memoria y uso de Chrome DevTools