---
title: Optimization
description: Reference page for optimization.
group: reference
---
Use this guide when you care about banner visibility speed, route static-ness, and reducing backend round-trip cost.

Why this helps:

* Same-origin requests avoid extra DNS/TLS setup in many deployments
* Ad blockers are less likely to block your init endpoint
* You can change backend infrastructure without touching client code

In production benchmarks with a same-origin rewrite, prefetching strategies show measurable improvement over client-only init:

|Strategy|Scripts loaded|Data request starts|Banner visible|
|--|--|--|--|
|Client-only (no prefetch)|baseline|baseline|baseline|
|Browser prefetch|\~1.3x faster|\~2.6x earlier|\~1.25x faster|
|Server prefetch|\~2x faster|before page loads|\~1.9x faster|

## Keep The Provider Mounted Across Navigation

Mount the consent provider at the app root so route transitions do not remount it.

Why this helps:

* Avoids re-running init work on client-side navigation
* Prevents extra callback churn from remount cycles
* Keeps banner/dialog state stable between route transitions

## Animation Performance

The default motion tokens are tuned for speed-first product UI:

|Token|Duration|Used for|
|--|--|--|
|`fast`|80ms|Banner slide + overlay, card scale, button hover, widget entry/exit|
|`normal`|150ms|Accordion, switch toggle|
|`slow`|200ms|Dialog trigger snap, tab indicator|

These defaults follow the principle that product UI should be fast and purposeful — animations exist for spatial continuity, not decoration. In benchmarks, animation duration contributes a constant floor to "data fetched → banner visible" timing. The default tokens sit at the lower end of standard UI ranges (80-200ms) to minimize that floor.

If you must use a cross-origin backend URL, add preconnect so the browser starts DNS/TLS early: