Add floors.js to SvelteKit

How it works

floors.js runs completely outside Svelte's component model. It loads as a standalone script that patches the browser's history APIs — pushState, replaceState, and the popstate event — to detect SvelteKit's client-side routing.

When a visitor navigates from /about to /blog/my-post, SvelteKit uses pushState under the hood, and floors.js picks that up automatically. No Svelte stores, no actions, no lifecycle hooks needed. It doesn't touch your component tree at all.

Because it operates at the browser level, it works with every SvelteKit routing pattern — file-based routes, dynamic params, route groups, and layouts.

Installation

Add the floors.js script tag to your src/app.html file, right before the closing </body> tag.

Replace flr_... with your site key from the floors.js dashboard. The script loads asynchronously and won't block SvelteKit's hydration.

Works with SvelteKit routing

SvelteKit's file-based routing maps directly to floors.js rooms. Every route in your src/routes/ directory becomes a room.

• Static routes — routes/about/+page.svelte → the /about room
• Dynamic params — routes/blog/[slug]/+page.svelte → each blog post is its own room
• Route groups — routes/(app)/dashboard/+page.svelte → the /dashboard room
• Nested layouts — layouts don't affect room assignment; only the final URL matters

No configuration needed. A visitor on /pricing and a visitor on /docs are in different rooms. They see each other when they're on the same route.

Configuration

All configuration is done via data- attributes on the script tag. No JavaScript API needed.

• data-key (required) — your site key, used to group visitors across your domain
• data-server (optional) — custom WebSocket server URL if you're self-hosting
• data-name (optional) — pre-set the visitor's display name instead of generating a random one

FAQ