Start with the interrupted task
Ask the colleague what happened when they returned to the tab: did the page reload, did the application request a new sign-in, or did an action fail? Record the sequence and the task they were trying to complete. Our recommendation is to keep these observations separate instead of treating every interruption as the same browser fault.
Google explains that Chrome Memory Saver deactivates unused tabs and reloads them when accessed again. That is a possible explanation to investigate, not a diagnosis of every reload. Work with the support owner to check the actual configuration and reproduce the reported behaviour using harmless test data.
Make one controlled comparison
Agree a representative task with the application owner. Record the starting browser configuration and the point at which the user leaves and returns to the tab. If a setting change is authorised, change one relevant variable and repeat the same task. Avoid making a fleet-wide adjustment on the strength of one interrupted session.
For a fictional service team, a colleague reports that a reference page reloads when they return from another task. Support reproduces the sequence with non-sensitive material and checks whether an approved configuration change affects it. They record the result rather than promising that a browser setting will cure every application problem.
Keep any exception narrow
Google documents an Always keep these sites active list to prevent selected sites being deactivated. If your support team considers an exception appropriate, ask it to choose the intended site carefully and confirm the change is allowed under your organisation’s browser management arrangements.
Give the exception a business reason, an owner and a review point. Do not turn a single application investigation into a broad promise to keep every tab active. If the original symptom continues, retain the observation and investigate other causes through the application’s support process rather than adding more exclusions without evidence.
Close the ticket with an observable outcome
Ask the colleague to repeat the original task under the agreed configuration. Record whether the interruption still occurs and whether the workflow is usable. If the test fails, leave a named next action; a changed setting alone is not a completed support outcome.
Keep the record proportionate: the application, relevant configuration, test sequence and result are more useful than screenshots containing live customer data. This is an editorial troubleshooting exercise, not a benchmark or a guarantee of performance improvements. Review the current vendor instructions before making changes and preserve centrally managed controls.
Sources
Practical suggestions in this article are editorial recommendations. The source supports the guidance attributed to it.
- Google Chrome Help · Performance settings ↗
Checked 17 October 2026
Something needs correcting?
Get in touch to explain which claim needs attention and share the supporting source.