Motor de reservas
NOW

Anatomía de un capítulo

Todos los capítulos abren con el número, el título, un resumen del hallazgo en una línea y una franja de metadatos: prioridad, alcance, métricas afectadas, esfuerzo y equipo responsable. Justo debajo va la cifra medida más importante de esa incidencia. El cuerpo sigue siempre el mismo orden:

Convenciones

Prioridad

La prioridad combina impacto y esfuerzo, no gravedad a secas. Una incidencia de impacto muy alto que exige trabajo de infraestructura entre equipos solo adelanta a una victoria rápida cuando su efecto multiplicador lo justifica — que es exactamente el caso de una de las catorce.

Los colores siguen la misma rampa que los umbrales de Core Web Vitals: rojo, ámbar y verde. La etiqueta siempre acompaña al color, de modo que el documento se lee igual en blanco y negro o con una deficiencia de visión cromática.

Etiquetas de métrica

Las métricas se agrupan por lo que describen:

LCPFCPTTFB carga  ·  TBTINPTTI interactividad y respuesta  ·  CLS estabilidad visual

Estado de la evidencia

Recopilada la captura existe en el directorio de evidencia. Pendiente falta por capturar; la afirmación que la rodea se apoya en la evidencia que sí está, y se señala como tal.

Los gráficos

Los gráficos de este informe son reconstrucciones vectoriales de los datos de captura, no capturas de pantalla de DevTools. Cada uno indica en su pie el fichero de evidencia del que sale. Ninguna cifra se ha redondeado ni suavizado para que el gráfico quede mejor.

Las cifras

Los valores medidos se dan tal cual. Las proyecciones usan la palabra estimado o un rango, y nombran siempre la línea base de la que extrapolan. Donde un valor es una cota inferior respecto al usuario real — que es prácticamente en todo el documento — el capítulo lo dice.

P0 — Atacar primero

P1 — Victorias rápidas de alto impacto

P2 — Mejoras estratégicas

P3 — Acabado e infraestructura

Condiciones de la línea base

Huecos conocidos de la medición

• WebPageTest está bloqueado por el CDN, así que no hay datos sintéticos de laboratorio de terceros para estas rutas.
• El entorno de desarrollo no usa el bundle de producción, de modo que los hallazgos sobre tamaño de bundle y scripts bloqueantes solo son reproducibles contra producción.
• No existe todavía ninguna captura tomada desde Latinoamérica. Todas las cifras de ese mercado son extrapolaciones desde la línea base europea, y así se etiquetan.

Estructura del directorio de evidencia

Cada incidencia guarda su evidencia en su propio subdirectorio. No todos los ficheros existen para todas: la tabla de evidencia de cada capítulo indica el conjunto realmente recopilado.

docs/performance/issues/evidence/
└── PERF-XXX/
    ├── CAPTURE-GUIDE.md                  instrucciones de captura paso a paso
    ├── PERF-XXX-no-cache.har             captura de red sin caché
    ├── PERF-XXX-with-cache.har           captura de red con caché
    ├── PERF-XXX-no-cache-trace.json.gz   traza de rendimiento sin caché
    ├── PERF-XXX-with-cache-trace.json.gz traza de rendimiento con caché
    ├── PERF-XXX-*.png                    capturas de cascada y flame chart
    └── PERF-XXX-recording.mp4            grabación (solo PERF-001, -002, -010)

Problema

El formulario de reserva carga su estructura mediante una cascada secuencial de peticiones. Cada una tiene que completarse antes de que arranque la siguiente:

• Descarga del HTML → arranque de Angular → comprobación de autenticación
• Autenticación resuelta → GET /reservas/schemas/default
• Esquema de arranque resuelto → POST /reservas/schemas/guest-details
• Datos del huésped resueltos → POST /reservas/schemas/rate-details
• Tarifas resueltas → POST /reservas/schemas/v2/extra-services
• …y así para cada sección del formulario

La cascada no es puramente serie: en cuanto /schemas/default responde, el resto de esquemas salen en oleadas paralelas. Pero todas las oleadas están detrás de esa primera respuesta, y esa primera respuesta tarda 3 871 ms.

Impacto en Core Web Vitals

Cada ida y vuelta adicional se traslada directamente a LCP y TTI. En PERF-005 está el motivo de que cada una de esas idas y vueltas cueste lo que cuesta.

Impacto medido

Capturado con devtools-snippet-perf001.js contra producción, con caché, España (UE) → /es-mx/reserva/crear.

Peticiones duplicadas

El snippet destapó un hallazgo que la cascada por sí sola no muestra: 15 endpoints únicos generan 32 peticiones HTTP dentro de una única carga de página.

Solución recomendada

1 · Identificar los esquemas invariantes y pedirlos en paralelo

Los esquemas que siempre hacen falta con independencia del tipo de reserva — datos del huésped, habitación, tarifas — pueden pedirse junto al esquema de arranque en lugar de después.

// libs/booking/data-access/src/services/bootstrap.service.ts
forkJoin({
  bootstrap: this.fetchBootstrapResponse(context),
  guestDetails:
    this.httpClient.get(this.configuration.fetchGuestDetailsSchema(context)),
  roomDetails:
    this.httpClient.post(this.configuration.fetchRoomDetailsSchema(context), payload),
}).pipe(...)

2 · Prefetch de esquemas al pasar por encima del enlace

Calentar los esquemas cuando el usuario pasa el ratón sobre el enlace de «Nueva reserva», con una estrategia de prefetch propia o una llamada directa de HttpClient.

3 · Fusionar arranque y esquema por defecto

Evaluar si el backend puede devolver los esquemas más habituales dentro de /reservas/schemas/default y eliminar así las idas y vueltas separadas.

4 · Deduplicar

Diecisiete de las treinta y dos peticiones repiten un esquema ya cargado. Añadir shareReplay(1) por URL en cada servicio de esquema, o un Map<url, Observable> compartido a nivel de interceptor, para que cada endpoint único se pida como mucho una vez por carga. Ver PERF-011, que aborda el mismo tipo de problema a nivel de interacción.

Evidencia

Mejora esperada

