WebXR Layers offers a more efficient way of drawing immersive content. In addition to support for native color and depth textures and texture arrays, it also provides support for different layer types that are managed by the system compositor (as opposed to javascript).
Performance: Layers are presented at the frame rate of the compositor but can be updated at a lower rate in the browser. The compositor can reproject layers at high refresh while the browser just needs to draw pixels when they need to change (instead of when the user moves) Legibility / visual fidelity: In a typical WebXR session, the pixels are resampled twice. This greatly affects text legibility by drawing into a layers, resampling only happens once. Power consumption / battery life: Because the browser only has to render the pixels that changed and can rely on the compositor to draw cubemaps and equirects, far less javascript and gl commands need to run in the browser which increases the system's battery life. Latency: Since the compositor always has the latest pose data and runs at very high system priority, the scene will “stick” to the right location which improves the experience and lowers user fatigue. A good example where this all comes to gether is 360 videos. With regular WebXR, a large framework and very careful coding is needed to do the reprojection. Typically, the resolution and framerates of the video is lowered so the experience can fit in the cpu/memory budget of the device. The efficiency gains of layers should enable such video to reach parity quality with what is possible in native apps on XR devices.
Samples: https://immersive-web.github.io/webxr-samples/layers-samples
Explainers: https://github.com/immersive-web/layers/blob/master/explainer.md