👨🏼‍💻

khriztianmoreno's Blog

Inicio Etiquetas Acerca |

Posts with tag chrome-devtools

Dominando Chrome DevTools para la Optimización del Rendimiento Web

2025-11-17
performancedevtoolschromechrome-devtools

Convierte Chrome DevTools de un simple visor a un arma de depuración de rendimiento.La mayoría de los equipos abren DevTools demasiado tarde. O miran los paneles equivocados, ahogándose en ruido mientras pasan por alto las señales que realmente afectan la experiencia del usuario.Si eres un ingeniero frontend senior o responsable de rendimiento, sabes que "se siente lento" no es un reporte de error, es un síntoma. Esta guía es para aquellos que necesitan diagnosticar ese síntoma, entender la causa raíz y verificar la solución.Nos enfocaremos en las características de Chrome DevTools que se relacionan directamente con las Core Web Vitals. Sin rodeos, solo los flujos de trabajo que necesitas para arreglar Interaction to Next Paint (INP), Largest Contentful Paint (LCP) y Cumulative Layout Shift (CLS).1. Modelo mental: del síntoma a la causa raízAntes de hacer clic en nada, necesitas el modelo mental correcto. Las métricas te dicen qué está mal. DevTools explica por qué.El rendimiento no se trata de números mágicos; se trata del Hilo Principal (Main Thread). El hilo principal del navegador es donde se ejecuta JavaScript, se analiza el HTML y se calculan los estilos. Es una autopista de un solo carril. Si un camión pesado (una tarea larga) bloquea el carril, los autos rápidos (clics del usuario, animaciones) quedan atrapados en el tráfico.Regla Clave: Si el hilo principal está bloqueado, la UX está rota.2. Panel de Rendimiento: el centro de la verdadEl panel de Rendimiento (Performance) te permite grabar exactamente lo que el navegador está haciendo durante un período de tiempo. Registra:Actividad del hilo principal: Ejecución de JS, análisis, Garbage Collection (GC).Pipeline de renderizado: Cálculo de estilos, Diseño (Layout), Pintura (Paint), Composición.Tiempos de red: Cuándo se solicitan y reciben los recursos en relación con la ejecución.Manejo de entrada del usuario: Cuánto tardó el navegador en responder a un clic.Grabando una traza útilLas trazas en reposo son inútiles. Necesitas trazas de interacción.Abre DevTools (Cmd+Option+I / Ctrl+Shift+I) y ve a la pestaña Performance.Marca Screenshots y Web Vitals en la configuración de captura. La memoria suele ser opcional a menos que sospeches una fuga.Haz clic en el botón Record (icono circular).Interactúa con la página (haz clic en el botón, desplázate por la lista, abre el modal).Haz clic en Stop.3. Leyendo la línea de tiempo de RendimientoLa traza resultante puede ser intimidante. Ignora el 90% inicialmente. Concéntrate en estas secciones:FPS & CPU: Chequeo de salud de alto nivel. Bloques sólidos de color en la CPU significan que el hilo principal está ocupado.Network: Líneas finas que muestran el orden de carga de recursos.Main: El gráfico de llama (flame chart) de las pilas de llamadas. Aquí es donde pasarás la mayor parte de tu tiempo.Frames: Capturas de pantalla de lo que el usuario vio en ese milisegundo.La Pista de Experiencia (Experience Track)Este es tu mejor amigo. Marca explícitamente:LCP: Dónde ocurrió el Largest Contentful Paint.Layout Shifts: Diamantes rojos indicando CLS.Long Tasks: Tareas que toman >50ms (triángulos rojos).Detectando Tareas Largas (Long Tasks)Una "Tarea Larga" es cualquier tarea que mantiene ocupado el hilo principal por más de 50ms. En la sección Main, busca barras grises con triángulos rojos en la esquina superior. Estas son las tareas que bloquean al navegador de responder a la entrada del usuario (INP).4. Depurando LCP con DevToolsLCP mide el rendimiento de carga. Para arreglarlo, necesitas saber qué es el elemento y por qué llegó tarde.Identifica el elemento LCP: En la pista Timings o Experience, encuentra el marcador LCP.Inspecciona el elemento: Al pasar el cursor sobre el marcador LCP a menudo se resalta el nodo DOM real.Analiza el retraso:Resource Load Delay: ¿Se descubrió la imagen tarde? (ej. imagen hero con lazy-load).Resource Load Duration: ¿La red estaba lenta o la imagen era demasiado grande?Render Delay: ¿La imagen estaba cargada pero esperando a que una tarea del hilo principal terminara para pintarse?Causas raíz típicas de LCP:Descubrimiento tardío: La etiqueta <img> es generada por JavaScript o tiene loading="lazy".Bloqueo de renderizado: Bundles de CSS enormes o JS síncrono en el <head> pausando el parser.TTFB del servidor: El backend tardó demasiado en enviar el HTML inicial.<!-- ❌ Mal: Carga diferida (lazy) del elemento LCP (ej. Imagen Hero) --> <img src="hero.jpg" loading="lazy" alt="Hero Image" /> <!-- ✅ Bien: Carga impaciente (eager) + fetchpriority --> <img src="hero.jpg" loading="eager" fetchpriority="high" alt="Hero Image" />Referencia: Optimizar el Largest Contentful Paint5. Depurando INP con DevToolsINP es la métrica que mata a las aplicaciones de una sola página (SPAs). Mide la latencia de las interacciones del usuario.Usa la pista de Interacciones: Busca la interacción específica (clic, pulsación de tecla) que grabaste.Expande la Interacción: Verás que se desglosa en tres fases:Input Delay: Tiempo esperando a que el hilo principal se libere.Processing Time: Tiempo ejecutando tus manejadores de eventos.Presentation Delay: Tiempo esperando a que el navegador pinte el siguiente frame.Correlaciona visualmente con el Hilo Principal: Haz clic en la barra de interacción. Mira directamente debajo en la pista Main.Si ves un bloque amarillo masivo de JavaScript debajo de la interacción, tu manejador de eventos es demasiado lento (Processing Time).Si ves un bloque masivo de JS antes de que comience la interacción, el hilo principal estaba ocupado haciendo otra cosa (Input Delay).Culpables comunes:Parseo de JSON de cargas grandes.Reconciliación de React/Vue (renderizar demasiados componentes).Bucles síncronos o cálculos costosos.// ❌ Mal: Bloquear el hilo principal con trabajo pesado button.addEventListener("click", () => { const result = heavyCalculation(); // Bloquea por 200ms updateUI(result); }); // ✅ Bien: Ceder el control al hilo principal button.addEventListener("click", async () => { showSpinner(); // Ceder al hilo principal para que el navegador pueda pintar el spinner await new Promise((resolve) => setTimeout(resolve, 0)); const result = heavyCalculation(); updateUI(result); });Flujo de trabajo de corrección: Identifica la función en el gráfico de llama → Optimízala o difiérela → Graba de nuevo → Verifica que el bloque sea más pequeño.Referencia: Interaction to Next Paint (INP)6. Depurando CLS con DevToolsLos cambios de diseño (layout shifts) son molestos y confusos. DevTools los visualiza claramente.Abre el Menú de Comandos (Cmd+Shift+P / Ctrl+Shift+P) y escribe "Rendering".Habilita "Layout Shift Regions".A medida que interactúas con la página, los elementos desplazados parpadearán en azul.En la Traza de Rendimiento: Mira la pista Experience en busca de diamantes rojos. Haz clic en uno. La pestaña Summary en la parte inferior listará exactamente qué nodos se movieron y sus coordenadas anteriores/actuales.Patrones comunes de CLS:Cambios de fuente (FOUT/FOIT): El texto se renderiza, luego la fuente web carga, cambiando el tamaño.Redimensionamiento de imagen: Imágenes sin atributos width y height.UI inyectada tarde: Banners o anuncios insertándose en la parte superior del contenido./* ❌ Mal: Sin espacio reservado para la imagen */ img.hero { width: 100%; height: auto; } /* ✅ Bien: Reservar espacio con aspect-ratio */ img.hero { width: 100%; height: auto; aspect-ratio: 16 / 9; }Referencia: Optimizar el Cumulative Layout Shift7. Pantalla de Live MetricsLa vista Live Metrics (en la barra lateral del panel de Rendimiento o página de inicio) proporciona retroalimentación en tiempo real sin una traza completa.Por qué importa:Retroalimentación instantánea: Ve los valores de LCP y CLS actualizarse mientras redimensionas la ventana o navegas.Alineado con el campo: Utiliza la misma implementación que la extensión Web Vitals.Casos de uso:Probar estados hover e interacciones pequeñas.Validar transiciones de ruta en SPAs.Comprobaciones rápidas de cordura antes de hacer commit del código.Nota: Esto sigue siendo "Datos de Laboratorio" corriendo en tu máquina, no datos reales de usuarios (CrUX).8. Panel de InsightsEl panel Performance Insights es una capa de análisis automatizado experimental pero poderosa. Utiliza los datos de la traza para resaltar riesgos automáticamente.Características clave:Culpables de Layout Shift: Apunta directamente a la animación o actualización del DOM que causó un cambio.Solicitudes que bloquean el renderizado: Identifica CSS/JS que retrasaron el First Contentful Paint.Tareas largas del hilo principal: Sugerencias sobre cómo dividirlas.Usa Insights como una pista, no un veredicto. Te apunta al lugar correcto en el gráfico de llama, pero aún necesitas interpretar el código.9. Throttling de CPU y Red (Obligatorio)Desarrollar en una MacBook Pro con internet de fibra es una mentira. Tus usuarios están en dispositivos Android de gama media con 4G irregular.Throttling de CPU:Configúralo a 4x slowdown. Esto simula aproximadamente un dispositivo Android de gama media.Expone "muerte por mil cortes": scripts pequeños que se sienten instantáneos en escritorio pero congelan un teléfono por 300ms.Throttling de Red: Fast 4G o Slow 4G. Crítico para depurar LCP (tiempos de carga de imagen) y comportamiento de carga de fuentes.El Wi-Fi rápido oculta una mala ingeniería. Siempre aplica throttling al probar rendimiento.10. Poniéndolo todo junto: un flujo de trabajo repetibleDetectar: Usa PageSpeed Insights o CrUX para identificar qué métrica está fallando.Reproducir: Abre DevTools, habilita Throttling (CPU 4x, Network 4G).Grabar: Inicia la traza, realiza la acción del usuario, detén la traza.Inspeccionar: Encuentra los marcadores rojos/amarillos en las pistas Experience/Main.Arreglar: Aplica el cambio de código (diferir JS, optimizar imágenes, reducir profundidad del DOM).Verificar: Vuelve a grabar y compara la traza. ¿Desapareció la tarea larga? ¿Se movió el marcador LCP a la izquierda?ConclusiónDevTools no es opcional. El rendimiento es observable. Cada problema de Core Web Vitals deja un rastro; solo necesitas saber dónde buscar.Si no puedes explicar un problema de rendimiento en DevTools, aún no lo entiendes.Recursos:Documentación de Chrome DevToolsGuías de Rendimiento de web.devDocumentación de CWV en Google Search CentralEspero que esto haya sido útil y/o te haya enseñado algo nuevo.Profile@khriztianmorenoHasta la próxima

