Booking engine
NOW

Anatomy of a chapter

Each chapter opens with a number, a title, a one-line summary of the finding, and a metadata strip: priority, scope, affected metrics, effort and owning team. Directly below sits the single most important measured figure for that issue. The body always follows the same order:

Conventions

Priority

Priority combines impact and effort, not severity alone. A very high-impact issue that demands cross-team infrastructure work only jumps ahead of a quick win when its multiplier effect justifies it — which is exactly the case for one of the fourteen.

The colours follow the same ramp as the Core Web Vitals thresholds: red, amber and green. The label always accompanies the colour, so the document reads the same in black and white or with a colour vision deficiency.

Metric labels

Metrics are grouped by what they describe:

LCPFCPTTFB loading  ·  TBTINPTTI interactivity and responsiveness  ·  CLS visual stability

Evidence status

Collected the capture exists in the evidence directory. Pending still to be captured; the claim around it rests on the evidence that is present, and says so.

The charts

The charts in this report are vector reconstructions of the capture data, not DevTools screenshots. Each one names the evidence file it comes from in its caption. No figure has been rounded or smoothed to make a chart look better.

The figures

Measured values are given as they were recorded. Projections use the word estimated or a range, and always name the baseline they extrapolate from. Wherever a value is a lower bound relative to the real user — which is nearly everywhere in this document — the chapter says so.

P0 — Attack first

P1 — High-impact quick wins

P2 — Strategic improvements

P3 — Polish and infrastructure

Baseline conditions

Known measurement gaps

• WebPageTest is blocked by the CDN, so there is no third-party synthetic lab data for these routes.
• The development environment does not use the production bundle, so the bundle-size and blocking-script findings are only reproducible against production.
• No capture has yet been taken from Latin America. Every figure for that market is an extrapolation from the European baseline, and is labelled as such.

Evidence directory structure

Each issue keeps its evidence in its own subdirectory. Not every file exists for every issue: the evidence table in each chapter states the set actually collected.

docs/performance/issues/evidence/
└── PERF-XXX/
    ├── CAPTURE-GUIDE.md                  step-by-step capture instructions
    ├── PERF-XXX-no-cache.har             cold network capture
    ├── PERF-XXX-with-cache.har           warm network capture
    ├── PERF-XXX-no-cache-trace.json.gz   cold performance trace
    ├── PERF-XXX-with-cache-trace.json.gz warm performance trace
    ├── PERF-XXX-*.png                    waterfall and flame chart screenshots
    └── PERF-XXX-recording.mp4            screen recording (PERF-001, -002, -010 only)

Problem

The booking form loads its structure through a sequential chain of requests. Each one has to complete before the next begins:

• HTML download → Angular bootstrap → authentication check
• Authentication resolved → GET /reservas/schemas/default
• Bootstrap schema resolved → POST /reservas/schemas/guest-details
• Guest details resolved → POST /reservas/schemas/rate-details
• Rates resolved → POST /reservas/schemas/v2/extra-services
• …and so on for every section of the form

The chain is not purely serial: once /schemas/default responds, the remaining schemas go out in parallel waves. But every wave sits behind that first response, and that first response takes 3,871 ms.

Core Web Vitals impact

Every additional round trip translates directly into LCP and TTI. PERF-005 explains why each of those round trips costs what it costs.

Measured impact

Captured with devtools-snippet-perf001.js against production, warm cache, Spain (EU) → /es-mx/reserva/crear.

Duplicate requests

The snippet surfaced a finding the waterfall alone does not show: 15 unique endpoints generate 32 HTTP requests within a single page load.

Recommended fix

1 · Identify the invariant schemas and request them in parallel

Schemas that are always needed regardless of booking type — guest details, room, rates — can be requested alongside the bootstrap schema rather than after it.

// 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 schemas on link hover

Warm the schemas when the user hovers the "New booking" link, using either a custom prefetch strategy or a direct HttpClient call.

3 · Merge bootstrap and default schema

Evaluate whether the backend can return the most common schemas inside /reservas/schemas/default, removing the separate round trips entirely.

4 · Deduplicate

Seventeen of the thirty-two requests repeat a schema already loaded. Add shareReplay(1) per URL in each schema service, or a shared Map<url, Observable> at interceptor level, so each unique endpoint is requested at most once per load. See PERF-011, which addresses the same class of problem at interaction level.

