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-kapsys]

@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.