Entrevista Frontend: ¿Cómo cargas scripts de terceros sin perjudicar el rendimiento?

Planteamiento y contexto

Una página de producto de comercio electrónico carga scripts de analítica, chat, publicidad y pruebas A/B. El LCP p75 de usuarios reales en dispositivos móviles es de 3.8 segundos y el INP es de 280 milisegundos; el JavaScript de terceros transfiere unos 1.2 MB desde 14 orígenes, mientras que las pruebas de laboratorio en escritorio se ven saludables. Debes preservar la funcionalidad de negocio necesaria mientras limitas los efectos de terceros en la red, el hilo principal, la privacidad y la disponibilidad de la página.

Aclara primero cuatro límites: qué scripts deben ejecutarse antes de la primera pantalla, cuáles se necesitan solo después de la interacción, si los scripts dependen del orden de otros, si los datos pueden enviarse antes del consentimiento y si una interrupción de un tercero puede bloquear el proceso de compra. El código de terceros es parte del entorno de ejecución de la página; no se puede tratar como un recurso estático ordinario que otro equipo posee para siempre.

Esto encaja en entrevistas de frontend, plataforma web e ingeniería de rendimiento. El material público de entrevistas frontend trata async, defer, el orden de los scripts y las compensaciones de rendimiento como fundamentos recurrentes; el material de web.dev, MDN y el W3C proporciona la base técnica para los tiempos de carga, las tareas largas, CSP y el control de fuentes. El núcleo de la pregunta es la gobernanza y la prueba, no memorizar un componente de un framework.

Qué evalúa el entrevistador

Una respuesta débil dice "agrega async en todas partes" o "coloca los scripts al final de la página". Una respuesta sólida inventaría los scripts por valor de usuario e impacto en la ruta crítica, luego elige async, defer, módulos, carga activada por interacción o una fachada de iframe basada en dependencias y límites de fallo.

El entrevistador busca cinco señales: si el candidato puede separar el tiempo de descarga del tiempo de ejecución; explicar el async desordenado frente al defer ordenado; combinar presupuestos de rendimiento, consentimiento, CSP/SRI y riesgo en la cadena de suministro; aislar un fallo de proveedor sin bloquear el pago; y usar RUM, datos de tareas largas y una comparación controlada para demostrar el cambio.

Una puntuación de Lighthouse por sí sola es insuficiente. Las condiciones de laboratorio no representan teléfonos de gama baja, redes lentas, bloqueadores de contenido o un servidor de proveedor que se detiene; la respuesta debe incluir percentiles de usuarios reales, tiempo de ejecución de scripts y tasa de finalización de negocio.

Preguntas aclaratorias para hacer primero

• ¿Qué scripts son realmente necesarios para el primer pintado o la primera interacción? Los pagos y las comprobaciones esenciales contra el fraude pueden ser críticos; el chat, las recomendaciones y la repetición de sesiones usualmente pueden esperar a la interacción o al tiempo de inactividad.
• ¿Los scripts dependen unos de otros? La analítica independiente puede usar async; el código de aplicación dependiente del DOM o del orden suele usar defer; las dependencias desconocidas no deben paralelizarse.
• ¿Qué está permitido antes del consentimiento? Define el propósito, la región y el estado de consentimiento antes de crear un script, cookie, solicitud de red o medición anónima.
• ¿A qué datos de la página puede acceder un proveedor? El código del mismo origen puede leer el contexto de la página; si un chat o un anuncio solo necesita renderizarse, prefiere un iframe o un evento del lado del servidor con una superficie de permisos más pequeña.
• ¿Cuál es la experiencia del usuario ante fallos? La compra, el inicio de sesión y la navegación necesitan rutas de origen propio (first-party); un tiempo de espera agotado del proveedor no debe hacer que un botón crítico o el hilo principal esperen indefinidamente.
• ¿Se puede reemplazar o alojar por cuenta propia (self-hosting) al proveedor? El autoalojamiento puede eliminar riesgos de DNS y de disponibilidad del proveedor, pero añade la responsabilidad sobre actualizaciones, integridad, licencias y caché; no es automáticamente más seguro.

