I don't think we have a lot of SharePoint users, yucky ;).

But in general. When are these complaints of slowness? Is it on a super basic form with 5 fields with 1 table? Or is it on forms based on queries? Or forms with calculations? Or forms with lots of combo boxes/lookups? These would be the first spot I'd look for trying to improve speed.

You may have already done this but in case you haven't, do a search on Google for "Why is SharePoint Online So Slow" and you will see a lot of answers to your question.

Hi Barbara is the use of SharePoint something mandated upon you from the company you work with? If you have an option, SQL Server is a far superior solution. I have migrated so far two customers from SharePoint back-ends to SQL Server because of all the issues they had with SharePoint.

I'm in a situation where I have to use SharePoint for some tables, and it can be quite painful to make it work, especially compared to working with SQL Server. It essentially broke my database in the sense that it was so slow it was unusable. Probably the best thing about SharePoint that I have found so far is being able to integrate Access with other online Microsoft workflows that can use Sharepoint (e.g., an online forms, syncing a task table with a team's tasks on Planner, etc.). So I'm learning to appreciate it.
What saved my database though was temp tables. Instead of Access reading from SharePoint, I download the SharePoint table data and store the data in local tables. If I need to edit data, then I switch to an edit form that only reads one record directly from SharePoint - so no noticeable delay.
After I make an edit, I have to download the table again, which sometimes works great, but sometimes SharePoint locks that table after an edit. So I have some complex tricks to make it work, otherwise a simple button to 're-sync' the table can work, kind of like having a button to requery a table. I'm sorry, I don't know of any simpler solutions; this is all 'developer' level stuff.
Here are some videos that helped me:
Sluggish forms, Tech Help: https://599cd.com/blog/display-article.asp?ID=3392
Dynamic Temp Tables, Developer 49: https://599cd.com/blog/display-article.asp?ID=3486

Dynamic temporary tables is the way to go. We sometimes have to do that even with SQL Server when it is hosted online. We download the troublesome tables to temporary tables at login. Whenever there is an update to the permanent table, we trigger a reload of the temporary table.

My comment won't help much but +1 for Shami. I have been using Sharepoint for a long time. First on premise, then online.
I have moved everything to local SQL server and created Access frontends. My sharepoint online is still alive but I barely use it.
No more
- network related issues
- weird bugs
- browser compatibility issues
- unwanted changes
- restrictions
If it is sharepoint online I would take a look at restrictions (I am sorry but currently I dont know where to look for but I am pretty sure You can google it out). I have experienced query limits in terms of data size and queries per time which made some of my ideas non workable. Finding shortcuts and workarounds was really not fun at all. None of that applied to SQL server - You do what You want to do and how You want to do it.

Barbara thanks for the replies - sharepoint is mandated :( we moved from SQL server

Moving from SQL Server to SharePoint? Talk about a downgrade. :/

Since SharePoint is nonnegotiable in your case, you're definitely facing the typical performance limitations of that backend. As Michael suggested, using temporary local tables to pull down SharePoint data upon opening your database - and then editing single records directly from SharePoint - can drastically reduce lag, even though it's a developerlevel workaround. Also, as Sami pointed out, you can trigger a reload of those temp tables whenever permanent tables are updated to keep everything in sync.

Thanks - they wanted a cloud server that wasn't as costly as azure with all our files also on sharepoint it was the solution mgmt and IT chose.

I think the issue came from using Azure, as it's metered, meaning you're paying per minute. A more cost-effective option would be a web hosting service like WinHost, where you can get SQL Server online for under $10 a month. That's how I ran my website for years before switching to a dedicated server, but for your needs, that level of hosting is probably more than enough.

While SharePoint works great for file storage, it's not the best choice for running a database. The reason I created a SharePoint seminar was because I had students in situations where their company was using SharePoint and couldn't switch to a different solution. But for a proper database setup, SQL Server is definitely the better choice.