Pick the loading strategy on purpose
| Strategy | When it loads | Use case |
|---|---|---|
beforeInteractive | Before hydration | Critical: bot detection, consent banners |
afterInteractive (default) | After hydration | Analytics, tag managers |
lazyOnload | During idle time | Chat widgets, social embeds |
worker | In a web worker | Heavy compute that shouldn't block main thread |
One rule
beforeInteractive is allowed only inside the root layout (it injects into the document head). Anywhere else it's a runtime error.
Choose a Script strategy from dependency order and user impact. Use beforeInteractive only for code that must precede hydration, default to afterInteractive for ordinary analytics, and defer nonessential widgets with lazyOnload. Give every script a stable identity. Verify that core content remains readable when a script fails or is blocked. An optional analytics or advertising script must not stop the application's own interactions.
Moving a third-party script later reduces contention but does not make it trustworthy or cheap. Consent, content security policy, failure isolation, data collection, and vendor downtime remain product concerns. Record the network waterfall and main-thread tasks with the script enabled, blocked, and slow. Verify hydration order, consent behavior, duplicate insertion across navigation, CSP violations, and that core interaction still works when the vendor never loads.