Evidence

Expected improvement

Based on the measured data. The savings in the first two rows overlap: the combined target is not their sum.

For users in Latin America at 300–500 ms RTT, every remaining serial hop is multiplied by an estimated 2 to 4× against the European baseline.

References

• web.dev — LCP · definition of the headline metric; understand what delays LCP before optimising it
• web.dev — Optimize LCP · full guide, with a section dedicated to eliminating resource load delay
• web.dev — Critical rendering path · why each additional network hop multiplies perceived latency
• High Performance Browser Networking — HTTP/2 (Ilya Grigorik) · the canonical chapter on multiplexing and head-of-line blocking; explains why HTTP/2 does not eliminate application-level chains
• RxJS — forkJoin · run independent observables in parallel and wait for all of them
• Chrome DevTools — network waterfall · measuring timings and visualising the dependency chain

Problem

All application styles are bundled into a single main.scss entry point that imports every section unconditionally:

CSS for sections not visible at initial render — billing, extra services, documentation, voucher, guided tour — is parsed and applied anyway, adding unnecessary style recalculation. The icon sprite (861 KB uncompressed, see PERF-014) and third-party styles are also loaded globally.

Core Web Vitals impact

CSS blocks rendering by design. Every extra kilobyte on the critical path delays FCP directly.

Measured impact

Captured with devtools-snippet-perf002.js, production, warm cache, Spain (EU) → /es-mx/reserva/crear.

Recommended fix

1 · Extract the critical CSS

Identify the styles needed to render the visible skeleton without shifting — grid, navigation bar, card container, field base — and inline them in a <style> block in the shell's index.html, or use Angular's inlineStyleLanguage with a critical CSS extractor.

2 · Lazy-load non-critical global styles

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

3 · Audit and remove unused global utilities

Run PurgeCSS, or @angular-builders/custom-webpack with a CSS tree-shaking pass, against actual template usage.

4 · Move route-specific styles into components

Billing, documentation and booking-detail styles should move their SCSS to component level. Worth verifying no duplication remains in the global bundle.

5 · Defer the assistant's stylesheet

It is third-party, render-blocking, fires at 2,673 ms, costs 108 ms per load even when cached, and is 99.3% unused at initial render. It should load asynchronously once the form is interactive, or only when the chat opens.

private loadAssistantStyles(): void {
  const link = document.createElement('link');
  link.rel = 'stylesheet';
  // URL taken from the <link> injected by the assistant script
  link.href = 'https://chat.assistant-vendor.com/...assistant-launcher.css';
  document.head.appendChild(link);
}

Evidence

Expected improvement

For users in Latin America at 300–500 ms RTT, the assistant-launcher.css round trip alone can cost 300 to 500 ms on a cache miss.

References

• web.dev — FCP · CSS blocks rendering by default and delays FCP directly
• web.dev — Eliminate render-blocking resources · how CSS blocks and which strategies reduce its impact
• web.dev — Defer non-critical CSS · loading non-critical CSS without blocking the render path
• web.dev — Extract critical CSS · inlining above-the-fold CSS to remove the round trip
• Chrome DevTools — Coverage tab · measuring the share of unused CSS and JS per load
• PurgeCSS · CSS tree-shaking based on real template usage
• Angular — Component styles · component-scoped styles to avoid unnecessary global CSS

Problem

The page requests resources from several external origins with no advance connection hint. The browser discovers those origins only after parsing HTML and CSS or executing JavaScript, and at that point it has to pay the full connection cost before receiving a single byte of content.

DNS resolution plus the TCP handshake plus TLS negotiation costs between 100 and 300 ms per origin from Spain, and it is paid in full during load.

Core Web Vitals impact

Measured impact

Recommended fix

1 · Static hints in the shell <head>

<!-- Critical preconnects: open the connection before JS triggers it -->
<link rel="preconnect" href="https://assets.tagmanager-vendor.com">
<link rel="preconnect" href="https://cdn.vantia.com" crossorigin>

2 · Programmatic hint for the maps SDK, on intent only

The map must not be preconnected at initialisation: PERF-013 is precisely about its eager loading. The hint is added when the user shows intent by hovering the address field.