Sobre los datos medidos. El ahorro de las dos primeras filas se solapa: el objetivo combinado no es su suma.

Para usuarios en Latinoamérica con RTT de 300–500 ms, cada salto serie restante se multiplica por un factor estimado de 2 a 4× respecto a la línea base europea.

Referencias

• web.dev — LCP · definición de la métrica principal; entender qué retrasa LCP antes de optimizarla
• web.dev — Optimize LCP · guía completa, con una sección dedicada a eliminar retardos de carga de recursos
• web.dev — Critical rendering path · por qué cada salto de red adicional multiplica la latencia percibida
• High Performance Browser Networking — HTTP/2 (Ilya Grigorik) · capítulo canónico sobre multiplexado y bloqueo de cabecera de línea; explica por qué HTTP/2 no elimina las cascadas de nivel de aplicación
• RxJS — forkJoin · ejecutar observables independientes en paralelo y esperar a todos
• Chrome DevTools — cascada de red · medir tiempos y visualizar la cadena de dependencias

Problema

Todos los estilos de la aplicación se empaquetan en un único punto de entrada main.scss que importa cada sección de forma incondicional:

El CSS de secciones que no se ven en el render inicial — facturación, servicios extra, documentación, voucher, tour guiado — se parsea y aplica igualmente, añadiendo recálculo de estilo innecesario. El sprite de iconos (861 KB descomprimidos, ver PERF-014) y los estilos de terceros también se cargan de forma global.

Impacto en Core Web Vitals

El CSS bloquea el render por diseño. Cada kilobyte extra en la ruta crítica retrasa FCP directamente.

Impacto medido

Capturado con devtools-snippet-perf002.js, producción, con caché, España (UE) → /es-mx/reserva/crear.

Solución recomendada

1 · Extraer el CSS crítico

Identificar los estilos necesarios para renderizar el esqueleto visible sin desplazar — rejilla, barra de navegación, contenedor de tarjeta, base de los campos — e incorporarlos en línea en un bloque <style> del index.html del shell, o usar inlineStyleLanguage de Angular con un extractor de CSS crítico.

2 · Cargar en diferido los estilos globales no críticos

private loadGuidedTourStyles(): void {
  const link = document.createElement('link');
  link.rel = 'stylesheet';
  link.href = '/assets/guided-tour.css';
  document.head.appendChild(link);
}

3 · Auditar y eliminar utilidades globales sin uso

Pasar PurgeCSS, o @angular-builders/custom-webpack con una pasada de tree-shaking de CSS, contra el uso real en las plantillas.

4 · Mover los estilos específicos de ruta a los componentes

Facturación, documentación y datos de la reserva deberían llevar su SCSS a nivel de componente. Conviene verificar que no queda duplicación en el bundle global.

5 · Aplazar la hoja del asistente

Es de terceros, bloquea el render, se dispara a los 2 673 ms, cuesta 108 ms por carga incluso cacheada y no se usa al 99,3 % en el render inicial. Debe cargarse de forma asíncrona cuando el formulario ya es interactivo, o solo al abrir el chat.

private loadAssistantStyles(): void {
  const link = document.createElement('link');
  link.rel = 'stylesheet';
  // URL tomada del <link> que inyecta el script del asistente
  link.href = 'https://chat.assistant-vendor.com/...assistant-launcher.css';
  document.head.appendChild(link);
}

Evidencia

Mejora esperada

Para usuarios en Latinoamérica con RTT de 300–500 ms, solo la ida y vuelta de assistant-launcher.css puede costar entre 300 y 500 ms si falla la caché.

Referencias

• web.dev — FCP · el CSS bloquea el render por defecto y retrasa FCP directamente
• web.dev — Eliminate render-blocking resources · cómo bloquea el CSS y qué estrategias reducen su impacto
• web.dev — Defer non-critical CSS · cargar CSS no crítico sin bloquear la ruta de render
• web.dev — Extract critical CSS · incorporar en línea el CSS visible para eliminar la ida y vuelta
• Chrome DevTools — pestaña Coverage · medir el porcentaje de CSS y JS sin usar por carga
• PurgeCSS · tree-shaking de CSS según el uso real en plantillas
• Angular — Component styles · estilos con ámbito de componente para evitar CSS global innecesario

Problema

La página pide recursos a varios orígenes externos sin ninguna pista previa de conexión. El navegador descubre esos orígenes solo después de parsear HTML y CSS o de ejecutar JavaScript, y en ese momento tiene que pagar el coste completo de conexión antes de recibir un solo byte de contenido.

La resolución DNS más el handshake TCP más la negociación TLS cuestan entre 100 y 300 ms por origen desde España, y se pagan íntegros durante la carga.

Impacto en Core Web Vitals

Impacto medido

Solución recomendada

1 · Pistas estáticas en el <head> del shell

<!-- Preconexiones críticas: abrir la conexión antes de que dispare el JS -->
<link rel="preconnect" href="https://assets.tagmanager-vendor.com">
<link rel="preconnect" href="https://cdn.vantia.com" crossorigin>

2 · Pista programática para el SDK de mapas, solo con intención

El mapa no debe preconectarse al inicializar: en PERF-013 el problema es precisamente su carga anticipada. La pista se añade cuando el usuario muestra intención pasando el ratón por el campo de dirección.

// libs/core/main/src/ui/places-autocomplete/maps-api.service.ts
private preconnectToMaps(): void {
  ['https://maps.geo-vendor.com', 'https://tiles.geo-vendor.com'].forEach((origin) => {
    if (!document.querySelector(`link[href="${origin}"]`)) {
      const link = this.document.createElement('link');
      link.rel = 'preconnect';
      link.href = origin;
      this.document.head.appendChild(link);
    }
  });
}

Se llama en el mouseenter del campo de dirección: para cuando se añade la etiqueta del script, la conexión ya está establecida.

Evidencia

Mejora esperada

Cada handshake inicial que se elimina ahorra entre 100 y 300 ms sobre fibra desde España, con unos 120 ms de RTT hasta orígenes alojados en EE. UU. Con tres o cuatro orígenes externos, un ahorro total de 300 a 900 ms en la primera carga es realista.