Un marco de respuesta de 30 segundos

"Crearía un inventario que registre valor de negocio, dependencias, bytes, solicitudes, tiempo del hilo principal, propósito de los datos e impacto de fallos, y luego clasificaría cada script como crítico, diferido o eliminable. Los scripts independientes usan async; los dependientes del DOM o del orden usan defer; los widgets interactivos usan una fachada o iframe. No crearía rastreadores no esenciales antes del consentimiento. CSP permitiría solo orígenes revisados y los recursos fijos podrían usar SRI. Cada proveedor recibe presupuestos de bytes, tiempo de ejecución y errores. RUM compararía LCP, INP, tareas largas, conversión y errores de scripts por dispositivo y estado de consentimiento. Haría una prueba gradual (gray out) de eliminación o diferimiento primero, y luego usaría inyección de fallos y reversión para demostrar que la página sigue completando la tarea principal."

Respuesta paso a paso a profundidad

1. Construir el inventario y la ruta crítica

Registra el proveedor de cada script, versión, desencadenante, dependencias, orígenes de solicitudes, bytes de transferencia, tiempo de análisis sintáctico y ejecución, tareas largas, datos leídos, propietario y condición de eliminación. Expresa el valor como un resultado verificable, como "atribuir fallos en el checkout", no "mejorar la experiencia". Un script sin un propósito claro, propietario o métrica es un candidato para eliminación.

Dibuja el grafo de dependencias para el primer pintado y la primera interacción. Mantén en la ruta crítica solo el código de origen propio necesario para la pantalla inicial, inicio de sesión, carrito y pago. La analítica, el chat, las recomendaciones, la repetición de sesiones y las etiquetas de marketing a menudo pueden esperar hasta después del pintado o de una interacción explícita. La descarga asíncrona no elimina el costo de análisis, compilación o ejecución en el hilo principal.

2. Elegir la semántica de carga a partir de las dependencias

Un script clásico sin atributos bloquea el análisis sintáctico del HTML. async se descarga en paralelo y se ejecuta tan pronto como está listo, sin garantía de orden; se adapta a analíticas independientes o anuncios. defer también se descarga en paralelo pero se ejecuta después del análisis sintáctico en el orden del documento, lo cual se adapta al código que necesita el DOM u otro script. Los scripts de módulo se difieren de forma predeterminada, pero su grafo de dependencias aún necesita revisión.

Usa una tabla de decisiones:

No marques todos los scripts dependientes con async. Si plugin.js necesita a vendor.js, usa defer ordenado, importaciones de módulos o un cargador explícito en lugar de esperar a que los tiempos de descarga coincidan.

3. Diferir, recortar o reemplazar funcionalidad

Usa la interacción del usuario, requestIdleCallback con un tiempo límite de reserva (fallback), o una cola posterior al pintado para el trabajo no crítico. Un botón de chat puede ser una entrada estática de origen propio que crea el widget solo al hacer clic; un video puede mostrar una miniatura y un control de reproducción antes de incrustar un iframe. Esto reduce el trabajo en la red y en el hilo principal durante la primera pantalla y evita pagar por características que el usuario nunca usa.

Elimina administradores de etiquetas duplicados, SDKs de analítica y experimentos abandonados. Solicita a los proveedores compilaciones reducidas, paquetes específicos por página, compresión y almacenamiento en caché. El autoalojamiento puede reducir riesgos de DNS de terceros o disponibilidad, pero requiere actualizaciones de versión, SRI, licencias, invalidación de caché y reversión; no elimina el costo de ejecución.

4. Definir límites de privacidad, seguridad y fallos

Antes de que se conozca el consentimiento, no crees scripts de rastreo no esenciales ni los cargues para simplemente deshabilitar el envío después. Define si la retirada del consentimiento borra cookies, detiene colas y previene solicitudes posteriores. Restringe orígenes con la directiva CSP script-src y directivas de conexión relevantes; usa SRI para recursos externos de versión fija. Audita la carga dinámica, las dependencias cargadas por proveedores y strict-dynamic por separado en lugar de confiar únicamente en el primer dominio.