// 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);
    }
  });
}

Called on the address field's mouseenter: by the time the script tag is added, the connection is already warm.

Evidence

Expected improvement

Each cold handshake removed saves 100 to 300 ms on fibre from Spain, at roughly 120 ms RTT to US-hosted origins. With three or four external origins, a total saving of 300 to 900 ms on first load is realistic.

For the Latin American market at 300–500 ms RTT the per-origin cost is 2 to 4× higher, so the improvement scales accordingly: between 600 ms and 1.6 s per cold load.

References

• web.dev — FCP · the metric most affected by external connection latency
• Ilya Grigorik — Eliminating Roundtrips with Preconnect · the reference article by the author of High Performance Browser Networking; explains the DNS, TCP and TLS layers and how preconnect removes each one
• web.dev — Preconnect to required origins · when to use preconnect rather than dns-prefetch
• MDN — Link types: preconnect · attribute specification
• Chrome DevTools — Network request timing · measuring DNS Lookup, Initial Connection and SSL per request
• web.dev — Resource hints · full guide to preconnect, dns-prefetch, preload, modulepreload and prefetch

Problem

The corporate fonts load as web fonts referenced by @font-face rules in the CSS. The browser cannot discover a font URL until it has:

• Downloaded and parsed the complete CSS bundle
• Found an element that needs that font
• Matched the @font-face rule

This three-step chain produces 300 to 600 ms of invisible or fallback text before the real face paints. FOUT and FOIT are two visible symptoms of the same discovery delay.

Core Web Vitals impact

Measured impact

Recommended fix

1 · Preload the critical variants in the <head>

<!-- Only the fonts on the critical rendering path -->
<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>

Only those used above the fold. Preloading every weight and style wastes bandwidth and competes with more critical resources.

2 · Add font-display: swap to every rule

@font-face {
  font-family: 'VantiaSans';
  src: url('../fonts/VantiaSans-Regular.woff2') format('woff2');
  font-display: swap; // text stays visible while loading
}

3 · Resolve the duplicates

Trace which two declarations reference the same Bold and Regular files, and consolidate them.

Evidence

Expected improvement

Preloading two or three critical files removes the discovery chain and can improve LCP by 200 to 400 ms on an uncached first visit, measured from the Spain/fibre baseline. Repeat visits are unaffected, since the fonts come from cache.

At 300–500 ms RTT the discovery delay is proportionally larger, putting the estimated improvement 2 to 4× higher: roughly 400 to 800 ms per cold load.

References

• web.dev — LCP · the LCP candidate is usually text that depends on the custom font
• Zach Leatherman — Comprehensive Guide to Web Font Loading Strategies · the definitive reference in this space; eleven-plus strategies with their trade-offs, FOUT, FOIT and the Critical FOFT pattern
• web.dev — Web font best practices · preload, font-display, self-hosting versus CDN, and their impact on Core Web Vitals
• web.dev / MDN — font-display · every descriptor value and when to use each
• CSS Font Loading API · detecting when a font is ready without polling or depending on CSS

Problem

The booking backend is deployed in the corporate cloud, in a US region, behind the corporate CDN. But the CDN effectively acts as a pass-through: every request is a cache miss, because the origin sends Cache-Control: no-cache, no-store, max-age=0 on all its responses. Every request reaches an origin that is nowhere near the users.

The server-timing header on each schema response states it unambiguously:

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

Confirmed measurements

Two captures, Chrome stable, Spain, 1 June 2026.

The HAR was captured on a single navigation to /reserva/crear. The snippet ran across a full session with form interactions, which is what exposes the real call volume and the cold starts beyond schemas/default.

Root causes

1 · The origin's own headers disable caching

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

no-store tells the CDN never to cache the response. The CDN infrastructure is already deployed and paid for: the headers are what stop it being effective.

2 · Cold-start penalty on schemas/default

The first schema request of each session takes 4,328 ms TTFB, of which 3,667 ms is spent at the origin. Subsequent ones drop to around 75 ms. That signature is consistent with lazy initialisation: connection pooling, VM warm-up or an on-demand computation.

3 · The origin is nowhere near the users

Even warm, a TTFB of 210–345 ms indicates real geographic distance between edge and origin. With 29 calls in the form load, that accumulates fast.