Para el mercado latinoamericano con RTT de 300–500 ms, el coste por origen es de 2 a 4× superior, así que la mejora crece en proporción: entre 600 ms y 1,6 s por primera carga.

Referencias

• web.dev — FCP · la métrica más afectada por la latencia de conexión externa
• Ilya Grigorik — Eliminating Roundtrips with Preconnect · artículo de referencia del autor de High Performance Browser Networking; explica las capas DNS, TCP y TLS y cómo preconnect elimina cada una
• web.dev — Preconnect to required origins · cuándo usar preconnect en lugar de dns-prefetch
• MDN — Link types: preconnect · especificación del atributo
• Chrome DevTools — Network request timing · medir DNS Lookup, Initial Connection y SSL por petición
• web.dev — Resource hints · guía completa de preconnect, dns-prefetch, preload, modulepreload y prefetch

Problema

Las fuentes corporativas se cargan como web fonts referenciadas por reglas @font-face en el CSS. El navegador no puede descubrir la URL de una fuente hasta que ha:

• Descargado y parseado el bundle completo de CSS
• Encontrado un elemento que necesita esa fuente
• Emparejado la regla @font-face

Esta cascada de tres pasos produce entre 300 y 600 ms de texto invisible o con fuente de respaldo antes de que se pinte la real. FOUT y FOIT son dos síntomas visibles del mismo retardo de descubrimiento.

Impacto en Core Web Vitals

Impacto medido

Solución recomendada

1 · Precargar las variantes críticas en el <head>

<!-- Solo las fuentes de la ruta crítica de render -->
<link rel="preload" href="/assets/fonts/VantiaSans-Regular.woff2"
      as="font" type="font/woff2" crossorigin>
<link rel="preload" href="/assets/fonts/VantiaSans-Bold.woff2"
      as="font" type="font/woff2" crossorigin>

Solo las que se usan sobre la línea de flotación. Precargar todos los pesos y estilos desperdicia ancho de banda y compite con recursos más críticos.

2 · Añadir font-display: swap a cada regla

@font-face {
  font-family: 'VantiaSans';
  src: url('../fonts/VantiaSans-Regular.woff2') format('woff2');
  font-display: swap; // el texto es visible durante la carga
}

3 · Resolver los duplicados

Rastrear qué dos declaraciones referencian los mismos ficheros Bold y Regular, y consolidarlas.

Evidencia

Mejora esperada

Precargar dos o tres ficheros críticos elimina la cascada de descubrimiento y puede mejorar LCP entre 200 y 400 ms en la primera visita sin caché, medido desde la línea base España/fibra. Las visitas siguientes no se ven afectadas, porque las fuentes ya vienen de caché.

Con RTT de 300–500 ms el retardo de descubrimiento es proporcionalmente mayor, lo que sitúa la mejora estimada entre 2 y 4× por encima: unos 400 a 800 ms por primera carga.

Referencias

• web.dev — LCP · el candidato a LCP suele ser texto que depende de la fuente personalizada
• Zach Leatherman — Comprehensive Guide to Web Font Loading Strategies · la referencia definitiva del ecosistema; más de once estrategias con sus compromisos, FOUT, FOIT y el patrón Critical FOFT
• web.dev — Web font best practices · preload, font-display, autoalojamiento frente a CDN y su impacto en Core Web Vitals
• web.dev / MDN — font-display · todos los valores del descriptor y cuándo usar cada uno
• CSS Font Loading API · detectar cuándo una fuente está lista sin sondeo ni dependencia del CSS

Problema

El backend de reservas está desplegado en la nube corporativa, en una región de EE. UU., detrás del CDN corporativo. Pero el CDN funciona de hecho como un simple paso a través: cada petición es un fallo de caché, porque el origen envía Cache-Control: no-cache, no-store, max-age=0 en todas sus respuestas. Todas las peticiones llegan a un origen que no está cerca de los usuarios.

La cabecera server-timing de cada respuesta de esquema lo declara sin ambigüedad:

server-timing: cdn-cache; desc=MISS
server-timing: edge; dur=108
server-timing: origin; dur=75

Mediciones confirmadas

Dos capturas, Chrome estable, España, 1 de junio de 2026.

El HAR se capturó en una única navegación a /reserva/crear. El snippet se ejecutó sobre una sesión completa con interacciones de formulario, que es lo que destapa el volumen real de llamadas y los arranques en frío más allá de schemas/default.

Causas raíz

1 · Las cabeceras del propio origen desactivan la caché

cache-control: no-cache, no-store, max-age=0, must-revalidate
pragma: no-cache
expires: 0

no-store le indica al CDN que no cachee nunca la respuesta. La infraestructura de CDN ya está desplegada y pagada: lo que impide que sea efectiva son las cabeceras.

2 · Penalización de arranque en frío en schemas/default

La primera petición de esquema de cada sesión tarda 4 328 ms de TTFB, de los cuales 3 667 ms se gastan en el origen. Las siguientes bajan a unos 75 ms. Esa firma es coherente con una inicialización perezosa: pool de conexiones, calentamiento de la máquina virtual o un cálculo bajo demanda.

3 · El origen no está cerca de los usuarios

Incluso con caché, 210–345 ms de TTFB indican distancia geográfica real entre el edge y el origen. Con 29 llamadas en la carga del formulario, eso se acumula deprisa.

Solución recomendada

Opciones por retorno sobre esfuerzo.

Opción 1 · Quitar no-store de las respuestas de esquema

Máximo retorno, mínimo esfuerzo. La infraestructura ya está; el único bloqueo es el Cache-Control del origen.

Cache-Control: private, max-age=30

O bien, para que cachee el CDN pero no el navegador:

Cache-Control: no-cache, s-maxage=60
Surrogate-Control: max-age=60

Las respuestas de esquema son en gran medida deterministas por cuenta y rol. Un TTL corto con una clave de caché que incluya el identificador de cuenta sería seguro y efectivo, y llevaría el TTFB de ~235 ms a ~10–20 ms en las respuestas cacheadas.

Opción 2 · Corregir el arranque en frío

