Reduce ArcGIS Pro network traffic

Bud

My unit and I.T. have tested new laptops with ArcGIS Pro over VPN (Microsoft Tunnel) for remote work.

We've found that Pro over VPN is too slow, regardless if using home WiFi or plugged directly into a home router. I.T. says the slow performance is due to ArcGIS Pro being very chatty when it comes to network traffic. Related info in an old comment from @ThomasColson here.

We don't have this problem with any other software on VPN, including ArcMap. And we don't have that problem in Pro when working in the office without VPN (corporate WiFi or LAN).

The issue is with Pro and VPN. This means laptops aren't a good option for ArcGIS Pro users. Users who do have existing laptops are currently using ArcMap over VPN without issue. But, since ArcMap is no longer supported, those users will eventually need to return their laptops to I.T. since they won't be useable with Pro/VPN.

So we will be stuck with in-office work (on our desktop PC towers) or remotely connecting to those computers via VMware/home computers. But laptops/VPNs won't be an option (laptops would be especially handy for in-person group meetings using Pro).

It wouldn't make sense to have laptops that would stay at our office desks (or used in in-office meetings) but can't be used at home with Pro and VPN. In that case, we'd be better off keeping our desktop PC towers with higher performance specs, since Pro has such high computer hardware requirements.

Idea:

This would all be solved if we could use Pro on laptops via VPN. Could Pro be enhanced so that network calls are reduced, making Pro/VPN feasible?

RTPL_AU

As you state, ArcGIS Desktop (ArcMap & Pro) generates a lot of network traffic; refreshing data in a map whenever you do anything, checking printer settings, and more. The killer aspect is latency (more so for Pro as ArcMap in my experience). No matter what speed you run the link at, if your latency is less than good LAN speed your users will suffer. This cannot change due to the software and storage design philosophy of ArcGIS (which is pretty good in my opinion).

I find it interesting that you say ArcMap over VPN is acceptable. Have you ever used ArcMap on a local 10GBE network with good storage behind it?  🙂  Joking just a bit.  I've encountered many people who have never worked on a decent computer, network, and server setup thus have no idea what proper performance should be like. 
If you want your users to be anywhere near productive and happy, keep the software installed as close to the data as you can. The pretty picture on the screen should do the travelling.

For a proper widely distributed remote work scenario you want to look at virtual desktops - Pro support a variety of methods and vendors. Depending on your org and data size you can look at a fully hosted (Esri documented and supported) AWS or Azure scenario where you place the data containers (SQL and/or file shares) and the desktops in the cloud and the user accesses the desktop or app via Appstream or similar from anything with a screen. Done well, the cost should be less than a decently deployed, maintained, and backed-up local metal & rust solution. Some countries' local Esri reps offer a fully managed solution for this so you can take the entire stack off IT's hands. It's been a thing for a long time so not a 'bleeding edge, make IT run away' idea.

You mention VMWare........ Taking the GIS stack off IT may help their budget while they try to figure out how to pay Broadcom at the next renewal.

If you have no alternative you have to control & limit a few things unless you have savvy users. (concepts below may be in place but simplistically stated for anyone else wandering here from a related search)

• Optimised data structure - small datasets, simple geometry, etc
• Efficient storage - well optimised SMB, SQL storage, etc. A QNAP in the corner is not it. wiki.gis.com System Design Principles used to be a solid resource to give IT.
• Do as much as possible via web services (AGOL or Portal) and have the office-bound users do the heavy lifting. Remote workers can check data out & in to edit but needs to be managed well.
  Pick the best traffic policies to ensure web services are accessed via the fastest link for the user (direct to internet or via VPN). Are you paying for users' internet and do they all have decent broadband?
• No printers on their local computers and no remote printer mappings (printers = camel's straw) but as I do not use paper a lot these days there may be black magic that a good IT tech can apply. Save maps to PDF and give to someone else to print 🙂
• Get decent laptops or PCs for remote workers - Pro's UI is laggy at the best of times before you even open a dataset so by minimising that irritation your users may accept some data hiccups.
• Change Pro settings for display etc to match device hardware, set appropriate default databases & toolboxes, etc. 
• Pick the best tool for the job i.e. don't waste time in Pro if a GDAL script is faster. Use QGIS to process some things that take 1 step vs 2 in Pro.  Post-process a kml (some people still need them) in Google Earth Pro rather than messing around in Pro to get the groupings right. Use Notebooks in Pro. Give people a common custom Quick Access Toolbar with tools they use most often so they don't have to navigate the dynamic ribbon all the time.

It is a balance between user happiness, their employment cost, device cost, and productivity.  If your staff are cheap then wasting their time isn't expensive. Expensive / good staff will absorb the increased cost of a decent solution very quickly with improved productivity.

Stating the obvious here but based on Esri's Pro 'be less productive through bad UI design decisions' central goals, it is more front of mind now that Map is getting phased out.