Recommended fix

Options by return on effort.

Option 1 · Remove no-store from the schema responses

Highest return, lowest effort. The infrastructure is already there; the only blocker is the origin's Cache-Control.

Cache-Control: private, max-age=30

Or, to let the CDN cache but not the browser:

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

Schema responses are largely deterministic per account and role. A short TTL with a cache key that includes the account identifier would be safe and effective, taking TTFB from ~235 ms to ~10–20 ms on cached responses.

Option 2 · Fix the cold start

The 3.67 s of origin time on the first call needs backend investigation. Likely causes: lazy service initialisation, connection pool expiry after idle, or an expensive first computation. Fixes: keep-alive connections, eager initialisation at deploy time, or a scheduled warm-up ping.

Option 3 · Regional gateway

Deploy a lightweight gateway near the market that terminates TLS regionally and proxies to the origin. Shortens the transatlantic leg regardless of caching policy.

Option 4 · Full regional deployment

Deploy the backend in a region close to the market. Maximum latency reduction; requires coordination with backend, infrastructure and the data residency and compliance teams.

Option 5 · Batch requests at the edge

Use CDN edge functions to batch several schema requests into a single round trip to the origin, reducing the number of trips even if the origin stays where it is.

Evidence

Expected improvement

The baseline figures reflect Spain on fibre. For the Latin American market at 300–500 ms RTT, warm TTFB is estimated between 500 and 900 ms per call, which worsens the cumulative session cost considerably (55 calls × ~700 ms average) and makes the caching fix proportionally more valuable.

References

• web.dev — Optimize TTFB · CDN strategy, response caching and Early Hints
• web.dev — LCP · every millisecond of TTFB delays LCP by the same amount
• web.dev — INP · interactions that trigger live calls also carry the geographic latency
• HTTP server-timing header · CDN and origin breakdown visible directly in the network panel
• High Performance Browser Networking — HTTP/2 · why latency dominates even with multiplexing
• Your CDN's HTTP response caching documentation · how it honours and overrides Cache-Control headers

Problem

Several sizeable JavaScript files load synchronously in the <head>, blocking parsing and rendering.

Core Web Vitals impact

Measured impact

Recommended fix

1 · Add defer to every static script in the <head>

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

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

2 · Delay the data layer injection

// 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)
    );
    // existing injection logic...
  }
}

3 · When to use async and when defer

Evidence

Expected improvement

Adding defer to the three static scripts removes the parse-blocking phase at 463 ms. On European desktop fibre FCP is already at ~643 ms, so the headroom under ideal conditions is modest — but the benefit multiplies on slow connections and at 300–500 ms RTT.

Delaying the data layer injection (269 KB, starting at 1,239 ms) to idle time additionally reduces TBT.

References

• web.dev — FCP · every blocking script delays the first pixel on screen
• V8 — The cost of JavaScript in 2019 (Addy Osmani) · essential reference from the V8 team: parse, compile and execute are three separate expensive phases; 300 KB of JS is not equivalent to 300 KB of image
• web.dev — Eliminate render-blocking resources · identifying what blocks FCP and moving it off the critical path
• MDN — <script> defer / async · execution order guarantees and timing relative to parsing
• MDN — requestIdleCallback · scheduling non-critical work in the browser's idle periods

Problem

Tag manager

• 466 KB compressed / 2.25 MB uncompressed across 13 requests: one main bundle and twelve extension files
• Queued at 4.06 s into the page lifecycle — injected dynamically by the shell, not a parser-discovered <script> tag
• Cold connection cost to the vendor CDN: DNS 10 ms + TCP 33 ms + SSL 18 ms = 61 ms of handshake before a single byte transfers
• EvaluateScript for the main bundle: a 51.3 ms long task on the main thread
• Not needed until the page is interactive

Virtual assistant (chat widget)

• 362 KB compressed / 3.1 MB uncompressed across more than 15 requests on first load, excluding API calls
• chat-launch.js and chat-loader.min.js each load twice: once from the page context and once from a high-priority parsed iframe. This is structural duplication caused by the eager initialisation pattern.
• Background activity continues for the whole session — polling was observed for over 8 minutes — even when the user never opens the chat
• Only needed when the user explicitly opens the chat; loads on every visit