Los 3,67 s de origen en la primera llamada deben investigarse desde backend. Causas probables: inicialización perezosa del servicio, expiración del pool de conexiones por inactividad o un primer cálculo costoso. Soluciones: conexiones keep-alive, inicialización anticipada en el despliegue o un ping de calentamiento programado.

Opción 3 · Gateway regional

Desplegar una pasarela ligera cerca del mercado que termine TLS regionalmente y haga de proxy contra el origen. Reduce el tramo transatlántico con independencia de la política de caché.

Opción 4 · Despliegue regional completo

Desplegar el backend en una región próxima al mercado. Máxima reducción de latencia; requiere coordinación con backend, infraestructura y los equipos de residencia de datos y cumplimiento.

Opción 5 · Agrupar peticiones en el edge

Usar funciones en el edge del CDN para agrupar varias peticiones de esquema en una sola ida y vuelta al origen, reduciendo el número de trayectos aunque el origen siga donde está.

Evidencia

Mejora esperada

Las cifras base reflejan condiciones de España sobre fibra. Para el mercado latinoamericano con RTT de 300–500 ms, el TTFB con caché se estima entre 500 y 900 ms por llamada, lo que empeora bastante el coste acumulado de sesión (55 llamadas × ~700 ms de media) y hace la corrección de caché proporcionalmente más valiosa.

Referencias

• web.dev — Optimize TTFB · estrategia de CDN, caché de respuestas y Early Hints
• web.dev — LCP · cada milisegundo de TTFB retrasa LCP en la misma proporción
• web.dev — INP · las interacciones que disparan llamadas en tiempo real arrastran también la latencia geográfica
• Cabecera HTTP server-timing · desglose de CDN y origen visible directamente en el panel de red
• High Performance Browser Networking — HTTP/2 · por qué la latencia domina incluso con multiplexado
• Documentación de tu CDN sobre caché de respuestas HTTP · cómo respeta y sobrescribe las cabeceras Cache-Control

Problema

Varios ficheros JavaScript de tamaño considerable se cargan de forma síncrona en el <head>, bloqueando el parseo y el render.

Impacto en Core Web Vitals

Impacto medido

Solución recomendada

1 · Añadir defer a todos los scripts estáticos del <head>

<!-- Antes -->
<script src="/booking/assets/app-initialization.production-[hash].js"></script>
<script src="/booking/rumagent-[hash].js"></script>

<!-- Después -->
<script src="/booking/assets/app-initialization.production-[hash].js" defer></script>
<script src="/booking/rumagent-[hash].js" defer></script>

2 · Retrasar la inyección del data layer

// libs/core/main/src/datalayer/datalayer-loader.service.ts
async load(): Promise<void> {
  if (this.configuration.dataLayer.scriptUrl) {
    await new Promise<void>((resolve) =>
      'requestIdleCallback' in window
        ? requestIdleCallback(() => resolve())
        : setTimeout(resolve, 200)
    );
    // lógica de inyección existente...
  }
}

3 · Cuándo async y cuándo defer

Evidencia

Mejora esperada

Añadir defer a los tres scripts estáticos elimina la fase de bloqueo del parseo a los 463 ms. Sobre fibra de escritorio en Europa el FCP ya está en ~643 ms, así que el margen en condiciones óptimas es modesto — pero el beneficio se multiplica en conexiones lentas y con RTT de 300–500 ms.

Retrasar la inyección del data layer (269 KB, arrancando a los 1 239 ms) a tiempo ocioso reduce además el TBT.

Referencias

• web.dev — FCP · cada script bloqueante retrasa el primer píxel en pantalla
• V8 — The cost of JavaScript in 2019 (Addy Osmani) · referencia imprescindible del equipo de V8: parseo, compilación y ejecución son tres fases caras distintas; 300 KB de JS no equivalen a 300 KB de imagen
• web.dev — Eliminate render-blocking resources · identificar qué bloquea el FCP y sacarlo de la ruta crítica
• MDN — <script> defer / async · garantías de orden de ejecución y momento respecto al parseo
• MDN — requestIdleCallback · planificar trabajo no crítico en los periodos ociosos del navegador

Problema

Gestor de etiquetas

• 466 KB comprimidos / 2,25 MB descomprimidos en 13 peticiones: un bundle principal y doce ficheros de extensiones
• Encolado a los 4,06 s del ciclo de vida de la página — lo inyecta el shell dinámicamente, no es una etiqueta <script> descubierta por el parser
• Coste de la conexión inicial al CDN del proveedor: DNS 10 ms + TCP 33 ms + SSL 18 ms = 61 ms de handshake antes de transferir un solo byte
• EvaluateScript del bundle principal: una tarea larga de 51,3 ms en el hilo principal
• No hace falta hasta que la página es interactiva

Asistente virtual (widget de chat)

• 362 KB comprimidos / 3,1 MB descomprimidos en más de 15 peticiones en la primera carga, sin contar llamadas a la API
• chat-launch.js y chat-loader.min.js se cargan dos veces cada uno: una desde el contexto de la página y otra desde un iframe parseado con prioridad alta. Es duplicación estructural, causada por el patrón de inicialización anticipada.
• La actividad de fondo continúa toda la sesión — se observó polling durante más de 8 minutos — aunque el usuario nunca abra el chat
• Solo hace falta cuando el usuario abre el chat explícitamente; se carga en todas las visitas

Beacons de analítica

Doce beacons por carga de página hacia el endpoint de recogida. Cada URL lleva un sufijo aleatorio único, que es el mecanismo estándar de la plataforma para evitar la caché, no un identificador por evento.

Tracker de personalización — recién identificado

Se carga un tracker adicional desde el CDN de un proveedor de personalización. Su alcance e impacto no están medidos todavía. Debería entrar en la auditoría de carga diferida junto con el gestor de etiquetas.

Impacto medido

Solución recomendada

Gestor de etiquetas — cargar tras la interactividad

// Sustituir el script anticipado por una inyección posterior al render
afterNextRender(() => {
  const script = document.createElement('script');
  script.src = '//assets.tagmanager-vendor.com/container-xxx.min.js';
  script.async = true;
  document.head.appendChild(script);
});

