Perfila un recorrido de cliente antes de cambiar código
Elige una ruta e interacción importantes, como abrir la navegación, filtrar resultados o enviar un formulario. Grábala en el panel Performance de Chrome DevTools desde un estado de navegador limpio. Repite la acción y captura una ejecución con CPU restringida así como una en máquina de desarrollo; los trazas de escritorio pueden ocultar trabajo que resulta disruptivo en un teléfono de baja potencia.
Usa el traza para probar una hipótesis concreta, no para culpar a un componente a partir de un informe de bundle. En el gráfico de llamas Main, las barras más anchas duran más y las barras apiladas muestran la pila de llamadas. Un triángulo rojo en una tarea identifica una posible tarea larga; selecciónala y sigue el enlace al código que la inició. Guarda trazas de antes y después para cambios significativos.
Graba justo antes de la acción y detén después del resultado visible.
Mantén consistente la ruta, el estado de la cuenta y la secuencia de acciones.
Asigna cada coste principal al equipo o proveedor capaz de cambiarlo.
Lee el traza como una cola de trabajo
Una tarea larga es un umbral para investigar, no un diagnóstico completo. La especificación W3C Long Tasks informa sobre tareas que duran 50 milisegundos o más. Mira debajo de una tarea para ver evaluación de JavaScript, un manejador de eventos, recálculo de estilos, layout o paint. La pila de llamadas indica por dónde empezar; los tiempos muestran si el problema es código, renderizado o un frame de terceros.
Prioriza el coste que se repite durante una interacción valiosa. Un manejador corto todavía puede parecer lento cuando desencadena layout o espera detrás de trabajo anterior. El traza es una medición de laboratorio, así que confirma la corrección en dispositivos representativos y, cuando esté disponible, con telemetría de campo respetuosa con la privacidad.
El análisis del código durante el arranque requiere una solución distinta de la de un controlador de eventos activado después de un toque.
Encuentra patrones repetidos de escritura de estilos y lectura de layout antes de refactorizar.
Adjunta el traza, el escenario y los costes principales al elemento de trabajo.
Entrega menos código cuando importa
Haz inventario de scripts por ruta y propósito. Elimina paquetes no usados, duplicados, experimentos retirados y código de funcionalidades terminadas. Luego separa las características específicas de ruta o poco usadas para que se carguen cuando sean necesarias en lugar de en la ruta inicial. La carga dinámica puede reducir el trabajo de arranque, pero puede crear un retardo visible cuando el usuario necesita la función de inmediato.
Pregúntate si un componente necesita un framework completo en el cliente, si una utilidad duplica una capacidad existente o si bastan HTML estático y una pequeña mejora. Prueba el estado alternativo de un módulo que se carga con retraso. La página debe permitir aplazar una funcionalidad opcional sin degradar la experiencia, en lugar de mostrar un control inoperante.
Documenta qué scripts están permitidos en una ruta y por qué.
Considera esto para editores opcionales, mapas, reproductores o vistas de informes.
Prueba autenticación, accesibilidad, pagos y completado de formularios; busca revisión cualificada cuando los controles se vean afectados.
Divide el trabajo para que el navegador pueda responder
Dividir el código en funciones más pequeñas no crea tareas independientes del navegador si se ejecutan de forma síncrona. Para un bucle largo, procesa el trabajo por lotes, actualiza de inmediato el estado visible para el usuario y cede el control antes de continuar. Así el navegador puede procesar la entrada y el renderizado entre lotes.
Donde esté soportado, scheduler.yield() cede al hilo principal y luego continúa el trabajo; detecta la característica y usa una alternativa para navegadores no soportados. No cedas después de cada operación mínima: tiene sobrecoste y puede aumentar el tiempo de finalización. Elige límites a partir de mediciones, preserva la cancelación y evita que resultados obsoletos reemplacen estado más reciente.
Muestra aceptación o progreso antes de trabajo de seguimiento no visible.
Cede antes de que el trabajo medido se vuelva largo, en vez de hacerlo por cada ítem.
La guía actual de web.dev no recomienda una nueva estrategia basada en isInputPending().
Mueve el cálculo, no la interfaz, a un worker
Un Web Worker ejecuta un script en un hilo de fondo separado del hilo principal de ejecución. Es adecuado para parseo costoso, transformación de datos, indexado de búsqueda y otros cálculos que no necesitan acceso directo a la interfaz. Envía una entrada definida, devuelve un resultado definido y deja el renderizado y cambios visibles en el hilo principal.
Los workers no son universales. No pueden manipular directamente el DOM ni usar Window, y la comunicación por mensajes copia datos. La creación de workers, el movimiento de datos y la coordinación de errores pueden superar una pequeña operación. Mide la interacción completa, termina workers innecesarios y diseña una alternativa si el trabajo del worker falla.
Empieza con un cálculo cuyo entrada y salida puedan serializarse y probarse.
Descarta resultados creados para un filtro, ruta o acción anterior.
Comunica progreso significativo mediante la interfaz habitual.
Gobierna el JavaScript de terceros como una dependencia de producción
Analytics, publicidad, experimentos, embeds sociales, reproductores de vídeo y widgets de soporte pueden añadir peticiones, evaluación de JavaScript, iframes y dependencias. Un script de proveedor puede ser necesario, pero está fuera del control directo del equipo de la aplicación y puede afectar rendimiento, privacidad, seguridad y continuidad. Haz inventario de su propósito, rutas, condición de carga, aprobador, requisito de consentimiento y responsable de eliminación.
Cuando las condiciones y los contratos lo permitan, compara una página representativa con y sin un origen de terceros. Las herramientas de rendimiento pueden revelar evaluaciones costosas, cargas útiles y atribución de tareas largas. Conserva una integración ligera o cargada de forma diferida solo cuando su valor documentado justifique el coste medido. Comprueba que el contenido principal y la transacción primaria sigan funcionando cuando una dependencia opcional sea lenta o no esté disponible.
Carga una etiqueta solo en rutas y condiciones que la necesiten.
Incluye cambios en el tag manager en la revisión de rendimiento, privacidad, seguridad y reversión.
Documenta y prueba cómo desactivar una integración no crítica.
Haz de la capacidad de respuesta una salvaguarda de lanzamiento
Convierte la traza de referencia en una pequeña comprobación de regresión para el recorrido importante. Define las interacciones cubiertas, el dispositivo o la restricción de CPU, la respuesta esperada y quién la revisará. Combínala con una revisión de los paquetes de código y del inventario de terceros para que un paquete o etiqueta nuevos no puedan reintroducir silenciosamente trabajo en el hilo principal.
Status Is UP usa esta evidencia para optimización proactiva y remediación segura, no para reemplazar la monitorización de disponibilidad en vivo. Antes de un cambio de alto riesgo, prepara la reversión y verifica el flujo crítico tras el despliegue. Los resultados varían según dispositivo, red, navegador, contenido y estado de cuenta; trata los umbrales como protecciones, no como garantías.
Requiere trazas de antes y después para navegación compartida, checkout, búsqueda o bundles grandes.
Conoce el feature flag, la configuración de la etiqueta o la versión de despliegue que restaura el comportamiento conocido como bueno.
Vuelve a perfilar después de lanzamientos mayores, cambios de proveedores o variaciones en la mezcla de dispositivos.