Analytics beacons

Twelve beacons per page load to the collection endpoint. Each URL carries a unique random suffix, which is the platform's standard cache-busting mechanism, not a per-event identifier.

Personalisation tracker — newly identified

An additional tracker loads from a personalisation vendor's CDN. Its scope and impact are not yet measured. It should be included in the lazy-loading audit alongside the tag manager.

Measured impact

Recommended fix

Tag manager — load after interactivity

// Replace the eager script with a post-render injection
afterNextRender(() => {
  const script = document.createElement('script');
  script.src = '//assets.tagmanager-vendor.com/container-xxx.min.js';
  script.async = true;
  document.head.appendChild(script);
});

Assistant — load on user interaction only

// 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 {
  // inject the assistant script here, and only now
}

Analytics — batch the flag activations

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 {
  // send a single beacon with all pending activations
  this.flushScheduled = false;
  this.pendingActivations.length = 0;
}

Personalisation — audit and defer

Determine whether the personalisation script is needed for initial render. If not, apply the same afterNextRender() pattern.

Evidence

Expected improvement

• Deferring the tag manager takes 466 KB (2.25 MB uncompressed) and a 51.3 ms task off the critical path, and removes the 61 ms cold handshake for first-time visitors.
• Fixing the assistant initialisation removes the iframe duplication, takes more than 362 KB out of the initial load for the large majority of users who never open the chat, and stops the eight minutes of background polling.
• Batching the beacons removes seven of the twelve analytics requests per load.
• Auditing personalisation may yield further savings once its scope is measured.

References

• web.dev — INP · third-party scripts are the leading cause of poor INP: they compete with interaction handlers on the main thread
• Harry Roberts — Identifying, Auditing, and Discussing Third Parties · a framework for auditing, classifying and negotiating third-party cost with stakeholders
• web.dev — Best practices for tags and tag managers · when to load them and how to measure their real Core Web Vitals impact
• web.dev — Third-party JavaScript · impact, diagnosis and mitigation: facades, lazy loading, Partytown
• Chrome DevTools — Identify slow third-party scripts · isolating cost per origin from the Performance panel
• Angular — afterNextRender · the correct hook for deferring work until after the first render cycle

Problem

Two large lazy-loaded chunks are required to render the form, but are only discovered after the initial bundle executes.

Because the chunks are discovered through dynamic import(), the browser cannot begin requesting them until the Angular router runs, which in turn depends on the main bundle being parsed and executed. The result is a serial dependency where 2.8 MB of critical code waits behind the bundle.

Core Web Vitals impact

Measured impact

Recommended fix

Add modulepreload hints in the shell <head>:

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

1 · Build-time generation

// scripts/inject-modulepreload.js (inside the build pipeline)
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}">`);
// inject into the shell template...

2 · Named chunks

The build already sets namedChunks: true. It only remains to map names to hashed files in a build artifact manifest.

3 · Coordination with the platform team

If the shell is generated by the corporate platform, the modulepreload hints need to be included in its own pipeline.

Evidence

Expected improvement

The two measured gaps total ~1,550 ms on fibre. Preloading both chunks in parallel with the main bundle can remove them, for a TTI improvement of 500 to 1,500 ms.

At 300–500 ms RTT each discovery round trip costs considerably more, and the improvement is estimated 2 to 4× higher. The Spain/fibre values are a lower bound.

References

• web.dev — LCP · critical chunks on the render path delay LCP directly
• web.dev — Module preload · rel=modulepreload versus rel=preload: semantic differences and module graph pre-reading
• MDN — <link rel="modulepreload"> · specification: as, crossorigin and ES module integration
• Angular — Lazy loading feature modules · how Angular generates chunks with loadChildren and its effect on the graph
• Angular CLI — --stats-json · identifying the largest chunks and their dependency tree

Problem

Once the form is complete, the user navigates to /reserva/confirmada. At that point the browser has to:

• Request the confirmation page's HTML and assets
• Download the lazy chunk for the confirmation container
• Make the API calls that confirm the booking

There is no prefetch strategy for this route. The delay lands exactly where frustration is most expensive: the user has already invested minutes of work and is committing to a purchase.

Core Web Vitals impact

Measured impact

Recommended fix

