Google Chrome detects any Babylon.js page as using WebXR, and therefore is not eligible for back/forward cache.
Test page: Babylon Template
Test method: Тестировать обратный/прямой кеш | DevTools | Chrome for Developers
Is there anything to do?
I am not using any XR related features, but It seems like the final .js file always has references to WebXR
The babylon UMD version includes all of our classes, including WebXR. However, nowhere in the code does a reference to WebXR exists, other than the fact that we have references to XR objects and classes. So I am not 100% sure how the webxr detection works here. If any page that has a reference to window.xruses XR, then there is little we can do about it for our UMD version.
I’ll anyhow dig in a bit more, making sure we are not running any XR code as side effects.
A propper solution for you would be to use the es6 package instead of UMD, bundle your own application, and make sure webxr is not imported and not included in your final bundle.
I am using Vite to build my project, using Babylon ES6 modules. Same thing.
In a clean project with nothing else than
import { Engine } from "@babylonjs/core";
const canvas = document.querySelector("canvas");
const engine = new Engine(canvas, true);
I get 4000kb js code, including 500kb XR.
Full analysis: Vite Bundle Visualizer
Somehow I need to shake that tree even harder 
Don’t import directly from @babylonjs/core. You will need to import from the correct file directly to get tree shaking working correctly - Babylon.js ES6 support with Tree Shaking | Babylon.js Documentation (babylonjs.com)
Thanks! It didn’t solve back/forward cache, but solved my tree shaking issue.
I think its due to xrCompatible parameter being sent to canvas.getContext()
canvas.getContext("webgl2", { "xrCompatible": false})
vs
canvas.getContext("webgl2", { "xrCompatible": true})
Yup, Solved:
new Engine(canvas, true, { xrCompatible: false })
Almost there…
back/forward cache fails whenever I use ScreenshotTools.CreateScreenshot
CreateScreenshot uses DumpTools which creates a new instance of ThinEngine which has options.xrCompatible enabled by default
We can try changing that, of course. There used to be a need to set it to true when making the context, but there should be a way around it. I’ll investigate and let you know.
I would appreciate it if some community members tested the webxr demos in the snapshot - Babylon.js Playground , because I’m traveling currently and don’t have a device. Thanks in advance!