Slightly improve perceived performance on EventHomepage

[jakob-info]

In reference to #525.
The app uses a white screen called the ssr-loader to hide the page until it finished loading it. The user can customize tha body background-color of the event homepage.
Every page starts white while the browser downloads the html and the render blocking css files. After that the ssr-loader can be displayed. which is also white. The user does not see any progess until all js is loaded and the ssr-loader gets removed. The new change introduce an intermediate step. The page changes from white to the body background-color. If we humans see progress like a progress bar or the background-color change, the waiting time feels shorter.

This does not improves the measured performance. Ideally the page would be entirely server-side rendered, no javascript would download more css and no ssr-loader would be used.

It uses a simple css varaible with white as a fallback if the variable is not set.

Checklist

• I have read the contributing guidelines.
• My code is of good quality and follows the coding standards of the project.
• I have tested my changes, and they work as expected.

Thank you for your contribution! 🎉

[daveearley]

Thanks for this! There’s one issue with this approach: when a user has set a background image for their event, the colored SSR loader appears first, and then the image loads. This creates a jarring transition if the color doesn't match the background image.

The SSR loader was originally a stopgap. I ran into issues with injecting Mantine UI styles into the during SSR - the flicker happens because Mantine inserts styles client-side.