Asistente — cargar solo con interacción del usuario

// libs/shell/src/services/virtual-assistant-display.service.ts
initOnInteraction(): void {
  const trigger = document.querySelector('[data-chat-trigger]');
  trigger?.addEventListener('click', () => this.loadChatWidget(), { once: true });
}

private loadChatWidget(): void {
  // inyectar aquí el script del asistente, y solo ahora
}

Analítica — agrupar las activaciones de flags

private readonly pendingActivations: FlagActivation[] = [];
private flushScheduled = false;

trackFlagActivation(activation: FlagActivation): void {
  this.pendingActivations.push(activation);
  if (!this.flushScheduled) {
    this.flushScheduled = true;
    queueMicrotask(() => this.flushActivations());
  }
}

private flushActivations(): void {
  // enviar un único beacon con todas las activaciones pendientes
  this.flushScheduled = false;
  this.pendingActivations.length = 0;
}

Personalización — auditar y aplazar

Determinar si el script de personalización hace falta para el render inicial. Si no, aplicarle el mismo patrón de afterNextRender().

Evidencia

Mejora esperada

• Aplazar el gestor de etiquetas saca 466 KB (2,25 MB descomprimidos) y una tarea de 51,3 ms de la ruta crítica, y elimina los 61 ms de handshake inicial para quien llega por primera vez.
• Corregir la inicialización del asistente elimina la duplicación por iframe, quita más de 362 KB de la carga inicial para el 80 % largo de usuarios que nunca abren el chat, y detiene los ocho minutos de polling de fondo.
• Agrupar los beacons elimina siete de las doce peticiones de analítica por carga.
• Auditar la personalización puede aportar ahorro adicional una vez se mida su alcance.

Referencias

• web.dev — INP · los scripts de terceros son la causa principal de un INP malo: compiten con los manejadores de interacción en el hilo principal
• Harry Roberts — Identifying, Auditing, and Discussing Third Parties · marco de trabajo para auditar, clasificar y negociar el coste de terceros con las partes implicadas
• web.dev — Best practices for tags and tag managers · cuándo cargarlos y cómo medir su impacto real en Core Web Vitals
• web.dev — Third-party JavaScript · impacto, diagnóstico y mitigación: fachada, carga diferida, Partytown
• Chrome DevTools — Identify slow third-party scripts · aislar el coste por origen desde el panel Performance
• Angular — afterNextRender · el hook correcto para aplazar trabajo hasta después del primer ciclo de render

Problema

Dos chunks grandes con carga perezosa hacen falta para renderizar el formulario, pero solo se descubren después de que se ejecute el bundle inicial.

Como los chunks se descubren mediante import() dinámicos, el navegador no puede empezar a pedirlos hasta que corre el router de Angular, que a su vez depende de que el bundle principal esté parseado y ejecutado. El resultado es una dependencia en serie donde 2,8 MB de código crítico esperan detrás del bundle.

Impacto en Core Web Vitals

Impacto medido

Solución recomendada

Añadir pistas de modulepreload en el <head> del shell:

<link rel="modulepreload" href="/now-web/chunk-[hash-a].js">
<link rel="modulepreload" href="/chunk-[hash-b].js">

1 · Generación en tiempo de build

// scripts/inject-modulepreload.js (dentro del pipeline de build)
const stats = require('./dist/now-web/stats.json');
const criticalChunks = stats.assets
  .filter(a => a.name.startsWith('chunk-') && a.size > 1_000_000)
  .map(a => `<link rel="modulepreload" href="/${a.name}">`);
// inyectar en la plantilla del shell...

2 · Chunks con nombre

El build ya tiene namedChunks: true. Basta con mapear los nombres a los ficheros con hash en un manifiesto del artefacto de build.

3 · Coordinación con el equipo de plataforma

Si el shell lo genera la plataforma corporativa, las pistas de modulepreload deben incluirse en su propio pipeline.

Evidencia

Mejora esperada

Los dos huecos medidos suman ~1 550 ms sobre fibra. Precargar ambos chunks en paralelo con el bundle principal puede eliminarlos, con una mejora de TTI de 500 a 1 500 ms.

Con RTT de 300–500 ms cada ida y vuelta de descubrimiento cuesta bastante más, y la mejora se estima entre 2 y 4× superior. Los valores de España/fibra son una cota inferior.

Referencias

• web.dev — LCP · los chunks críticos en la ruta de render retrasan LCP directamente
• web.dev — Module preload · rel=modulepreload frente a rel=preload: diferencias semánticas y prelectura del grafo de módulos
• MDN — <link rel="modulepreload"> · especificación: as, crossorigin e integración con módulos ES
• Angular — Lazy loading feature modules · cómo genera Angular los chunks con loadChildren y su efecto en el grafo
• Angular CLI — --stats-json · identificar los chunks más grandes y su árbol de dependencias

Problema

Completado el formulario, el usuario navega a /reserva/confirmada. En ese momento el navegador tiene que:

• Pedir el HTML y los assets de la página de confirmación
• Descargar el chunk perezoso del contenedor de confirmación
• Hacer las llamadas a la API que confirman la reserva

No hay ninguna estrategia de prefetch para esta ruta. El retardo cae justo donde la frustración sale más cara: el usuario ya ha invertido minutos de trabajo y está comprometiéndose con una compra.

Impacto en Core Web Vitals

Impacto medido

Solución recomendada

Inyectar las reglas de especulación cuando el usuario ha demostrado progreso real en el formulario — por ejemplo, al validar el primer paso — y no en la carga de página.

// En comfortable-navigation.component.ts — desde viewSummary()
// o desde la suscripción a showViewSummaryButton$
private injectSpeculationRules(): void {
  if (!HTMLScriptElement.supports?.('speculationrules')) return;         // detección
  if (document.querySelector('script[type="speculationrules"]')) return; // ya inyectada

  const script = document.createElement('script');
  script.type = 'speculationrules';
  script.textContent = JSON.stringify({
    prefetch: [{
      urls: ['/booking/es-mx/reserva/confirmada'],
      eagerness: 'moderate',
    }],
  });
  document.head.appendChild(script);
}