El código de terceros que se ejecuta en el mismo origen tiene una amplia superficie de permisos. Coloca componentes de solo renderizado en un iframe y envía los campos mínimos a través de postMessage. Mantén la compra, el inicio de sesión, la navegación y la recuperación de errores bajo control de origen propio; finaliza los tiempos de espera del proveedor con un timeout, un disyuntor (circuit breaker) o un elemento de reemplazo (placeholder) en lugar de bloquear el flujo central.

5. Establecer presupuestos y monitorear

Asigna a cada proveedor y tipo de página presupuestos de bytes de transferencia, recuento de solicitudes, ejecución en el hilo principal, tareas largas, tasa de errores y contribución a LCP/INP. Exceder un presupuesto debe activar una revisión o degradación automática, no un ticket de limpieza a futuro. Segmenta los presupuestos por dispositivos de gama baja, redes lentas y estado de consentimiento, ya que los promedios ocultan la cola de la distribución.

En el laboratorio, usa los paneles Performance y Network de DevTools, WebPageTest e inyección de fallos para observar el análisis sintáctico, la ejecución, las tareas largas y los puntos únicos de fallo. En producción, usa RUM para registrar origen, temporización de recursos, tareas largas con PerformanceObserver, LCP, INP, CLS, conversión y errores. Compara segmentos por dispositivo, navegador, región y plantilla de página para que los cambios en la mezcla de tráfico no se confundan con una optimización.

6. Desplegar, revertir y gobernar los cambios de proveedores

Haz un despliegue gradual primero en una sola plantilla de página y un pequeño porcentaje del tráfico móvil. Cada cambio de script lleva una versión, origen, configuración de consentimiento e interruptor de reversión; las actualizaciones de proveedores siguen el mismo proceso. Si un script agota el tiempo de espera o lanza un error, omítelo o degrada por defecto en lugar de reintentar indefinidamente. La reversión restaura el último manifiesto revisado en lugar de obtener una versión desconocida de una URL del proveedor.

Verifica las invariantes: los usuarios pueden navegar, agregar al carrito y comprar cuando un proveedor falla; no se solicitan datos restringidos sin consentimiento; los presupuestos de scripts se mantienen bajo los límites; los reportes de CSP no muestran nuevos orígenes; y el INP de interacciones críticas no presenta regresiones. Mantén detonantes explícitos de eliminación o reemplazo para cada proveedor.

7. Hacer la verificación ejecutable

Prueba DNS lento, respuestas 5xx del proveedor, una descarga interrumpida a la mitad, una excepción no controlada, una tarea larga en el hilo principal, retirada de consentimiento, cookies de terceros deshabilitadas, un bloqueador de contenido y un navegador antiguo. Valida más que el renderizado visual: el estado de compra, la recuperación, la interacción por teclado, los anuncios del lector de pantalla y los límites de solicitud de datos.

Usa un grupo de control que cambie solo una estrategia de carga, como pasar de síncrona a diferida, manteniendo constantes las reglas de contenido y tráfico. Verifica LCP, INP, tareas largas, bytes de recursos, conversión y errores del proveedor en p75/p95. Si el checkout mejora pero abrir el chat se vuelve más lento, reporta el compromiso (trade-off) y ajusta el activador en lugar de reportar solo una métrica atractiva.

Respuesta de muestra de alta calidad

"No comenzaría agregando async a los 14 scripts. Haría un inventario del propósito de cada script, dependencias, solicitudes, bytes, tiempo del hilo principal, uso de datos, propietario e impacto ante fallos, para luego clasificarlo como crítico, diferido o eliminable. El pago y el inicio de sesión permanecen en una ruta crítica de origen propio; la analítica independiente puede ser asíncrona; el código dependiente del DOM o del orden usa defer; el chat, los mapas y el video se cargan mediante interacción o detrás de una fachada de iframe.

Antes del consentimiento no crearía rastreadores no esenciales. CSP permitiría fuentes revisadas y los recursos fijos podrían usar SRI. Un widget de solo renderizado se coloca en un iframe, mientras que la compra y la navegación conservan un mecanismo de respaldo de origen propio. Cada proveedor tiene presupuestos de bytes, ejecución, tareas largas y errores.