Inject the speculation rules once the user has shown real progress through the form — for example, on validating the first step — rather than on page load.

// In comfortable-navigation.component.ts — from viewSummary()
// or from the showViewSummaryButton$ subscription
private injectSpeculationRules(): void {
  if (!HTMLScriptElement.supports?.('speculationrules')) return;         // detection
  if (document.querySelector('script[type="speculationrules"]')) return; // already injected

  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);
}

For browsers without support — Safari and Firefox — fall back to a standard prefetch:

<!-- Fallback for browsers without Speculation Rules -->
<link rel="prefetch" href="/booking/es-mx/reserva/confirmada">

moderate avoids spending bandwidth on users who abandon the form early.

Evidence

Expected improvement

For the Latin American market at 300–500 ms RTT, the baseline is estimated between 3 and 6 s and the projected improvement scales in the same proportion.

References

• Chrome Developers — Prerender pages for instant navigations · full guide: eagerness levels, prerendering restrictions and behaviour on authenticated pages
• MDN — Speculation Rules API · specification: JSON syntax, prefetch and prerender fields, eagerness and where selectors
• web.dev — <link rel="prefetch"> · the fallback that works in Safari and Firefox
• Chrome DevTools — Debug Speculation Rules · rule status, errors and active prerendered pages

Problem

The compact form view renders every section in the DOM at once, even though only one is visible at a time. The summary panel additionally renders the full state of every completed step.

The browser lays out, recalculates style and paints all DOM nodes regardless of visibility. With fifteen or more sections mounted — billing, extra services, guest details, documentation and the rest — that is a lot of unnecessary render work. The step configuration defines more than thirty components, and all of them can exist in the DOM during transitions.

This is a problem felt most on modest devices, where the bottleneck is rendering rather than the network.

Core Web Vitals impact

Measured impact

Recommended fix

Option A · CSS content-visibility, no JavaScript changes

// In the compact form section styles
.booking-form-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 300px;  // approximate height, avoids CLS
}

Option B · Angular @defer (on viewport) — recommended

This additionally defers component initialisation and change detection, not just layout and paint.

<guest-details-form [state$]="state$" />   <!-- critical: always -->

@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>
}

Evidence

Expected improvement

Applying content-visibility: auto or @defer (on viewport) excludes off-screen sections from the layout pass and brings the dirty node count down to the 40–60 actually in the viewport. Expected improvement: a 40 to 60% reduction in layout and paint time. On modest devices, 200 to 500 ms off Time to Interactive and noticeably smoother scrolling.

The expected remote-market multiplier is 2 to 4×, and here it is driven by weaker hardware rather than the network.

References

• web.dev — INP · less layout and paint work means faster interaction response
• web.dev — content-visibility: the new CSS property that boosts your rendering performance (Una Kravets and Vladimir Lebedev) · the original article, with measurements showing up to 7× reductions in render time
• MDN — content-visibility · the auto, hidden and visible values and their relationship to CSS containment
• MDN — contain-intrinsic-size · reserving space to avoid CLS when content-visibility: auto skips layout
• Angular — @defer blocks · on viewport, on idle and on interaction triggers, plus @placeholder, @loading and @error blocks

Problem

Network analysis shows several endpoints being called far more often than necessary.

Every duplicate call wastes a 150 to 250 ms round trip against the Spain/fibre baseline, backend CPU for an identical request, and 50 to 200 KB of the user's bandwidth per response.

Core Web Vitals impact

Measured impact

Recommended fix

Level 1 · debounceTime and distinctUntilChanged

formValueChanges$.pipe(
  debounceTime(300),
  distinctUntilChanged((a, b) => isEqual(a, b)),           // ignore identical payloads
  switchMap((payload) => this.schemaService.fetch(payload)), // cancel in-flight
)

switchMap is the critical operator: it cancels in-flight requests when a new trigger arrives, preventing an older response from landing after a newer one.

Level 2 · Deduplicate in-flight requests

// libs/shared/schemas/data-access — deduplication layer
@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>;
  }
}

Use a hash of the booking payload as the key.

Level 3 · Cache deterministic responses

For endpoints whose response is deterministic given the same input payload, cache client-side keyed on the payload hash, and invalidate when the booking state resets.

Evidence

Expected improvement