Para navegadores sin soporte — Safari y Firefox — se recurre a un prefetch estándar:

<!-- Alternativa para navegadores sin Speculation Rules -->
<link rel="prefetch" href="/booking/es-mx/reserva/confirmada">

Con moderate se evita gastar ancho de banda en usuarios que abandonan el formulario pronto.

Evidencia

Mejora esperada

Para el mercado latinoamericano con RTT de 300–500 ms, la línea base se estima entre 3 y 6 s y la mejora proyectada escala en la misma proporción.

Referencias

• Chrome Developers — Prerender pages for instant navigations · guía completa: niveles de eagerness, restricciones del prerenderizado y comportamiento en páginas autenticadas
• MDN — Speculation Rules API · especificación: sintaxis JSON, campos prefetch y prerender, eagerness y selectores where
• web.dev — <link rel="prefetch"> · la alternativa compatible con Safari y Firefox
• Chrome DevTools — Debug Speculation Rules · estado de las reglas, errores y páginas prerrenderizadas activas

Problema

La vista compacta del formulario renderiza todas las secciones en el DOM a la vez, aunque solo una sea visible en cada momento. El panel de resumen renderiza además el estado completo de todos los pasos ya completados.

El navegador hace layout, cálculo de estilo y pintado de todos los nodos del DOM con independencia de su visibilidad. Con quince o más secciones montadas — facturación, servicios extra, datos del huésped, documentación y el resto — eso es mucho trabajo de render innecesario. La configuración de pasos define más de treinta componentes, y todos pueden existir en el DOM durante las transiciones.

Es un problema que se nota sobre todo en dispositivos modestos, donde el cuello de botella es el render y no la red.

Impacto en Core Web Vitals

Impacto medido

Solución recomendada

Opción A · CSS content-visibility, sin tocar JavaScript

// En los estilos de sección del formulario compacto
.booking-form-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 300px;  // altura aproximada, evita CLS
}

Opción B · @defer (on viewport) de Angular — recomendada

Difiere además la inicialización del componente y su detección de cambios, no solo el layout y el pintado.

<guest-details-form [state$]="state$" />   <!-- crítico: siempre -->

@defer (on viewport) {
  <billing-form [state$]="state$" />
}
@placeholder {
  <div class="section-placeholder" style="min-height: 300px"></div>
}

@defer (on viewport) {
  <extra-services-form [state$]="state$" />
}
@placeholder {
  <div class="section-placeholder" style="min-height: 300px"></div>
}

Evidencia

Mejora esperada

Aplicando content-visibility: auto o @defer (on viewport), las secciones fuera de pantalla quedan excluidas de la pasada de layout y el recuento de nodos sucios baja a los 40–60 que están realmente en el viewport. Mejora esperada: reducción del 40 al 60 % en tiempo de layout y pintado. En dispositivos modestos, entre 200 y 500 ms menos de Time to Interactive y un desplazamiento apreciablemente más suave.

El multiplicador esperado para el mercado remoto está entre 2 y 4×, y aquí lo impulsa el hardware más limitado, no la red.

Referencias

• web.dev — INP · menos trabajo de layout y pintado significa respuesta más rápida a la interacción
• web.dev — content-visibility: the new CSS property that boosts your rendering performance (Una Kravets y Vladimir Lebedev) · el artículo original, con mediciones de hasta 7× de reducción en tiempo de render
• MDN — content-visibility · valores auto, hidden y visible, y su relación con la contención CSS
• MDN — contain-intrinsic-size · reservar espacio para evitar CLS cuando content-visibility: auto omite el layout
• Angular — bloques @defer · disparadores on viewport, on idle, on interaction y bloques @placeholder, @loading y @error

Problema

El análisis de red muestra que varios endpoints se llaman muchas más veces de las necesarias.

Cada llamada duplicada desperdicia una ida y vuelta de 150 a 250 ms sobre la línea base España/fibra, CPU de backend para una petición idéntica, y entre 50 y 200 KB de ancho de banda del usuario por respuesta.

Impacto en Core Web Vitals

Impacto medido

Solución recomendada

Nivel 1 · debounceTime y distinctUntilChanged

formValueChanges$.pipe(
  debounceTime(300),
  distinctUntilChanged((a, b) => isEqual(a, b)),           // ignora payloads idénticos
  switchMap((payload) => this.schemaService.fetch(payload)), // cancela las que vuelan
)

switchMap es el operador crítico: cancela las peticiones en vuelo cuando llega un disparo nuevo, lo que evita que una respuesta antigua aterrice después de una reciente.

Nivel 2 · Deduplicar peticiones en vuelo

// libs/shared/schemas/data-access — capa de deduplicación
@Injectable({ providedIn: 'root' })
export class SchemaRequestDeduplicator {
  private readonly inFlight = new Map<string, Observable<unknown>>();

  deduplicate<T>(key: string, request$: Observable<T>): Observable<T> {
    if (!this.inFlight.has(key)) {
      const shared$ = request$.pipe(
        share({ resetOnComplete: true, resetOnError: true }),
        finalize(() => this.inFlight.delete(key)),
      );
      this.inFlight.set(key, shared$);
    }
    return this.inFlight.get(key) as Observable<T>;
  }
}

Como clave, un hash del payload de la reserva.

Nivel 3 · Cachear respuestas deterministas

Para los endpoints cuya respuesta es determinista dado el mismo payload de entrada, cachear en cliente con el hash del payload como clave, e invalidar al reiniciar el estado de la reserva.

Evidencia

Mejora esperada

Tras una única interacción se observan 57 llamadas donde se esperan unas 40: 17 idas y vueltas sobrantes. A entre 150 y 670 ms cada una sobre la línea base España/fibra, eliminarlas reduce el tiempo de red desperdiciado estimado de ~21,8 s a prácticamente cero.

Con RTT de 300–500 ms la ganancia escala en la misma proporción: la corrección vale bastante más para el mercado prioritario de lo que sugieren las cifras europeas.

Referencias

