# Introduction


If you haven't turned on tracing yet, start with [turn on tracing](/docs/svelte/getting-started/quick-start#turn-on-tracing) in the quick start. This page covers the Svelte-specific half: naming navigation spans after your SvelteKit routes. You can stop after the error reporting steps in the quick start and come back to this later. It isn't required to get errors into Flare.

On its own, `@flareapp/js` already traces page loads, client side navigations, and the `fetch`/`XMLHttpRequest` calls your page makes. This includes plain Svelte, without SvelteKit: the base client watches `history.pushState`, `history.replaceState`, and `popstate` itself, so a `browser_navigation` span opens whenever the path changes, no framework code required. What plain Svelte doesn't have is a router for Flare to read a route pattern from, so that span only knows the raw path, for example `/products/482`.

`@flareapp/sveltekit` adds the route pattern, through `traceSvelteKitRouter()`. This is SvelteKit only: plain Svelte has no router integration, so its navigation spans keep the raw path name described above.

## Setting up the router integration

Call `traceSvelteKitRouter()` once, from `src/hooks.client.ts`:

```ts
// src/hooks.client.ts
import { traceSvelteKitRouter } from '@flareapp/sveltekit/client';

traceSvelteKitRouter();
```

Unlike a router integration in other frameworks, `traceSvelteKitRouter()` takes no arguments. It reads SvelteKit's own reactive navigation state directly, through `$app/state`'s `page` and `navigating`, so there is no router instance to pass it.

It also replaces the base client's own History-based navigation detection, so a navigation is only ever traced once, not twice.

## What the router integration adds

Without `traceSvelteKitRouter()`, a `browser_navigation` span only knows the path it navigated to, for example `/products/482`. With it registered, the span also contains SvelteKit's own route ID, taken from `page.route.id` verbatim, for example `/products/[id]`, so every navigation to a product page groups together on the Pages table instead of becoming one entry for every product. When you open a single trace, you still see the path. Flare uses the route ID to group pages, not to name the span. The `browser_pageload` span for the very first load gets the same route ID. See the screenshot on the [quick start](/docs/svelte/getting-started/quick-start#trace-navigations) for what a navigation span looks like in a trace.

## What doesn't open a navigation span

`traceSvelteKitRouter()` follows SvelteKit's own navigation lifecycle, so a few things that change the URL don't open a `browser_navigation` span:

- Shallow routing, `pushState()` or `replaceState()` imported from `$app/navigation`, since SvelteKit treats those as history updates, not page navigations.
- A hash-only change to the URL.
- A navigation a `beforeNavigate` guard in your app cancelled.
- A navigation to a route SvelteKit itself doesn't own, since that unloads the document; the next `browser_pageload` span covers it instead.

## Stopping the router integration

`traceSvelteKitRouter()` returns a stop function:

```ts
const stopTracingNavigations = traceSvelteKitRouter();

// Later, for example when tearing down the client in a test:
stopTracingNavigations();
```

Calling it stops opening navigation spans from SvelteKit's router state. You only need this if you tear down or reinitialize the client while your app keeps running, for example in a test.

## Read more

- [Sampling](/docs/javascript/tracing/sampling): control how many traces get sent.
- [Manual spans](/docs/javascript/tracing/manual-spans): time your own code inside a trace.
- [Profiling introduction for Svelte](/docs/svelte/profiling/introduction): time component mounts inside a trace.