After a single interaction, 57 calls are observed where roughly 40 are expected: 17 surplus round trips. At 150 to 670 ms each against the Spain/fibre baseline, removing them cuts the estimated wasted network time from ~21.8 s to essentially zero.

At 300–500 ms RTT the gain scales in the same proportion: the fix is worth considerably more to the priority market than the European figures suggest.

References

• web.dev — INP · interaction-triggered duplicate calls degrade INP directly
• RxJS — switchMap · cancels the previous observable when a new emission arrives; the antidote to reactive cascades
• RxJS — debounceTime · suppresses intermediate emissions over an interval; essential on form changes
• RxJS — share · multicasting a cold observable so several subscribers share one execution
• RxJS — distinctUntilChanged · prevents emissions when the value has not changed; the necessary companion to debounceTime
• Angular — HttpClient · interceptors as the centralised point for caching and deduplication

Problem

The booking engine's TTFB sits around 250 ms, and in the capture below it measured 338 ms. For that entire window the browser has sent its request and received nothing: it cannot start requesting any resource because it does not yet know what they are.

HTTP/2 103 Early Hints lets the server send a preliminary response carrying Link preload headers before the full HTML response is ready. The browser can act on those hints immediately.

Core Web Vitals impact

The technique pays off precisely when TTFB is high, which per PERF-005 is the normal condition here.

Measured impact

Cold connection — 2 June 2026, Spain → /es-mx/

The 338 ms TTFB is above the ~250 ms baseline in PERF-005, consistent with server variability. DNS, TCP and TLS together total around 81 ms: four times less than TTFB alone, which makes the idle window the dominant cost by a wide margin.

Warm connection — HTTP/2 reuse

Warm TTFB is lower because there is no connection cost, but it is still 228 ms during which nothing can download.

Absence of hints confirmed at both layers

• HTTP layer — the response headers contain no Link: header, so Early Hints is not in operation.
• HTML layer — the resource hints snippet confirms there is no application-owned <link rel="preload"> or <link rel="preconnect"> in the DOM. The first critical resource starts at 463 ms, against an HTML responseStart of 403 ms.

Recommended fix

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;
}

At the CDN

Most modern CDNs offer Early Hints as a one-click option, and some even infer the Link headers from the previous HTML response. The specific assets to preload should come from the build's stats.json: the initial CSS and JS chunks needed on every load.

Evidence

Expected improvement

103 Early Hints can recover up to ~413 ms of idle time per cold load. Critical resources would begin downloading during the TTFB wait rather than after it.

References

• web.dev — FCP · Early Hints brings asset download start forward into the idle window
• Chrome Developers — HTTP 103 Early Hints · full guide with examples, real-world impact and server support
• RFC 8297 — An HTTP Status Code for Indicating Hints · specification: 103 semantics, supported Link fields and expected client behaviour
• Your CDN's Early Hints documentation · enabling it and automatic Link header inference
• web.dev — Optimize TTFB · Early Hints within the broader TTFB work: CDN, HTML streaming and edge caching

Strategic framing

Problem

The SDK is only needed when the user focuses an address field and types (autocomplete), when they select a suggestion (geocoding to extract the address components), or when they view the property map, which is a different route entirely and unrelated to /reserva/crear.

Root cause — two triggers, not one

Trigger 1, primary · constructor subscription

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

private readonly placesLibraryStatus =
  toSignal(this.mapsApiService.placesLibraryStatus$, {
    requireSync: true,   // ← synchronous subscription at construction
  });

placesLibraryStatus$ derives from api$, which injects the SDK's <script> tag into the DOM:

Form renders
  → AddressInputComponent constructed
    → toSignal(placesLibraryStatus$, { requireSync: true })
      → placesLibraryStatus$ → api$
        → <script src="maps.geo-vendor.com/..."> injected
          → network request at 4,716 ms   ← confirmed in the trace

It is unconditional: it fires whether or not the user ever touches an address field.

Trigger 2, secondary · preloadLib() after view init

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

Because api$ is memoised, the script is injected only once, so trigger 1 wins the request. But preloadLib() would cause it anyway if the first were removed. Both had to be fixed.

Fix applied

Fix 1 · Do not subscribe to SDK status in the constructor