• web.dev — INP · las llamadas duplicadas que dispara la interacción degradan INP directamente
• RxJS — switchMap · cancela el observable anterior cuando llega una emisión nueva; el antídoto contra las cascadas reactivas
• RxJS — debounceTime · suprime las emisiones intermedias durante un intervalo; imprescindible en cambios de formulario
• RxJS — share · multidifusión de un observable frío para que varios suscriptores compartan una sola ejecución
• RxJS — distinctUntilChanged · evita emisiones cuando el valor no ha cambiado; complemento necesario de debounceTime
• Angular — HttpClient · los interceptores como punto centralizado para caché y deduplicación

Problema

El TTFB del motor de reservas ronda los 250 ms, y en la captura de abajo se midió en 338 ms. Durante toda esa ventana el navegador ha enviado su petición y no ha recibido nada: no puede empezar a pedir ningún recurso porque todavía no sabe cuáles son.

HTTP/2 103 Early Hints permite al servidor enviar una respuesta preliminar con cabeceras Link de preload antes de que la respuesta HTML completa esté lista. El navegador puede actuar sobre esas pistas de inmediato.

Impacto en Core Web Vitals

La técnica rinde justo cuando el TTFB es alto, que según PERF-005 es aquí la condición normal.

Impacto medido

Conexión nueva — 2 de junio de 2026, España → /es-mx/

Los 338 ms de TTFB están por encima de la línea base de ~250 ms de PERF-005, algo coherente con la variabilidad del servidor. DNS, TCP y TLS juntos suman unos 81 ms: cuatro veces menos que el TTFB por sí solo, lo que convierte la ventana ociosa en el coste dominante con diferencia.

Conexión reutilizada — HTTP/2

El TTFB con la conexión reutilizada es menor porque no hay coste de conexión, pero siguen siendo 228 ms durante los cuales no puede descargarse nada.

Ausencia de pistas confirmada en las dos capas

• Capa HTTP — la sección de cabeceras de respuesta no contiene ninguna cabecera Link:, de modo que Early Hints no está en funcionamiento.
• Capa HTML — el snippet de resource hints confirma que no hay <link rel="preload"> ni <link rel="preconnect"> propios de la aplicación en el DOM. El primer recurso crítico arranca a los 463 ms, frente a un responseStart del HTML de 403 ms.

Solución recomendada

Nginx

location /reserva/crear {
  add_header Link "</now-web/main.js>; rel=preload; as=script";
  add_header Link "</now-web/styles.css>; rel=preload; as=style";
  return 103;
  proxy_pass http://upstream;
}

En el CDN

La mayoría de CDN modernos ofrecen Early Hints como una opción de un solo clic, e incluso infieren las cabeceras Link a partir de la respuesta HTML anterior. Los assets concretos a precargar deben salir del stats.json del build: los chunks iniciales de CSS y JS que hacen falta en todas las cargas.

Evidencia

Mejora esperada

103 Early Hints puede recuperar hasta ~413 ms de tiempo ocioso por primera carga. Los recursos críticos empezarían a descargarse durante la espera de TTFB en lugar de después.

Referencias

• web.dev — FCP · Early Hints adelanta el inicio de descarga de los assets dentro de la ventana ociosa
• Chrome Developers — HTTP 103 Early Hints · guía completa con ejemplos, impacto real y compatibilidad de servidores
• RFC 8297 — An HTTP Status Code for Indicating Hints · especificación: semántica del 103, campos Link admitidos y comportamiento esperado del cliente
• Documentación de Early Hints de tu CDN · activación e inferencia automática de cabeceras Link
• web.dev — Optimize TTFB · Early Hints dentro del trabajo global sobre TTFB: CDN, streaming de HTML y caché en el edge

Encuadre estratégico

Problema

El SDK solo hace falta cuando el usuario enfoca un campo de dirección y escribe (autocompletado), cuando selecciona una sugerencia (geocodificación para extraer los componentes de la dirección), o cuando consulta el mapa de la propiedad, que es una ruta distinta y ajena a /reserva/crear.

Causa raíz — dos disparadores, no uno

Disparador 1, principal · suscripción en el constructor

libs/booking/feature-create/src/components/address-input/address-input.component.ts:58

private readonly placesLibraryStatus =
  toSignal(this.mapsApiService.placesLibraryStatus$, {
    requireSync: true,   // ← suscripción síncrona al construir
  });

placesLibraryStatus$ deriva de api$, que inyecta la etiqueta <script> del SDK en el DOM:

Se renderiza el formulario
  → se construye AddressInputComponent
    → toSignal(placesLibraryStatus$, { requireSync: true })
      → placesLibraryStatus$ → api$
        → se inyecta <script src="maps.geo-vendor.com/...">
          → petición de red a los 4 716 ms   ← confirmado en la traza

Es incondicional: se dispara toque o no toque el usuario un campo de dirección.

Disparador 2, secundario · preloadLib() tras inicializar la vista

constructor() {
  effect(() => {
    if (!this.viewInitialized()) return;
    if (this.autocompleteEnabled()) {
      this.autocompleteApiService.preloadLib();  // ← se dispara en AfterViewInit
    }
  });
}

La memoización de api$ hace que el script se inyecte una sola vez, así que el disparador 1 se lleva la petición. Pero preloadLib() la provocaría igualmente si se eliminara el primero. Había que corregir los dos.

Solución aplicada

Corrección 1 · No suscribirse al estado del SDK en el constructor

El componente usaba placesLibraryStatus$ solo para decidir qué interfaz mostrar: campo de búsqueda si el SDK ha cargado, campo manual si ha fallado o sigue cargando. Ese patrón fuerza una carga del SDK únicamente para pintar la interfaz.

Se sustituye por un valor optimista: mostrar el campo de búsqueda por defecto, asumir que el SDK estará disponible, y caer al campo manual solo cuando falle de verdad. El esqueleto de carga sobra: al usuario no le aporta nada saber que el SDK se está inicializando antes de tocar el campo.

// Antes — dispara la carga del SDK al construir:
private readonly placesLibraryStatus =
  toSignal(this.mapsApiService.placesLibraryStatus$, { requireSync: true });

