Previous page shadow when loading

[Pietro]

I am working on a Streamlit web application consisting of multiple complex pages. During every redirection, the experienced ui workflow is the following:

1- Component (often a button) redirecting to a new page is triggered.
2- Actual page becomes blurred and the new page starts rendering from the top.
3- Only after the new page is rendered completely the blurred previous page disappears.

The heavier the new page the longer it is required for rendering and the more this behaviour is annoying. It is not a functional bug preventing the correct execution of logic but it is very detrimental to the UI experience and smoothness of the application.

This issue is partially covered in this ticket: Page refresh is slow and ugly. However, no effective solution/explanation is provided.

Would be great to understand what is the reason for this and to have either:

• A solution using Streamlit
• An effective workaround (something simple)
• A feature in the roadmap that addresses this issue

[dataprofessor]

Hi @Pietro

Thanks for your feedback, this sounds like a feature request on the page reload, perhaps you’d like to open a GitHub issue (Issues · streamlit/streamlit · GitHub).

If the app is deployed to Streamlit Community Cloud and the app is resource intensive, it may have reached its resource limit (e.g. 1 GB RAM). In such case, deploying to a 3rd party with a higher-resource compute server (Deploy Streamlit apps - Streamlit Docs) would be the next step so as to provide the necessary resource that the app requires.

There are ways on counteracting the resource limits as discussed in the following blog:

Common app problems: Resource limits

Hope this helps!

[Pietro]

Thank you @dataprofessor for the fast reply, awesome support!

A few points referring to the direction you provide:

First, I am actually not experiencing any disruption in the workflow (e.g. “Argh” page suggesting resource limit overflow), would this suggest that, indeed, the limit has not been reached?

Second, I was wondering, even if deploying the application to a more capable container (e.g. Docker) would result in a faster application, the UI experience would remain the same with a reduced time in which the system is in status 2 (from above “2- Actual page becomes blurred and the new page starts rendering from the top”). Am I wrong?

Considering this I want to drive the request for this topic to a proposal for supporting an alternative smoother UI workflow.

Just an idea, would be great to have something like:

1- Component (often a button) redirecting to a new page is triggered.
2- The page is destroyed (and disappears)
3- White page / Loader is shown
4- New page is presented as soon as it is rendered completely.

As alternative, another workflow that could actually be easier would be:

1- Component (often a button) redirecting to a new page is triggered.
2- The page is destroyed (and disappears)
3- New page is rendered on the go, with components appearing as they are “ready”

The focus of this post is indeed to address the page shadow that is experienced in navigating multi pages Streamlit applications.

Thanks for the support, very curious to know your and other opinions on this!

[dataprofessor]

Hi,

For me, switching from one page to the next in a multi-page app did not take long to load (rather instantaneous).

Do you have a link to your app that is displaying the issue faced? With some tweak and optimizations, the app may run like new.

As mentioned in the previous post, there are ways to optimize the app so that the app runs quicker and that there is no need for the page to reload (if using Session State this usually resolves most of the app rerun issues). Great examples on using Session State is provided here: Add statefulness to apps - Streamlit Docs

[Goyo]

I have seen apps with heavy pages (for several definitions of “heavy”) that don’t show this issue. So I don’t think it is just a matter of being heavy, but instead it is something more specific to your application. What it might be exactly is anyone’s guess.