Lighthouse scanning performance issue: Page prevented back/forward cache restoration

[TrustyTechSG]

Hi there, I notice my next site have lighthouse performance issue saying 'Page prevented back/forward cache restoration', anyone know how to solve it? big thanks

[icyJoseph]

Got anymore insight into your project? Does it happen if you run the report from an incognito window?

[JamesSingleton]

I am also getting this, it happens when I run npm run build && npm start locally in an incognito window as well as when I run my website against https://pagespeed.web.dev.

[riosant]

Does anyone found any solution for this??

[SakarDev]

I had same back/forward cache problem saying Pages that use WebXR are not currently eligible for back/forward cache. but i haven't used webXR and based on my researches there are 3 things that may cause that error:

• unload event
• beforeunload event
• Cache-Control: no-store

But i didn't use any of that.

Lighthouse was not clear what exactly was causing that error so i did the following to get an insightful answer:

i opened application tab and under Background Services opened Back/forward cache tab and pressed the button Test back/forward cache and the message was clear

the page has an unload handler in a sub frame. Learn more: Never use unload handler UnloadHandlerExistsInSubFrame
1 frame:
https://newassets.hcaptcha.com/captcha/ // .....and the rest of the link

So i discovered an unload handler in an hCaptcha subframe was blocking the cache. Thus, the @hcaptcha/react-hcaptcha package was impacting cache behavior.

Also a youtube link of ReactPlayer was causing same issue.

[tugay-ken]

@SakarDev and how did you solve it?

[SakarDev]

I had to remove @hcaptcha/react-hcaptcha package.

[NicolasCharpentier]

For me, serving the application locally but in standalone mode after building it.

I do have the warnings after running Lighthouse

When analyzing as suggested by @SakarDev I see that some responses disable the BFC because of a Cache-Control: no-store header in requests they name "JavaScript network request"

But in every JS request, i never see such header

So my probably wrong guess is, that Chrome is talking about the DOC page header

and if so, it could be normal (again an interpretation from me) since Next say in their docs that they do the client-caching themselves and (here comes the interpretation) not the browser default way so disabling cache headers

https://nextjs.org/docs/app/building-your-application/caching#4-nextjs-caching-on-the-client-router-cache

As i'm probably wrong, i'm curious to see if anyone finds the reason. I don't see anything else

[syi0808]

I found solution.
According to https://nextjs.org/docs/app/api-reference/file-conventions/route-segment-config .
Add export const dynamic = 'force-static'; in layout.tsx or page.tsx.
It probably solve your problem.
But, it can makes new problem because it's break next.js automatic cache control.

[SalahAdDin]

So, we will need to ignore this issue, right?

[engageintellect]

bump - me too. 😅

[syi0808]

Check this comment. #57644 (reply in thread)

[SalahAdDin]

It is not the solution.

[scottquested]

Same here +1

[littleblack111]

same here

[DarioLopes]

Same here, has anyone found a solution or what could be the culprit?

[SamuelSmeys]

Same here, would be great to know if anyone knows what the issue could be.

[nikolayemrikh]

The no-store header sent on HTML documents disallows bfcache.

By default, Next.js sends the Cache-Control header with the value private, no-cache, no-store, max-age=0, must-revalidate for HTML requests.

It is possible to change this behavior and override the Cache-Control header only for HTML page requests (not for other files) by using middleware:

middleware.ts

export async function middleware(request: NextRequest) {
  response.headers.set('Cache-Control', 'public, no-cache, max-age=0, must-revalidate');
  return response;
}

export const config = {
  matcher: [
    '/((?!api|_next/static|_next/image|favicon.ico|sitemap.xml|robots.txt).*)',
  ],
}

I took the matcher config from here:
https://nextjs.org/docs/app/building-your-application/routing/middleware#matcher

This pattern ensures that the middleware is applied only to HTML page requests.

[nikitafloy]

You shouldnt use this way
There is right answer: https://nextjs.org/docs/app/api-reference/file-conventions/route-segment-config#dynamic

Use force-static and your page will return right headers for bf.

[nikolayemrikh]

Hm, no. My app is not static, so can't be used

[nikitafloy]

Hm, no. My app is not static, so can't be used

yes, thats why you got no-cache. Because your data might to change.

[SalahAdDin]

Hm, no. My app is not static, so can't be used

yes, thats why you got no-cache. Because your data might to change.

when to use cache then?

[finfin]

for static contents, contents that only change at build time

https://nextjs.org/docs/app/building-your-application/caching#generatestaticparams

[ahmed-fawzy99]

Same here. Did anyone a solution for this?

[liunice]

Same here!

[fingertips18]

Same here!

Pages that use WebLocks are not currently eligible for back/forward cache.

After some digging I found the culprit, it’s coming from Clerk — the auth library.

Specifically, Clerk is using navigator.locks to coordinate session token refresh across tabs (to avoid race conditions).

🧨 This Is Why Back/Forward Cache (bfcache) Is Blocked
Clerk uses WebLocks for refreshSessionToken, every page that initializes Clerk is ineligible for bfcache. This matches the Lighthouse warning:

❌ "Pages that use WebLocks are not currently eligible for back/forward cache."

🔍 Where It's Coming From
Likely somewhere in my app, I'm importing Clerk:

import { ClerkProvider } from '@clerk/nextjs';

Or you’re using:

• <UserButton />
• <SignIn />
• useUser()
• useAuth()

✅ Things To Do?

1. Avoid initializing Clerk on pages where you want bfcache

• If your landing page doesn't need auth context, you can delay loading Clerk:
  Example: Only load Clerk on pages that need it

// layout.tsx (App Router)
export const metadata = { ... };

export default function RootLayout({ children }: { children: ReactNode }) {
  const pathname = usePathname();

  const shouldLoadClerk = pathname.startsWith('/dashboard') || pathname.startsWith('/profile');

  return (
    <html>
      <body>
        {shouldLoadClerk ? (
          <ClerkProvider>
            {children}
          </ClerkProvider>
        ) : (
          children
        )}
      </body>
    </html>
  );
}

2. No Choice, File or track an issue with Clerk
   Clerk is the one calling navigator.locks, and they should either:
   Provide a way to opt out of WebLocks
   Or use a fallback coordination strategy (like BroadcastChannel or localStorage locking)