👨🏼‍💻

khriztianmoreno's Blog

Inicio Etiquetas Acerca |

Posts with tag devtools

El stack web que no puedes ignorar en 2026

2025-12-26
web-performanceidentitypwaaidevtoolsprogrammingweb-developmentdiscuss

Después de revisar roadmaps, specs, charlas del Chrome Dev Summit y señales reales en producción, mi predicción es simple:El desarrollo web en 2026 se moverá hacia más capacidades nativas, menos JavaScript innecesario y performance medible en el mundo real.Esto no es una lista de “herramientas cool”. Estas son las áreas que se vuelven no negociables.1. Performance (Core Web Vitals + Soft Navigation)Si solo vas a arreglar una cosa, arregla esta. Performance es la prioridad. Sin discusión.Por qué será vital en 2026Google está apostando por la experiencia real del usuario, no por benchmarks sintéticos. Soft Navigation también cambia cómo se evalúan las SPAs modernas (y las apps “tipo MPA”).En 2026:Si no mejoras INP y LCP, no solo “pierdes SEO” — pierdes conversiones.Si no mides bien las soft navigations, vas a enviar rutas “más rápidas” con métricas falsas.Qué cambiaCLS deja de ser “cosmético”.INP reemplaza por completo la mentalidad de “FID”.El performance de una SPA se juzga como una MPA.Qué debes dominarweb-vitals en producciónLong tasks (y qué los provoca)Heurísticas de soft navigationRUM > LighthouseRecursosWeb VitalsSoft NavigationCrUX2. Identity: Passkeys + FedCMEl login tradicional se está muriendo. Solo que todavía no se ha enterado.Por qué será vital en 2026Las contraseñas son una responsabilidad técnica y legal. Las passkeys reducen fricción y fraude. Y FedCM es la respuesta real del navegador a la identidad en un mundo sin third‑party cookies.En 2026:Un producto sin passkeys se percibirá como obsoleto.El “OAuth clásico” sin FedCM se va a degradar (o romper) en flujos que a los usuarios sí les importan.Qué cambiaLo passwordless se vuelve normal.La UI de login nativa del navegador se vuelve la expectativa.Menos JS. Más plataforma.Qué debes dominarWebAuthnPatrones de UX para passkeysFlujos de FedCMIdentity privacy‑preserving por defectoRecursosFedCMPasskeysWebAuthn3. Fugu / PWA APIsLa web ya habla con el hardware. El debate se acabó — lo que queda es ejecución.Por qué será vital en 2026Las apps web compiten directo con nativas cuando la brecha de capacidades es pequeña. Y los navegadores siguen entregando APIs basadas en estándares: menos dependencias, menos “pegamento”.En 2026:WebUSB, File System Access y Badging dejan de ser “raros”.Las PWAs se sienten cada vez más como apps de primera clase cuando el caso de uso lo amerita.Qué cambiaOffline realIntegración más profunda con el OSUX más rápida sin wrappers nativosQué debes dominarFile System Access APIBackground SyncBadging APIHeurísticas de instalación (PWA)RecursosWeb capabilitiesProgressive Web Apps4. AI for Web Developers (Built-in AI APIs)La IA deja de ser “solo un SaaS”. Pasa a ser parte del navegador.Por qué será vital en 2026Menos latencia. Más privacidad (porque lo local se vuelve el default). Y mejor UX sin obligar a cada producto a construir un backend de IA costoso.Esto no es “embeber ChatGPT”. Esto es IA nativa, con progressive enhancement.En 2026:On-device AI se vuelve el default cuando esté disponible.La UX impulsada por IA se vuelve un diferenciador real.Qué cambiaModelos más pequeños y rápidos corriendo localmenteMenos llamadas externasPatrones de UI que se adaptan al contextoQué debes dominarRestricciones de inferencia on-device (y fallbacks)Patrones de UX con IA (asistiva, no invasiva)IA privacy-firstProgressive enhancement con IARecursosAI in Chrome5. DevTools & Browser AutomationEl debugging tradicional no escala.Por qué será vital en 2026Las apps se vuelven más complejas. Los problemas de performance se vuelven más sutiles. Y el testing manual simplemente no es viable si quieres velocidad y calidad.En 2026:La observabilidad desde DevTools se vuelve un hábito diario.La automatización se vuelve parte del flujo, no una “fase de QA”.Qué cambiaDevTools más inteligentesTesting más integradoDebugging centrado en UX realQué debes dominarFlujos avanzados del panel de PerformanceLighthouse CIPuppeteer / PlaywrightTracing y profiling profundoRecursosChrome DevToolsLighthouseMi predicción final (sin marketing)Si tuviera que apostar por una sola base:Performance + Identity serán el fundamento. Todo lo demás se apoya encima de eso.La web en 2026 será:Más nativaMás rápidaMás privadaMenos dependiente de la “magia del framework”El resto es ruido.¡Espero que esto haya sido útil y/o te haya hecho aprender algo nuevo!Profile@khriztianmoreno 🚀Hasta la próxima

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

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 