Capturing Internet Speed in Power Apps: Implementing Offline Mode in Power Apps for Low Internet Speeds

(0) Share

Report

Posted on by VeeraPowerBIDev

Hello Power Apps Community,

I hope you're all having a productive day!

I'm currently working on optimizing user experience in my Power Apps application, and I'm seeking advice on a specific feature: handling low internet speeds. My goal is to not only detect internet speeds within the app but also suggest switching to an offline mode if the speed falls below a certain threshold, such as 100kbps. This would ensure smoother functionality and uninterrupted access to critical features, even in challenging network conditions.

If anyone has insights, suggestions, or experience in implementing offline modes or managing internet speed thresholds within Power Apps, I would greatly appreciate your expertise.

Thank you for your valuable input and support!

All responses (3)

Answers (0)

cchannon 4,702 Super User 2025 Season 1 on at

Like (0)

Report

Re: Capturing Internet Speed in Power Apps: Implementing Offline Mode in Power Apps for Low Internet Speeds

Yeah, you can definitely use other datasources; SharePoint would be fine if that's what the rest of your app is running on. But rather than testing for a defined interval, I would test a set number of small-chunk runs and average the time: i.e. download the same 1Mb file 5 times in a row and average the times.
VeeraPowerBIDev 12 on at

Like (0)

Report

Re: Capturing Internet Speed in Power Apps: Implementing Offline Mode in Power Apps for Low Internet Speeds

Hi @cchannon ,

Thank you so much for taking the time to respond. I truly appreciate it.

I wanted to ask if it would be feasible to use SharePoint as a data source.

I want to Save the Internet Speed for, let's say, about 30 seconds on average with a click of the Save button.
cchannon 4,702 Super User 2025 Season 1 on at

Like (0)

Report
Re: Capturing Internet Speed in Power Apps: Implementing Offline Mode in Power Apps for Low Internet Speeds

That is a really cool idea! I can imagine it being especially useful in mobile / field service use cases where offline mode is already part of the pattern and you're just trying to be more selective about when to go online.

I've never built something like this before, but here are my initial thoughts, maybe they'll be helpful:

Some basic technical considerations:

The most relevant speed, I assume, is download speed so you will want a server-side component from which you can download a fixed-size packet and benchmark the load time.

You want an accurate benchmark, so ideally the packet is coming from the same server infrastructure as your app (i.e. Dataverse, as opposed to some other cloud storage location)

Bandwidth (especially on mobile networks) is highly variable from second to second, so whatever speed monitoring solution you want to use should probably be averaging speeds in chunks over some period of time

Some functional considerations:

Human operators should have ultimate control; the ability to say "test now because I just went outside and the connection should be better now" or "use online anyway: I know the speed is bad and I don't care."

Whatever testing you're doing on performance will impact performance and will be impacted by app usage so you would need to be very careful about when you are speed testing and probably lock the app somehow so that you aren't accidentally creating a scenario where the users think the app is slower than it really is

To me, those functional considerations are the really important ones here. While an automated, background bandwidth monitoring capability is something so cool I would LOVE to build it, I think it might not be the right answer to your situation. Rather, it seems like what you want is a simple Connection Speed Test button that downloads a 1Mb file from Dataverse and then gives the user a score from 1 - 10 or something, then gives them two buttons; Go Offline or Sync with Cloud, something like this:

That would give your users the ability to work around these low-speed scenarios, but only manually. Which is less cool, of course, but it would be more intuitive to the users and would avoid creating a scenario where you're accidentally degrading app performance and making the problem worse.