Lanzaría el cambio gradualmente a una pequeña cohorte móvil. En el laboratorio limitaría el ancho de banda de la red, inspeccionaría trazas de Performance e inyectaría fallos del proveedor. En producción segmentaría RUM por dispositivo, región y estado de consentimiento, comparando LCP, INP, CLS, tareas largas, temporización de recursos, conversión y errores. Cada cambio es reversible y las actualizaciones de proveedores son revisadas. Si un proveedor falla, la compra principal sigue funcionando; si se envían datos antes del consentimiento o las protecciones exceden el presupuesto, la expansión se detiene."

Errores comunes

• Agregar async a cada script → los scripts dependientes pueden ejecutarse fuera de orden y la ejecución aún puede interrumpir el análisis sintáctico → mapea las dependencias; usa async para trabajo independiente y defer o módulos para trabajo ordenado.
• Mover únicamente las etiquetas al final del body → la descarga y la ejecución siguen compitiendo por el hilo principal y la interacción puede sufrir regresiones → difiere, recorta, divide o activa por función, y luego mide el costo de ejecución.
• Usar únicamente Lighthouse → las condiciones de laboratorio omiten dispositivos de gama baja, redes lentas y bloqueos de proveedores → compara percentiles de usuarios reales, tareas largas y métricas de negocio.
• Deshabilitar el rastreo después de que se rechaza el consentimiento → el script ya se ejecutó y puede haber enviado una solicitud → verifica el consentimiento antes de crear el script o la solicitud de red.
• Tratar el autoalojamiento como una solución de seguridad completa → las actualizaciones, la integridad, las licencias y el costo de ejecución persisten → combina versiones revisadas, SRI, CSP, presupuestos y reversión.
• Reintentar un proveedor fallido hasta que funcione → el proveedor se convierte en un punto único de fallo para la página crítica → usa tiempos de espera, un placeholder degradado y una ruta principal de origen propio.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: La analítica debe enviar un evento de primera pantalla de inmediato. ¿Puede ser crítica?

Primero verifica si verdaderamente debe enviarse antes del primer pintado. Si un evento de vista de página se puede agrupar en lotes después del pintado y la pérdida de datos es aceptable, difiérelo. Si la atribución o el cumplimiento normativo requieren una entrega más temprana, usa un script async independiente, un tiempo de espera corto y una pequeña cola de origen propio; no bloquees el renderizado. Establece el presupuesto comparando el retraso del evento con el valor de negocio de LCP e INP.

Pregunta de seguimiento 2: Un proveedor solo ofrece una URL dinámica. ¿Cómo puedes usar SRI?

No puedes asignar un hash confiable a un contenido que cambia continuamente. Solicita recursos con versiones definidas, construye un proceso de lanzamiento firmado y autoalojado, o aisla la funcionalidad en un iframe o integración del lado del servidor. CSP, las auditorías de acceso y el monitoreo de cambios reducen el riesgo. No utilices un hash simulado ni lo reemplaces con unsafe-inline.

Pregunta de seguimiento 3: Un script de terceros sigue creando tareas largas con defer. ¿Qué sigue?

defer cambia el momento de ejecución, no el trabajo de análisis sintáctico o ejecución. Usa la traza de Performance para identificar el script y la tarea, luego solicita al proveedor que lo divida, lo active por interacción, elimine funcionalidades o traslade el trabajo a un iframe o evento del lado del servidor. Si debe ejecutarse, programa fragmentos más pequeños en tiempo de inactividad con un timeout y verifica la cola de la distribución con RUM.

Pregunta de seguimiento 4: Marketing quiere añadir cinco etiquetas al mismo tiempo. ¿Qué les respondes?

Exige que cada etiqueta declare su propósito, propietario, decisión esperada, categoría de consentimiento, presupuesto de rendimiento y condición de eliminación. Verifica si hay recolección duplicada o un evento existente que ya responda a la necesidad. Mide en un entorno aislado (sandbox) y realiza el despliegue gradual solo después de que el valor sea claro. Una etiqueta sin valor medible o que no esté dentro del presupuesto no entra a producción.