The component used placesLibraryStatus$ only to decide which interface to show: search field if the SDK loaded, manual field if it failed or was still loading. That pattern forces an SDK load purely to paint the interface.

Replace it with an optimistic value: show the search field by default, assume the SDK will be available, and fall back to the manual field only on a real failure. The loading skeleton is unnecessary: the user gains nothing from knowing the SDK is initialising before they touch the field.

// Before — triggers the SDK load at construction:
private readonly placesLibraryStatus =
  toSignal(this.mapsApiService.placesLibraryStatus$, { requireSync: true });

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

// After — nothing loads until there is interaction.
private readonly mapsLoadFailed = signal(false);

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

// Called by AddressSearchInputComponent when the SDK fails:
onMapsLoadFailed(): void {
  this.mapsLoadFailed.set(true);
}

Fix 2 · Move preloadLib() to the focus event

// After: the SDK loads only when the user shows intent
private handleTextInputFocus(): Subscription {
  return fromEvent(this.textInput, 'focus').subscribe(() => {
    this.autocompleteApiService.preloadLib();    // ← on first focus
    if (this.currentPredictions().length > 0 || this.showLastAutocompleteOption()) {
      this.showDropdown();
    }
  });
}

preloadLib() already has an internal guard, so calling it on every focus is safe: the script is injected only once.

Optional improvement · preconnect on hover

With the eager load removed, a preconnect to the SDK domain on the address container's mouseenter gives the browser a head start on the handshake before the user reaches the field. This matters most where RTT is high.

Evidence

Improvement achieved

The baseline is Spain (EU) on fibre: the best possible case. At 300–500 ms RTT and on modest devices, the "before" figures were 2 to 4× worse.

References

• V8 — The cost of JavaScript in 2019 (Addy Osmani) · the cost of parsing, compiling and executing beyond download size; the key data point for justifying lazy loading to stakeholders
• web.dev — Third-party JavaScript · impact, diagnosis and mitigation: facades, lazy loading, Partytown
• web.dev — Facade pattern for third-party embeds · replacing a heavy third party with a lightweight placeholder until interaction
• Maps SDK documentation — dynamic library import · loading only the libraries you need, on demand
• MDN — focus event · propagation, focusin as the delegable alternative, and differences from click

Problem

design-system-icons.svg is the corporate design system's icon sprite and loads as a static asset on every page. It is referenced in the project's asset configuration:

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

This monolithic asset blocks the two-second render milestone and contributes to Total Blocking Time.

Core Web Vitals impact

Icon usage audit

Recommended fix

Step 1 · Audit usage — done

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

Result: 76 unique icons across all templates, out of 694 available.

Step 2 · Generate a custom sprite — preferred

// scripts/build-icon-sprite.js — inside the build pipeline
const svgstore = require('svgstore');
const usedIcons = require('./used-icons.json');   // output of step 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());

Then swap the asset glob for the generated sprite.

Step 3 · Inline the icons visible on load

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

Step 4 · Lazy load — fallback if a custom sprite is not 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);
});

Evidence

Expected improvement

On the Spain/fibre baseline the sprite starts at 3,077 ms and takes 244 ms, completing around 3,321. At 300–500 ms RTT, the download window for 861 KB is estimated 2 to 3× longer, adding two or three seconds for the priority market.

• Custom sprite (steps 1–2): removes the two-second render block on fibre, and pays off proportionally more on constrained connections.
• Inline icons (step 3): appear immediately, at zero network cost.
• Lazy loading (step 4): defers the 861 KB until the page is interactive.

References

• web.dev — LCP · the sprite competes with critical path resources and delays LCP directly
• SVGO · the most widely used SVG optimiser; shrinks each icon before the sprite is composed
• svgstore · generating sprites by concatenating icons as <symbol> elements
• svg-sprite · a more complete alternative: generates sprites in several modes (inline, CSS, view, defs)
• MDN — SVG <use> element · href referencing, shadow DOM behaviour and cross-origin restrictions

What it would take to close the gaps

• One capture from the priority market. This is the highest-value contribution available. It turns fourteen extrapolations into fourteen measurements.
• A US baseline. It settles the argument about how much of the TTFB is distance and how much is origin processing.
• Continuous monitoring. This report is a snapshot. Without field data and regression tests, there will be no way to know in three months whether the fixes held.