Vaadin Flow session memory keeps a low-traffic app on an oversized instance — is passivation viable?

A low-traffic Vaadin Flow application (assume Vaadin 24 on Spring Boot) costs more to host than its page-view count suggests. Because Flow holds each user's UI component tree in server memory tied to the HTTP session, instance sizing is driven by concurrent sessions and session timeout, not request volume. The goal is to move this workload to a smaller instance without breaking active user sessions.

The documented lever is session serialization/passivation: if the UI state is serializable, a servlet container or Spring Session (e.g., Redis or JDBC backend) can persist idle sessions externally, so memory only needs to cover genuinely active sessions. The uncertainty is that Vaadin views must not hold non-serializable fields (injected services, streams, lambdas capturing non-serializable state), and this application's views have not been audited. Silent failures here would force sessions to stay in memory anyway.

Secondary options under consideration: shortening the session timeout (at the risk of logging users out mid-task) and confirming that server push is not keeping idle WebSocket connections alive unnecessarily.

1. What is a reliable way to verify that all views and their fields are serializable before enabling passivation, beyond waiting for NotSerializableException at runtime?
2. How should heap per session be measured under realistic concurrency to size the smaller instance?
3. Does Spring Session passivation interact with Vaadin's session-timeout and heartbeat settings in a way that changes effective session lifetime?