How to Fix: Google fonts are not being bundled in Next.js 15 turbopack dev builds
Aldawsari Next.js 15 Turbopack dev mode can render Google Fonts correctly in CSS while still failing to bundle the actual font files, which is why text may fall back inconsistently or fonts appear missing even though next/font/google is configured properly. This usually shows up only in development builds with Turbopack, while production builds behave normally.
Table of Contents
Understanding the Root Cause
This issue is tied to how Next.js 15 handles font optimization through next/font/google when running next dev --turbopack. In a normal flow, Next.js fetches the Google Font at build time, rewrites it into local assets, and serves those files from the app so the browser does not need to request them directly from Google.
In this bug, the Turbopack development pipeline does not consistently emit or serve those generated font assets. The CSS class created by next/font/google may still be applied, which makes the setup look correct at first glance, but the font files themselves are not bundled into the dev output as expected.
That explains the symptoms:
- The font import code looks valid.
- The generated class name appears in the DOM.
- The browser cannot load the expected local font asset in dev mode.
- Webpack-based dev or production builds may work correctly, making the bug look environment-specific.
So the problem is not usually your Tailwind config, your CSS variables, or the Google Font definition itself. The real issue is a bundling regression in Turbopack dev mode.
Step-by-Step Solution
The most reliable fix right now is to avoid Turbopack for development until the bug is resolved upstream, or to use a local font fallback strategy if you must stay on the same toolchain.
1. Confirm that the problem only happens in Turbopack dev
If your app currently starts like this:
next dev --turbopackswitch temporarily to standard dev mode:
next devIf the font starts working normally, you have confirmed this is the Turbopack-specific bug.
2. Update your package scripts
In package.json, replace the development script so local development uses the stable bundler:
{
"scripts": {
"dev": "next dev",
"build": "next build",
"start": "next start"
}
}This is the simplest and safest workaround for teams blocked by broken font loading.
3. Keep using next/font/google correctly
Your font setup should still follow the standard Next.js pattern. For example:
import { GeistMono } from 'next/font/google'
const geistMono = GeistMono({
subsets: ['latin'],
variable: '--font-geist-mono'
})
export default function RootLayout({ children }) {
return (
<html lang="en" className={geistMono.variable}>
<body>{children}</body>
</html>
)
}If you are using Tailwind, map the font variable into your theme or utility classes as usual. The font definition is not the root bug here.
4. Use a local font as a temporary workaround if needed
If your project must run with Turbopack dev and you cannot tolerate missing font assets, move the font to a local file and load it with next/font/local.
import localFont from 'next/font/local'
const mono = localFont({
src: './fonts/YourMonoFont.woff2',
variable: '--font-mono',
display: 'swap'
})
export default function RootLayout({ children }) {
return (
<html lang="en" className={mono.variable}>
<body>{children}</body>
</html>
)
}This bypasses the Google font fetch-and-bundle path that is affected by the bug.
5. Clear the build cache after changing font behavior
Old generated assets can make testing confusing. Remove the Next.js cache before re-running dev:
rm -rf .next
next devOn Windows PowerShell:
Remove-Item -Recurse -Force .next
next dev6. Verify in the browser network panel
Open DevTools and filter by Font. In a healthy setup, you should see local font files being served successfully. If requests are missing or returning errors only under Turbopack dev, that confirms the bundling issue rather than a styling mistake.
7. Track the upstream fix
Because this is a framework-level regression, the permanent fix will come from Next.js updates. Monitor the related GitHub issue in the Next.js issue tracker and test again after upgrading:
npm install next@latest react@latest react-dom@latestCommon Edge Cases
- Tailwind font variable mismatch: If your font variable name in
next/fontdoes not match what Tailwind expects, the fallback font will be used even without the Turbopack bug. - Testing only in production:
next build && next startmay work fine. That does not mean dev mode is healthy. - Multiple font imports: Importing several Google fonts can make it harder to identify which one is failing to emit assets.
- Cached browser font responses: A previously loaded font can hide the issue temporarily. Use a hard refresh or an incognito window.
- Monorepo path issues: If you switch to
next/font/local, verify the font file path resolves correctly relative to the importing file. - Mixing App Router and legacy patterns: Keep your font definition in the root layout when using the App Router, otherwise class application can become inconsistent.
FAQ
Is this a Google Fonts issue or a Next.js issue?
It is primarily a Next.js 15 Turbopack development bundling issue. Google Fonts are not the real problem; the generated local assets are not being handled correctly in this environment.
Why does the font class appear in the DOM if the font is not working?
Because next/font/google still generates the CSS class and variable. The failure happens later, when the actual font file should be emitted and served by the dev bundler.
Should I stop using next/font/google?
No. next/font/google is still the recommended approach. The practical workaround is to use standard Next.js dev mode instead of Turbopack for now, or temporarily switch to local fonts if your workflow requires it.
Bottom line: if Google Fonts are not being bundled in Next.js 15 Turbopack dev builds, the fastest production-safe fix is to run next dev without Turbopack, keep your existing next/font/google setup, and retest after upgrading Next.js once the upstream patch lands.