Removing Sanity Studio from Next.js build for faster load times

Based on your concern about the Sanity Studio adding significant bundle size to your Next.js build, there are several effective strategies you can use:

1. Use Dynamic Imports with SSR Disabled (Quick Fix)

The most common solution is to dynamically import the Studio component with SSR disabled. In your Studio route (typically app/studio/[[...index]]/page.tsx), use:

import dynamic from 'next/dynamic'
import config from '@/sanity.config'

// Dynamically import with SSR disabled
const NextStudio = dynamic(
  () => import('next-sanity/studio').then(mod => mod.NextStudio),
  { ssr: false }
)

export default function StudioPage() {
  return <NextStudio config={config} />
}

This prevents the Studio from being included in your server-side bundle and only loads it client-side when users actually visit the /studio route.

2. Use Route Groups to Isolate the Studio

Structure your Studio in a route group to better isolate it from your main site:

app/
  (site)/          # Your main website routes
    page.tsx
    layout.tsx
  (studio)/        # Isolated studio routes
    studio/
      [[...index]]/
        page.tsx

This organizational approach, combined with dynamic imports, helps keep the Studio completely separate from your main application bundle.

3. Deploy Studio Separately (Best for Production)

For the cleanest separation and smallest bundle size, deploy your Studio as a completely separate application:

Option A: Separate Vercel/hosting deployment

• Create a standalone Studio project using npm create sanity@latest
• Deploy it to a subdomain like studio.yoursite.com or yoursite.com/admin using Vercel rewrites
• Your main Next.js site won't include any Studio code

Option B: Use Sanity's managed hosting

• Deploy your Studio to Sanity's hosting at yourproject.sanity.studio
• This is the simplest approach and completely removes Studio from your Next.js bundle

4. Verify Bundle Exclusion

After implementing dynamic imports, you can verify the Studio isn't in your main bundle by:

npm run build

Check the build output - the Studio route should show as a separate client-side chunk, and your main pages should have significantly smaller "First Load JS" sizes.

Why This Matters

The next-sanity package includes the entire Studio application when you embed it, which can add several hundred KB to your bundle. Since most site visitors never need to access the Studio (only content editors do), it makes sense to code-split it away from your public-facing pages.

The dynamic import approach is the easiest to implement if you want to keep everything in one codebase, while separate deployment gives you the cleanest separation and best performance for your public site.