protected readonly showManualAddressInput = computed(
  () => this.placesLibraryStatus().failed
     || this.overrideShowManualAddressInput()
     || this.hasSomeAddressFieldFilledIn(),
);

// Después — nada se carga hasta que hay interacción.
private readonly mapsLoadFailed = signal(false);

protected readonly showManualAddressInput = computed(
  () => this.mapsLoadFailed()
     || this.overrideShowManualAddressInput()
     || this.hasSomeAddressFieldFilledIn(),
);
protected readonly showSearchAddressInput = computed(
  () => !this.showManualAddressInput(),
);

// Lo llama AddressSearchInputComponent cuando el SDK falla:
onMapsLoadFailed(): void {
  this.mapsLoadFailed.set(true);
}

Corrección 2 · Mover preloadLib() al evento de foco

// Después: el SDK carga solo cuando el usuario muestra intención
private handleTextInputFocus(): Subscription {
  return fromEvent(this.textInput, 'focus').subscribe(() => {
    this.autocompleteApiService.preloadLib();    // ← al primer foco
    if (this.currentPredictions().length > 0 || this.showLastAutocompleteOption()) {
      this.showDropdown();
    }
  });
}

preloadLib() ya tiene una guarda interna, así que llamarlo en cada foco es seguro: el script se inyecta una sola vez.

Mejora opcional · preconnect al pasar el ratón

Eliminada la carga anticipada, un preconnect al dominio del SDK en el mouseenter del contenedor de dirección le da al navegador ventaja sobre el handshake antes de que el usuario llegue a enfocar el campo. Importa sobre todo donde el RTT es alto.

Evidencia

Mejora obtenida

La línea base es España (UE) sobre fibra: el mejor caso posible. Con RTT de 300–500 ms y dispositivos modestos, las cifras del «antes» eran de 2 a 4× peores.

Referencias

• V8 — The cost of JavaScript in 2019 (Addy Osmani) · el coste de parseo, compilación y ejecución más allá del tamaño de descarga; el dato clave para justificar la carga diferida ante los responsables
• web.dev — Third-party JavaScript · impacto, diagnóstico y mitigación: fachada, carga diferida, Partytown
• web.dev — Facade pattern for third-party embeds · sustituir un tercero pesado por un marcador ligero hasta que hay interacción
• Documentación del SDK de mapas — importación dinámica de librerías · cargar bajo demanda solo las librerías necesarias
• MDN — evento focus · propagación, focusin como alternativa delegable y diferencias con click

Problema

design-system-icons.svg es el sprite de iconos del sistema de diseño corporativo y se carga como asset estático en todas las páginas. Está referenciado en la configuración de assets del proyecto:

{
  "glob": "design-system-icons.svg",
  "input": "node_modules/@vantia/design-system",
  "output": "/assets"
}

Este asset monolítico bloquea el hito de render de los dos segundos y contribuye al Total Blocking Time.

Impacto en Core Web Vitals

Auditoría de uso de iconos

Solución recomendada

Paso 1 · Auditar el uso — hecho

grep -r 'icon="[^"]*"' apps/now-web libs --include="*.html" | \
  grep -o 'icon="[^"]*"' | sort -u

Resultado: 76 iconos únicos en todas las plantillas, de 694 disponibles.

Paso 2 · Generar un sprite a medida — preferido

// scripts/build-icon-sprite.js — dentro del pipeline de build
const svgstore = require('svgstore');
const usedIcons = require('./used-icons.json');   // salida del paso 1

const sprite = svgstore();
usedIcons.forEach(iconId => {
  sprite.add(
    iconId,
    fs.readFileSync(`node_modules/@vantia/design-system/icons/${iconId}.svg`)
  );
});
fs.writeFileSync('dist/assets/now-icon-sprite.svg', sprite.toString());

Después se sustituye el glob de assets por el sprite generado.

Paso 3 · Incorporar en línea los iconos visibles al cargar

<!-- En lugar de <vds-icon icon="status_check_small"> -->
<svg aria-hidden="true" width="16" height="16" focusable="false">
  <use href="#status_check_small"></use>
</svg>

Paso 4 · Carga diferida — alternativa si el sprite a medida no es viable

afterNextRender(() => {
  const link = document.createElement('link');
  link.rel = 'preload';
  link.as = 'image';
  link.type = 'image/svg+xml';
  link.href = '/assets/design-system-icons.svg';
  link.setAttribute('fetchpriority', 'low');
  document.head.appendChild(link);
});

Evidencia

Mejora esperada

Sobre la línea base España/fibra el sprite arranca a los 3 077 ms y tarda 244 ms, completándose hacia los 3 321. Con RTT de 300–500 ms, la ventana de descarga de 861 KB se estima entre 2 y 3× más larga, lo que añade dos o tres segundos para el mercado prioritario.

• Sprite a medida (pasos 1–2): elimina el bloqueo de render de los dos segundos sobre fibra, y rinde proporcionalmente más en conexiones limitadas.
• Iconos en línea (paso 3): aparecen de inmediato, con coste de red cero.
• Carga diferida (paso 4): aplaza los 861 KB hasta que la página es interactiva.

Referencias

• web.dev — LCP · el sprite compite con los recursos de la ruta crítica y retrasa LCP directamente
• SVGO · el optimizador de SVG más extendido; reduce el tamaño de cada icono antes de componer el sprite
• svgstore · generar sprites concatenando iconos como elementos <symbol>
• svg-sprite · alternativa más completa: genera sprites en varios formatos (inline, CSS, view, defs)
• MDN — elemento SVG <use> · referencia href, comportamiento del shadow DOM y restricciones de origen cruzado

Qué haría falta para cerrar los huecos

• Una captura desde el mercado prioritario. Es la aportación de mayor valor. Convierte catorce extrapolaciones en catorce mediciones.
• Una línea base desde EE. UU. Zanja la discusión sobre cuánto del TTFB es distancia y cuánto es proceso de origen.
• Monitorización continua. Este informe es una fotografía. Sin datos de campo y sin tests de regresión, dentro de tres meses no habrá forma de saber si las correcciones aguantaron.