App Router or Pages Router: where exactly do you load the snippet?
In the Next.js App Router, the snippet belongs in the root app/layout.tsx so it loads on every route without repeating it in each page.tsx. In the classic Pages Router, add it instead to pages/_document.tsx inside the <Head> section, because _app.tsx re-runs on every client-side navigation and could otherwise include the script multiple times. In plain React without a framework, a <script> tag in the public/index.html is enough. In all three cases the snippet stays active regardless of which route the user is currently on.
Client-side routing and dynamic content
In single-page apps the view changes without a full reload, since the router only swaps parts of the DOM. nootiz records the current URL, including query parameters, with every note, so a route's state stays reliably reproducible. For content that loads after the initial render via a fetch call – a product list or a dashboard widget, for example – the note simply attaches to the element the user actually sees at the moment of feedback, regardless of when it loaded.
How do you load the snippet without hurting load time?
In Next.js, next/script with the „afterInteractive“ strategy is the recommended approach: the snippet loads once the page has become interactive, so it blocks neither the first render nor your Core Web Vitals. In plain React, an async or defer attribute on the <script> tag achieves the same effect. In practice the load-time difference between a version with and without nootiz becomes unmeasurable, which matters especially on performance-sensitive marketing pages.
Per-pull-request preview deployments
Vercel, Netlify and Cloudflare Pages create a dedicated preview URL with a full build for every pull request by default. With the snippet in your root layout, feedback works in every one of those previews immediately – no extra setup per branch and no reviewers manually pasting screenshots into tickets. This is especially useful for design reviews before merging, since product owners and clients comment directly on the real rendered version instead of a Figma export.
Loading it in staging only: how do you keep production clean?
If the tool is only used for internal sign-off and QA, simply leave the snippet out of production and only serve it when an environment variable like NEXT_PUBLIC_ENABLE_NOOTIZ, or a check like process.env.VERCEL_ENV === 'preview', evaluates to true. That keeps your production bundle marginally smaller and end users never see a feedback icon, while preview and staging deployments keep working unchanged.
Do clients need a GitHub or Vercel account to comment?
No. Clients and stakeholders just open the shared preview or staging URL in their browser and place notes there, with no repository access, no Vercel team membership and no need to understand branches or deployments. That's the key advantage over plain code-review comments on pull requests, which require technical understanding and usually stay out of reach for non-technical participants.
Where are the honest limits in React and Next.js setups?
Server Components, which never execute in the browser, obviously cannot embed the snippet themselves – it always has to load through a client component or the root layout that ships server-rendered HTML to the browser. With very aggressive preloading or prefetching of individual routes, there can occasionally be a brief moment where an element in a not-yet-fully-hydrated component isn't clickable yet; waiting a moment after the route change reliably resolves that.