Optimizar para velocidad - Estrategias prácticas para mejorar tus Core Web Vitals

2025-11-04
performancecore-web-vitalsweb-vitalslcpinpclschrome-devtools

Las páginas pueden cargar rápido.Y aun así sentirse lentas.Esa es la trampa moderna del performance: shippeas un render inicial “snappy”, pero las interacciones se traban, la UI salta y la página pierde confianza. Core Web Vitals existen para exponer esa brecha—y se evalúan en el field, no en tu corrida local de Lighthouse.

Desmitificando Core Web Vitals - guía para desarrolladores sobre LCP, INP y CLS

2025-10-19
web-performancecore-web-vitalslighthouseweb-developmentcruxchromeperformancedevtoolschrome-devtools

Core Web Vitals son señales de ranking, pero la mayoría de los equipos todavía las optimiza como si fueran un score de laboratorio. Esta guía convierte CWV en trabajo de ingeniería accionable: cómo medir (field + lab), cómo depurar causas raíz en DevTools y qué arreglos realmente mueven el percentil 75.

Presentando Chrome DevTools MCP

2025-09-30
javascriptchromedevtoolsaimcpdebuggingperformancechrome-devtools

Participé en el programa de acceso anticipado (Early Access Program) de Chrome DevTools MCP y puse a prueba la funcionalidad en proyectos reales. Me enfoqué en cuatro escenarios: corregir un problema de estilos, ejecutar trazas de rendimiento y extraer insights, depurar una solicitud de red fallida y validar que los assets tengan encabezados de caché óptimos. En este post comparto esa experiencia práctica: qué funcionó, dónde brilla y cómo lo usaría en el día a día.Chrome DevTools MCP proporciona a los asistentes de codificación con IA visibilidad real en un navegador Chrome activo para que puedan inspeccionar, probar, medir y corregir problemas basados en señales reales, no en suposiciones. En la práctica, esto significa que tu agente puede abrir páginas, hacer clic, leer el DOM, recopilar trazas de rendimiento, analizar peticiones de red y perfeccionar soluciones en un ciclo cerrado.Por qué es importanteLa mayoría de los agentes de codificación son ciegos. Proponen código, pero no pueden ver la UI renderizada, la consola, las cascadas de red o los problemas de layout thrashing. Chrome DevTools MCP elimina esa venda conectando cualquier cliente AI habilitado para MCP (por ejemplo, Cursor, Claude Code, Gemini CLI) a una instancia local de Chrome con superpoderes a nivel de DevTools. El resultado es un flujo de trabajo donde el agente puede implementar un cambio, ejecutarlo en Chrome, observar el resultado y refinarlo.Introducción rápida: ¿Qué es MCP?MCP (Model Context Protocol) es un estándar abierto (de Anthropic) que define cómo los asistentes de IA se conectan a herramientas y fuentes de datos mediante una interfaz consistente. Un servidor MCP expone "herramientas" (capacidades). Un cliente MCP (tu asistente de IA) llama a esas herramientas. Chrome DevTools MCP es un servidor MCP que conecta un asistente de IA con DevTools de Chrome y su superficie de automatización.Puppeteer para confiabilidad: El servidor MCP utiliza Puppeteer para manejar la navegación, esperar a selectores, inactividad de red, diálogos, etc. Obtienes un control del navegador robusto y de nivel de producción en lugar de los peligros del CDP puro.Capa de herramientas MCP: El servidor expone herramientas de alto nivel (por ejemplo, navigate_page, click, performance_start_trace) a través de MCP. Tu AI llama a una herramienta; el servidor traduce eso en automatización de Chrome confiable y devuelve resultados estructurados.Chrome local y aislado: Se ejecuta localmente con un directorio de datos de usuario separado o perfiles efímeros completamente aislados. Puedes adjuntarte a un Chrome existente o iniciar una nueva instancia, en modo headless o visible.Capacidades clave (herramientas seleccionadas)Navegación y ciclo de vida: new_page, navigate_page, wait_for, avance/retroceso, listar páginas abiertas.Interacción de usuario: click, fill, fill_form, hover, drag, handle_dialog, upload_file.DOM y scripting: evaluate_script, take_snapshot, take_screenshot, list_console_messages.Red: list_network_requests, get_network_request para introspección de solicitudes/respuestas.Emulación: emulate_cpu, emulate_network, resize_page para restricciones de dispositivo/red.Rendimiento: performance_start_trace, performance_stop_trace, performance_analyze_insight para extraer métricas como LCP y TBT de trazas reales.Estas son primitivas a nivel de DevTools: puedes reproducir flujos de usuario reales y obtener la misma fidelidad que tendrías al depurar manualmente en Chrome.Flujos de trabajo prácticos que utilizaría en proyectos realesA continuación se presentan flujos probados en batalla que entregaría a un asistente de IA cuando trabajo en aplicaciones frontend a escala.1) Verificar una corrección de UI de extremo a extremoAplicar el parche (PR del agente o cambio local).navigate_page a la URL de vista previa.click o fill para reproducir la ruta del error.take_screenshot del estado roto para la línea base.Aplicar la corrección; recargar; repetir pasos 2–4.Comparar capturas de pantalla y list_console_messages para regresiones.Por qué es útil: reemplaza las pruebas manuales con un bucle determinista que el agente puede ejecutar repetidamente en diferentes páginas y puntos de interrupción.2) Detectar y explicar errores de ejecución rápidamentenavigate_page a la ruta fallida.list_console_messages y evaluate_script para inspeccionar el estado.list_network_requests + get_network_request para confirmar el estado del backend, payload, CORS y tiempos.Proponer corrección con contexto (marcos de pila, respuestas erróneas, encabezados mal configurados).Por qué es útil: tu agente deja de adivinar—los errores están fundamentados en la actividad real de la consola y la red.3) Reproducir recorridos críticos de usuario antes de implementarnew_page a staging.fill_form para iniciar sesión, click CTA, navegar por el checkout.take_screenshot en cada paso para aceptación visual.emulate_network 3G-lento y volver a intentar el flujo para la resiliencia.Por qué es útil: ejecuciones E2E realistas y repetibles que puedes adjuntar a los PRs.4) Depuración de estilos y layout en la que puedes confiartake_snapshot y evaluate_script para extraer estilos computados para un componente problemático.Aplicar parche de estilo; take_screenshot en múltiples tamaños de viewport mediante resize_page.Validar riesgo de CLS y problemas de desbordamiento.Por qué es útil: previene el "funciona en mi máquina" al basarse en el renderizado real.5) Triaje de rendimiento sin salir de tu editor performance_stop_trace + performance_analyze_insight para extraer señales y bloqueadores de LCP/TBT/CLS.Recomendar optimizaciones específicas (por ejemplo, precarga de imágenes, división de código basada en rutas, eliminar tareas largas, diferir la hidratación no crítica).Por qué es útil: integra una auditoría estilo Lighthouse en tu ciclo de agente con especificidad basada en trazas.Patrones avanzados para equipos seniorArnés de regresión: Codifica los recorridos principales (inicio de sesión, búsqueda, checkout) como secuencias MCP. Ejecuta en cada PR con capturas de pantalla + registros de consola/red adjuntos a los artefactos de CI.Presupuestos de rendimiento: Falla CI si performance_analyze_insight excede los presupuestos para LCP/TBT; incluye trazas como evidencia.Contratos de red: Usa get_network_request para validar esquemas y encabezados de caché; marca sorpresas (por ejemplo, falta de cache-control, JSON sobredimensionado o sobre-fetching).Verificaciones de accesibilidad: Combina evaluate_script para consultar heurísticas de ARIA y contraste; captura screenshots para diferencias visuales.Seguridad y restricciones a tener en cuentaTrata al navegador automatizado como un perfil separado. Evita navegar a sesiones de producción sensibles con sesión iniciada.Prefiere perfiles efímeros/aislados para ejecuciones reproducibles.Sé explícito sobre los datos de prueba y los entornos para prevenir efectos secundarios en sistemas reales.Primeros pasos (nivel alto)El repositorio documenta los detalles de instalación y configuración. A alto nivel:Instala el servidor Chrome DevTools MCP (paquete de Node.js).Configura tu cliente habilitado para MCP (Cursor, Claude Code, Gemini CLI) para registrar el servidor DevTools MCP.Inicia tu cliente; generará/se conectará a una instancia de Chrome cuando se invoquen herramientas.Llama a herramientas desde la interfaz del cliente o mediante prompts (por ejemplo, “abrir página, hacer clic en botón, recopilar traza de rendimiento”).Ejemplo de llamadas a herramientas MCP que podrías orquestar en una sesión:navigate_page -> wait_for(selector) -> click(selector) -> list_console_messages -> take_screenshot -> performance_start_trace -> trigger_interaction -> performance_stop_trace -> performance_analyze_insightConsulta la documentación oficial y el repositorio para obtener la lista más reciente de herramientas, flags y opciones de configuración.Cuándo recurrir a estoSi ya te apoyas en un asistente de IA para cambios de código, agrega DevTools MCP siempre que la corrección deba fundamentarse en el navegador: correcciones visuales/UI, interacciones inestables, depuración de tiempo de ejecución y red, y cualquier cosa relacionada con el rendimiento.ReferenciasAnuncio y documentación de Chrome DevTools MCPDescripción general del Model Context Protocol (MCP)Puppeteer y Chrome DevTools Protocol (CDP)¡Espero que esto haya sido útil y/o te haya enseñado algo nuevo!Profile@khriztianmoreno �